I just published a post on Fast Company’s Co.Design about usability in programming language design, based on some interesting research from Southern Illinois University. The comments on that post will no doubt get heated, but there is some additional material I wanted to put out there which I couldn’t fit into that post.
I interviewed Alex Payne, a former developer at Twitter, now CTO of Simple Finance, and organizer of a fascinating thing called “Emerging Languages Camp” (which I covered for Technology Review in 2010), which gathers designers of new programming languages to share their work and ideas. Payne made some of the same points that Andreas Stefik (the lead author of the paper I discussed in the Co.Design post) did about how programming languages get created, and how peculiarities of syntax can affect the learning curve of a programming language.
But Payne had another insight on the design of programming languages that I found particularly interesting. I’ll quote him [emphasis added by me]:
A secondary factor that shapes the language learning curve is fuzzier: the ideas that the language is trying to get across. Programming languages are usually more than just a way to get a computer to do stuff. They’re often a collection of opinions about how one should go about getting a computer to do stuff.
For example, the Haskell language basically argues that you should program computers in very much the way a mathematician might work out a problem. In order to program in Haskell, you need to learn both its syntax and its mindset, if you will. This contrasts with a language like Python that has very little syntax to learn and not much of an opinion about how one should program, beyond that you should do it in a straightforward way. No wonder, then, that Python is considered very easy to learn and is often used to educate burgeoning programmers.
This is tangent to another question I was curious to answer, which led me to cover the Emerging Languages Camp in the first place: why do we need many different programming languages, or new languages, at all? But if a programming language is not just an interface, but an argument, the need for (or at least desire for) making new ones all the time makes more sense.