Language Trickery and EJB

Written in October 2004 as a long reply to an Amazon colleague who'd dismissed closures as "language specific trickery," the piece opens with the friendliest thought experiment in the Drunken canon: imagine Java without a for keyword, where printing even numbers from 2 to 100 requires a LoopObject — setStartingValue(2), setCounterIncrement(2), a callback. Everyone agrees the imaginary code is awful. From that baseline Steve turns it around: the for-loop is a service rendered to the programmer, the same kind of service an EJB renders to its callers, except the syntax forces the API to be used correctly. Compilers can check that you initialized the counter; they can't check that you ever called setStartingValue at all. So you want some syntax — but not syntax for everything, because that way lies Perl. The slope from that question runs through Java's clumsy closures (every anonymous inner class with a final capture is a closure in disguise), on to macros, then to Erlang's syntax for distributed computing (a million lines of Erlang doing what would be 20 million lines of buggy C++), then to the broader puzzle: Java programmers will stay up all night reading Hibernate manuals but recoil from the word map, even when the new syntax is worth a 10× or 100× productivity gain.

One of the cleanest first statements of what becomes the Drunken-era's central preoccupation — that syntax is not cosmetic, and the industry's allergy to it is what's holding it back. Two years later the same argument is sharpened into Execution in the Kingdom of Nouns; here it's still patient, still talking to the EJB people on their own terms.