When I Said "The Last Twenty Years..."

Last week, in response to Google's announcement of a new programming language called Go, I said:

I'm underwhelmed: it's as if the last 20 years of programming language research hadn't happened.
Turns out I was being generous: read this post from start to finish, and you'll see what I mean.

So what should a new programming language do to get my attention? First, just as applications should be designed for testability, languages should be too. That means choosing constructs to make the lives of static and dynamic analysis tools better. Building such tools after the fact is like trying to add security to an app after it has been deployed; I think we'd do better to treat the capabilities of today's leading-edge program analysis tools as hard (but not unbreakable) constraints on what's allowed to go into a language, and see how far it gets us. I suspect this will push us toward strongly typed and mostly functional languages.

Second, user testing of language features. The folks at CWI did this with ABC (a precursor of Python); Steven Clarke has done excellent work on API usability at Microsoft (see for example this DDJ article from 2004), and there's lots of other prior art --- hell, I did a little myself nine years ago for Python (see these messages for details). I'm not suggesting design by committee [1], but checking to see how comprehensible or surprising feature XYZ is going to be to the average programmer before it's put into the language just seems like common sense. I suspect this will push us away from pure functional languages: monads are just plain hard, and while purely functional data structures are possible, they're hardly intuitive.

Third, a new language should explicitly be designed to make the expression of common design patterns as straightforward as possible. Languages (of all kinds, not just programming languages) evolve by formalizing the common usages of the day: idiomatic uses of goto statements become for loops, structs with function pointers become objects, and so on. There's a tremendous literature on design patterns at several scales; why not treat them as something akin to use cases?

Of course it's never too late --- if someone has the time and energy, they could apply these three criteria to Go (or any other language) right now. Hm... sounds like an interesting thesis topic...

[1] Which gets an unfairly bad rap --- both the American Constitution and the King James version of the Bible were produced by committees.