Views and Feelings: Programmers are Humans Too, 2

Steven Pemberton

Imagine, hypothetically, just for a moment, that programmers are humans. No, don't laugh, I'm serious. I know that all evidence is to the contrary: they work at night and sleep during the day, and only need 2 hours of sleep, they have a diet of pure sugar and caffeine, they can use, and actually enjoy using the vi editor, but despite all this, just for the sake of the argument, imagine that they are human.

Now suppose for a moment, also for the sake of the argument, that their chief method of communicating and interacting with computers was with programming languages. What would we, as HCI people then do? Run screaming in the other direction, I hear you think. No, task analysis of course, requirements analysis, user testing of programming languages, iterative design, is the right answer.

I recently was present at a presentation by a group who study how programmers program. They had discovered problems in the group they studied, and their conclusion was that the educational materials for the particular language they were studying needed to be changed to better handle the cases that they had observed that didn't work well.

A bell rang in my head. Where had I heard that before? Well, for user interfaces of course. It's one of the many deadly sins of User Interface Design: documenting a problem rather than fixing it, so that people have to learn how to use it rather than understand how to use it, making it the user's problem rather than the designer's.

I asked the presenter innocently if there was any evidence that programming languages were actually designed for people, but the audience laughed, and so the question wasn't taken seriously. But are programming languages designed for people? I would argue that they are principally designed for computers.

Another of the sins of user interfaces is letting the implementation of the interface shine through. Elements of the implementation shouldn't be an artifact of the interface. So what about the keyword "register" in C then, or the keyword "packed" in Pascal, or the fact that the types of values you can return in Pascal are limited to what can fit in a register? These are evidence that the languages are designed for the computer, not the programmer (and you can find dozens of similar artifacts).

You might argue that it is exactly the task of programming to address the computer, but I doubt it. Most programs have a job to do in terms of how they behave, not in terms of the underlying computer. Addressing the computer is just doing the job that a good optimiser should be doing for you.

But what are the major tasks of programmers? Well, most programs I have ever written contain searching and sorting, but which programming languages offer support for those activities as primitives? On the other hand, which description of a required program has ever contained reference to manipulating pointers as a major task? Not many, that's for sure.

The argument seems to be, a programming language supplies the low-level tools, which you can then use to create the high-level tools that you need. But in fact that's exactly the wrong way round. You never need the low-level tools except to build those high-level tools. It is the high-level tools which you needed in the first place, and these should be supplied as basic.

If someone said that you can have a hammer and a hand drill, and build your own power tools (building them anew each time you have to repair something) or you can have the power tools in the first place, which would you choose? Only a masochist would want to build power tools first in order to get the job done; and even if you did build the power tools yourself, would you be able to do it as well as someone who built them for a living?

So why are programming languages so bad? We have known for years that a dominant cost in producing programs is debugging, and we have known similarly for at least 20 years that else constructs increase debugging time. Is there any sign that else is disappearing? There have been language designs for years that can guarantee at compile time that NULL pointers don't get dereferenced, or that array accesses won't go out of bounds. Any signs of those being adopted?

So why are programming languages so bad? I think there are two answers. Firstly they are designed by technologists rather than people skilled in designing for people, and secondly there are no good role models.

Steven Pemberton

Contributions to Views and Feelings are welcomed. They should be around 800 words long.

Issue
Article
Vol.29 No.3, July 1997
Article
Issue