Timeline for Lambda calculus didn't seem abstract. And I can't see the point of it
Current License: CC BY-SA 3.0
9 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Dec 3, 2016 at 12:18 | comment | added | JDG | "However, this interesting historical discussion doesn't belong to the comment section." Where does it belong? I think it's directly relevant to answering the question of what significant advantages does λCalc bring to programming? 1. Functions that create functions (though we disagree on that point as being directly due to λCalc). 2. Safety (though I feel that advantage belongs to strong typing). 3. Immutability (but I got this from middle school math class discussions on functions). 4. . . . ? | |
Dec 3, 2016 at 12:14 | comment | added | JDG | Eval may have come from list, but I remember when I first wrote that type of program, I didn't know what eval was. I googled how to execute strings in python. The fact that the idea was formalized in λCalc (or in its CS descendents) as partial functions doesn't mean λCalc was relevant to the inclusion of eval(). If a teenager can independently come up with the idea in a moment of laziness, it may be a brilliant idea, but . . . it's a little surprising if that's the impressive power of a λCalc. There's got to be more to it. | |
Dec 3, 2016 at 12:09 | comment | added | Yuval Filmus | On the contrary, we know that its eval capability was influenced by earlier programming languages. Eval is related to the universal Turing machine. Nevertheless, I don't think it is just by chance that a language like LISP supported metaprogramming whereas procedural languages didn't. However, this interesting historical discussion doesn't belong to the comment section, so I suggest we stop it at this point. | |
Dec 3, 2016 at 12:06 | comment | added | JDG | Yes, python supports functional progamming---but I'm not sure it's eval() ability was inspired by λCalc---you don't λCalc to think: I want to auto-generate code that I can eval later. That's like saying λCalc is required to think, "I'll tell Miranda to use her best judgement on how to run her department"---in other words getting a function to generate its own functions. You don't need λCalc to think about delegating high-level tasks. If you want to talk about drawing inspiration from λCalc, it's more appropriate point to lambda functions, comprehensions, etc. | |
Dec 3, 2016 at 12:04 | comment | added | Yuval Filmus | Eval originated in LISP, which was strongly influenced by the lambda calculus. Something like this isn't possible in FORTRAN, C, COBOL, and many other programming languages. | |
Dec 3, 2016 at 11:13 | comment | added | Yuval Filmus | Python supports functional programming. The first programming languages didn't. If you had programmed in FORTRAN, you would not have created programs with text containing functions that you later evaluated. Without even noticing it, you made use of the capabilities provided by ideas from the lambda calculus. | |
Dec 3, 2016 at 10:51 | comment | added | JDG | this was before I knew much of anything. I just thought code was annoying to type over and over and that programming should help me auto generate functionality, including functions themselves. | |
Dec 3, 2016 at 10:50 | comment | added | JDG | "I suspect that one of the reasons that you are not impressed with lambda calculus" Therin lies the question I’m asking: What does lambda calculus do for us? In other words, when we don’t use lambda calculus, what happens. When we do use lambda calculus, what do we gain? If lambda calculus was the first time that people thought, what if functions could themselves create functions, then is that impressive? Among my initial python programs made text containing functions that I later evaluated, much like delegating the task of decision making to anther person. Seems obvious? | |
Dec 3, 2016 at 10:22 | history | answered | Yuval Filmus | CC BY-SA 3.0 |