Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.misc
Subject: Re: The powerlessness of Lisp
Message-ID: <27234:Mar2603:13:2991@kramden.acf.nyu.edu>
Date: 26 Mar 91 03:13:29 GMT
References: <1991Mar25.210406.9384@linus.mitre.org>
Organization: IR
Lines: 60

In article <1991Mar25.210406.9384@linus.mitre.org> john@clouseau.mitre.org (John D. Burger) writes:
  [ on ``short-running'' ]
> Huh?  I don't understand this at all; your implication is not obvious
> to me.  Anyway, as I said, the Lisp programs I'm referring to run for
> hours/days at a time.  Is that long enough to be significant?

You said it was ``fast enough,'' so obviously its run time is not
particularly significant. I claim that for most programs the opposite is
true, and dynamic typing can greatly increase the turnaround time during
development. You can measure the accuracy of this claim by dividing the
CPU time of test runs by the total programming time, for various
programs.

>   So it's not worth programming in Lisp unless all else is not
>   equal---i.e., unless Lisp significantly reduces the number of test
>   runs, or the pain of maintenance. See below.
> All else isn't equal, as is usually the case when people say that.
> Lisp gives you heterogenous collections, incremental compilation, a
> REAL source level debugger, and lots more.  That's why development in
> Lisp IS significantly faster.

A ``REAL source level debugger'' and incremental compilation are
functions of the environment. Heterogeneous collections don't seem to be
used in real applications---or do you have a counterexample?

>   ... e.g., byte-copying into a character buffer, which can then be
>   written portably to disk and read back later ...
> This can be done in Lisp.

No. You can use a list to simulate the buffer, but you cannot do the job
as stated. You can construct other examples where Lisp's lack of pointer
arithmetic or byte-oriented memory shows through.

>   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.
> It's not clear to me that it doesn't, but anyway, I don't want to
> model hardware, I want to model the problems I need to solve.

Huh? Are you not trying to write programs so that machines can run them?

> I find your example, and others like it, much more compelling than any
> rewrite examples.  Why do you think it was deemed necessary to
> implement dynamic typing in C for GNU Emacs?  Why do you think X
> Windows effectively implements dynamic typing for interface entities,
> not to mention a run time interpreter?
  [ etc. ]

``Why do you think people write libraries and use them?'' Because it's
easier to use a library than to rewrite its code. Can we apply your
logic to insist that all library routines should be part of every
language?

The point is that someone who wants to use dynamic typing in C can
easily do so. I believe we agree here. So what is gained by including
dynamic typing in the language (hence compiler), rather than in a
standard library? The obvious disadvantage is that most existing
dynamically typed languages *force* you to use dynamic typing, and don't
let you declare types even when you know what they will be.

---Dan