Why Programming Languages need More HCI
I just posted a comment to Lambda the Ultimate trying to clarify some misunderstandings about user testing and HCI. Here is the original comment, and my reply is below.
I just created an account to reply to the above post. Just for background purposes, I teach human-computer interaction at Carnegie Mellon University, and am part of the School for Computer Science.
I believe the above poster is making a similar argument that Doug Engelbart made a long time back about the difference between tricycles and bicycles. More specifically, if ease of use was all that mattered, then we would all be riding tricycles.
However, I believe that the above post shows a common misunderstanding of the nature of user tests, and human-computer interaction more broadly. Specifically, HCI is not just about ease of use for "walk up and use" interfaces. We advocate that designers should understand the context of use, set appropriate goals, and measure that we are achieving those goals. Like security or performance, it is holistic and something that has to be intentionally designed in from the beginning, rather than slapped on at the end.
There have also been several studies looking at expert performance of user interfaces, spanning several weeks or months, to measure such things as learnability and overall performance. I believe these kinds of studies could address many of the concerns the above post makes.
Human-computer interaction can also provide new insights for programming languages. To give a concrete example, I will refer readers to the Natural Programming project at CMU, which is looking at how programmers (and non-programmers) already work and developing better tools to streamline those existing practices.
This project has led to better debugging tools (supporting "why" and "why not" questions, which turned out to be how every programmer studied phrased their debugging questions), a better understanding of what kinds of APIs are easier to use (it turns out, quite surprisingly, that objects with lots of constructors don't fare as well as those with simple ones), and better ways of validating that data is correct. Companion projects at other universities have also examined, for example, the role of gender and programming (finding that men tend to tinker a lot more when programming and debugging, which may suggest better ways of teaching computer science).
So, in a narrow sense, I would agree that user testing for ease of use is not enough, but I would also argue that human-computer interaction has *a lot* more to offer programming languages than may appear on first glance.