Subject: another take on "C is faster than lisp"
From: Erik Naggum <>
Date: 21 Aug 1994 00:41:43 UT
Newsgroups: comp.lang.lisp
Message-ID: <>

[Thomas M. Breuel] <>

|   The only way to program around those limitations is to convert
|   everything to FORTRAN-style code, where you don't use structures and
|   rely on monotyped arrays of characters, bytes, and floating point
|   numbers and use array indexes as pointers.  If you do program
|   FORTRAN-style, it is usually relatively easy to get good performance
|   in CommonLisp (there are still some gotchas to watch out for), but
|   most people choose Lisp in order to have convenient and powerful means
|   of expressing their algorithms at their disposal, not to be squeezed
|   into FORTRAN-style programming.

I have been reading this rather long-winded discussion with interest
because I have just recently decided that my mental health was more
valuable to me than programming in C++.  it is years since I programmed
anything useful in LISP besides the daily functions I write in Emacs LISP
to write code in various stupid programming languages for me, so I was
happy to return and see so many good tools and compilers and so much neat
stuff lying around.  I'm really grateful to all of you who have unwittingly
helped me become one happy programmer, again.

to the point: I am about 50 times more efficient in LISP than I am in C++,
and about 20 times more efficient in LISP than in C, but that's because I
write C with my spinal cord.  I build small tools to build other things,
and like to build languages that I express myself in, instead of writing
everything in the base language.  I've done this ever since I programmed in
MACRO-10 and -20 on the truly lovely PDP-10, so it may be a habit that's
hard to break, and that itself may explain my painful encounter with C++,
where this is surprisingly hard to do well (it shouldn't have been).

if these numbers are not untypical, it means programmers will spend _far_
less time getting the software to do what it should do, find all the bugs
and gaps in the _design_ (rather than their code or the compiler), and they
have time to redesign the whole thing from scratch several times over, if
they use LISP instead of C++ and C.  you know this.

now, my nearly 12-year experience with C is that it takes a lot of solid,
hard-earned skills to be good at C.  C is not efficient per se, although
the machine will do what you ask it to do without much further ado.  the
question is what you ask it to do, and whether you want to write portable
code.  you know this, too, right?

_because_ C is deemed to be efficient because it doesn't add any (visible)
overhead, vast scores of programmers think they write efficient programs.
they couldn't be more wrong!  the same vast scores of programmers wouldn't
know a good algorithm from a kluge.  even with good algorithms, you need to
make tradeoffs between space and time that can be affected by the length of
the input you expect, etc, etc.  this is not news, either.

what I don't understand, even after reading so many posts on this topic,
is: why do you compare C with LISP?  why do you want C-type efficiency in
LISP?  if it takes you longer to experiment with a design in C than in
LISP, what makes you think you will find the best solution sooner in C?
don't your programs _evolve_?  do you think overhead is important if your C
algorithm is O(n^2) with really tight loops and your LISP algorithm is
O(n), perhaps with a much higher cost per loop?

I don't write programs to handle tiny known-size amounts of data, anymore.
I would be happy to stay with C if I did.  I don't write programs that will
do one task and then terminate, either.  my programs don't know much about
the external world except that it's a hostile place, and they need to be
able to undo possible damage if the world unexpectedly changes around them.
C is not the language to do this in.  there are a number of arbitrary
limits in C that are really hard to work around and still be reasonably
efficient.  I could implement bignums and use them transparently with C++,
but why?  I don't want to know about implementing bignums.  consistent
error handling in C (Unix) is a pain.  I need polymorphous types -- and I
don't want to implement them myself; I trust that somebody else is _much_
better than me at such things, and at making it reasonably fast, to boot.

until I know _exactly_ what the program is going to do, and I reasonably
safely can assume it won't be radically changed next week, I cannot trust
that I will find the best solution at the first attempt.  if I write in C,
I often don't get more than one attempt.  doing more than the primitive
operations take a _lot_ of time in C and C++ is even worse, with its very
annoyingly inappropriate defaults for classes.  a language encouraging you
to use pointers should not require you to do so many stupid tricks if you do.

so, if you think in FORTRAN, why don't you program in FORTRAN?  if you need
speed over flexibility, why don't you write in C?  why do you think one
language fits all?  the clue is to know more than one language and to use
them well.  this _must_ be obvious.  I can't have figured this out all by
myself and _nobody_ else got the idea.

if speed is so important to you, and you still need to be reasonably
efficient as a programmer, try writing a program in LISP that will write
the program you want in FORTRAN or C at the source level.  people did this
all the time back when they used strong macro assemblers.  in C, however,
macros are so hard to define properly, more than one-liners are effectively
discouraged.  anybody remember RATFOR?  isn't there a lesson from history
here, somewhere?  how old do you need to be to remember these things and
apply this knowledge to those supposedly "modern" languages?  why do such
newbie-languages become popular in the first place?

I'm not sure this needed to be said, but thanks for listening.


Microsoft is not the answer.  Microsoft is the question.  NO is the answer.