[Seaside] [OT] Lisp vs. Smalltalk

[Avi Bryant]

On Wed, 5 Jun 2002, Frank Sergeant wrote:

> Well, somewhat off-topic and for my relatively idle curiosity, I thought
> I would ask about your use of Lisp versus Smalltalk.  From other posts,
> I have gathered you were web programming in Lisp and then switched to
> Squeak?  Why?  What are the tradeoffs as you see them?

Oh dear, that question.

My take is roughly this:  Lisp gives you macros.  Macros are very
appealing - they are immensely powerful, and let you approach
problems, in a very real sense, by building a custom language within which
to solve them.  This is very much the way I prefer to write code - don't
bring the problem to the language, bring the language to the problem.

On the face of it, Smalltalk's lack of macros makes it rather less useful
than Lisp.  However, Smalltalk makes an engineering trade off.  It says,
no, you don't get macros, you get one syntax and one paradigm.  It's a
very powerful paradigm, but it's the only one you get.  In return,
however, we can do this: because we know exactly what paradigm you're
writing your code in, we can support it in all these amazing ways.  We can
have browsers that structure your code meaningfully, we can have change
sets that track program modifications semantically instead of textually,
we can build automated refactoring support, and so on.  To me, this is a
worthwhile trade off: I lose some of the strict power of Lisp, but I gain
a hugely productive environment.

That's also where I think Self might have gone wrong.  Self removed some
of the paradigm restrictions - yes, you *can* build class systems, but you
don't have to.  But giving you the choice reduces you to writing all your
code in inspectors instead of browsers.

Obviously you could impose arbitrary restrictions on Lisp, or build more
structured frameworks out of something like Self or Scheme, but then what
do you end up with?  A non-standard, buggy implementation of half of
Smalltalk ;-).

A couple of other engineering points in Smalltalk's favor: closures/blocks
have a much lighter-weight syntax in Smalltalk, and thus can be
realistically used in more places without wrapping them in macros.  Also,
although I love multimethods, the generic function approach to polymorhism
doesn't allow #doesNotUnderstand:, which is invaluable for things like
distributed objects and database systems.

 > There seems to be a certain amount of the "care and feeding
of the > image" necessary in Smalltalk that the use of Lisp might avoid,
> although I guess Smalltalk could be used that way by starting from a
> standard base image and reloading packages (Dolphin) or change sets.

I've had decent success recently in Squeak with my DVS system, which syncs
a smalltalk image with on-disk source code (this is similar to the
cvstproj, but tailored to my needs).

An interesting point between Smalltalk and Lisp, by the way, is Ruby -
Smalltalk semantics, but no image, and decent support for metaprogramming.
If you haven't looked into it yet I suggest you check it out.

Avi