Croquet alpha release(s?)

Daniel Vainsencher danielv at netvision.net.il
Fri Dec 6 07:44:21 UTC 2002


Joshua 'Schwa' Gargus <schwa at cc.gatech.edu> wrote:
> Unless it stands in the way of progress.  I'll take Traits over complete
> backwards compatability with ST-80, any day.
I think the two cases are very different. Point by point -
Usefulness/power -
Traits are a general purpose tool that allows to express more kinds of
design. They might (or might not) be useful for programming any kind of
system. And their usefulness (if it's real) would translate into better
factored, more concise systems. This is a huge advantage, because it
makes every piece of code that uses it more accessible to contributors.
I put alot of conditionals there because so far it's been used only by
it's designer (Nathanael) and an expert (Andrew Black). Nathanael will
hopefully soon release on SM and we'll all be able to judge for
ourselves.

The proposed change for Matrix does change the syntax, allowing the
writing of methods that no Smalltalk compiler would accept. This code is
equivalent to somewhat more verbose code - this means that it makes the
code somewhat shorter, but it doesn't simplify the design. 

The same speed advantages could be gained using more conventional by a
special case in the compiler  syntax (like #ifTrue: uses). Andreas,
please correct me if I'm wrong here. 

Compatibility -
Traits are designed to be rendered into Smalltalk - they have no syntax
and no semantics. So the flattened code is Smalltalk. This allows some
semblance of compatibility. Matrix operations are not valid Smalltalk
code.

Scope -
The scope of Matrix seems to be exactly the definition of new 3D
primitives and operations - once you've defined how these should be
rendered/executed in speedy terms, these can be reused from the outside
using pure Smalltalk code. So it really seems to me to appeal to the
rather small minority of future Squeakers that actually do new 3D
graphics stuff. Most of the people drawn to Croquet and interested in
adapting it to their own uses, will be reusing and scripting around
existing 3D objects and operations, and won't use Matrix much.

As I've said above the scope of Traits is likely to be quite large,
though we won't know until more of us have used it.

Some of the above is speculative - I'm no sort of Croquet expert. I'm
sure David or Andreas will catch me if I'm assuming something
inappropriate.

About making things easier for a hoped-for inpouring of 3D experts, we
can always tell them in the Squeak-for-c/ASM-3D-hackers tutorial to just
subclass from Object3D, which defines it's compilerClass. A crutch they
can easily leave behind when their Smalltalk expertise grows.

(just think of the syntax changes we'll see when quantum computing comes
on line.... scary ;-)

Daniel

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



More information about the Squeak-dev mailing list