On Fri, Dec 06, 2002 at 12:33:04AM +0300, Daniel Vainsencher wrote:
> There are a few different reasons. I'll list them in ascending order of
> importance, as I see them:
> 1. Compatibility with other Smalltalks. Being able to port code around
> is a good thing.

Unless it stands in the way of progress.  I'll take Traits over complete
backwards compatability with ST-80, any day.

> 2. Compatibility with thing that refer to Smalltalk syntax, like books
> and ST parsing tools. These include, but are not limited to the
> RefactoringBrowser and the related tools, like Smalllint. 

See above.

> 3. Simplicity. Today we can excuse an extension because we need fast 3d
> graphics, tommorrow we'll find another that's very convinient for
> printing financial information, and before you know it, we'll be
> programming in CobTran. Or ForBol. Or something just as elegant.

We are witnessing a fundamental change in the architecture of the
average user's computer, as modern graphics processors surpass the
transistor counts of CPUs.  It seems vaguely silly to compare a syntax
extension for bean-counters (sorry, bean-counters) to a syntax
extension that can elegantly and efficiently access vast new hardware
capabilities.  

Furthermore, computational media and dynamic simulation have been
central to the Dynabook vision since its inception.  Again with
apologies to the bean-counters, financial information is not.

> 
> It's really mostly the third - I like Smalltalk small. I've heard from
> David Simmons all the best reasons to extend the Smalltalk syntax in
> magnificently ingenious ways, serving scenarios much more common,
> AFAICT, than matrix operations (easy interoperability with c headers),
> and my conclusion is that that's great for the expert, not such a hot
> deal for the newbie, and the expert can override compilerClass.

I can appreciate your sentiment; I like Smalltalk small, too.
However, Smalltalk isn't perfect, and we should be open to changing it
if the benefits outweigh the costs in terms of decreased compatibility
and simplicity (which, as Andreas explained, aren't so large anyway).
Of course, being a graphics person, my bias is evident.

What will be Squeak's killer app?  My money is on Croquet.  I expect
that the official release of Croquet will bring with it a large amount
of interest from graphics hackers.  These people are experts in their
domain, but they will not immediately be Squeak experts, and they will
not know that each class is capable of specifying its own compiler.
Simplicity isn't just in the syntax.

Best wishes,
Joshua