Subject: another take on "C is faster than lisp" From: Erik Naggum <erik@naggum.no> Date: 21 Aug 1994 00:41:43 UT Newsgroups: comp.lang.lisp Message-ID: <19940821.4497@naggum.no> [Thomas M. Breuel] <TMB.94Aug20205223@arolla.idiap.ch> | 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. #<Erik> -- Microsoft is not the answer. Microsoft is the question. NO is the answer.