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]
