How to talk about progamming languages

15 June 2014

I can’t talk about programming languags online anymore. It’s impossible. There is so much misinformation, misunderstanding, misdirection – people just talk past each other all day long.

It doesn’t have to be this way. We really can have insightful, engaging discussions of programming languages. They don’t just have to be miscommunication and misunderstanding. Go read Evee’s critique of PHP, Coda Hale’s account of Yammer’s issues with Scala or the C++ FQA and see what I’m talking about.

So here’s what I’m going to do. In this series of blog posts, I’m going to lay down a framework for reasoning about and discussing programming languages. I’m going to publish it, and then that’ll be the end of it. Everyone will just use this framework and we’ll have clear, levelheaded discussions all day long. So here we go.

How do you evaluate a programming language?

There are three broad categories in which we will assess programming languages:

• As tools to be studied, learned and mastered.
• By the characteristics of the software artifacts they create.
• As communities and ecosystems.

These categories aren’t totally separate: for example, languages with energetic communities will often produce plenty of tutorials and documentation, which in turn makes it easier to learn the language. Even so, programming languages are simply too large a topic to analyze without some sort of system. Looking at PL discussions online, I believe that much of the confusion and talking-past-each-other stems from people conflating these categories.

For example, suppose Alice claims C++ is too complicated and for that reason she prefers Python. Bob responds by claiming C++ executes more quickly and uses less memory than Python. Alice and Bob are not really communicating. They are talking about totally different things. Alice is talking about the experience of using the tool, but Bob is talking about the quality of the artifact the tool generates.

If you aren’t talking about tradeoffs, you aren’t worth listening to

What people in Bob’s position usually actually mean is something along the lines of “Yea, C++ is more complicated than Python, but if you can handle the complexity, it’s a better tool because it’s much more efficient.” But that’s a very different assertion than just “C++ is more efficient than Python”. In particular, the “Yes, but” statement acknowledges a tradeoff. Reading the second statement, it’s obvious that there are some situations when C++ is not a better tool than Python: when the extra complexity of the language is not worth the efficiency gains.

Too often, people talking about programming languages get tripped up on this sort of unacknowledged tradeoff. Don’t fall into this trap. Make your point as explicitly as possible, and keep in mind that this is a topic that frequently confuses people. Software development largely revolves around managing tradeoffs. Tradeoffs are the most important part of the conversation. Call them out.

Next time, I’ll dive deeper into the first category for evaluating programming languages: as tools that programmers study, learn, and master.

comments powered by Disqus