May 2001(These are some notes I madefor a panel discussion on programming language designat MIT on May 10, 2001.)1. Programming Languages Are for People.Programming languagesare how people talk to computers. The computer would be just ashappy speaking any language that was unambiguous. The reason wehave high level languages is because people can't deal withmachine language. The point of programminglanguages is to prevent our poor frail human brains from being overwhelmed by a mass of detail.Architects know that some kinds of design problems are more personalthan others. One of the cleanest, most abstract design problemsis designing bridges. There your job is largely a matter of spanninga given distance with the least material. The other end of thespectrum is designing chairs. Chair designers have to spend theirtime thinking about human butts.Software varies in the same way. Designing algorithms for routingdata through a network is a nice, abstract problem, like designingbridges. Whereas designing programming languages is like designingchairs: it's all about dealing with human weaknesses.Most of us hate to acknowledge this. Designing systems of greatmathematical elegance sounds a lot more appealing to most of usthan pandering to human weaknesses. And there is a role for mathematicalelegance: some kinds of elegance make programs easier to understand.But elegance is not an end in itself.And when I say languages have to be designed to suit human weaknesses,I don't mean that languages have to be designed for bad programmers.In fact I think you ought to design for the best programmers, buteven the best programmers have limitations. I don't think anyonewould like programming in a language where all the variables werethe letter x with integer subscripts.2. Design for Yourself and Your Friends.If you look at the history of programming languages, a lot of the bestones were languages designed for their own authors to use, and alot of the worst ones were designed for other people to use.When languages are designed for other people, it's always a specificgroup of other people: people not as smart as the language designer.So you get a language that talks down to you. Cobol is the mostextreme case, but a lot of languages are pervaded by this spirit.It has nothing to do with how abstract the language is. C is prettylow-level, but it was designed for its authors to use, and that'swhy hackers like it.The argument for designing languages for bad programmers is thatthere are more bad programmers than good programmers. That may beso. But those few good programmers write a disproportionatelylarge percentage of the software.I'm interested in the question, how do you design a language thatthe very best hackers will like? I happen to think this isidentical to the question, how do you design a good programminglanguage?, but even if it isn't, it is at least an interestingquestion.3. Give the Programmer as Much Control as Possible.Many languages(especially the ones designed for other people) have the attitudeof a governess: they try to prevent you fromdoing things that they think aren't good for you. I like the opposite approach: give the programmer as muchcontrol as you can.When I first learned Lisp, what I liked most about it wasthat it considered me an equal partner. In the other languagesI had learned up till then, there was the language and there was my program, written in the language, and the two were very separate.But in Lisp the functions and macros I wrote were just like thosethat made up the language itself. I could rewrite the languageif I wanted. It had the same appeal as open-source software.4. Aim for Brevity.Brevity is underestimated and even scorned.But if you look into the hearts of hackers, you'll see that theyreally love it. How many times have you heard hackers speak fondlyof how in, say, APL, they could do amazing things with just a couplelines of code? I think anything that really smart people reallylove is worth paying attention to.I think almost anythingyou can do to make programs shorter is good. There should be lotsof library functions; anything that can be implicit should be;the syntax should be terse to a fault; even the names of thingsshould be short.And it's not only programs that should be short. The manual shouldbe thin as well. A good part of manuals is taken up with clarificationsand reservations and warnings and special cases. If you force yourself to shorten the manual, in the best case you do it by fixingthe things in the language that required so much explanation.5. Admit What Hacking Is.A lot of people wish that hacking wasmathematics, or at least something like a natural science. I thinkhacking is more like architecture. Architecture isrelated to physics, in the sense that architects have to designbuildings that don't fall down, but the actual goal of architectsis to make great buildings, not to make discoveries about statics.What hackers like to do is make great programs.And I think, at least in our own minds, we have to remember that it'san admirable thing to write great programs, even when this work doesn't translate easily into the conventional intellectualcurrency of research papers. Intellectually, it is just asworthwhile to design a language programmers will love as it is to design ahorrible one that embodies some idea you can publish a paperabout.1. How to Organize Big Libraries?Libraries are becoming anincreasingly important component of programming languages. They'realso getting bigger, and this can be dangerous. If it takes longerto find the library function that will do what you want than itwould take to write it yourself, then all that code is doing nothingbut make your manual thick. (The Symbolics manuals were a case in point.) So I think we will have to work on ways to organizelibraries. The ideal would be to design them so that the programmercould guess what library call would do the right thing.2. Are People Really Scared of Prefix Syntax?This is an openproblem in the sense that I have wondered about it for years andstill don't know the answer. Prefix syntax seems perfectly naturalto me, except possibly for math. But it could be that a lot of Lisp's unpopularity is simply due to having an unfamiliar syntax. Whether to do anything about it, if it is true, is another question. 3. What Do You Need for Server-Based Software?I think a lot of the most exciting new applications that get writtenin the next twenty years will be Web-based applications, meaningprograms that sit on the server and talk to you through a Webbrowser. And to write these kinds of programs we may need somenew things.One thing we'll need is support for the new way that server-based apps get released. Instead of having one or two big releases ayear, like desktop software, server-based apps get released as aseries of small changes. You may have as many as five or tenreleases a day. And as a rule everyone will always use the latestversion.You know how you can design programs to be debuggable?Well, server-based software likewise has to be designed to bechangeable. You have to be able to change it easily, or at leastto know what is a small change and what is a momentous one.Another thing that might turn out to be useful for server basedsoftware, surprisingly, is continuations. In Web-based softwareyou can use something like continuation-passing style to get theeffect of subroutines in the inherently stateless world of a Websession. Maybe it would be worthwhile having actual continuations,if it was not too expensive.4. What New Abstractions Are Left to Discover?I'm not sure howreasonable a hope this is, but one thing I would really love to do, personally, is discover a new abstraction-- something that wouldmake as much of a difference as having first class functions orrecursion or even keyword parameters. This may be an impossibledream. These things don't get discovered that often. But I am alwayslooking.1. You Can Use Whatever Language You Want.Writing applicationprograms used to mean writing desktop software. And in desktopsoftware there is a big bias toward writing the application in thesame language as the operating system. And so ten years ago,writing software pretty much meant writing software in C.Eventually a tradition evolved:application programs must not be written in unusual languages. And this tradition had so long to develop that nontechnical peoplelike managers and venture capitalists also learned it.Server-based software blows away this whole model. With server-basedsoftware you can use any language you want. Almost nobody understandsthis yet (especially not managers and venture capitalists).A few hackers understand it, and that's why we even hearabout new, indy languages like Perl and Python. We're not hearingabout Perl and Python because people are using them to write Windowsapps.What this means for us, as people interested in designing programminglanguages, is that there is now potentially an actual audience forour work.2. Speed Comes from Profilers.Language designers, or at leastlanguage implementors, like to write compilers that generate fastcode. But I don't think this is what makes languages fast for users.Knuth pointed out long ago that speed only matters in a few criticalbottlenecks. And anyone who's tried it knows that you can't guesswhere these bottlenecks are. Profilers are the answer.Language designers are solving the wrong problem. Users don't needbenchmarks to run fast. What they need is a language that can showthem what parts of their own programs need to be rewritten. That'swhere speed comes from in practice. So maybe it would be a net win if language implementors took half the time they wouldhave spent doing compiler optimizations and spent it writing agood profiler instead.3. You Need an Application to Drive the Design of a Language.This may not be an absolute rule, but it seems like the best languagesall evolved together with some application they were being used towrite. C was written by people who needed it for systems programming.Lisp was developed partly to do symbolic differentiation, andMcCarthy was so eager to get started that he was writing differentiationprograms even in the first paper on Lisp, in 1960.It's especially good if your application solves some new problem.That will tend to drive your language to have new features that programmers need. I personally am interested in writinga language that will be good for writing server-based applications.[During the panel, Guy Steele also made this point, with theadditional suggestion that the application should not consist ofwriting the compiler for your language, unless your languagehappens to be intended for writing compilers.]4. A Language Has to Be Good for Writing Throwaway Programs.You know what a throwaway program is: something you write quickly forsome limited task. I think if you looked around you'd find that a lot of big, serious programs started as throwaway programs. Iwould not be surprised if most programs started as throwawayprograms. And so if you want to make a language that's good forwriting software in general, it has to be good for writing throwawayprograms, because that is the larval stage of most software.5. Syntax Is Connected to Semantics.It's traditional to think ofsyntax and semantics as being completely separate. This willsound shocking, but it may be that they aren't.I think that what you want in your language may be relatedto how you express it.I was talking recently to Robert Morris, and he pointed out thatoperator overloading is a bigger win in languages with infixsyntax. In a language with prefix syntax, any function you defineis effectively an operator. If you want to define a plus for anew type of number you've made up, you can just define a new functionto add them. If you do that in a language with infix syntax,there's a big difference in appearance between the use of anoverloaded operator and a function call.1. New Programming Languages.Back in the 1970sit was fashionable to design new programming languages. Recentlyit hasn't been. But I think server-based software will make new languages fashionable again. With server-based software, you canuse any language you want, so if someone does design a language thatactually seems better than others that are available, there will bepeople who take a risk and use it.2. Time-Sharing.Richard Kelsey gave this as an idea whose timehas come again in the last panel, and I completely agree with him.My guess (and Microsoft's guess, it seems) is that much computingwill move from the desktop onto remote servers. In other words, time-sharing is back. And I think there will need to be supportfor it at the language level. For example, I know that Richardand Jonathan Rees have done a lot of work implementing process scheduling within Scheme 48.3. Efficiency.Recently it was starting to seem that computerswere finally fast enough. More and more we were starting to hearabout byte code, which implies to me at least that we feel we havecycles to spare. But I don't think we will, with server-basedsoftware. Someone is going to have to pay for the servers thatthe software runs on, and the number of users they can support permachine will be the divisor of their capital cost.So I think efficiency will matter, at least in computationalbottlenecks. It will be especially important to do i/o fast,because server-based applications do a lot of i/o.It may turn out that byte code is not a win, in the end. Sun andMicrosoft seem to be facing off in a kind of a battle of the bytecodes at the moment. But they're doing it because byte code is aconvenient place to insert themselves into the process, not becausebyte code is in itself a good idea. It may turn out that thiswhole battleground gets bypassed. That would be kind of amusing.1. Clients.This is just a guess, but my guess is thatthe winning model for most applications will be purely server-based.Designing software that works on the assumption that everyone will have your client is like designing a society on the assumption thateveryone will just be honest. It would certainly be convenient, butyou have to assume it will never happen.I think there will be a proliferation of devices that have somekind of Web access, and all you'll be able to assume about them isthat they can support simple html and forms. Will you have abrowser on your cell phone? Will there be a phone in your palm pilot? Will your blackberry get a bigger screen? Will you be ableto browse the Web on your gameboy? Your watch? I don't know. And I don't have to know if I bet oneverything just being on the server. It'sjust so much more robust to have all the brains on the server.2. Object-Oriented Programming.I realize this is acontroversial one, but I don't think object-oriented programmingis such a big deal. I think it is a fine model for certain kindsof applications that need that specific kind of data structure, like window systems, simulations, and cad programs. But I don'tsee why it ought to be the model for all programming.I think part of the reason people in big companies like object-orientedprogramming is because it yields a lot of what looks like work.Something that might naturally be represented as, say, a list ofintegers, can now be represented as a class with all kinds ofscaffolding and hustle and bustle.Another attraction ofobject-oriented programming is that methods give you some of theeffect of first class functions. But this is old news to Lispprogrammers. When you have actual first class functions, you canjust use them in whatever way is appropriate to the task at hand,instead of forcing everything into a mold of classes and methods.What this means for language design, I think, is that you shouldn'tbuild object-oriented programming in too deeply. Maybe theanswer is to offer more general, underlying stuff, and let people designwhatever object systems they want as libraries.3. Design by Committee.Having your language designed by a committee is a big pitfall, and not just for the reasons everyone knows about. Everyoneknows that committees tend to yield lumpy, inconsistent designs. But I think a greater danger is that they won't take risks.When one person is in charge he can take risksthat a committee would never agree on.Is it necessary to take risks to design a good language though?Many people might suspectthat language design is something where you should stick fairlyclose to the conventional wisdom. I bet this isn't true.In everything else people do, reward is proportionate to risk.Why should language design be any different?
