-11487

183637

Commentary: Paul Graham on `Beating the Averages'

	Title	Graham	David Ness
	Initial Comment	Graham's paper is a plea for using Lisp, or languages like Lisp, for software development. Interesting, as Graham usually is, but the argument ultimately fails on many grounds, not the least of which is that there isn't much evidence presented that Graham's approach works for a very wide community of developers. A few interesting painters paint with ink-blob guns, but it isn't a technology that one would recommend to painters in general, even though some would---no doubt---do quite well with it.
	Site	(This article is derived from a talk given at the 2001 Franz Developer Symposium. It describes how we used Lisp to write Viaweb Store, which is still, as Yahoo! Store, the most popular e-commerce software, running about 20,000 stores.)	Is it still in Lisp? If so, have there been any political battles fought to keep it as the language? If not, why isn't it?
	History	In the summer of 1995, my friend Robert Morris and I started a startup called Viaweb. Our plan was to write software that would let end users build online stores. What was novel about this software, at the time, was that it ran on our server, using ordinary Web pages as the interface.	Nice problem, nice timing.
		Web-Based Application: A lot of people could have been having this idea at the same time, of course, but as far as I know, Viaweb was the first Web-based application. It seemed such a novel idea to us that we named the company after it: Viaweb, because our software worked via the Web, instead of running on your desktop computer.	Lots of systems ran on `servers' on LANs, and most of the delivery of time-shared results---the last round of technology prior to the growth of the net, worked in this way. So I fail to see what's really `first' about it, but that probably doesn't matter much anyway, it's unclear to me why it's worth making this claim. I don't see that any particular consequences flow from it.
		Written in Lisp: Another unusual thing about this software was that it was written primarily in a programming language called Lisp. It was one of the first big end-user applications to be written in Lisp, which up till then had been used mostly in universities and research labs. Lisp gave us a great advantage over competitors using less powerful languages.	Probably true. Of course lots of programs had been written in a whole variety of other languages, but Lisp hadn't been much used for this kind of purpose. It still isn't.
	The Secret Weapon	The Secret Weapon	I'm assuming that we will get to the point of understanding what's `secret' about this, but again it probably doesn't matter to the central thread of the argument very much.
		Eric Raymond: Eric Raymond has written an essay called "How to Become a Hacker," and in it, among other things, he tells would-be hackers what languages they should learn. He suggests starting with Python and Java, because they are easy to learn. The serious hacker will also want to learn C, in order to hack Unix, and Perl for system administration and cgi scripts. Finally, the truly serious hacker should consider learning Lisp.	Not a bad list, but it misses data base operations and array processing languages, some of which have proven to be extemely important in the handling of financial data, a particularly important sub-class of problem that is dealt with by lots of systems, and that consumes a great deal of programming energy. The relationship of C and Unix is unclear to me, C has been useful on all kinds of system since its earliest PC implementations on CPM, and certainly has as large a role to play in Windows environments as it does in Unix. So this makes the case questionnable, but again it hardly seems very central to what is going on. The argument that `the truly serious hacker should consider learning Lisp' is made by assertion only, and not defended by anything else.
		Lisp Worth Learning: Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.	I have not doubt whatsoever that this is true of the author. And perhaps he believes it is true of everyone else. But if so, it is an incredibly naive view. Unless, of course, the only argument being made is the trivial one that anything is worth learning as it might be the source of `profound enlightenment' for some. In my experience, I have learned Lisp and not found it very enlightening, while I have found APL 650 Machine Language and PostScript to the be source of considerable enlightenment for me---though I probably wouldn't recommend any of them to others.
		The Latin Argument: This is the same argument you tend to hear for learning Latin. It won't get you a job, except perhaps as a classics professor, but it will improve your mind, and make you a better writer in languages you do want to use, like English.	A naive argument at best. Most of what is claimed for Latin could certainly also be claimed for German (see Paul Tillich's notes in The Protestant Era), with the added supplement that German has many other uses as well.
		Stretched Too Far: But wait a minute. This metaphor doesn't stretch that far. The reason Latin won't get you a job is that no one speaks it. If you write in Latin, no one can understand you. But Lisp is a computer language, and computers speak whatever language you, the programmer, tell them to.	The reason latin won't get you a job---perhaps outside of The Church---is that those who can communicate with it, generally also can communicate using other languages these days. It is no longer the lingua framca of international communication.
		Use It?: So if Lisp makes you a better programmer, like he says, why wouldn't you want to use it? If a painter were offered a brush that would make him a better painter, it seems to me that he would want to use it in all his paintings, wouldn't he? I'm not trying to make fun of Eric Raymond here. On the whole, his advice is good. What he says about Lisp is pretty much the conventional wisdom. But there is a contradiction in the conventional wisdom: Lisp will make you a better programmer, and yet you won't use it.	This is truly a terrible argument. No painter would expect a particular brush to be better for all paintings. The painting on the roof of the Sistine Chapes surely requires a different brush than the Mona Lisa. It is silly to say If a painter were offered a brush ... he would want to use it in all his paintings. In addition, there may well be a strong interaction between a brush and a painter. The Brush for one painter may not work at all well for another. Same for programming languages.
		You Should: Why not? Programming languages are just tools, after all. If Lisp really does yield better programs, you should use it. And if it doesn't, then who needs it?	Ok. Needs to be slightly rephrased `If Lisp really does yield better programs for you, you should use it. But otherwise, ok.
		Natural Monopolies: This is not just a theoretical question. Software is a very competitive business, prone to natural monopolies. A company that gets software written faster and better will, all other things being equal, put its competitors out of business. And when you're starting a startup, you feel this very keenly. Startups tend to be an all or nothing proposition. You either get rich, or you get nothing. In a startup, if you bet on the wrong technology, your competitors will crush you.	Just how often in the history of the recent rise and fall of the .COM were the outcomes determined by the quality of the software involved. I'd say that in my experience the number was very small. Almost all of the failures were due to a blow-up in the `business plan' not to badly (or well) executed software. While it might be consoling for a programmer to believe that it is the quality of his/her software that determines the future of the company, we surely have a lot of evidence that this is not the case in a great number of situations. Has Windows developed a 90%+ share of the market by being better software? Quality of software is only a tiny part of what makes a company successful or unsuccessful.
		Instincts: Robert and I both knew Lisp well, and we couldn't see any reason not to trust our instincts and go with Lisp. We knew that everyone else was writing their software in C++ or Perl. But we also knew that that didn't mean anything. If you chose technology that way, you'd be running Windows. When you choose technology, you have to ignore what other people are doing, and consider only what will work the best.	Again, a naive view. Quite typical of a programmer-centric view that overemphasises and overglorifies the importance of the software, but no surprise in these kind of circumstances.
		Startup: This is especially true in a startup. In a big company, you can do what all the other big companies are doing. But a startup can't do what all the other startups do. I don't think a lot of people realize this, even in startups.	Surely an insignificant part. In the incredibly unlikely case that the only difference between two startups is the software---not the other capabilities of the staff, the depth of the financing, prior experience of the participants, ...---there is not even a guarrantee that the `better' software (where better is measured by some programmers definition of `better') will ultimately lead to success in the financial world.
		Growth: The average big company grows at about ten percent a year. So if you're running a big company and you do everything the way the average big company does it, you can expect to do as well as the average big company-- that is, to grow about ten percent a year.	Depends on what is going on, doesn't it. Lucent used to be a `big company' by most people's definition, but it never managed to make much money. Airlines were big companies, so were railroads.
		Averages: The same thing will happen if you're running a startup, of course. If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you'll go out of business. The survival rate for startups is way less than fifty percent. So if you're running a startup, you had better be doing something odd. If not, you're in trouble.	Far from true. And bad modelling and mathematics at that. So naive that it might be a joke. But I don't think it is. Oh well.
		OS Bias: Back in 1995, we knew something that I don't think our competitors understood, and few understand even now: when you're writing software that only has to run on your own servers, you can use any language you want. When you're writing desktop software, there's a strong bias toward writing applications in the same language as the operating system. Ten years ago, writing applications meant writing applications in C. But with Web-based software, especially when you have the source code of both the language and the operating system, you can use whatever language you want.	I disagree with this point. As far as I can see there's nothing but `bulk' in using the same language to develop applications and to write an OS. By this I mean that while you unquestionably get the advantage of being able to use whatever debugging tools were made available to help with debugging the operating system, in many cases this particular technology is of little use in handling the kinds of problems that arise on the application level. Probably more important OS solve completely different kinds of problems than do lots of applications. The fact that some languages `can handle' the whole gamut of tasks ranging from OS all the way through applications appears to be something that is important to Graham, but he fails to make the case here, and I believe that that is at least partially due to the fact that the point he makes is wrong.
		Which to Use: This new freedom is a double-edged sword, however. Now that you can use any language, you have to think about which one to use. Companies that try to pretend nothing has changed risk finding that their competitors do not.	I think this wildly overemphasises software as a strategic element in corporate business. But then, time will tell. In my experience the vast majority of business outcomes are determined by the complex interplay of people, funding, competitive environment, demand for product, etc., and software is one one very small---and largely insignificant---link in the chain.
		Choosing Lisp: If you can use any language, which do you use? We chose Lisp. For one thing, it was obvious that rapid development would be important in this market. We were all starting from scratch, so a company that could get new features done before its competitors would have a big advantage. We knew Lisp was a really good language for writing software quickly, and server-based applications magnify the effect of rapid development, because you can release software the minute it's done.	This seems to me to mix two rather separate threads. I'd be happy to believe that either of them important. I see no necessary relationship between Lisp and `server-based applications'. We have delivered Lisp systems that aren't server-based, and more important we have delivered lots of server-based applications that aren't in Lisp. So the story is confounded.
		Other Companies: If other companies didn't want to use Lisp, so much the better. It might give us a technological edge, and we needed all the help we could get. When we started Viaweb, we had no experience in business. We didn't know anything about marketing, or hiring people, or raising money, or getting customers. Neither of us had ever even had what you would call a real job. The only thing we were good at was writing software. We hoped that would save us. Any advantage we could get in the software department, we would take.	I'm happy to accept this testimony at its face value. But for Viaweb to be successful, one can be reasonably sure that somewhere along the line (probably quite quickly) either some of the founders developed a skill and interest in business (Steve Jobs, for example) or that they early hired someone who did, and who was able to negotiate the corporate voyage necessary to build a functioning organization. It wasn't a choice of Lisp that influenced any of this aspect of the situation.
		An Experiment: So you could say that using Lisp was an experiment. Our hypothesis was that if we wrote our software in Lisp, we'd be able to get features done faster than our competitors, and also to do things in our software that they couldn't do. And because Lisp was so high-level, we wouldn't need a big development team, so our costs would be lower. If this were so, we could offer a better product for less money, and still make a profit. We would end up getting all the users, and our competitors would get none, and eventually go out of business. That was what we hoped would happen, anyway.	This is all pretty specious reasoning. Our first successful system and product (developed in 1970) was written in machine language and FORTRAN, but otherwise the paragraph could have been written identically about our experience. A programmer throroughly familiar with Lisp, and who likes Lisp, may well be able to create software at a furious pace. But the same can be said of lots of other languages, and similar claims might will be made for languages as divergent as K and PeopleSoft. Indeed, such claims have been made in the past by those who use high-level data base software. So, while I don't dispute the story, any notion that it is peculiarly a Lisp story does not seem correct to me.
		A Success: What were the results of this experiment? Somewhat surprisingly, it worked. We eventually had many competitors, on the order of twenty to thirty of them, but none of their software could compete with ours. We had a wysiwyg online store builder that ran on the server and yet felt like a desktop application. Our competitors had cgi scripts. And we were always far ahead of them in features. Sometimes, in desperation, competitors would try to introduce features that we didn't have. But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too.	There are server based systems and there are client based systems. There are fast systems and there are slow systems. Apparently there is an attempt here to argue that something about running on the server makes the application particularly fast. In my experience that is sometimes true and sometimes false. We have one application, for example, that would demand extremely high bandwidth if we attempted to run it on the server. This is the case with one of our systems that would place both great processing and great bandwidth demands on the system if computations were to be performed centrally. In addition, the features based argument presented here is presented again, as it has been before and will be again later, pretty much just as an assertion, without any particular evidence other than the feelings of the author. While I have no doubt the author believes them, so do people who believe in UFOs and `communication with the beyond'.
		Secrets?: It must have seemed to our competitors that we had some kind of secret weapon---that we were decoding their Enigma traffic or something. In fact we did have a secret weapon, but it was simpler than they realized. No one was leaking news of their features to us. We were just able to develop software faster than anyone thought possible.	There are (at least) two questions raised by this remark. First, and central to the whole issue is how important are features in making software successful anyway? If one looks at the record, there doesn't seem to be much evidence that it does. Indeed, in other contexts programmers often bemoan the lack of success that their favorite good languages have. Second, there is the question of how good the author is at using this particular language (he's undoubtedly very good) and whether the success reported might stem from that interaction.
		Purloined Letter: When I was about nine I happened to get hold of a copy of The Day of the Jackal, by Frederick Forsyth. The main character is an assassin who is hired to kill the president of France. The assassin has to get past the police to get up to an apartment that overlooks the president's route. He walks right by them, dressed up as an old man on crutches, and they never suspect him.	Is this the story of the purloined letter repeated in a different context? Does it matter? I doubt it. In my experience the competition is usually so very occupied with their own situation and problems that there isn't much attention paid to the competition.
		Bizzare Look: Our secret weapon was similar. We wrote our software in a weird AI language, with a bizarre syntax full of parentheses. For years it had annoyed me to hear Lisp described that way. But now it worked to our advantage. In business, there is nothing more valuable than a technical advantage your competitors don't understand. In business, as in war, surprise is worth as much as force.	K is often described as looking like `line noise'. This is a reference to the kind of garbled pattern that used to result when the communications with the telephone-based systems encountered difficulties and would often spit random characters into the middle of messages. How much surprise is worth as much as force remains to be seen.
		Keeping Quiet: And so, I'm a little embarrassed to say, I never said anything publicly about Lisp while we were working on Viaweb. We never mentioned it to the press, and if you searched for Lisp on our Web site, all you'd find were the titles of two books in my bio. This was no accident. A startup should give its competitors as little information as possible. If they didn't know what language our software was written in, or didn't care, I wanted to keep it that way.[2]	Perfectly sensible, I suppose. One of the interesting observations about software development is that the more successful it is, the less the people doing it are likely to talk about it. This is for at least two reasons. One, as Graham suggests, is why bother to talk about it. Two, is that those who are successful are generally busy building more. The less successful generally have plenty of time available to discuss what they are doing, as they really aren't doing very much. One of our early discoveries in the academic world was that if we asked for suggestions about future developments, we were more likely to get elaborate suggestions for plans from our less busy colleagues. The further one is out of the core of the practice of a field, the more time is available to spend speculating about the future.
		The Customers: The people who understood our technology best were the customers. They didn't care what language Viaweb was written in either, but they noticed that it worked really well. It let them build great looking online stores literally in minutes. And so, by word of mouth mostly, we got more and more users. By the end of 1996 we had about 70 stores online. At the end of 1997 we had 500. Six months later, when Yahoo bought us, we had 1070 users. Today, as Yahoo Store, this software continues to dominate its market. It's one of the more profitable pieces of Yahoo, and the stores built with it are the foundation of Yahoo Shopping. I left Yahoo in 1999, so I don't know exactly how many users they have now, but the last I heard there were about 20,000.	A good product combined with a market need can produce dramatic growth. As late as the middle 1950s, people were confidently predicting that the world might need a few dozen computers. Indeed, there were extravagant predictions that the largest of the companies might, themselves, need two or even three. By the 1960s we passed to thousands, and today we have more like tens of millions---particularly if we count computers that are embedded in other systems. So growth is a natural consequence of a good problem meeting up with a good way of handling the problem.
	The Blub Paradox	The Blub Paradox	I'm not sure it's worth inventing a pseudo-language to make these points, but we can reconsider that after the argument is articulated.
		What's Great abot Lisp: What's so great about Lisp? And if Lisp is so great, why doesn't everyone use it? These sound like rhetorical questions, but actually they have straightforward answers. Lisp is so great not because of some magic quality visible only to devotees, but because it is simply the most powerful language available. And the reason everyone doesn't use it is that programming languages are not merely technologies, but habits of mind as well, and nothing changes slower. Of course, both these answers need explaining.	We are visiting this point again. And this is a wrong answer, based on incorrect assumptions.
		Variable Power: I'll begin with a shockingly controversial statement: programming languages vary in power.	I'll accept that statement, with the qualification that they vary in power along several separate dimensions.
		High Level Languages: Few would dispute, at least, that high level languages are more powerful than machine language. Most programmers today would agree that you do not, ordinarily, want to program in machine language. Instead, you should program in a high-level language, and have a compiler translate it into machine language for you. This idea is even built into the hardware now: since the 1980s, instruction sets have been designed for compilers rather than human programmers.	There are many dimensions to `power'. It is naive and overly simplistic to summarize it this way. Is a hammer more powerful than a scalpel? Surely it depends on both the problem you have to solve and on the particular skills of whoever is going to wield the device. Generally a hammer is `more powerful' if your problem is building a chest of drawers, but not if you want to remove a wart. Similarly, a scalpel is a very powerful tool to a skilled surgeon, but perhaps even dangerous to someone who wants to put some boards together. So I guess I end up disputing that high level languages are more powerful than machine languages. It depends on time, place and a good deal upon circumstance.
		Machine Language: Everyone knows it's a mistake to write your whole program by hand in machine language. What's less often understood is that there is a more general principle here: that if you have a choice of several languages, it is, all other things being equal, a mistake to program in anything but the most powerful one. [3]	This is a common error. It is a bit like saying `a Nikon (you can pick your brand, I'm using cameras as an example, not trying to argue about them) is generally conceded to be the `most powerful' camera. It's a mistake to take pictures with anything else. This is, of course, manifesly untrue. First, a great many wonderful photographs are taken with cheap cameras. Second, some people find the flexibility and power of the camera steals their focus from more important issues like subject selection and composition. Third, we all live in a world of constraints and since Nikons are generally pretty expensive, using one may well cause us to compromise more in other directions. This is not necessarily a good thing. So if this is something that everyone knows then they are wrong.
		Exceptions: There are many exceptions to this rule. If you're writing a program that has to work very closely with a program written in a certain language, it might be a good idea to write the new program in the same language. If you're writing a program that only has to do something very simple, like number crunching or bit manipulation, you may as well use a less abstract language, especially since it may be slightly faster. And if you're writing a short, throwaway program, you may be better off just using whatever language has the best library functions for the task. But in general, for application software, you want to be using the most powerful (reasonably efficient) language you can get, and using anything else is a mistake, of exactly the same kind, though possibly in a lesser degree, as programming in machine language.	Another assertion of the `most powerful language' philosophy. I am getting the feeling that while I keep saying I don't understand, I simply get a repeat assertion, perhaps somewhat LOUDER and s-l-o-w-e-r. I don't buy the argument and saying it over and over again doesn't help me to understand it in greater depth.
		Low Level: You can see that machine language is very low level. But, at least as a kind of social convention, high-level languages are often all treated as equivalent. They're not. Technically the term "high-level language" doesn't mean anything very definite. There's no dividing line with machine languages on one side and all the high-level languages on the other. Languages fall along a continuum [4] of abstractness, from the most powerful all the way down to machine languages, which themselves vary in power.	I don't think that languages fall along any convenient `continuum'. For example, there are languages that are `high-level' with regard to the expression of procedures, and yet rather simplistic with regard to representation of data. Other languages are the reverse. It is overly simplistic to treat this as uni-dimensional.
		Consider Cobol: Consider Cobol. Cobol is a high-level language, in the sense that it gets compiled into machine language. Would anyone seriously argue that Cobol is equivalent in power to, say, Python? It's probably closer to machine language than Python.	Rather depends on the problem, I'd think. I am no fan of COBOL so this isn't a specific defense of that particular language, but some people still regard COBOL's data description facilities as better than those in many more modern languages. My only point is that one has to be careful when talking about language power. One person's power may well be another person's weakness.
		More Powerful?: Or how about Perl 4? Between Perl 4 and Perl 5, lexical closures got added to the language. Most Perl hackers would agree that Perl 5 is more powerful than Perl 4. But once you've admitted that, you've admitted that one high level language can be more powerful than another. And it follows inexorably that, except in special cases, you ought to use the most powerful you can get.	No it doesn't. The existence of the Nikon doesn't mean that it is the best camera for all situations.
		Not to Extreme: This idea is rarely followed to its conclusion, though. After a certain age, programmers rarely switch languages voluntarily. Whatever language people happen to be used to, they tend to consider just good enough.	A rather stark case of simple age prejudice. And quite untrue in my experience. Lots of us have shifted languages many times. In the days of machine languages we were forced to do so with each successive generation. Then many of us have moved through FORTRAN, COBOL, ALGOL, APL, Lisp, perl, Python, Ruby, J, K, various SQLs, etc. So what evidence, other than simpleminded prejudice, does Graham offer for this proposition.
		Programmer's Attachment: Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abtractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.	Everyone is attached to what they alread know. Why? Because the setup costs involved in using it are small. For small problems, there generally isn't enough total effort involved to make it possible to save enough energy learning a new language to make it worthwhile---at least on this next job. While poetry in some domain might sound better in French, it is asking a lot of someone to learn French well enough for them to be able to compose their poems in it. Of course it is overly simplistic to talk of languages as lying on some `abtractness continuum' anyway, as any such thing would have, at a minimum, to be rather confusingly multi-dimensional, but that hardly matters. The point isn't a very good one even before we get around to worrying about this.
		Stuff Not in Blub: And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).	Well, it's just a hypothetical story anyway, so it doesn't make much sense to argue about a conversation that only exists in a gedanken experiment.
		Less Power: As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.	This is a fairly condescending view that strikes me as not true of most of the programmers I have worked with. Long before I learned any K or J I was certainly able to see that there was, in all probability something there even if I didn't understand it.
		More Power: When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.	Continuation of the simplistic, and mildly condescending, point of view.
		By Induction: By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.	I guess I won't argue this propostition. But just because you understand the most powerful language doesn't mean you necessarily have much of a grip of the capabilities of the less powerful. It is all too easy to assume that lower-level languages lack major capabilities when in fact they don't.
		From Experience: I know this from my own experience, as a high school kid writing programs in Basic. That language didn't even support recursion. It's hard to imagine writing programs without using recursion, but I didn't miss it at the time. I thought in Basic. And I was a whiz at it. Master of all I surveyed.	There are different modes of thinking. Back in my college days I had a particularly productive academic collaboration with a co-author who quite naturally `thought recursively'. For me, iteration or `array' orientation has always been easier. Different modes of thought for different people. There's no right vs. wrong or inferior vs. superior going on here.
		Five Languages: The five languages that Eric Raymond recommends to hackers fall at various points on the power continuum. Where they fall relative to one another is a sensitive topic. What I will say is that I think Lisp is at the top. And to support this claim I'll tell you about one of the things I find missing when I look at the other four languages. How can you get anything done in them, I think, without macros? [5]	And some might equally think, how can you get anything done without easily comprehensible data descriptions. Or straightforward string processing. What makes certain languages stronger or weaker is often how they fit with our problems, not an inherent characteristic of the languages themselves.
		Macros: Many languages have something called a macro. But Lisp macros are unique. And believe it or not, what they do is related to the parentheses. The designers of Lisp didn't put all those parentheses in the language just to be different. To the Blub programmer, Lisp code looks weird. But those parentheses are there for a reason. They are the outward evidence of a fundamental difference between Lisp and other languages.	Well, I don't find parenthesis all that strange, so so far this claim tends to fall on deaf ears. We have the assertion that what is `different' about Lisp somehow relates to the particular ways that it handles macros. I guess we'd better read on.
		Lisp Data Objects: Lisp code is made out of Lisp data objects. And not in the trivial sense that the source files contain characters, and strings are one of the data types supported by the language. Lisp code, after it's read by the parser, is made of data structures that you can traverse.	That's pretty much true of K too, I think. And I guess we need to get some more definitive word about what it means to `traverse' in this sense---as otherwise macro processing has been a part of lots of computer languages since the early 1960s, as is evidenced by Strachey's early GPM work.
		Lisp Syntax?: If you understand how compilers work, what's really going on is not so much that Lisp has a strange syntax as that Lisp has no syntax. You write programs in the parse trees that get generated within the compiler when other languages are parsed. But these parse trees are fully accessible to your programs. You can write programs that manipulate them. In Lisp, these programs are called macros. They are programs that write programs.	Again, the depth of the consequences of this are not investigate, merely asserted. Lots of languages write programs that are then executable on the fly. It is a commonplace in perl, for example.
		Programs write Programs?: Programs that write programs? When would you ever want to do that? Not very often, if you think in Cobol. All the time, if you think in Lisp. It would be convenient here if I could give an example of a powerful macro, and say there! how about that? But if I did, it would just look like gibberish to someone who didn't know Lisp; there isn't room here to explain everything you'd need to know to understand what it meant. In Ansi Common Lisp I tried to move things along as fast as I could, and even so I didn't get to macros until page 160.	And macros well predate Strachey's mid-1960s article. Macros are nice, if you understand them, but they aren't a deal-breaker in my experience. Indeed, having made heavy use of them for years, I then started to find them unusually difficult to maintain, with small changes often having profound (and way too often terrible) effect on code scattered all through a system. This caused me to ease off using them.
		Viaweb Editor: But I think I can give a kind of argument that might be convincing. The source code of the Viaweb editor was probably about 20-25% macros. Macros are harder to write than ordinary Lisp functions, and it's considered to be bad style to use them when they're not necessary. So every macro in that code is there because it has to be. What that means is that at least 20-25% of the code in this program is doing things that you can't easily do in any other language. However skeptical the Blub programmer might be about my claims for the mysterious powers of Lisp, this ought to make him curious. We weren't writing this code for our own amusement. We were a tiny startup, programming as hard as we could in order to put technical barriers between us and our competitors.	This is simply wrong. Macros can, and often are, used in situations where the target language is not Lisp. So whether the macros are necessary or not, no argument is made here, other than by assertion xxxxxxxx
		Correlation: A suspicious person might begin to wonder if there was some correlation here. A big chunk of our code was doing things that are very hard to do in other languages. The resulting software did things our competitors' software couldn't do. Maybe there was some kind of connection. I encourage you to follow that thread. There may be more to that old man hobbling along on his crutches than meets the eye.	Yes. But I suppose an alternative explanation might be that Graham and/or his colleagues were just very clever. That's what made their software do things that the competitor's software couldn't do. Try two different chains of argument: (1) Smart guys choose Lisp and this let them be clever; (2) Smart guys can be clever. The second seems to me to win by Occam's Razor.
	Sidebar	I remain unconvinced that the case that Lisp is truly `different' from everything else has been made here. Macros, interpreters and programs writing programs have been around from the earliest days of machine language programming, and were particularly important back then as other facilities that are commonplace today had not yet been developed.
	=Aikido for Startups	Aikido for Startups	I gues Aikido is some particular form of Zen self-defense. But I don't know and I'm not sure that raising it without more explanation helps me see the point of what is going on.
		Lisp's Power: But I don't expect to convince anyone (over 25) to go out and learn Lisp. The purpose of this article is not to change anyone's mind, but to reassure people already interested in using Lisp---people who know that Lisp is a powerful language, but worry because it isn't widely used. In a competitive situation, that's an advantage. Lisp's power is multiplied by the fact that your competitors don't get it.	And it's divided by your own discomfort with it.
		Lisp in Startup: If you think of using Lisp in a startup, you shouldn't worry that it isn't widely understood. You should hope that it stays that way. And it's likely to. It's the nature of programming languages to make most people satisfied with whatever they currently use. Computer hardware changes so much faster than personal habits that programming practice is usually ten to twenty years behind the processor. At places like MIT they were writing programs in high-level languages in the early 1960s, but many companies continued to write code in machine language well into the 1980s. I bet a lot of people continued to write machine language until the processor, like a bartender eager to close up and go home, finally kicked them out by switching to a risc instruction set.	Having been at MIT in the early 1960s I'd agree with some of this, so long as we are willing to recognize FORTRAN as the higher-level language that was in substantial use up well into the 1970s. But in my experience---MIT had us doing lots of consulting back in those days, so we were well acquainted with commercial practice---our business associates used COBOL and FORTRAN about as much as we did. And I don't think that RISC instruction sets had much to do with anything on either side.
		Technology Changes Fast: Ordinarily technology changes fast. But programming languages are different: programming languages are not just technology, but what programmers think in. They're half technology and half religion.[6] And so the median language, meaning whatever language the median programmer uses, moves as slow as an iceberg. Garbage collection, introduced by Lisp in about 1960, is now widely considered to be a good thing. Runtime typing, ditto, is growing in popularity. Lexical closures, introduced by Lisp in the early 1970s, are now, just barely, on the radar screen. Macros, introduced by Lisp in the mid 1960s, are still terra incognita.	As mentioned Lisp by no means `introduced' macros. Macros were in wide use on several of our machines at MIT, well ahead of McCarthy's earliest implementations of Lisp. But, leaving that aside, Knuth makes a point that is at least worth considering that stability in a language environment is a good thing, not something that is `slow as an iceberg'.
		Median Language: Obviously, the median language has enormous momentum. I'm not proposing that you can fight this powerful force. What I'm proposing is exactly the opposite: that, like a practitioner of Aikido, you can use it against your opponents.	An interesting formulation. As though languages are `opponents' of one another. And instead of finding one which allows us to express ourselves as easily and as effectively---for the circumstances---as our environment might allow, Graham formulates the problem as a battle.
		Big Company Effect: If you work for a big company, this may not be easy. You will have a hard time convincing the pointy-haired boss to let you build things in Lisp, when he has just read in the paper that some other language is poised, like Ada was twenty years ago, to take over the world. But if you work for a startup that doesn't have pointy-haired bosses yet, you can, like we did, turn the Blub paradox to your advantage: you can use technology that your competitors, glued immovably to the median language, will never be able to match.	Weak reasoning, but it almost turns out to be true. First, deprecating (and unnecessary) characterizations aside, `bosses' typically have a wider purview than the typical programmer. And Graham may be comfortable using Lisp, because if he were to `leave the company' in this case he would, presumably, have little to do with the kind of problems that any such choices might ultimately make. Second, he reiterates (for the nth time) the unsupported proposition that it is the language that makes the difference. Case still not proven.
		Evaluating Competitors: If you ever do find yourself working for a startup, here's a handy tip for evaluating competitors. Read their job listings. Everything else on their site may be stock photos or the prose equivalent, but the job listings have to be specific about what they want, or they'll get the wrong candidates.	Probably not bad advice. But then it's probably also good advice to read their 10-K listings (or equivalents) if they exist. Or any advertising for other purposes. In other words, knowing more about your competitors rather than less may give you some advantage. Might as well make use of it.
		Read Descriptions: During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening---that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried.	This is an interesting, and perhaps psychologically revealing, statement, but I don't see that it has much to do with programming other than to expose the prejudices of the writer. Perhaps there is evidence for what he says, but---in that case---it sadly isn't presented here. I'm wondering if there was any careful data collection about what actually happened to the companies involved. Surely most of them collapsed, independent of any considerations about choice of computer language. One can only wonder if the author is indulging his prejudices, and thus reading the `data' with some real bias. Without any data it's difficult to say.
	Notes	Notes	Notes refer to the [...] numeric references in the paper.
		Two Parts: [1] Viaweb at first had two parts: the editor, written in Lisp, which people used to build their sites, and the ordering system, written in C, which handled orders. The first version was mostly Lisp, because the ordering system was small. Later we added two more modules, an image generator written in C, and a back-office manager written mostly in Perl.	A somewhat confusing point, given that most of the rest of this paper is devoted to Lisp. But here there is at least a chance to be informative, suggesting why some parts of the system are written in Lisp while other parts are C and perl. Unfortunately that discussion isn't presented here.
		C++ and Perl: In January 2003, Yahoo released a new version of the editor written in C++ and Perl. It's hard to say whether the program is no longer written in Lisp, though, because to translate this program into C++ they literally had to write a Lisp interpreter: the source files of all the page-generating templates are still, as far as I know, Lisp code. (See Greenspun's Tenth Rule.)	Where is Greenspun's Tenth Rule? It would be easier on me if I could have a sentence about what it says rather than a non-traceable reference to it. In any case, am I reading correctly that after all is said and done, the owners of the code began to replace Lisp? If that's so, doesn't it at least raise some question about many of the points made in the paper?
		Already in Lisp?: [2] Robert Morris says that I didn't need to be secretive, because even if our competitors had known we were using Lisp, they wouldn't have understood why: "If they were that smart they'd already be programming in Lisp."	There's a strong argument against secrecy that at least ought to be considered. That is that the actual truth may really be distractive. It strikes me that even if Graham's competitors had known and internalized the fact that he was using Lisp, their trying to do so might have been a real nightmare for them. Except in very unusual circumstances, the Lisp processing skill of competitors would probably been substantially less than that of Graham and attempts to use Lisp might well have landed them in worse trouble.
		Turing Equivalents: [3] All languages are equally powerful in the sense of being Turing equivalent, but that's not the sense of the word programmers care about. (No one wants to program a Turing machine.) The kind of power programmers care about may not be formally definable, but one way to explain it would be to say that it refers to features you could only get in the less powerful language by writing an interpreter for the more powerful language in it. If language A has an operator for removing spaces from strings and language B doesn't, that probably doesn't make A more powerful, because you can probably write a subroutine to do it in B. But if A supports, say, recursion, and B doesn't, that's not likely to be something you can fix by writing library functions.	This doesn't follow. In our first major programming efforts we had to use FORTRAN for reasons too numerous---and far too boring---to discuss. This language completely lacked (this was a long time ago, remember) any facility for automatic memory allocation, something we deemed vital to solving our problem. We had to write two relatively short machine language programs to make up for the deficiency. It worked from the beginning and the particular scheme was used in a successful production system that ran more than a decade, across a number of different machines.
		A Lattice?: [4] Note to nerds: or possibly a lattice, narrowing toward the top; it's not the shape that matters here but the idea that there is at least a partial order.	Ok.
		Macros not separate: [5] It is a bit misleading to treat macros as a separate feature. In practice their usefulness is greatly enhanced by other Lisp features like lexical closures and rest parameters.	I guess the reader is supposed to know what these are, and that they are important. Otherwise, mentioning them accomplishes little.
		Religious War: [6] As a result, comparisons of programming languages either take the form of religious wars or undergraduate textbooks so determinedly neutral that they're really works of anthropology. People who value their peace, or want tenure, avoid the topic. But the question is only half a religious one; there is something there worth studying, especially if you want to design new languages.	Designing new languages is a task for only a rather narrow part of the population. And the wars, like those of religion, may shed considerable heat, but rarely show any particular light.
	Conclusion	Viaweb was a success. Graham thinks it was due to his choice of Lisp as a programming language. My alternative explanantion is that it was good luck. Either way he should be happy that he took the money. But there is a danger in attempting to draw conclusions about policy from good luck. It's probably no help to those who don't have the good luck, and those who do don't need the advice.
	Sidebar: Peculiar Skills	Many programmers are guilty of a rather peculiar, and incorrect, form of reasoning. While few, these programmers included, would expect everyone to be equally comfortable with all kinds of different sports, or with all sorts of intellectual activities, they seem to expect that everyone will end up comfortable with `their favorite language' if only they are willing to give it a chance. I profoundly disagree with this. I think humans, proagrammers included, have different skills and interest and are therefore quite likely to be comfortable with different tools. Some people who read some Shakespeare find it quite readable and interesting, but still choose Stephen King when they actually have time to read. And on the topic of Lisp (or APL, as another example) people have voted with their feet. We've taught thousands of people APL, but as far as I can see, the high-water mark in usage was some time in the 1970s, and the population of users is now on the wane. Some of us learned Lisp in the late 1950s, in the days before McCarthy left MIT for the West Coast, but the number has never risen very substantially, although it has remained an extremely important vehicle for teaching and exercising some sub-set of programming concepts.
	Testimony	Graham's tale reminds me most of the kind of `testimony' that I am most used to hearing from TV evangelists or in the revival tent. We have, over and over again, the assertion that `try it, you'll like it.' Or, `trust me, this is good for you because it's good for me.' While I don't mind hearing these arguments, by-in-large I remain unconvinced by them. I am, of course, quite willing to accept Graham's testimony as honest, in that I am sure he believes it. But then, I accept Jerry Falwell, Pat Robertson and (although with a bit more trepedation) Jimmy Swaggart's testimony as honest as well. But, while I am willing to believe it works for them I find this of no use whatsoever in determining whether it is going to work for me or not.