On Thursday 19 April 2001 08:45, Paul Fernhout wrote:

> I enjoyed your write up. It takes a certain set of skills to be able to
> produce such a detailed and well written set of issues from a first-hand
> perspective, and thanks for doing it.

And thank you for reading and responding!  I was quite nervous to be posting 
a draft of something critical so early in my squeaking career, but it seems 
presently topical so I didn't want to miss the opportunity.  Happy to see 
that the community is so friendly and erudite :).

> You get pretty much complete agreement from me.

Glad to hear that too.

> [much stuff elided]

> Manual De Landa in his book "A Thousand Years of Non-Linear History"
> talks about "hierarchy" and "mesh-works" as two organizational forces
> that are always intertwining on a practical basis. The problem we have
> here is a basic difference in slant from SqueakC and developers coming
> from a Unix (or commercial) background. The original Smalltalkers must
> believe in mesh-works, but we are saying Squeak needs a bit more
> hierarchy. The reality is probably that something in the middle is a
> better thing than being at either extreme.

It seems to me that the heirarchical organization of a UNIX installation is 
more of an issue from a technical perspective than a social perspective.  In 
the case of Linux, Linus manages the core but does practically nothing to 
dictate policy even to a group as system-level as the XF86 people, since they 
are working to a more-or-less specified standard of UNIX, and their code 
works on FreeBSD too.

Whereas Squeak is a mesh-work in terms of its internal organization, but 
socially, it is currently a very strong heirarchy with SqC at the top. The 
absence of modularity (heirarchy?) in the code doesn't permit anyone to make 
changes that will continue to work with other people's work in the future 
without SqC's approval.  It seems that revolution is brewing around the 
Squeak World Tour, but without some sort of modularity being included in 
their plans, it would just be 2 heirarchies.

> > However, making the virtual machine modular, adding namespaces,
> > fixing the UI [etc] is a difficult, but eminently possible task.
>
> Agreed. Having pluggable primitives is already there to an extent
> (yahoo!) as a nod to modularity, but the deeper issues of modularity

As a matter of fact, what convinced me to stick with Squeak was browsing 
through the FFI examples :).

> (vm-to-vm remote debugging),

How far in that direction does Nebraska get us already?

> namespaces,

Environment already does this to some extent, right?

> and alternative "classic" GUI

There were GTK bindings at some point (again, broken by evolution of the 
interface) but how hard would it be to get them working again, this time 
using the modular FFI?

Less extreme, and more portable: a modification of the virtual machine that 
would allow multiple toplevel "native" windows to be created would make a 
more normal-looking UI quickly possible.

> > The problems I've enumerated here are some of the things I hope
> > to work on as I work with Squeak.
>
> You and many other people!

Well, let's get together then! :)

> There needs to be a group that has a mainline distribution with an emphasis 
> of addressing these issues. (SqueakFoundation?)

I believe this is what the Squeak World Tour is doing, right?  I would like 
to contribute to a group doing this as soon as possible.  How do I sign up?

> My prediction is that within a year if a fork happened and took off,

My prediction is that such a fork *will* happen. Although I'm no expert in 
smalltalk yet, I will do my best to help make it happen if SqueakC doesn't 
make modularity and some sort of "baseline" API beyond ST-80 a high priority.

> no one will want the SqueakC distribution,

Certainly nobody will want their (monolithic) distribution, but everyone will 
want their features.  Despite the problems we're discussing, there are a 
number of terribly smart people working on adding some great things to squeak 
at SqC.  Pressure for them to modularize such features would be nothing but 
good, IMHO.

> But there is a high cost for everyone to pay [...]

Not as high as the cost that has been paid, and will continue to be paid, by 
the development community in terms of lost interest and continued bad press.

> [ snip stuff about apple and IBM ]

Your suggestions would involve a corporate entity behaving rationally, so 
I've got to discount them as whimsy. :)

> However, the essential thing to remember is the most important aspect of
> Squeak is the community and this mailing list. If we all "burned the
> disk packs" I'm sure this crowd could have a better Squeak up and
> running in six months! (Probably with protoypes like Self.) Whatever is
> done, I think an essential aspect of any effort has to be to keep the
> Squeak community strong and growing.

It is indeed unfortunate that a fork is necessary, but let's thank the magic 
of Open Source that a fork is possible!  It certainly wouldn't be possible to 
accomplish such a thing with VisualWorks.

-- 
                      ______      __   __  _____  _     _
                     |  ____ |      \_/   |_____] |_____|
                     |_____| |_____  |    |       |     |
                     @ t w i s t e d m a t r i x  . c o m
                     http://twistedmatrix.com/users/glyph