Mind the gap please

Or, how all programming language evolution charts are incomplete.

Or even, how so many of you are looking the wrong way!

Just a quick moan this time. No doubt you’ve all seen charts which show how ideas from one programming language have flowed into others, in a kind of tracking-the-evolution sense.

Ever noticed what’s wrong with these diagrams? I think they are missing a crucial detail, and by missing this, they are missing a very important aspect of programming language work: the wider picture.

The same applies during many ‘discussions’ about programming languages etc. The discussion tends to focus on existing languages, as if we had to pick something that already exists. Looking backwards, in a sense.

What I think gets lost is the context. We’re programming to solve problems, and most of the fun parts of problem solving are done in our heads and then transferred to some executable format. There’s a gap between “brain” and “machine” that we need to bridge somehow, with a mix of languages, processes, techniques, and I think you’ll all agree the gap is pretty big at present.

My second favourite joke is relevant here. An eminent Comp Sci professor was asked what was the best programming language. Prof. paused, then answered “graduate student”.

So if we could, wouldn’t it be fun to explain to a graduate student what needed doing and then get a working program back? We’ve made the bridge shorter by using a fairly high-level entity to encode our solution. (YMMV though.) Sadly, there aren’t so many graduate students around and we sometimes have to do our own work. How do we reduce how much needs to be bridged?

Notice that I’m not recommending we work at the machine level. We should aim to do better than this. For example, I don’t program in Haskell: I write programs in my head and then write them down as Haskell programs. It’s the difference between programming with versus programming in. I would like my future languages to make it easier to write down what is in my head, not only because I’m lazy, but because it’s probably a bit safer that way.

One way to view programming language development is as an attempt to narrow the brain-machine gap.We try to provide features which make it easier to encode and think about concepts from the problem domain, and to say how they relate. Quite rightly, there’s a growing interest in techniques like DSLs (domain specific languages) as a way to encode important ideas more directly, without the noise of the host programming language. We can go further though.

I like the flexibility and terseness given by Haskell-style languages – great for saying what you mean without too much ceremony. But, quite often I know more about the problem domain etc and how things work than is possible to write in the code, and this is annoying. I don’t want to write such things down as comments, or write test cases to try to document and confirm additional properties. I think we can do better, and one way is with the new generation of dependently typed languages. (You can find an intro in recent PragPub magazines, in particular starting with the April 2013 issue.) Dependent types aren’t perfect, but it’s a good step forward and they introduce many new ideas to explore.

To sum up, I believe we need to be aware of the brain-machine gap and be aware how we need to develop tools (languages and otherwise) plus techniques to get more control over the gap. Don’t turn your back on it!