Ugh. It's nice that Steve is reaching down to his audience, but it would be nice for the audience to step out of their muddy sandbox once in a while.
Ugh. It's nice that Steve is reaching down to his audience, but it would be nice for the audience to step out of their muddy sandbox once in a while.
I also think teaching this using mathematical notation would be a mistake. People only learn things when they relate in part to something they already know. The original lambda calculus syntax is not only abstract, it was invented before programmable computers existed.
Unless someone is either already comfortable with mathematical notation or has a background in a programming language with similar concepts (Lisp, Haskell, etc.), it's going to be a stretch to teach someone the lambda calculus -- really teach them -- unless it's framed in terms of a language they already know.
JavaScript is a great language to use for this because it has C-like syntax, which virtually all programmers understand, and first-class functions. You could use Ruby, too, but the syntax would be even more opaque.
Here's someone building the lambda calculus using only Procs in Ruby: http://codon.com/programming-with-nothing
Then using Ruby 1.9's "stabbby lambda syntax" you get
-> x { -> f { f[x] } }
Not sure that's any better. The key is explaining it in terms of something the ready already understands well.If they're not already thinking mathematically a straight-forward introduction to the lambda calculus would be ineffective.
I agree that the terser notation is better if you're just considering the mathematics in isolation. However, I also think that the true power of this kind of mathematics isn't made evident to people until you actually add some integers and make some lists.... from "nothing"... in a language you already know.
It's the same reason he doesn't use lisp or haskell, which are, obviously, vastly more appropriate. The idea is to illustrate something using something people have readily at hand. Once you have the concrete representation of the idea, you can work backwards to whatever notation you desire and forwards again using that notation, understanding that, yes, it has a basis in reality.
It's the same reason people draw 2d graphs to represent machine learning concepts instead of solely relying upon linear algebra notation. Humans are limited in that way: we have to gain some kind of appropriate intuition, and then we can work with the abstractions after that. No one is going to argue that js is an appropriate way to develop the mathematics -- it's just a way to make it more concrete for people, that's all.
function(x) {return function(f) {return f(x);};}
can be considered easier to comprehend than λx. λf. f x (λx. (λf. f)) x
(λx. (λf. f) x)
(λx. (λf. f x))
The lambda calculus notation is weird. Using "." to separate parameter and body is unusual. The scope of the body isn't obvious.JS is painfully verbose, but it's a verbose syntax many people have already put the time in to internalize.
x => f => f(x)
http://wiki.ecmascript.org/doku.php?id=harmony:arrow_functio...I prefer this stuff in python. Less syntax, more clear. But then, is the same thing: You imagine your (math) syntax is better, I think is python, somebody will complain why not haskell, but js is more practical. Or, is just the one the OP like. That is probably the only and best reason.
Agreed, but it doesn't take more than a couple of sentences to describe the entire syntax of the λ-calculus. It's not hard to pick it up even if you've never encountered it before.
Contrast that with JavaScript, where even as someone who has written my fair share of it, my eyes tend to glaze over when they hit a string of `});}))());};`. Yet people happily write that sort of thing, then turn around and complain about nested parentheses in Lisp!