🚀 go-pugleaf

>Newsgroups: comp.lang.misc,comp.object
>Subject: Re: blip [Re: Dynamic typing -- To Have and Have Not ...]
>Date: 20 Mar 91 13:06:03 GMT
>
>In article <1991Mar20.041716.4486@cs.cmu.edu> ram+@cs.cmu.edu (Rob MacLachlan) writes:
>> I think that you overstate the case.  Common Lisp is at least as portable as
>> C,
>
>What world do you live in? [...]  95% of the machines I use do *not* support
>Lisp even if they *could*.

I live in a research-oriented computer science department.  Nearly everything
is done on technical workstations (Suns, DECstations, etc.)  These systems all
support Common Lisp.  What world do you live in?  Probably it is a world where
Lisp programming doesn't make any sense (real time? operating systems?).

Both my direct and indirect experience in this environment has lead me to
believe that Lisp provides a better way of evolving solutions to complex
problems than is offered by more conventional programming languages.  I
suspect (and have heard some claims that) Lisp is also helpful in industrial
R&D and prototyping.

>> and Lisp systems offer unsurpassed compile-debug turnaround times (through
>> incremental compilation.)
>
>``Unsurpassed'' is exaggeration, and even if compile times were instant
>I'd spend forever just waiting for most programs to run.

Not really an exaggeration...  Once you get down under a second, additional
improvements become relatively unimportant.

>>  -- For some uses, efficiency isn't everything (research, prototyping,
>>     development.) 
>
>In fact, I've been focusing on the prototyping and development stage of
>a program, because that's when it's most important to get good compile
>times *and* run times.

I agree that good run-times are crucial in a protopying and development
environment.  This is the main reason why CMU CL goes to so much effort to
minimize the overhead for dynamic type checking (doing as much checking as
possible at compile time), and also why CMU CL has such good support for
source-level debugging of optimized compiled code. 

In previous non-Lispm Lisp environments, in order to get safety and
debuggability, you had to pay a big efficiency hit (5x or more) to get safe
code.  In CMU CL, the penalty never exceeds a factor of two, and is often down
around 10%.  This is in comparison to pull-out-all-the-stops benchmark mode
optimized compilation.

>In article <19MAR91.22493670@uc780.umd.edu> cs450a03@uc780.umd.edu writes:
>> What I have claimed is that I can solve problems faster
>> in a dynamically typed language than in a statically typed language.
>
>I firmly believe that the speed of problem-solving in any language is
>based mostly, if not almost entirely, on how much already-written code
>you can apply to the problem.

In research and development, you are devising and perfecting new solutions.
Reuse is important, but in R&D, this mostly takes the form of self-reuse
(cannibalization or evolutionary programming), rather than glomming onto
existing code.

>There is no reason beyond religion to believe that dynamic typing helps
>reusability. 

There is good reason to believe that polymorphism aids reuse, since you can
program "generic" facilities.  Dynamic typing makes polymorphism trivial, and
Lisp was the first widely used polymorphic language.  In recent years, other
forms of polymorphism have become available outside of Lisp (including object
oriented extensions.)

Another aspect of Lisp that aids reuse, but which is poorly understood (even
in the Lisp community) is meta-programming.  The ease of adding new linguistic
features (and their associated semantics) to Lisp is the main reason why Lisp
systems were the first to offer "industrial strength" object oriented
programming environments.

Now that OOP is relatively well understood, it is trickling down into
mainstream languages, but there is no reason to suppose that programming
language development will stop with OOP.  Using a language that supports
meta-programming allows you to devise new languages for solving new problems.

  Rob MacLachlan (ram@cs.cmu.edu)