🚀 go-pugleaf

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