Pizza to Scala: The Ten Year Road of Language Design

James Gosling, yesterday:

There has been a lot of chatter about the closures proposal penned by Neal Gafter. And, in particular, whether or not I support it. I absolutely do.
--James Gosling, Thursday January 31, 2008

He goes on to add "Closures were left out of Java initially more because of time pressures than anything else." Java was introduced in 1995. Let's look a bit back into history to see what's been happening since then.

In 1998, my advisor advised me to take a look at some related work, something called Pizza, "a substantial companion to Java." Pizza was a joint project between Philip Wadler and Martin Odersky. They wanted to add closures, parametric polymorphism, and abstract datatypes to Java.

Then anonymous classes were introduced to Java, which went 80% of the way toward giving Java the utility of closures (4 out of 5 programmers thought it was good enough). Still a syntactic pain, but a net win considering the convenience of putting your code where it makes sense rather than a class definition elsewhere. Wadler and Odersky decided to focus their energies on generics, and moved on to Generic Java. I used the Generic Java compiler at the time simply because it was faster than Sun's javac for compiling ordinary Java code. The work on Generic Java was then actually adopted into the Java standard.

That brings us to 2008. Martin Odersky is now realizing the original goals of Pizza with Scala, and closures are being brought to Java.

I appreciate the efforts of Wadler and Odersky in bringing functional programming closer to the average programmer. In 1998 Wadler wrote an enjoyable piece "Why No One Uses Functional Languages", a kind of State of the Functional Programming Union, in which he lists 8 barriers to adoption of functional programming. At a casual glance, I count 5 out of 8 of these barriers broken down by the association with the Java platform. These include portability, libraries, and compatibility (e.g. foreign function interfaces and other ways to interface with legacy systems). A sixth reason, tools, is addressed or helped to a large degree by Eclipse, which while written in Java, largely owes its existence as far as spirit of design and the benefit of years of hard-toil experience to the Smalltalk community.

Joel Spolsky and they that hire have been bemoaning the dilution of fresh CS grads coming out of the Java mills. In light of the above technical developments, this is an ironic trend, considering the "training" barrier Wadler mentions:

To programmers practiced in C, C++, or Java, functional programs look odd. It takes a while to come to grips with writing f(x,y) as f x y. Curried food and curried functions are both acquired tastes.
--Philip Walder

My understanding of Spolsky's point is that "the kids aren't learning Scheme - they don't know the great ideas of computer science anymore, they just learn Java and design patterns." If it is the case, yes it does bother me. I don't know if that is the case; I don't hire people, and the people I've worked worth have been (mostly) great.

What I will say is this. The churn of progress has been steadily raising the level abstraction over time. We have needed, and will continue to need, people who create the new abstractions (languages and frameworks) and people who apply the new abstractions. Bright engineers out of the Java mill will eventually be challenged with problems their existing tools don't address (hey, this is tedious and error prone...) and if nothing else they'll reinvent the great ideas of the past, and relearn them the hard way. Learning things the hard way is effective (you tend to internalize lessons better when they involve words like "shots fired" and "you [and your slipped schedule] are gonna cost me a billion dollars!") and expensive. Managers should be noticing things like that. I hope some bright engineering managers, who sit on their local university's advisory board, notice these trends as they arise and say a few words on their next visit to the department.

---

Community service footnote: I sit on the advisory board for the CS department at my alma mater and provide feedback as an alum and industry representative. If a school you care about doesn't have such a board and you think they need to hear from you, start it. Even if you don't think you have influence, alums in the technical fields can always pretend they'll strike it rich someday and therefore should have some influence.