Subject: Re: lisp is *SLOW*
From: Erik Naggum <>
Date: 1997/08/12
Newsgroups: comp.lang.lisp,comp.lang.c++,comp.programming
Message-ID: <>

* Sajid Ahmed
| I tried to tell the CS teacher about machine language instructions, but
| he shoved it off and tried to say that some processors were designed to
| do only recursion; biggest bunch of bologna I've ever heard.
| Anyway, I've come to conclusion that Lisp is bad, Lisp is evil, and as
| the subject says lisp is *SLOW*.

* Alexey Goldin
| My lesson: do not teach pig to sing: it is useless and annoys the pig.

I think there are a couple other possible lessons.

(1) there are people out there who think they know what computing is all
    about, and who will object vehemently to any conflicting suggestions,
    especially when they come from someone better educated than themselves.
    dismissing such people at a young age will cause them to go mad with
    rage, targeting any and all reasonbly well-educated people they can
    find, preferably somebody working in a field that isn't too popular.
    the only other case I have found of this kind of lunatic rage against
    better education is Larry Wall.  he is also kicking Lisp and academics
    even more than this "Peaceman" bozo does, equipped with slightly better
    intellectual ammunition (I gotta give him that).

(2) efficiency concerns _are_ actually legitimate at some level, and those
    who think low-level code efficiency is the alpha and omega of software
    performance can probably be put to good use in optimizing inner loops
    and reordering data to increase cache hit rates and the like, after the
    designers have gone home and the software actually works (otherwise,
    they will just screw it up).  I imagine this kind of people would be
    useful in writing optimizers for compilers, too, after the real brains
    have found new ways and directions in which to optimize.

in both cases, we have classes of people who can do something good and
useful, but which it would not be beneficial to tell much of the big
picture.  you can teach a mechanic to fix your car, and you need a damn
good mechanic these days, but it would be a mistake to discuss new metal
alloys that can withstand higher pressures in the combustion chambers or
new kinds of fuel with him, especially if they could replace the engines
that this mechanic knows and on which he has based his career and all his
education from when he was just a boy and loved cars.

for all intents and purpose, I grew up on a DEC-10.  I had met other
architectures before it, but this lovely machine was where I became a
programmer.  others have argued that other CPUs are their model of beauty
and intelligent elegance, and they typically argue differently than I do,
not infrequently based on their perception of the system software and the
way everything was organized, as far as they could understand it at their
age.  the Intel generation, further misguided by Bill Gates' total lack of
appreciation of the DEC-10 on which he pilfered CPU time to defraud his
first customer and ever since has peddled shoddy excuses for software, has
had to deal with a totally different kind of "incubating environment".  I
believe that a good environment brings out the best in people, and that a
really bad one brings out the worst.  after all, we're still animals that
try very hard to adapt and survive.

yet, I, too, am a deeply concerned "software mechanic" at times, and I
could be exceedingly myopic in my concerns, but in time, I discovered that
the car wasn't invented, much less built, in a run-down garage, tuning and
tweaking doesn't make a better engine, washing and polishing doesn't make a
better car, etc.  I wanted to figure out how people who designed these
things thought and how they worked.  I wanted to make some _significant_
improvement one day, not just tweak a single engine to yield a little
better, but make _all_ engines yield better, not just polish a single hood
better, but design a metal allow and coat it with something that would make
all hoods look shinier no matter the weather conditions and air pollutants.

now, there's a important distinction between being satisfied with your
ability to tweak an engine or polish a car, and being deeply frustrated
with the limits of tweaking or the need to polish cars so frequently while
you're looking for that better design that would make such trivial problems
go away.  my guess is that there's a frightening lot of frustrated, but
good, mechanics out there.  Peaceman the bozo is not among them, obviously,
but I'm afraid that he talks their lingo.  "Lisp is evil", the frustrated
mechanic says, and any other mechanic will look at him, they will _feel_
his frustration (which is real enough), and they will murmur "it's all
because of unleaded fuel" or whatever it is that car aficionados lament --
I wouldn't know.  I don't actually own a car, because today's automobile
design _sucks_, and the taxes they levy on owning and using one are just
criminally insane (at least in this country).  I'm waiting patiently here
while I'm sure they're hard at work designing those nifty "transporters"
from Star Trek.  _then_ I'll start going places.  fortunately, we already
have programming languages that work like "transporters", taking care of
all the crufty details, so I don't have to wait.  but think of it: how
would the automotive and oil industries react to "transporters"?  wouldn't
they call them evil and worse?  not to mention that you could probably get
a least five kilometers in your highly optimized car before the transporter
could beam you anywhere, and let's not forget that any teenager can learn
to drive, but it would probably still require a pretty solid education
before you could operate a transporter safely.  of _course_ transporters
are bad, evil, and slow.  sheesh!

it all boils down to this: if Lisp were allowed to win, just how would
society cope with all the criminals who were just writing bad code?

404 Give me a URL I cannot refuse.