I've been thinking a lot about the history of Lisp and how it got to be the way it is. Lisp had many advantages over other languages designed by committee. The social setting allowed for experimentation and fast adoption of features. It was a research language that managed to incorporate new ideas quickly.
People talk today about how many programming languages have borrowed features from Lisp. I would like to suggest that many languages have also borrowed the social/development model.
I hope I'm not being too simplistic with this take on the history. Anyone who was there might want to chime in to correct any mistakes.
Since Lispers tend to model all problems as lists, here is a list:
Each programmer added his own features to the system. As programmers developed their applications, pieces of those applications were folded into the language. Lisp (originally) was not committee-ware.
Lisp was built on the backs of graduate students. Principally at MIT and Stanford, two of the most competitive Computer Science schools in the nation. A lot of hours went into it. They were dedicated, passionate users.
Every lab wrote their own Lisp. Sometimes they had experience with another Lisp. They brought what they learned. But basically, each Lisp was separate and could only exchange with other Lisps after long intervals.
Lisp was rewritten occasionally (as in #3 above, or when your lab got a new machine). This ensured constant evolution even at a single lab. New features that couldn't be implemented using Lisp's programmability were finally added when the system was rebuilt.
I'll leave the thought here for you to continue. Maybe Lisp now has better social conditions. Maybe they're worse. I'd love to hear what you have to say.
Comments
Common Lisp
I think that rule #2 should be
"Be tolerant of those who can't be nice" . People who are passionate about their ideas don't always mind their Ps and Qs. Creative, positive environments always have conflict. Conversely, over regulated and polite environments are essentially dead from a creative point of view.
I do remember reading some of Kent's own stories about how Common Lisp came together and how the Hyperspec was written. Like a real birth, it wasn't a "pretty" process.
I guess the point I'm trying
I guess the point I'm trying to make here is that you gloss over a lot when you say "lisp was disorganized". The birth of Common Lisp and all the messy arguments it made for should be included in your social history.
Decade
The technology of Lisp was never more than a decade old? I'm not sure what you mean by that, but I can't think of any sense in which it's very accurate.
If you mean the language definition, it's way, way off. The names "car" and "cdr" were recognized as a mistake not long after they were first used, about 50 years ago, but by then it was too late, and we're still stuck with them. Much more positively, the heard of the language hasn't changed, although a lot of new things have been added. For example, Lisp macros were introduced in 1963. The defmacro-and-backquote technology, to make macros easier to write, developed over many years and was perfected in about 1977. They're still what we use.
If you mean the implementation techniques, they've evolved over time, as have the implementation techniques for most other languges. But I don't think you can put a number of years on it; it's just a gradual process.
Probably the main difference between Lisp, and the languages that have recently become popular, is that the latter often have one person with control over all major decisions, whereas Common Lisp has nothing like that. The reasons for that and its pros and cons is a a very long and complicated issue, but I think it's clear that this is a big distinction.
Frequent reimplementation
I could be wrong, but from what I understand of histories such as this, Lisp was reimplemented frequently. I assume that during those reimplementations, improvements get embedded deep within the core.
For instance, when MacLisp improved error handling, it wasn't just tacked on top. It was folded into the core implementation. That's what I mean. When I say "never more than a decade old", I mean just that: an upper bound on the time between reimplementations.
Post new comment