Lambda The Ultimate refers to the idea that the lambdas of lambda-calculus can effectively implement every builtin concept in every programming language, past, present, and future. Classes, Modules, Packages, Objects, Methods, Control-Flow, Data Structures, Macros, Continuations, Coroutines, Generators, List Comprehensions, Streams, and so on.
As it happens, that ultimate nature includes standing for an Anonymous Function. But lambdas are not, at their core, limited to just anonymous functions. They get taught that way, but the essence of lambda goes far deeper than mathematical functions without names. In other words, I take issue with:
I understand what lambda means, the idea of an anonymous function is
both simple and powerful, but I fail to understand what "the ultimate"
means in this context.
As a practical matter, the use of lambdas as syntactic abstractions ('macros'), which are not call-by-value/applicative (which mathematical functions are), is absolutely crucial to buying into the idea that lambdas really can serve as the core of every programming language processing system.
For Theory: There is an interesting connection with Bertrand Russell's paradox and the Axioms of Comprehension (and Extension) in naive set theory. A lambda is to functions what set-builder notation is to sets: lambdas are function-builder notation. There is an important difference, usually ignored, between (lambda (x) (* x x)) and what that evaluates to (the function that squares). If one fails to distinguish between the two in general, that is, between the notation and the denotation (a mistake that Church and Frege both made) then one runs afoul of paradoxes. For sets and Frege, it is Bertrand Russell's Barber of Seville that illustrates the error; for functions and Church, it is Alan Turing's Halting Oracle.
Note that the paradoxes are good, practical, things. We want EVAL to be expressible, and we want lambdas to mean more than just functions. That assuming the opposite leads to contradiction is the desirable result; it serves as a nice sanity test: lambdas can hardly be ultimate if they only express mere functions.
Racket (formerly PLT Scheme) continues to prosecute the idea that practical programming languages really can be built, from the ground up, on 'just lambda'.
Kernel, by Shutt, argues that lambda is not really the ultimate abstraction. He argues there is one concept more primitive still (for Greek, dubbed vau) which was known to Sussman as FEXPR.
Felleisin and company (for Racket) get much of the power of Shutt's vau by using the concept of phases, or metalevels, which approximately means running the source code through multiple stages of translation (as with preprocessing C, but using the same language at each 'step', and the 'steps' are not actually entirely distinct in time). (So, they argue that a lambda in a higher phase approximates a vau well enough.) In fact, they argue that phases are better than FEXPRs, precisely for being more limited; in short, "FEXPRs are too powerful" (see Wand's work, which Shutt argues against).
Brian Smith's 3-Lisp, "Procedural reflection in programming languages", attempts a rigorous reformulation of the theory of LISP-like languages along the lines of sharply distinguishing notations (symbols/language/programs) from denotations (things/referrents/values/results). http://dspace.mit.edu/handle/1721.1/15961
Mitchell Wand's "The Theory of FEXPRs is Trivial" sends more nails into the (temporary?) coffin that Kent Pittman wrought for FEXPRs (who, like Felleisen, argues against FEXPRs as making compilation too hard).
Paul Graham argues with strength and at length in "On Lisp" that the real power is lambdas as transformers of syntax (macros), rather than as transformers of values (mathematical functions). Plotkin's development of the applicative lambda-calculus could be taken as somewhat contrasting, because Plotkin limits Church's calculus to its call-by-value/applicative subset. Of course, handling the applicative part efficiently is very important, so it is important to develop theory specialized to that use of lambda. (Plotkin and Graham do not argue against one another.)
In fact, in general, the notion of Lambda as Ultimate is just one such twist on the eternal debate between efficiency and expressiveness; it is the position that lambda is the ultimate tool for expressiveness, and, given enough study, will ultimately prove to be the ultimate tool for efficiency as well. In other words, we can, if we want to, see the future of programming languages as nothing more and nothing less than the study of how to efficiently implement all of the practically relevant fragments of the lambda calculus.
Landin's "The Next 700 Programming Languages", http://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf, is an accessible reference that contributes to the development of that concept that Lambda is Ultimate.
