This article is an appeal to increase the awareness about usability aspects of programming languages. Searching the internet for this topic reveals a meager result. You can find online material for a university course whose title is quite similar to this article’s. Other than that, not much else. Incidents like the recent Heartbleed bug suggest that programming languages matter and seeing that one can understand them as the least usable but most powerful human-computer interface ever invented leads to the conclusion that we really should place more value on the usability of programming languages.
In other areas like product design and graphical user interfaces, usability concerns have rightly found their way into the consciousness of creators and, more importantly, users. My impression is that in recent years users point out usability problems much more than just putting up with them. On the other hand, we as programmers still tend to accept usability issues with our programming languages and tools due to the pain we forgot. For that very reason it is important, as a programmer, to actively make yourself aware of what is a usable way to achieve a task and what is not. After all, circumventing usability deficits costs valuable time, hides the intention of code, decreases its maintainability and so on. Ideally, this awareness should amount to choosing a usable language, libraries with usable APIs and usable tools for the task at hand. For many (external) reasons this is utopian. However, if we build up our awareness of usability of programming languages and their tools then we will be able to make better decisions on that score, write better code, make better arguments against or in favor of alternatives and indicate previously unrecognized deficits. We might even discover wholly new ways of realizing a task.
But how to concretely analyze the usability of a programming language? A programming language is a complex and immaterial thing after all. We could conduct studies. In practice, there are quite some issues. First, as an individual you probably do not have the means to conduct such a study. Such studies are expensive and essentially only research institutes like universities or companies with lots of money to spare have this privilege. Second, the results of such (experimental) studies will be relatively precise but at the same time rather narrow simply due to their nature. A more attractive alternative is an analytical approach using expert reviews. You can even conduct such an analysis with yourself being the sole expert which probably would not be accepted in a prestigious journal but still can be immensely valuable even if only for yourself. 1
In the land of user interface design there are, for instance, Shneiderman’s Eight Golden Rules or Nielsen’s 10 Usability Heuristics to analyze the usability of a user interface. In programming resp. computer science related areas besides HCI there are standardized metrics to analyze a software’s quality. For algorithms, there are different time and space classes to analyze an algorithm’s efficiency. One of the main benefits of these standardized criteria is the common vocabulary they provide. Wouldn’t it be great to have something similar to analyze a programming language’s merit in terms of its notational aspects?
Enter Cognitive Dimensions of Notations (CDs) framework. CDs is an “approach to analyzing the usability of information artifacts” of which programming languages are a particular kind. As such, CDs has been used in a variety of papers to analytically investigate the usability of programming language features or an API. CDs consists of fourteen dimensions although, often, only a subset of these fourteen dimensions – one which makes sense for a particular information artifact – is employed. Wikipedia provides a succinct list of the dimensions. Granted, CDs’ presentation leans a bit on the academic side and seems somewhat obscure at first but do not let that distract you from its content. I am convinced that reading the explanations of the dimensions, the questions to ask yourself for each dimension and maybe one or two papers where CDs is applied, will most probably already considerably increase your awareness of, at least notational, usability aspects of programming languages. I would like to hope that the vocabulary of this framework will find its way into our communication even if the chance is tiny. 324
Notational aspects are very important but certainly not all-encompassing in terms of programming language usability, especially when considering a language’s ecosystem in addition. For example, the usability of tooling like IDEs is very important. Light Table is a new Editor/IDE that employs novel ideas to, among other aspects, provide better development usability. There are several other interesting projects that all somehow want to improve usability aspects for programmers (and other things) like the Quorum Programming Language, some of Bret Victor’s projects, the Wolfram Language and research like this. 5
To conclude, I believe that usability of programming languages is somewhat neglected and an increased awareness would lead to many benefits. To this end, the vocabulary of CDs could be used to improve this awareness and provide a basis for communication. Both notational usability aspects and usability aspects of the ecosystem of a programming language are important. 6
The following are further relevant links I found after having published this article.
- Java Pain / HN discussion
- The Economic Value of Rapid Response Time
- Ryan Dahl’s Rant
- Code’s Worst Enemy
- Simple Made Easy
- The Future Of Programming Manifesto
Well, actually you could devise an online questionnaire or use something like mechanical turk if you wanted to conduct a “cheap” study. But even this approach has a lot of challenges like finding enough suitable participants that are willing to invest their time. ↩
In one of my future articles I’d like to use CDs to myself analyze certain programming language features or compare different languages. I invite you to do the same! ↩
For a project of mine I’ve combined explanations for the dimensions Abstraction Level, Closeness of Mapping, Hidden Dependencies, Error-proneness, Diffusenes and Viscosity from various sources and extended them with some of my own examples. ↩
I mean surely you can find some existing terms that more or less coincide with one or another dimension. But again, having a consistent set of common vocabulary is valuable in itself. Besides, thank god are these dimensions neutral and tastefully selected. You don’t find something like “Readability” or “Cleanliness” because these terms are often used so subjectively that you would only start flame wars by using them. ↩
Regarding IDE’s, I am consistently amazed whenever I read comments in online discussions where IDE features like auto-complete are played down as irrelevant or, worse, as “helping too much”. Having to manually search documentation when it could be provided automatically right in the context where it is needed is surely such a considerable usability advantage that you must have evil intentions to simply dismiss it :P. ↩