A few years ago I was trying to explain to a Java programmer what closures were and after listening to me, he merely replied “I’d use an object for that”. After he started working with Python, he began to change his mind after encountering Python’s somewhat limited lamba expressions. Once you understand closures, they become an indispensable tool for making code smaller and more flexible, but trying to explain closures to someone is about as daunting as explaining objects to seasoned COBOL programmers.

The Sapir-Whorf hypothesis basically asserts that thought is constrained by language. Some have interpreted this to mean (incorrectly) that we cannot understand ideas that we do not have words for. However, it might be better stated that we have difficulty understanding ideas that we do not have words for. Programming languages support this hypothesis.

My friend did not understand closures because most of his work was with Java, Prolog and C (static variables don’t count). The notion of a function “closing over” its lexical scope was so completely foreign to him that he didn’t understand the utility of closures. His programming languages of choice did not give him the vocabulary to express a particular idea, so he considered that idea uninteresting.

Guido van Rossum takes a similar view regarding multi-statement lambdas and seems to mistakenly conclude that these are merely Rube Goldberg toys. Few self-respecting Ruby or Perl programmers who’s grown used to the flexibility and code simplification that closures provide would agree.

Yesterday, I read a curious Weblog entry by Gilad Bracha, the current maintainer of the Java language specification, about why Java will not have continuations. While he mentions potential security problems and how continuations would be difficult to implement, his primary argument seemed to boil down to “continuation-based Web servers are the main reason we’d have continuations and those are a flash in the pan”.

Frankly, my jaw dropped when I read that. He can’t be serious that the main reason for continuations is a particular breed of Web server, can he? If he simply argued that continuations would be very hard to implement in the Java model, I’d be OK with that, but picking a particular reason for them and then trying to shoot down that reason sounds an awfully lot like a straw man. However, I wonder if the main reason he doesn’t worry too much about continuations is the same reason Tim Bray doesn’t worry about continuations, he doesn’t find them idiomatic. That goes back to Sapir-Whorf: if your language doesn’t express a particular concept, it’s difficult to think about that concept.

If you’re not familiar with continuations, Dan Sugalski has a nice entry in his blog to explain them. Further, he also explains why Parrot uses a continuation passing scheme. Though it took some effort to get this to work, the exra effort up front saved a lot of time down the road. Continuations make tail-call optimization a breeze. It also makes handling calling context very simple. These provide performance benefits and make functional programming more, er, functional.

In the end, the biggest arguments against closures, continuations, curried functions and other ideas that many programmers aren’t as familiar with seems to boil down to the “syntactic sugar” argument. This false argument states that since this is merely different functionality, not new functionality, that it’s not really that important. My rebuttal is simple: loops are “syntactic sugar” as we can merely use conditional jumps to implement them (which is how they’re often implemented internally). Yet would most programmers be happy without while and for loops?

It’s astonishing how so many of us are at the cutting edge of technology, yet we often resemble Luddites.