Xref: utzoo comp.lang.misc:6940 comp.object:2790
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!batcomputer!llenroc!cornell!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!ram
From: ram+@cs.cmu.edu (Rob MacLachlan)
Newsgroups: comp.lang.misc,comp.object
Subject: Re: blip [Re: Dynamic typing -- To Have and Have Not ...]
Message-ID: <1991Mar20.041716.4486@cs.cmu.edu>
Date: 20 Mar 91 04:17:16 GMT
References: <1991Mar16.052952.10201@cs.cmu.edu> <3523:Mar1803:21:0591@kramden.acf.nyu.edu> <22032@yunexus.YorkU.CA> <11820:Mar1923:59:3591@kramden.acf.nyu.edu>
Sender: netnews@cs.cmu.edu (USENET News Group Software)
Organization: School of Computer Science, Carnegie Mellon
Lines: 57

Subject: Re: blip [Re: Dynamic typing -- To Have and Have Not ...]
Date: 19 Mar 91 23:59:35 GMT

>Of the languages that I've used much, I find Forth the most expressive.  Lisp
>and C come in way below [...]  Yet I continue to use C (and, when necessary,
>Fortran) much more than any other. Why?  Because Forth is not portable, Lisp
>on anything but a Symbolics is so slow that my test runs often take ten times
>as long, and Ada compilers are snails.

Are you doing number crunching?  If so, non-Symbolics Lisp products perform
badly.  But for other problems, Lispms have been surpassed in speed by Lisps
running on conventional workstations (MIPS, SPARC, etc.)  And CMU Common Lisp
provides better-than-Lispm safety and debuggability with better-than-Lispm
speed (not to mention cost-effectiveness.)  CMU CL also offers good number
crunching performance in real programs (5x Allegro.)

>I need portability. I need fast compile times and run times so
>that the machine's turnaround time during testing and debugging doesn't
>become a significant part of my turnaround time. I need language power:
>full access to what the machine can do. Lisp doesn't have any of this.

I think that you overstate the case.  Common Lisp is at least as portable as
C, and Lisp systems offer unsurpassed compile-debug turnaround times (through
incremental compilation.)  "Full access to what the machine can do" is
somewhat more nebulous.  If you mean writing device drivers, then Lisp is not
for you.  But if you just mean that you want to use all the machine's
primitive datatypes with reasonable efficiency, then Lisp *can* do this
(although not all implementations provide as consistent support as CMU CL.)

Common Lisp certainly wins big compared to, say Pascal, in that it has about
all the operations that hardware implements (boolean arithmetic, bit-vectors,
decode-float, all the flavors of division, etc.)

>[...] if you want to buck the establishment, it's your problem to prove that
>dynamically typed languages aren't as inefficient as most experiments have
>found them to be.

Some statements I am willing to defend:
 -- For some uses, efficiency isn't everything (research, prototyping,
    development.) 
 -- For the things that C, Pascal, Modula, C++, etc. are used for, it is
    almost always possible to get a Lisp program to come withing a factor of
    two of the performance of these more conventional languages.
    (I am confining myself to general or "systems" programming, as opposed to
    data processing and scientific computing.)
 -- It can be very, very hard to get this good performance, but many of
    the performance tar-pits can be reliably negotiated when there is good
    compiler feedback.

>Would you write a compressor in a dynamically typed language?

If you mean something like the Unix system program "compress", then I
wouldn't.  But if your goal was to compress a complex input (like natural
language) down to the smallest amount of space, with run-time relatively
unimportant, then Lisp would be a good candidate.

  Rob MacLachlan (ram@cs.cmu.edu)