Addressing Misconceptions: Procedures ("lambdas") vs Objects

Randall Maas 5/19/2010 1:25:25 PM

Some time ago I saw a Microsoft video wherein Eric Meijer claimed that object's were more powerful than "lambda's". I was pretty surprised, since it is (or was?) a standard undergraduate homework problem to show their equivalence.

Let's take a step back. First, in computer science "X is more powerful than Y" only when you can do everything in X that you can do in Y (no matter how inconvenient or slow),and you can do stuff in X that you can't do in Y (no matter how inconvenient or slow). Second, a 'lambda' are a reference to a procedure with a closure - that is private memory for each instance of the variable. (I could explain why, despite the heated hyperbole, this is not a lambda function as used in lambda calculus, but that is for another time.)

Eric Meijer's basic argument is that a "lambda" is only one procedure that has access to its set of variables, while an object is a bunch of different procedures that can access the same set of variables. In this manner you could construct a bunch of different operations on those variables, and mix them in interesting ways. (Btw, this is called an abstract algebra, and the variables with the procedures are an algebraic structure). Sounds good - but this is a trap for young players.

Youcan build objects out of these "lambdas." All you need to do is create a procedure that you give the method selector (e.g. the method name, name and call signature, etc.) and it returns a procedure ("lambda") that performs the specified behaviour. Then you can call the procedure with the parameters you like.

Of course, the real world likes a mix of the notations. That kind of lookup is used heavily in dynamic dispatch systems, often implicitly. Indeed, Microsoft's DLR does that with it's DynamicObject.

(This could lead to an interesting discussion in how it is done in Objective-C, JavaScript, Common LISP Object System, and other various systems, or my experiments with such systems, or ideas of what makes a good tradeoff of notation, design structure, and for how long...)