Subject: Re: Why lisp failed in the marketplace
From: Erik Naggum <>
Date: 1997/02/27
Newsgroups: comp.lang.lisp,comp.lang.scheme
Message-ID: <>

* Markku Laukkanen
| Well, I consider myself a good Lisp programmer, and it took me over a
| year to MASTER the Common Lisp. Of course, if you mean some C/C++ like
| programming, it is possible to grab CL quite soon, but to learn CL in two
| weeks..  That is a good joke.

more anecdotal evidence: I don't know how much time I spent learning the
basics in Lisp, because I don't think I spent any conscious time on it.
The Little Lisper lay on a table in the "pause area" where I once worked,
and I picked it up and read it.  reading that book was probably all it took
to get most of the basics down pat.  (I was somewhere between 13 and 15 at
the time, probably very impressionable.)  the rest has just sort of floated
my way, _except_ for the more advanced aspects of CLOS and the condition
system, which I still find troubling -- philosophical misalignment, I
guess.  (`change-class' still makes me queasy, but I was on the road to
reinventing it, so I have come to conclude it can be the Right Thing when
state-changes are easier to express with class changes.)

most of my journey in Common Lisp has been a series of incidents like this:
a week of programming, realizing that I'm doing "grunt work", having a
flash of anxiety that this is "bad", reading up on some of the stuff I
didn't see any use for or didn't understand in Steele or the HyperSpec, and
getting much relieved, then deleting 500 lines of code and doing that
week's work over in two hours.  very satisfied, I write my observations
down in a "programmer's log", take the rest of the day off, and play with
the concept (and my cat).  two years of that, and I think I have a pretty
good grasp of the language.  (Scheme, in contrast, gives me the feeling
that this kind of "grunt work" is _not_ bad -- Scheme programmers implement
complex stuff with basic buildings blocks over and over, it seems.)

however, and this is what I find important, at no point in my using Common
Lisp have I been _stumped_, or feeling that I was banging my head against a
wall of minutiae or any such thing.  I didn't _need_ to "master" Common
Lisp to use it well.  the simpler aspects of CLOS was shown to me by a
friend not long ago -- it's just been saving me time, not the insufferable
hair that I had to fight myself through in C++.  I'm sure C++ can be as
easy to learn as CLOS (Andrew Koenig's ever-present counter-argument that
C++ is hard is that he can teach people this stuff in mere days), but
_mistakes_ in C++ devour you (and sometimes your machine), and face you
with language details you didn't even know _could_ exist.  a C++ programmer
might very easily see his program do something completely insane and spend
the next three days trying to figure out what the hell happened, just to
find that he had declared a new function and some other function was called
with an argument of the wrong type and some constructor was called that he
didn't even know would be affected by his new function.  contrast this kind
of incident (I had one of them a week, not all equally severe, when I tried
to use C++ in a project in 1993) with the Common Lisp incidents I described
above.  C++ instilled in me a fear of mistakes that crippled my ability to
experiment with the language, because I was unable to see the chain of
events that led to the compiler's decisions, and I don't think I should
have had to, either.  Common Lisp provided me with an environment where
mistakes had a _very_ low cost and offered early and precise detection to
boot.  this provided me with an early warning system for anything I might
need to look up or study more.  in C++, I would tend to think "sh*t, this
_should_ work", whereas in Common Lisp, I would think "hmm, that's odd",
and reach for the documentation.  (I have subtracted for the normal
bug-hunting in all the software I use in these descriptions.)

concluding from the way I have learned many different programming languages
(and CPU's) over the years, I'd say that the _only_ thing that matters to a
student of a language is that he can _trust_ the language.  I can trust C,
I can trust Common Lisp, but I _could not_ trust C++.  most of today's
programmers _don't_ trust their programming language or environment and
thus have a hard time with the "trust" concept, or so it seems, anyway.

(speaking of trust, allow me a digression: people will associate feelings
of distrust and the resulting powerlessness with some part of the learning
experience, but not necessarily the right one.  I suspect that some of this
distrust from other languages is hurting Lisp.  I speculate (I haven't made
the slightest effort to test this idea on others, however) that when a
programmer in a syntax-rich language reaches for the parens, it is because
he cannot trust the compiler to do what he wants.  I know from my own
experience that I have had to add parens to oddly misbehaving expressions
in C, but I haven't associated the pain of the debugging with the parens --
I have associated it with the infix syntax.  if you associate the pain with
the parens, how will you feel about a language where there are parens all
over the place?  now, if you're into conspiracy theories, or just enjoying
them, consider that the most overloaded of all the horribly overloaded
operators in C++ are the parens.  if you were desinging a language, and you
understood this feeling of distrust and the associative nature of the human
brain, would it not be a great idea to make parens the most painful of all
your operators if you wanted to keep your victims from discovering Lisp?)

if you think big enough, you never have to do it