Daniel,

Ultimately this is a point of view issue. It is unfortunate that Croquet
was reveiled to the Squeak list too early. At this stage *none* of the
advantages of Matrix can be seen and we are discussing things without
having anything to talk about. "Usefulness" cannot be discussed in such
a context. "Compatibility" cannot be discussed unless the impact is
clear. "Scope" cannot be discussed unless it is known where it is being
used. Yes, it would be feasable to allow these extensions only in
certain classes but (just to stay with one of your arguments) these
classes would be no more portable and would break the RB regardless of
whether the extensions were allowed in every class. It simply makes no
difference.

I believe that these extensions will solve one of the major problems
Squeak has today in the area of manipulating media - namely the need to
write primitives for about everything that needs to add two numbers for
a large data set. This may not be important for "bean counters" but it
certainly is for -say- kids who want to make their own visualizations
(something like WinAmps visualizer). They should be able to make
something like a "StarMusic" simulation (think of StarLogo based on
frequency, rythm, beat, whatever) and then have it being run in
real-time WITHOUT having to learn how to subclass InterpreterPlugin and
compile VMs for each platform. Got it?

Many problems in simulation can be expressed in much easier terms if you
think about the problem spatially instead of having to write loops. This
is one of the primary motivations here. If you look at the TFlag in
Croquet I'm pretty certain you will not figure out easily that all it
does is take an array of vertices and subtract them shifted by one row.
If you could see this (rather than endlessly nested loops) you might
actually be able to build your own simulations along those lines. A
typical example is image filtering where you have to write  four levels
deep loops along the lines of:
	1 to: image width do:[:x|
		1 to: image height do:[:y|
			1 to: filter width do:[:i|
				1 to: filter height do:[:j|
etc. etc. etc. And no, this is of no importance for bean-counters ;-)
but it is important if you want to deal with media.

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

This is wrong (yet for very nit-picky details which I am not going to
explain).

> The scope of Matrix seems to be exactly the definition of new 3D
> primitives and operations -

This is "even more wrong". The idea is to have a very efficient "spatial
number cruncher" which can be used to process arbitrary large data sets.
3Dish data just happens to fall into that category.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Daniel Vainsencher
> Sent: Friday, December 06, 2002 8:44 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Croquet alpha release(s?)
> 
> 
> 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
>