I hope I can be forgiven for jumping onto a soap-box a bit late, but I'd like to propose a broader view of the "Lisp vs. other languages" issue than has arisen so far from the feature-level comparison of Lisp and Haskell. In particular, I'd like to look at the issue from the perspective of programming language design methodology. One problem with discussions of Lisp vs. other languages is that Lisp, as a language, is harder to pin down than most. It is really more than just an object language in the usual sense: its meta-linguistic features (syntactic extensions, reflection, etc.) mean that Lisp programmers can (and do) modify the language "dynamically", so to speak. Thus Lisp is constantly changing, in a way that spawns new versions of the language all the time, with a myriad of minor and major variations (witness Sandra's response to Alastair regarding Lisp's recent incorporation of object-oriented features). With other languages we tend to recognize such changes as water-shed events: a new language, a new version or at least a boot-strapping of the compiler to implement new extensions. But in Lisp this seems to be more of a standard programming technique, and thus more of an everyday occurrence. For example, when discussing Lisp vs. <whatever language> with Lisp fans in the past, I've often heard remarks (regarding some specific feature, say pattern-matching) along the lines of: "Oh, we could add that quite easily to our Lisp" or "I know someone who's added essentially that feature to his own Lisp environment". Of course, other languages, including Haskell, go through changes too, leading to different versions and ultimately even new "family branches". But with Lisp, I get the impression that this change happens on a much finer-grained level (say, the individual programmer level), at a different pace (say, several times during one Jolt-cola-driven night :) ) and in a different way (i.e., using reflective features and such) than it does for most languages. All these languages (Lisp, Haskell, etc.) are computationally complete, so they can all claim to implement *any* language feature, in some sense: just write an interpreter for the desired language in the given one. But whereas for most languages this strategy would seem to be "cheating", or least to result in an entity clearly separated from the original language, for Lisp it is apparently not out of the ordinary; that is, it is the *usual* way in which the language has evolved (and continues to evolve). Thus perhaps the greater tendency of Lisp fans to think of Lisp as a unified, unbroken whole across historical changes and varying implementations which most programmers would consider to merit at least a change of version number, if not language name. (but, on the other hand, see Jeff's recent remarks re speaking of more specific things than Lisp in general). In some sense, language *design* is incorporated into Lisp programming practice, just as its meta-level features are incorporated into its object-level. To me, this aspect of Lisp's evolution gives it a more *organic* flavor than other languages have; it is what gives Lisp much of its charm and power, while at the same time making it more difficult to formalize or analyze. Of course, one can separate off some feature-of-interest from the Lisp whole into a toy, "static" language for the purposes of analysis; but to do so is to lose much of the essence of Lisp, in terms of the synthetic gestalt of its features and the potentially dynamic character of its growth. Now as it happens, I'm not a Lisp programmer (most of the opinions above are based on discussion or debate with Lisp fans, or on readings in the literature). But after an initial (short) period of grimacing over its "untidiness", I've come to welcome its role alongside the more "static", well-circumscribed languages like ML or Haskell: I think the Lisp style of exploratory, grass-roots language design complements the more formalized approach in a way which is beneficial for all concerned. On the other hand, I may have developed an overly-romantic view of the use and evolution of Lisp, through the influence of programmers who are especially fond of a certain style of programming. And I may have an unrealistically tidy view of the design of languages like Haskell and ML, never having sat on a design committee :) . -- Fritz Ruehr [EMAIL PROTECTED]