Re: Lisp considered unfinished

[doner@aero.org (John Doner)]

In article <3r0v3d$bvp@tools.near.net>,
Barry Margolin <barmar@nic.near.net> wrote:
>But before programmers can use Lisp for large
>applications they need to get their feet wet on small ones, and Lisp
>usually isn't the appropriate language for little applications (the 5MB
>"hello world" binary is the usual example).

Hear, hear.  I would like to add the perspective of a professor who
would like to teach Lisp dialects to students of math and computer
science, but who has trouble making it work.  An important part of
the problem is the size and complexity of the environment within
which the learner must learn.  Since students' computers are apt to
be small, maybe slow, this is a big obstacle.  So is cost.  (Gambit
scheme solves the cost problem, maybe the size problem, and part of
the complexity problem, so I do use that.)  But there are other
serious obstacles.

The first is comprehensibility.  In the case of Lisp, there is the
sheer size of the language.  It prevents all but a few from ever
getting a feeling that they have really mastered it; in fact, it
leaves most with the sense that they have only scratched the
surface.  Scheme is much better here.

Then there is the problem of abstractions.  Lambda, one of the key
things that makes Lisp & friends so nifty (you can make functions
on the fly, have functions returning other functions, create
closures, etc.) is a DIFFICULT CONCEPT.  Look folks, we have
trouble teaching them what ordinary mathematical functions are, let
alone functions of higher type (a.k.a functionals or operators).
(Actually, I have hopes that teaching a Lisp dialect will help
students learn mathematical concepts!  So I'm not objecting to
abstractions, I'm only pointing out that for the beginning
programmer they're a source of difficulty and complexity that must
be addressed.)

Another aspect of comprehensibility: In my view, most people reach
an understanding of how a programming language "works" by
constructing a mental model of the computer and how it executes the
statements of the language.  C is close to an assembly language, so
the mental models (which change as learning occurs) reach a good
approximation of reality in a relatively short time, and thus serve
as reliable predictors of what a particular piece of code is going
to do.  The reality of Lisp implementations is relatively
complicated, and the mental model must also be more complicated.  I
spend some effort explaining "how it all works" to students, but
however useful this may be, it does add an extra layer of
complexity.

There is the problem of efficiency.  I don't mean whether the
compiler can generate fast code.  The problem is seeing whether one
has written good code or not.  It is hard to tell.  I have a friend
who maintains a large Lisp program written years ago by others.
Often, he comments on what poor code is there, and he improves it.
But the original coders were hardly Lisp neophytes; why didn't they
see how bad the stuff they were writing really was?

Program size: as Barry notes, even "hello world" can be huge.  How
important do you suppose it is that student programmers and other
learners be able to create small programs that they can pass around
to friends?  Some don't care but many do.  If I write a piece of
Lisp code for some simple string manipulation, I may find it very
useful myself, but I might actually be embarrassed to offer the
complete stand-alone application to anyone unfamiliar with Lisp.

Accessibility: Good C compilers are available, are cheap, and fit
on relatively small student-owned machines.  Having your own system
on your own machine is a big plus for anyone learning a language.
It isn't a requirement, but it helps.

Debugging: Most Lisps have pretty serviceable debugging tools.  But
what if your code breaks something at a low level?  It's pretty
easy to tell what piece of C source some assembly code corresponds
to, but not so for Lisp.  And there are other difficult situations:
I've been scratching my head for a while over one where the
compiler chokes on code produced by several layers of interacting
macros.  It is bewildering trying to figure out where this code
originally came from!

John Doner