Lambda the Ultimate

I, on the other hand, find it bothersome. There's no need to get pedantic here.

They are using the new query sub-language (LINQ) to generate SQL and send it to databases. When a method takes a lambda expression as an argument, it has the choice of either getting the value as an anonymous method (compiled code) or as an abstract syntax tree. If it takes an AST, it can interpret the expression in some nonstandard way, such as using three-valued logic, which is likely what happens when it's translated to SQL.

It seems to me that "the mainstream languages" community is mainly driven by corporate needs (taking into account the context of a lot of not so good programmers, not really willing to change their mindset or learn new/different things) and maybe consider things from a more "practical" point of view, that is taking into account the inertia of human factors.

However, it seems like thanks to scripting languages (like Ruby or Python), people start to realize that there are other ways to write programs, and I think this surely drives some people to the more academic functional community.

Maybe it's just a friction due to a transition perdiod. I would bet that 10 years ago, few people knew as many PLs as today.

"Whatever" is sometimes used as a conversational filler, but the phrase "lambda expressions or lambda calculus or whatever" sounds rather uncertain/uninformed to me. It certainly doesn't sound like "We got this cool feature called lambda expressions". That whole paragraph could have carried a lot more enthusiasm about them and type inference.

Guido trying to remove Lambdas from Python concerns me more than a statement that says C# is going in that direction - even if the explanation of Lambdas is rather peculiar.

Anders likely has people he works with that can fully comprehend (and probably even explain) lambdas. Anders is probably more manager than theoretician at this point, and he was hired for his practical implementation skills. The fact that C# is willing to go down this road makes me more comfortable than with the direction of Java, where the JVM and it's bytecodes have become locked and any new language designs (such as Generics) must work within that constraint. (Inner classes are a poor substitute for lambdas).

Python being mainstream and having lambdas doesn't still make lambdas mainstream. So the question remains: do mainstream programmers use lambdas?

It also turns out that they are being used pretty widely. I can't say exactly how widely, but a simple google search returns a lot of python sources with lambda's.

As GvR has famously pointed out, anonymous functions are exact equivalents to lambda. So the use of the word "lambda" is pretty well irrelevant.

Do mainstream programmers pass functions around? I think it's pretty common; I've seen few large C/C++ projects which do not at some point feel the need to pass a pointer to a function, or a pointer to a member function, usually coupled (in the case of C) with a void* "baton".

But that's not the issue either: the real issue is closures, a word completely missing from the rather disappointing interview, but which would be almost the only thing (aside from syntactic convenience) which transcends the "passing [of] code as parameters" as epitomized by C function pointers. (See Henry Baker's 1993 paper Iterators: Signs of Weakness in Object-Oriented Languages for why it's important; as usual, he says it much better than I could.)

(It actually astounds me that a serious interviewer could let someone get away with saying So really, the thing expressively that has been missing in programming languages is the ability to pass code as parameters. The word "sycophantic" sprung to my lips as I read it.)

Looking at the docs, It would appear that C# handles closed outer variables by creating a new binding initialized to a copy of the value of the outer variable at the moment of instantiating the anonymous method (or delegate), which is, I believe, similar to Python, but rather different from Scheme or (say) Lua. I suppose that some people prefer that kind of closure.

As GvR has famously pointed out, anonymous functions are exact equivalents to lambda. So the use of the word "lambda" is pretty well irrelevant.

...

But that's not the issue either: the real issue is closures, a word completely missing from the rather disappointing interview, but which would be almost the only thing (aside from syntactic convenience) which transcends the "passing [of] code as parameters" as epitomized by C function pointers.

Just a nitpick, sorry: the concepts of lexical closure and lexically nested scopes are implicit in the term "lambda", so the above seems a little contradictory to me. Mentioning the word "closure" ought to be redundant when talking about implementing "real" lambda-calculus-derived Lisp/Scheme/Haskell/ML-style lambdas. (Whether it actually is redundant or not depends on whether real lambdas are being implemented.)

Indeed, it ought to be redundant. But since "lambda" was used rather informally in the article, I felt the need to dig into the C# documentation to see if it was for real or not.

I personally think it is not, and that Python got it wrong, too. But since the difference is only apparent in the face of side effects, that might not be a big concern to the FP folk here.

Its a actually quite interesting. You see few people seem to understand exactly how much of a FP ancestery C has. In the begining was a language called CPL (Combined Programing Language) that was an atempt to combine functional and imperative programing. It never had any real succes, mainly becourse it was to hard to impliment. So a simpler language was created: BCPL. As I understand it BCPL had first class function represented as a pointer to the part of the code there the definition of the function began. I don't think this feature got much attention, maybe cause the untyped nature of BCPL didn't have to asign a type to functions (not even at runtime). Somehow this probably survived through B and C.

Quoting from Dennis Ritchie's 1993 HOPL paper on the history of C:

BCPL, B and C differ syntactically in many details, but broadly they are similar. Programs consist of a sequence of global declarations and function (procedure) declarations. Procedures can be nested in BCPL, but may not refer to non-static objects defined in containing procedures. B and C avoid this restriction by imposing a more severe one: no nested procedures at all.

You might find interesting this thread on the PLT Scheme mailing list from 2001, which discusses closures and C. I believe that the paper by Dave Hanson referenced in that thread is to be found here

"an attempt to combine functional and imperative programing'

afaik CPL was an attempt to combine the efforts of Cambridge University and London University - so C(Combined)PL became a more acceptable name than C(Cambridge)PL.


Note: a BCPL implementation is available from Martin Richards website.

...that its most popular descendant is considered one of the canonical imperative languages, although Scala appears to be going back to its roots.

The comment also suggests that it was his design that made the feasible in a mainstram programming language. This ignores the fact that C# is being pushed (hard) by Microsoft as *the* language to program in.

It's much more impressive to see languages like Perl/Python/Ruby/Haskell emerge as programmer favorites without corporate enforcement.

It's much more impressive to see languages like Perl/Python/Ruby/Haskell emerge as programmer favorites without corporate enforcement.

... being pushed by a crowd of fanatics armed with pitchforks -- and I ought to know, I'm practicing daily with my pitchfork.

More seriously, I guess it's an occurrence of Paul Graham's remark about Lisp. No one can seriously believe that Java or C# is the best language of the universe. At most, people can not know that there are better languages, but there is a distinction. On the other hand, Python/Ruby/Haskell/OCaml/Lisp programmers can honestly believe that they are using the best language ever, or at least the best language ever for a particular task.

If I'm not mistaken, Pages 1-3 in Part 2 were also in Part 1. However, is this an interesting comment or what:

And for certain things, you know, dynamically typed languages are more appropriate if you're just going to write a few lines of code, and you don't want to first have to do a bunch of declaring upfront.

And this one:

In many ways, that's why so many people are interested in functional programming languages and why academia has so much energy going into that; there is a whole class of problems that all of a sudden become relevant once you have these capabilities in the programming language.