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.
Funny thing, purely functional data structures are in practice often easier to work with and reason about than their imperative alternatives. But I think we have entirely different criteria for deciding that a language is interesting, if your list is anything to go by.
I suspect that you’ll see the largest wins in user testing of language features when the target user population is very different from the language designers. For example, there was some user testing of the Applescript language (see doi:10.1145/1238844.1238845), but (alas) it came too late to have any real impact.
It’s true that writing purely functional data structures is hard, but if you can get a good core set into the standard library, it becomes less of an issue. For example, in C++ it’s really hard to write generic data structures with templates, but using the data structures provided by the STL isn’t too painful.
However, I’m also very skeptical of widespread adoption of functional programming languages. The Lispers have been trumpeting improved productivity for years, but Lisp has never really broken into into the mainstream (any bets on Clojure adoption?). Sure, there’s no hard empirical evidence that Lisp is more productive than alternatives, but when has that ever been a factor in widespread adoption of software technologies?
On the other hand, there’s a multicore wildcard here. If it end up being much easier to write correct concurrent programs with a functional programming language (Erlang? Haskell? Scala?) , then perhaps that will turn the tide?
Also, Haskell is another success story of a language produced by a committee.
It would be great to see a language designed for testability, but I would imagine that there would be a lot of complaints about the constraints that it would place on the way that people can write code.
I was actually wondering as well why you’d consider purely functional data types ‘hardly intuitive’, as long as one is willing to think/learn about them for the same amount of time (or even less) as one needs to ‘understand’ e.g. class-based internal-mutable-state data structures.
If one’d be educated using purely functional data types, something like
thelist.append(item)
is most likely as hard to understand fully at first sight as
thelist = thelist.append(item)
would be hard to understand for someone educated using the first approach (simple/dumb example, I know…).
I think more people should at least know about functional data structures, so the pros and cons will become more well-known, and they’ll be used where appropriate (and make code more bug-free as a side-effect
).
*Third, a new language should explicitly be designed to make the expression of common design patterns as straightforward as possible.*
Could we please stop calling them languages? Programming languages are specialized notation. Calling them languages just gives us an instant way to talk about them (linguistics came up with the terms syntax, semantics, grammar, etc.) by way of analogy. Programming languages aren’t like regular languages at all.
Your “idioms” are in fact abstractions, and they do not change from year to year, they are meant, just as in mathematics, to last as long as possible.
This is why we have to stop talking in terms of language. Idioms are natural to a certain group of people. Using your goto/for-loop example, the assembly coders who are used to goto or branching of that sort may never realize that they can talk about it in terms of a for-loop construct.
*structs with function pointers become objects*
That didn’t happen. C came out after Smalltalk and Modula. C is the notation that took a giant step backwards. We were finally moving towards good solid notations and then it steamrolled over everything.
*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.*
The average programmer is an idiot. The field and industry have low standards as we can see when we look at the majority of academic papers and all the buggy software shipped. We can see it when the average programmer gets confused by the various analogies with engineering, linguistics/languages, etc. Many consultants and “coaches” and “mentors” have become rich due to this confusion and over-use of inappropriate analogies.
Mathematicians do not appeal to the “average” mathematician when devising their new notations, so why should programmers?
@Bryan I’d be interested to hear what your criteria are…
@Nicolas I’m reminded of something one of my math profs said once (not joking): “Sure it’s intuitive—you just have to spend a few years training your intuition.”
@Rudolf I think your comment “The average programmer is an idiot” says more about you than it does about programming or programmers…