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.
Encoding integers with lambda is called the curch encoding: http://en.wikipedia.org/wiki/Church_numerals
Functional programming in general is built upon the foundations laid out by him.
Actually the domainname of hackernews (ycombinator) has a lot todo with lambda calculus.
Scott encoding doesn't get much publicity but its perfectly valid and much more intuitive, IMO.
:-)
Lots of useful programs can be written without turing completeness. It can be useful, but only for a limited problem domain.
Including Bitcoin transactions - I learned this from elsewhere on HN today.
I'm not totally sold that objects are a "bigger" language feature than closures, conceptually.
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
If you're too impatient, here's the punchline:
The venerable master Qc Na was walking with his student, Anton. Hoping to
prompt the master into a discussion, Anton said "Master, I have heard that
objects are a very good thing - is this true?" Qc Na looked pityingly at
his student and replied, "Foolish pupil - objects are merely a poor man's
closures."
Chastised, Anton took his leave from his master and returned to his cell,
intent on studying closures. He carefully read the entire "Lambda: The
Ultimate..." series of papers and its cousins, and implemented a small
Scheme interpreter with a closure-based object system. He learned much, and
looked forward to informing his master of his progress.
On his next walk with Qc Na, Anton attempted to impress his master by
saying "Master, I have diligently studied the matter, and now understand
that objects are truly a poor man's closures." Qc Na responded by hitting
Anton with his stick, saying "When will you learn? Closures are a poor man's
object." At that moment, Anton became enlightened.Based on that, I think that closures and objects are probably equivalent in their expressive ability. Could be wrong though, like I said it was a long time ago.
"If you ignore the practical issues of computers like size, weight, cost, heat,
and so on, what do you really need in a programming language?"
One instructionI use blocks in Objective-C and "closures" in Applescript.
to lambda(aStatment)
script intern
say aStatment
end script
end lambda
set a to lambda("applescript…")
set b to lambda("knows how to …")
set c to lambda("make a closure if not a lambda…")
tell a to run
tell b to run
tell c to run