kend@data.UUCP (Ken Dickey) (03/27/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >I claim that run time is, overall, a significant percentage of >turnaround time during the development and maintenance of most programs. >Since programs in Lisp are often several times slower than the same >programs in C, Lisp significantly slows down program development, all >else being equal. All else is *not* equal... A) In most production development environments for I have seen (e.g. for FORTRAN, C, Pascal, C++, COBOL), Compile and Link times predominate. This is true even for those languages such as C and C++ [well, C++ is almost a language] that spend a significant time scanning hundreds of include files [it is amazing to me that languages which pass around source descriptions of how bits are layed out in memory rather than teach the compiler--once--about new data types are still in wide use]. As to development speed, the Sabre C interpreter --which is at least an order of magnitude slower than most interpretive Lisps--makes C development almost reasonable. B) Lisp is not especially slow as compared to C. Where are you getting your benchmarks? While I don't really want to get into benchmark entanglements, let me give a sample on Scheme [note that cc is missing from most of the following because things are being measured which you can't do portably in C]. [From Feeley & Miller: "A Parallel Virtual Machine for Efficient Scheme Compilation", Proceedings of the 1990 ACM Conference on Lisp and Functional Programming.] Relative timings: [HP 90000/340--68020 CPU] Gambit Orbit LIAR cc ------ ----- ---- -- boyer 1 2.09 1.96 browse 1 1.65 6.12 cpstak 1 1.93 1.57 dderiv 1 2.04 1.99 deriv 1 1.76 1.82 destructive 1 1.49 3.71 div-iter 1 2.29 1.39 div-rec 1 2.14 1.57 puzzle 1 1.39 3.59 0.61 tak 1 1.30 3.15 1.71 takl 1 1.53 1.86 1.80 traverse 1 0.80 1.68 triangle 1 0.89 1.96 0.83 [MIPS R2000] scc tak 1 1.17 2.83 1.17 2.00 takl 1 1.14 2.57 1.79 2.36 triangle 1 1.02 2.60 0.85 1.77 Note that for the small set of benchmarks where C is applicable it is not "several times slower" than Scheme. I am sure if you take a look at Common Lisp you will find a similar pattern: Cl beats C at some benchmarks and C beats CL at some. It really depends on what you are trying to do... >I don't want to have to know about the underlying architecture either. >I'm glad that C provides a powerful yet portable model of almost all >existing hardware architectures. It's a shame that Lisp doesn't. Actually, C is providing a model of the underlying architecture. If it is not a close fit, one must do quite a bit of work to make C perform well. By contrast, most Lisps are related to the Lambda Calculus and as such are based upon a model of computable functions rather than a particular machine model--much more portable than C [What is the size of a pointer on a 386? How many bits in an emum? How many CPU's are you running on?]! I routinely write Scheme code which is portable (across Vax, Sun3/4, MIPS, PC, Mac, Amiga, BBN Butterfly, Encore Multimax, etc.) with no source changes and no #ifdef's. Try that in C. {While I am at it, "Lisp" is the name of a *family* of languages. Calling a set of languages Lisp is a bit like referring to C, Pascal, and PL/1 as Algol.} >... I'm all in favor of >good libraries, but what does that have to do with dynamic typing? Perhaps because better reuse leads to more reusable libraries. {Small amounts of code being reused more, leveraged more, better tested, fewer "special case variants",...} -- Dan, I have written between 50-100,000 lines of production code in C and about 50,000 lines in Pascal. I suggest you do a comparable amount of work in Scheme or CL before you decide they are not worthwhile. -Ken Dickey kend@data.uucp