Helping the Average Programmer

March 10, 2005

Paul Graham is working on a new programming language called Arc. It’s a dialect of Lisp. The design philosophy of Arc is to be a language for good programmers. He argues that languages designed for good programmers last (C, Smalltalk, Lisp), while those designed for average programmers don’t (Cobol, Pascal, Ada). He forgets Basic, which was not only designed for the average programmer but for the beginner programmer. Basic is one of the most-used programming languages today!

I don’t think there’s anything inherently wrong with designing a language for good programmers, but I do think it’s a waste of time. It’s an easy problem, plus it doesn’t really contribute much. Good programmers make up a very small percentage of all the programmers, and they’re already very efficient, so making them slightly more efficent will have negligable effect on the world.

Average programmers, though, are everywhere. Make them 5% more efficient, or make them create 5% better programs, and you’ve made a huge difference. That’s why Basic (and the whole suite of Microsoft tools like Access) are so great. (Not “great” as in “good programs”, “great” as in “good for the world”.)

Arc’s design philosophy page points to the 1973 Cadillac (though any GM or Ford would have done) and the 1973 Porsche, saying that the Porsche’s design is timeless. I think that’s a great analogy, because how many people really benefited from the Porsche? Developing Arc is like improving the Porsche. Not inherently bad, but how much are you really improving people’s lives? Shouldn’t you be improving the GM car instead?

My wife Jennifer, who has a business degree, was a database programmer for several years using Access. Access allowed her to contribute in a significant way to her company. The resulting database was solid and useful; maybe not what an Oracle expert would have done, but the company couldn’t afford that anyway, so it was either Jennifer’s Access database or a bunch of Excel files. Arc will not help that company, nor any of the thousands like it.

Instead of making Arc, for example, make a system that creates better dialog boxes. Dialog boxes are used all the time and there are no good tools to create them. You either have to use the built-in ones that just have “OK” and “Cancel”, or make your own by dragging a bunch of widgets onto a canvas and programming all the interaction. So you either end up with bizarre dialog boxes that offer you a binary choice phrased like, “To run the debugger press OK, to continue press Cancel” or you get ugly dialog boxes with bad spacing and alignment and where Cancel is the default button.

My friend Drew Olbrich put together a library that lets users create dialog boxes by just specifying high-level structures like, “I want to know the first name, last name, and company of the user” and the program lays out the labels, text boxes, and buttons, aligns the baseline of the labels with the baseline of the text boxes, and generally makes it look beautiful. It’s extremely flexible in case you don’t want the default, but by encouraging you to use the defaults the program lets average programmers do what even good programmers have trouble doing well.

(Tragically, his programs can only be used internally to the company where he works. You might think that “tragically” is too melodramatic a word, but you also haven’t seen his programs.)

Designing tools and languages for average programmers is hard. Drew spent many months on that program, working out all the different dialog boxes people might want and all their special needs. Why hasn’t Microsoft done this? Probably because the temptation for good programmers is to make tools for other good programmers.

What will Arc accomplish? It will help several dozen programmers save time by writing “fn” instead of “lambda”. In other words, it will accomplish exactly nothing (statistically speaking). What a waste of our efforts! I’m guessing that making the average programmer more efficient is not a very useful goal (they don’t care about efficiency), but making their programs better (with the same amount of work) would make a giant difference. I don’t know how to do that. I could write a library for Visual Basic users, but no one will buy it. (Jennifer would have never fished around for a library to make better dialog boxes.) It needs to fall into their lap.