Vivek Haldar

Whither programming language research?

Cristina Lopes (whom I’ve had the pleasure of being taught by, in a grad course on UbiComp) laments the current state of programming language research and the lack of innovation in the field. You should go read the whole thing.

I largely agree with her, but have a few observations to add:

  • progress seems slow because being incremental is necessary for any hope of wide adoption. The population of practicing programmers, as well as the ocean of existing code, can only absorb so much change at a time. Languages that are too radical don’t make it beyond the paper they’re described in. For example, lambda expressions and closures have only recently made (or are making) the jump from largely academic functional languages to mainstream ones like Python, C++ and Java.
  • this is further exacerbated because the window of opportunity for new languages to take off is extremely slim. Languages don’t take off by themselves, they ride on the backs of platforms, and those only come along once or twice a decade.
  • the mantle of programming language innovation firmly passed to industry sometime in the 90s. Why? Because that’s where all the interesting problems were starkly revealed. Matt Welsh went from Harvard to Google because he found “problems that are orders of magnitude larger and more interesting than I can work on at any university.” This is not to disparage academic PL research, because a big part of new PL design is cherry-picking the best constructs from past academic research.
  • that said, I think currently we’re in the valley of “good enough” languages. There are certainly tons of annoyances and there will always be room for improvement in the mainstays (e.g. Java, C++ and Python, to count category representatives), but by and large they get the job done. I have yet to run into a project where the language was the bottleneck for success. That doesn’t mean that there are not problems on the horizon (concurrency, distributed computing…) that will eventually become painful enough to force a move to new languages (or old languages with new constructs).
  • because of the above two points, language engineering resources have mostly been devoted to virtual machine and runtime engineering, because they provide an immediate payback in terms of hardware dollars utilized and saved.