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.

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.)

Yet another comprehensibility issue: I believe that most people
reach an understanding of how a programming language "works" by
constructing a mental model of the computer and how it responds to
language constructs.  This model changes as learning occurs.  In
the case of C, the language is close to the hardware, and it is
relatively easier to arrive at a mental model that is a serviceable
approximation to reality.  But the reality of Lisp implementations
is much more complicated, and calls for a more complicated mental
model.  So students spend more time blundering around, wondering
why things happen the way they do.  I spend some time explaining
"how it all works", but there's little doubt that this adds to the
perceived complexity of the whole experience.

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