[Seaside] [OT] Lisp vs. Smalltalk

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