Programming Languages Are the Most Powerful, and Least ­Usable and Learnable ­User Interfaces

Andy Ko wrote a recent blog post with an important claim: "Programming languages are the least usable, but most powerful human-computer interfaces ever invented." Andy argues the "powerful" part with points about expressiveness and political power. He uses HCI design heuristics to show how programming languages have poor usability. Obviously, some people can use programming languages, but too few people and at great effort.

I see that Andy's argument extends to learnability. There are two ways in which programming languages have poor learnability today — (1) in terms of expectancy-value and (2) in terms of social cost.

What's the benefit of a closure? Eugene Wallingford tweeted a great quote the other day:

"Think back to before you understood closures. I'm sure you couldn't even imagine it. Now imagine them away. See, you can't do that either."

— wallingf (@wallingf) March 25, 2014

Educational psychologists measure the cognitive load of instruction, which is the effort that a student makes to learn from instruction. Every computer scientist can list a bunch of things which were really hard to learn, and maybe couldn't even be imagined to start, like closures, recursion in your first course, list comprehensions in Python, and the type systems in Haskell or Scala.

Expectancy-value theory describes how individuals balance out the value they expect to get from their actions. Educational psychologists talk about how that expectation motivates learning. Students ask themselves, "Can I learn this?" and "Do I want to learn this? Is it worth it?" You don't pursue a degree in music if you don't believe you have musical ability. Even if you love art history, you might not get a degree in it if you don't think it'll pay off in a career. Most of us don't learn Dvorak keyboards, even though they're provably better than Qwerty, because the perceived costs just aren't worth the perceived benefit. The actual costs and benefits don't really play a role here — perception drives motivation to learn.

If you can't imagine closures, why would you want to learn them? If our programming languages have inscrutable features (i.e., high cognitive load to learn them) with indeterminate benefits, why go to the effort? That's low learnability. If students are not convinced they can learn it and they are not convinced of the value, then they don't learn it.

The social cost of going in a new direction. I was at a workshop on CS Education recently, where a learning scientist talked about a study of physicists who did their programming in Fortran-like languages and only use arrays for all their data structures. Computer scientists in the room saw this as a challenge. How do we get these physicists to learn a better language with a better design, maybe object-oriented or functional? How do we get them to use better data structures? Then one of the other learning scientists asked, "How do we know that our way is better? Consider the possibility that we're wrong."

We computer scientists are always happy to argue about the value of one programming paradigm over another. But if we think about it from Andy Ko's usability perspective, we need to think about it for specific users and uses. How do we know that we can make life better for these Fortran-using physicists?

What if we convinced some group of these Fortran-using physicists to move to a new language with a new paradigm? Languages don't get used in a vacuum — they get used in a community. We have now cut our target physicists off from the rest of their community. They can't share code. They can't use others' libraries, tools, and procedures. The costs of learning a new language (with new libraries, procedures, and tools) would likely reduce productivity enormously. Maybe productivity would be greater later. Maybe. The value is uncertain and in the future, but the cost is high and immediate.

Maybe we should focus on students entering the Fortran-using physics community, and convince them to learn the new languages. Learning scientists talk about student motivation to join a "community of practice." Our hypothetical physics student wants to join that community. They are learning to value what the community values. Trying to teach them a new language is saying: "Here, use this — it's way better than what the people admire use." The student response is obvious, "Why should I believe you? How do you know it's better, if it's not what my community uses?"

Solution: Focus on usability. Communities change, and people learn. Even Fortran-using physicists change how they do what they do. The point is that we can't impose change from the outside, especially when value is uncertain.

The answer to improving both usability and learnability of programming languages is in another HCI dictum: "Know thy users, for they are not you." We improve the usability and learnability of our programming languages by working with our users, figuring out what they want to do, and help them to do it. Then the value is clear, and the communities will adopt what they see as valuable.