It"s true, certainly, that most people don"t choose programming languages simply based on their merits. Most programmers are told what language to use by someone else. And yet I think the effect of such external factors on the popularity of programming languages is not as great as it"s sometimes thought to be. I think a bigger problem is that a hacker"s idea of a good programming language is not the same as most language designers".
Between the two, the hacker"s opinion is the one that matters. Programming languages are not theorems. They"re tools, designed for people, and they have to be designed to suit human strengths and weaknesses as much as shoes have to be designed for human feet. If a shoe pinches when you put it on, it"s a bad shoe, however elegant it may be as a piece of sculpture.
It may be that the majority of programmers can"t tell a good language from a bad one. But that"s no different with any other tool. It doesn"t mean that it"s a waste of time to try designing a good language. Expert hackers can tell a good language when they see one, and they"ll use it. Expert hackers are a tiny minority, admittedly, but that tiny minority write all the good software, and their influence is such that the rest of the programmers will tend to use whatever language they use. Often, indeed, it is not merely influence but command: often the expert hackers are the very people who, as their bosses or faculty advisors, tell the other programmers what language to use.
The opinion of expert hackers is not the only force that determines the relative popularity of programming languages-legacy software (Fortran, Cobol) and hype (Ada, Java) also play a role-but I think it is the most powerful force over the long term. Given an initial critical ma.s.s and enough time, a programming language probably becomes about as popular as it deserves to be. And popularity further separates good languages from bad ones, because feedback from real live users always leads to improvements. Look at how much any popular language has changed during its life. Perl and Fortran are extreme cases, but even Lisp has changed a lot.
So whether or not a language has to be good to be popular, I think a language has to be popular to be good. And it has to stay popular to stay good. The state of the art in programming languages doesn"t stand still. Though there is little change in the depths of the sea, in core language features, there is quite a lot up on the surface, in things like libraries and environments.
Of course, hackers have to know about a language before they can use it. How are they to hear? From other hackers. But there has to be some initial group of hackers using the language for others even to hear about it. I wonder how large this group has to be; how many users make a critical ma.s.s? Off the top of my head, I"d say twenty. If a language had twenty separate users, meaning twenty users who decided on their own to use it, I"d consider it to be real.
Getting there can"t be easy. I would not be surprised if it is harder to get from zero to twenty than from twenty to a thousand. The best way to get those initial twenty users is probably a trojan horse: give people an application they want, which happens to be written in the new language.
14.2. External Factors
Let"s start by acknowledging one external factor that does affect the popularity of a programming language. To become popular, a programming language has to be the scripting language of a popular system. Fortran and Cobol were the scripting languages of early IBM mainframes. C was the scripting language of Unix, and so, later, were Perl and Python. Tcl is the scripting language of Tk, Visual Basic of Windows, (a form of) Lisp of Emacs, PHP of web servers, and Java and Javascript of web browsers.
Programming languages don"t exist in isolation. To hack is a transitive verb-hackers are usually hacking something-and in practice languages are judged relative to whatever they"re used to hack. So if you want to design a popular language, you either have to supply more than a language, or you have to design your language to replace the scripting language of some existing system.
One way to describe this situation is to say that a language isn"t judged on its own merits. Another view is that a programming language really isn"t a programming language unless it"s also the scripting language of something. This only seems unfair if it comes as a surprise. I think it"s no more unfair than expecting a programming language to have, say, an implementation. It"s just part of what a programming language is.
A programming language does need a good implementation, of course, and this must be free. Companies will pay for software, but individual hackers won"t, and it"s the hackers you need to attract.
A language also needs to have a book about it. The book should be thin, wellwritten, and full of good examples. Kernighan and Ritchie"s C Programming Language is the ideal here. At the moment I"d almost say that a language has to have a book published by O"Reilly. That"s becoming the test of mattering to hackers.
There should be online doc.u.mentation as well. In fact, the book can start as online doc.u.mentation. But physical books aren"t obsolete yet. Their format is convenient, and the de facto censorship imposed by publishers is a useful if imperfect filter. Bookstores are one of the most important places for learning about new languages.
14.3. Succinctness
Given that you can supply the three things any language needs-a free implementation, a book, and something to hack-how do you make a language that hackers will like?
One thing hackers like is succinctness. Hackers are lazy, in the same way that mathematicians and modernist architects are lazy: they hate anything extraneous. It would not be far from the truth to say that a hacker about to write a program decides what language to use, at least subconsciously, based on the total number of characters he"ll have to type. If this isn"t precisely how hackers think, a language designer would do well to act as if it were.
The most important kind of succinctness comes from making the language more abstract. It is to get this that we use highlevel languages in the first place. So it would seem that the more of it you can get, the better. A language designer should always be looking at programs and asking, is there some way to express this in fewer tokens? If you can do something that makes many different programs shorter, it"s probably not a coincidence: you"ve probably discovered a useful new abstraction.
It"s a mistake to try to baby the user with long-winded expressions meant to resemble English. Cobol is notorious for this flaw. A hacker would consider being asked to write add x to y giving z instead of z = x + y as something between an insult to his intelligence and a sin against G.o.d.
Succinctness is one place where statically typed languages lose. All other things being equal, no one wants to begin a program with a bunch of declarations. Anything that can be implicit, should be. The amount of boilerplate in a Java h.e.l.lo-world program is almost enough evidence, by itself, to convict.
Individual tokens should be short as well. Perl and Common Lisp occupy opposite poles on this question. Perl programs can be cryptically dense, while the names of built-in Common Lisp operators are comically long. The designers of Common Lisp probably expected users to have text editors that would type these long names for them. But the cost of a long name is not just the cost of typing it. There is also the cost of reading it, and the cost of the s.p.a.ce it takes up on your screen.
14.4. Hackability
There is one thing more important than succinctness to a hacker: being able to do what you want. In the history of programming languages, a surprising amount of effort has gone into preventing programmers from doing things considered to be improper. This is a dangerously presumptuous plan. How can the language designer know what the programmer will need to do? I think language designers would do better to consider their target user to be a genius who will need to do things they never antic.i.p.ated, rather than a b.u.mbler who needs to be protected from himself. The b.u.mbler will shoot himself in the foot anyway. You may save him from referring to variables in another module, but you can"t save him from writing a badly designed program to solve the wrong problem, and taking forever to do it.
Good programmers often want to do dangerous and unsavory things. By unsavory I mean things that go behind whatever semantic facade the language is trying to present: getting hold of the internal representation of some highlevel abstraction, for example. Hackers like to hack, and hacking means getting inside things and second-guessing the original designer.
Let yourself be second-guessed . When you make any tool, people use it in ways you didn"t intend, and this is especially true of a highly articulated tool like a programming language. Many a hacker will want to tweak your semantic model in a way that you never imagined. I say, let them. Give the programmer access to as much internal stuff as you can.
A hacker may only want to subvert the intended model of things once or twice in a big program. But what a difference it makes to be able to. And it may be more than a question of just solving a problem. There is a kind of pleasure here too. Hackers share the surgeon"s secret pleasure in poking about in gross innards, the teenager"s secret pleasure in popping zits. For boys, at least, certain kinds of horrors are fascinating. Maxim magazine publishes an annual volume of photographs, containing a mix of pin-ups and grisly accidents. They know their audience.
A really good language should be both clean and dirty: cleanly designed, with a small core of well understood and highly orthogonal operators, but dirty in the sense that it lets hackers have their way with it. C is like this. So were the early Lisps. A real hacker"s language will always have a slightly raffish character.
A good programming language should have features that make the kind of people who use the phrase "software engineering" shake their heads disapprovingly. At the other end of the continuum are languages like Pascal, models of propriety that are good for teaching and not much else.
14.5. Throwaway Programs
To be attractive to hackers, a language must be good for writing the kinds of programs they want to write. And that means, perhaps surprisingly, that it has to be good for writing throwaway programs.
A throwaway program is a program you write quickly for some limited task: a program to automate some system administration task, or generate test data for a simulation, or convert data from one format to another. The surprising thing about throwaway programs is that, like the "temporary" buildings built at so many American universities during World War II, they often don"t get thrown away. Many evolve into real programs, with real features and real users.
I have a hunch that the best big programs begin life this way, rather than being designed big from the start, like the Hoover Dam. It"s terrifying to build something big from scratch. When people take on a project that"s too big, they become overwhelmed. The project either gets bogged down, or the result is sterile and wooden: a shopping mall rather than a real downtown, Brasilia rather than Rome, Ada rather than C.
Another way to get a big program is to start with a throwaway program and keep improving it. This approach is less daunting, and the design of the program benefits from evolution. Programs that did evolve this way are probably still written in whatever language they were first written in, because it"s rare for a program to be ported, except for political reasons. And so, paradoxically, if you want to make a language that is used for big systems, you have to make it good for writing throwaway programs, because that"s where big systems come from.
Perl is a striking example of this idea. It was not only designed for writing throwaway programs, but was pretty much a throwaway program itself. Perl began life as a collection of utilities for generating reports, and only evolved into a programming language as the throwaway programs people wrote in it grew larger. It was not until Perl 5 (if then) that the language was suitable for writing serious programs, and yet it was already ma.s.sively popular.
What makes a language good for throwaway programs? To start with, it must be readily available. A throwaway program is something you expect to write in an hour. So the language probably must already be installed on the computer you"re using. It can"t be something you have to install before you use it. It has to be there. C was there because it came with the operating system. Perl was there because it was originally a tool for system administrators, and yours had already installed it.
Being available means more than being installed, though. An interactive language, with a command-line interface, is more available than one that you have to compile and run separately. A popular programming language should be interactive, and start up fast.
Another thing you want in a throwaway program is succinctness. This is always attractive to hackers, and never more so than in a program they expect to turn out in an hour.
14.6. Libraries
Of course the ultimate in succinctness is to have the program already written for you, and merely to call it. And this brings us to what I think will be an increasingly important feature of programming languages: libraries. Perl wins because it has large libraries for manipulating strings. This cla.s.s of library function is especially important for throwaway programs, which are often originally written for converting or extracting data. Many Perl programs probably begin as just a couple library calls stuck together.
I think a lot of the advances that happen in programming languages in the next fifty years will have to do with library functions. I think future programming languages will have libraries that are as carefully designed as the core language. Programming language design will not be about whether to make your language statically or dynamically typed, or object-oriented, or functional, or whatever, so much as about how to design great libraries. The kind of language designers who like to think about how to design type systems may shudder at this. It"s almost like writing applications! Well, too bad. Languages are for programmers, and libraries are what programmers need.
It"s hard to design good libraries. It"s not simply a matter of writing a lot of code. Once the libraries get too big, it can sometimes take longer to find the function you need than to write it yourself. Libraries need to be designed using a small set of orthogonal operators, just like the core language. It ought to be possible for the programmer to guess what library call will do what he needs.
14.7. Efficiency
A good language, as everyone knows, should generate fast code. But in practice I don"t think fast code comes primarily from things you do in the design of the language. As Knuth pointed out long ago, speed only matters in certain critical bottlenecks. And as many programmers have observed since, one is often mistaken about where these bottlenecks are.
So, in practice, the way to get fast code is to have a good profiler, rather than by, say, making the language statically typed. You don"t need to know the type of every argument in every call in the program. You do need to be able to declare the types of arguments in the bottlenecks. And even more, you need to be able to find out where the bottlenecks are.
One complaint people have had with very high level languages like Lisp is that it"s hard to tell what"s expensive. This might be true. It might also be inevitable, if you want to have a very abstract language. And in any case I think good profiling would go a long way toward fixing the problem: you"d soon learn what was expensive.
Part of the problem here is social. Language designers like to write fast compilers. That"s how they measure their skill. They think of the profiler as an add-on, at best. But in practice a good profiler may do more to improve the speed of actual programs written in the language than a compiler that generates fast code. Here, again, language designers are somewhat out of touch with their users. They do a really good job of solving slightly the wrong problem.
It might be a good idea to have an active profiler-to push performance data to the programmer instead of waiting for him to ask for it. For example, the editor could display bottlenecks in red when the programmer edits the source code.
Another approach would be to somehow represent what"s happening in running programs. This would be an especially big win in server-based applications, where you have lots of running programs to look at. An active profiler could show graphically what"s happening in memory as a program"s running, or even make sounds that tell what"s happening.
Sound is a good cue to problems. At Viaweb we had a big board of dials showing what was happening to our web servers. The hands were moved by little servomotors that made a slight noise when they turned. I couldn"t see the board from my desk, but I found that I could tell immediately, by the sound, when there was a problem with a server.
It might even be possible to write a profiler that would automatically detect inefficient algorithms. I would not be surprised if certain patterns of memory access turned out to be sure signs of bad algorithms. If there were a little guy running around inside the computer executing our programs, he would probably have as long and plaintive a tale to tell about his job as a federal government employee. I often have a feeling that I"m sending the processor on a lot of wild goose chases, but I"ve never had a good way to look at what it"s doing.
A number of languages now compile into byte code, which is then executed by an interpreter. This is usually done to make the implementation easier to port, but it could be a useful language feature. It might be a good idea to make the byte code an official part of the language, and to allow programmers to use inline byte code in bottlenecks. Then such optimizations would be portable too.
The nature of speed, as perceived by the end user, may be changing. With the rise of server-based applications, more and more programs may turn out to be I/O-bound. It will be worth making I/O fast. The language can help with straight forward measures like simple, fast, formatted output functions, and also with deep structural changes like caching and persistent objects.
Users are interested in response time. But another kind of efficiency will be increasingly important: the number of simultaneous users you can support per processor. Many of the interesting applications written in the future will be server-based, and the number of users per server is the critical question for anyone hosting such applications. In the capital cost of a business offering a server-based application, this is the divisor.
For years, efficiency hasn"t mattered much inmost end-user applications. Developers have been able to a.s.sume that users would have increasingly fast processors sitting on their desks. And Parkinson"s Law has proven as powerful as Moore"s. Software has bloated to consume the resources available. That will change with server-based applications, because hardware and software will be supplied together. For companies that offer server-based applications, it will make a big difference to the bottom line how many users they can support per server.
In some applications, the processor will be the limiting factor, and execution speed will be the most important thing to optimize. But often memory will be the limit; the number of simultaneous users will be determined by the amount of memory you need for each user"s data. The language can help here too. Good support for threads will enable all the users to share a single heap. It may also help to have persistent objects and/or language-level support for lazy loading.
14.8. Time
The last ingredient a popular language needs is time. No one wants to write programs in a language that might go away, as so many programming languages do. So most hackers will tend to wait until a language has been around for a couple years before even considering it.
Inventors of wonderful new things are often surprised to discover this, but you need time to get any message through to people. A friend of mine rarely does anything the first time someone asks him. He knows that people sometimes ask for things they turn out not to want. To avoid wasting his time, he waits till the third or fourth time he"s asked to do something. By then whoever"s asking him may be fairly annoyed, but at least they probably really do want whatever they"re asking for.
Most people have learned to do a similar sort of filtering on new things they hear about. They don"t even start paying attention until they"ve heard about something ten times. They"re perfectly justified: the majority of hot new whatevers do turn out to be a waste of time, and eventually go away. By delaying learning VRML, I avoided having to learn it at all.
So anyone who invents something new has to expect to keep repeating their message for years before people will start to get it. It took us years to get it through to people that Viaweb"s software didn"t have to be downloaded. The good news is, simple repet.i.tion solves the problem. All you have to do is keep telling your story, and eventually people will start to hear. It"s not when people notice you"re there that they pay attention; it"s when they notice you"re still there.
It"s just as well that it usually takes a while to gain momentum. Most technologies evolve a good deal even after they"re first launched programming languages especially. Nothing could be better for a new technology than a few years of being used only by a small number of early adopters. Early adopters are sophisticated and demanding, and quickly flush out whatever flaws remain in your technology. When you only have a few users you can be in close contact with all of them. And early adopters are forgiving when you improve your system, even if this causes some breakage.
There are two ways new technology gets introduced: the organic growth method, and the big bang method. The organic growth method is exemplified by the cla.s.sic seat-of-the-pants underfunded garage startup. A couple guys, working in obscurity, develop some new technology. They launch it with no marketing and initially have only a few (fanatically devoted) users. They continue to improve the technology, and meanwhile their user base grows by word of mouth. Before they know it, they"re big.
The other approach, the big bang method, is exemplified by the VC-backed, heavily marketed startup. They rush to develop a product, launch it with great publicity, and immediately (they hope) have a large user base.
Generally, the garage guys envy the big bang guys. The big bang guys are smooth and confident and respected by the VCs. They can afford the best of everything, and the PR campaign surrounding the launch has the side effect of making them celebrities. The organic growth guys, sitting in their garage, feel poor and unloved. And yet I think they are often mistaken to feel sorry for themselves. Organic growth seems to yield better technology and richer founders than the big bang method. If you look at the dominant technologies today, you"ll find that most of them grew organically.
This pattern doesn"t only apply to companies. You see it in research too. Multics and Ada were big-bang projects, and Unix and C were organic growth projects.
14.9. Redesign
"The best writing is rewriting," wrote E. B. White. Every good writer knows this, and it"s true for software too. The most important part of design is redesign. Programming languages, especially, don"t get redesigned enough.
To write good software you must simultaneously keep two opposing ideas in your head. You need the young hacker"s naive faith in his abilities, and at the same time the veteran"s skepticism. You have to be able to think how hard can it be ? with one half of your brain while thinking it will never work with the other.