On Usability of Programming Languages

This ar­ti­cle is an ap­peal to in­crease the aware­ness about us­abil­ity as­pects of pro­gram­ming lan­guages. Search­ing the in­ter­net for this topic re­veals a mea­ger re­sult. You can find on­line ma­te­r­ial for a uni­ver­sity course whose title is quite sim­i­lar to this ar­ti­cle’s. Other than that, not much else. In­ci­dents like the re­cent Heart­bleed bug sug­gest that pro­gram­ming lan­guages mat­ter and see­ing that one can un­der­stand them as the least us­able but most pow­er­ful hu­man-com­puter in­ter­face ever in­vented leads to the con­clu­sion that we re­ally should place more value on the us­abil­ity of pro­gram­ming lan­guages.

In other areas like prod­uct de­sign and graph­i­cal user in­ter­faces, us­abil­ity con­cerns have rightly found their way into the con­scious­ness of cre­ators and, more im­por­tantly, users. My im­pres­sion is that in re­cent years users point out us­abil­ity prob­lems much more than just putting up with them. On the other hand, we as pro­gram­mers still tend to ac­cept us­abil­ity is­sues with our pro­gram­ming lan­guages and tools due to the pain we for­got. For that very rea­son it is im­por­tant, as a pro­gram­mer, to ac­tively make your­self aware of what is a us­able way to achieve a task and what is not. After all, cir­cum­vent­ing us­abil­ity deficits costs valu­able time, hides the in­ten­tion of code, de­creases its main­tain­abil­ity and so on. Ide­ally, this aware­ness should amount to choos­ing a us­able lan­guage, li­braries with us­able APIs and us­able tools for the task at hand. For many (ex­ter­nal) rea­sons this is utopian. How­ever, if we build up our aware­ness of us­abil­ity of pro­gram­ming lan­guages and their tools then we will be able to make bet­ter de­ci­sions on that score, write bet­ter code, make bet­ter ar­gu­ments against or in favor of al­ter­na­tives and in­di­cate pre­vi­ously un­rec­og­nized deficits. We might even dis­cover wholly new ways of re­al­iz­ing a task.

But how to con­cretely an­a­lyze the us­abil­ity of a pro­gram­ming lan­guage? A pro­gram­ming lan­guage is a com­plex and im­ma­te­r­ial thing after all. We could con­duct stud­ies. In prac­tice, there are quite some is­sues. First, as an in­di­vid­ual you prob­a­bly do not have the means to con­duct such a study. Such stud­ies are ex­pen­sive and es­sen­tially only re­search in­sti­tutes like uni­ver­si­ties or com­pa­nies with lots of money to spare have this priv­i­lege. Sec­ond, the re­sults of such (ex­per­i­men­tal) stud­ies will be rel­a­tively pre­cise but at the same time rather nar­row sim­ply due to their na­ture. A more at­trac­tive al­ter­na­tive is an an­a­lyt­i­cal ap­proach using ex­pert re­views. You can even con­duct such an analy­sis with your­self being the sole ex­pert which prob­a­bly would not be ac­cepted in a pres­ti­gious jour­nal but still can be im­mensely valu­able even if only for your­self. 1

In the land of user in­ter­face de­sign there are, for in­stance, Shnei­der­man’s Eight Golden Rules or Nielsen’s 10 Us­abil­ity Heuris­tics to an­a­lyze the us­abil­ity of a user in­ter­face. In pro­gram­ming resp. com­puter sci­ence re­lated areas be­sides HCI there are stan­dard­ized met­rics to an­a­lyze a soft­ware’s qual­ity. For al­go­rithms, there are dif­fer­ent time and space classes to an­a­lyze an al­go­rithm’s ef­fi­ciency. One of the main ben­e­fits of these stan­dard­ized cri­te­ria is the com­mon vo­cab­u­lary they pro­vide. Wouldn’t it be great to have some­thing sim­i­lar to an­a­lyze a pro­gram­ming lan­guage’s merit in terms of its no­ta­tional as­pects?

Enter Cog­ni­tive Di­men­sions of No­ta­tions (CDs) frame­work. CDs is an “ap­proach to an­a­lyz­ing the us­abil­ity of in­for­ma­tion ar­ti­facts” of which pro­gram­ming lan­guages are a par­tic­u­lar kind. As such, CDs has been used in a va­ri­ety of pa­pers to an­a­lyt­i­cally in­ves­ti­gate the us­abil­ity of pro­gram­ming lan­guage fea­tures or an API. CDs con­sists of four­teen di­men­sions al­though, often, only a sub­set of these four­teen di­men­sions – one which makes sense for a par­tic­u­lar in­for­ma­tion ar­ti­fact – is em­ployed. Wikipedia pro­vides a suc­cinct list of the di­men­sions. Granted, CDs’ pre­sen­ta­tion leans a bit on the aca­d­e­mic side and seems some­what ob­scure at first but do not let that dis­tract you from its con­tent. I am con­vinced that read­ing the ex­pla­na­tions of the di­men­sions, the ques­tions to ask your­self for each di­men­sion and maybe one or two pa­pers where CDs is ap­plied, will most prob­a­bly al­ready con­sid­er­ably in­crease your aware­ness of, at least no­ta­tional, us­abil­ity as­pects of pro­gram­ming lan­guages. I would like to hope that the vo­cab­u­lary of this frame­work will find its way into our com­mu­ni­ca­tion even if the chance is tiny. 324

No­ta­tional as­pects are very im­por­tant but cer­tainly not all-en­com­pass­ing in terms of pro­gram­ming lan­guage us­abil­ity, es­pe­cially when con­sid­er­ing a lan­guage’s ecosys­tem in ad­di­tion. For ex­am­ple, the us­abil­ity of tool­ing like IDEs is very im­por­tant. Light Table is a new Ed­i­tor/IDE that em­ploys novel ideas to, among other as­pects, pro­vide bet­ter de­vel­op­ment us­abil­ity. There are sev­eral other in­ter­est­ing pro­jects that all some­how want to im­prove us­abil­ity as­pects for pro­gram­mers (and other things) like the Quo­rum Pro­gram­ming Lan­guage, some of Bret Vic­tor’s pro­jects, the Wol­fram Lan­guage and re­search like this. 5

To con­clude, I be­lieve that us­abil­ity of pro­gram­ming lan­guages is some­what ne­glected and an in­creased aware­ness would lead to many ben­e­fits. To this end, the vo­cab­u­lary of CDs could be used to im­prove this aware­ness and pro­vide a basis for com­mu­ni­ca­tion. Both no­ta­tional us­abil­ity as­pects and us­abil­ity as­pects of the ecosys­tem of a pro­gram­ming lan­guage are im­por­tant. 6

The fol­low­ing are fur­ther rel­e­vant links I found after hav­ing pub­lished this ar­ti­cle.

  1. Well, ac­tu­ally you could de­vise an on­line ques­tion­naire or use some­thing like me­chan­i­cal turk if you wanted to con­duct a “cheap” study. But even this ap­proach has a lot of chal­lenges like find­ing enough suit­able par­tic­i­pants that are will­ing to in­vest their time. 

  2. In one of my fu­ture ar­ti­cles I’d like to use CDs to my­self an­a­lyze cer­tain pro­gram­ming lan­guage fea­tures or com­pare dif­fer­ent lan­guages. I in­vite you to do the same! 

  3. For a pro­ject of mine I’ve com­bined ex­pla­na­tions for the di­men­sions Ab­strac­tion Level, Close­ness of Map­ping, Hid­den De­pen­den­cies, Er­ror-prone­ness, Dif­fusenes and Vis­cos­ity from var­i­ous sources and ex­tended them with some of my own ex­am­ples. 

  4. I mean surely you can find some ex­ist­ing terms that more or less co­in­cide with one or an­other di­men­sion. But again, hav­ing a con­sis­tent set of com­mon vo­cab­u­lary is valu­able in it­self. Be­sides, thank god are these di­men­sions neu­tral and taste­fully se­lected. You don’t find some­thing like “Read­abil­ity” or “Clean­li­ness” be­cause these terms are often used so sub­jec­tively that you would only start flame wars by using them. 

  5. Re­gard­ing IDE’s, I am con­sis­tently amazed when­ever I read com­ments in on­line dis­cus­sions where IDE fea­tures like auto-com­plete are played down as ir­rel­e­vant or, worse, as “help­ing too much”. Hav­ing to man­u­ally search doc­u­men­ta­tion when it could be pro­vided au­to­mat­i­cally right in the con­text where it is needed is surely such a con­sid­er­able us­abil­ity ad­van­tage that you must have evil in­ten­tions to sim­ply dis­miss it :P. 

  6. By the way, I found a some­what sim­i­lar ar­ti­cle to mine where the au­thor ap­plies Nielsen’s us­abil­ity heuris­tics for UI de­sign to pro­gram­ming lan­guage de­sign. 

Published: 25.05.2014 Last modified: 02.02.2015
Comment? Mail or tweet me.