Re: Lisp considered unfinished

[futrelle@ccs.neu.edu (Robert Futrelle)]

In article <3r5ads$60l@news.aero.org> doner@aero.org (John Doner) writes:
>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).

I am a professor who has taught lisp to students and it works.
>
>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.

MCL isn't very big.  It will fit easily onto all the machines 
in our Mac labs.  The very fact that the listener is there makes 
the environment trivial.  Type in whaterver and it compiles and
executes and gives you an answer (defs are added to the running
environment).

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

The language is only as big as you make it.  If the sample code you
give the students to guide them in their work only includes a handful
of functions, growing to 40 or so, then why should they be confused.
Don't just hand them Steele and say, this is it.  There are numerous
texts that only teach a core set of functionality.

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

Lambdas are a separate topic from returning functions, creating
closures and the like.  They can and should be treated separately.
You don't give "beginning" programmers exercises that involve these
things.

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

The reality you speak of really isn't there.  Modern CPUs and compilers
do exotic things to your code.  What about conditionals and case
statements? -- they certainly compile to odd things with gotos and
worse at the assembler level.  Is that the model you want.

Lisp has an elegant and simple model.  Arguments are evaluated and then
functions are applied to them and the value returned.  Data and function forms
have the identical syntax.  Could things be simpler?  As far as mental
models go, this takes a lot off my mind.

>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?

Since the beginning of programming, people have been commenting
on the poor quality of code that they are given to change/maintain.
This has _nothing_ to do with Lisp.  As for what is good style,
the same rule applies as applies to writing prose -- you have to
read good things in order to learn how to write good things.
(Peter Norvig makes that remark explicitly in his Paradigms book
and I seconded in in my AI Magazine review.)

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

Students, like professors, when it comes to programming, are more
interested in source code than in compiled applications.  The source
code for "hello world" in Lisp is (princ "hello world").  They 
can give that to their friends and their friends can compile it.

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

Digitool is now offering MCL 3.0 orderable directly from them
with student pricing.  It's not $39.95, but you get a lot for
your money.
>
>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!

Lisp doesn't tend to break on "low-level" things because there
are reliable parts of the Lisp system that handle pointers and memory
allocation for you.  If you write several layers of interacting
macros, you could be making trouble for yourself.  See Paul Graham's
book On Lisp for discussions of how you can hang yourself writing
macros.

>John Doner

  Bob Futrelle
-- 
Prof. Robert P. Futrelle | Biological Knowledge Lab, College of CS
Office: (617)-373-2076   | Northeastern University, 161CN
Fax:    (617)-373-5121   | 360 Huntington Ave.
futrelle@ccs.neu.edu     | Boston, MA 02115