Against wastefull forks (Re: Taking Ownership of Squeak (WAS Re: Python at Disney))

Paul Fernhout pdfernhout at kurtz-fernhout.com
Sun Mar 11 04:16:28 UTC 2001


"Andrew C. Greenberg" wrote:
> Be patient.  2.8 is stable.  

Events?
Exception handling?
Debugging launched windows without hangs?
Complete reliable deployable good-looking widget set?
Truncating files?
Reliable efficient cross-platform sockets?
Callbacks?

> In short, I simply don't see any problem with Squeak's stability that
> would give pause to any serious developer.  

See above. Some are stability some are critical functionality for the
types of (business) applications Dan is talking about.

> EVERY version that has
> reached solid release status has bugs.  Guess what?  ALL SOFTWARE HAS
> BUGS.  But every version since I have been involved with Squeak has
> been remarkably stable, or trivially patched where it has hiccupped.

There's bugs and then there's things that make something unsuitable for
a purpose (e.g. shippable applications). 
 
> Perhaps you ought to hang out for awhile longer, and at least try to
> contribute your modifications, before proposing a fork.  Forks should
> be the result of irreconcilable differences, and never one of mere
> convenience.

Dan has made several contributions and been on the list for quite a
while. I've been on the list myself more or less since 1996. 

I appreciate your point of effectively "put up or shut up" in terms of
implementing suggestions. Generally that is the right thing to say if
said tactfully in an open source context. Except in THIS case. This
isn't just a whine about a bug to be fixed or a widget to be added.

The point is that the fundamental Squeak architecture is roughly done
because it is not modular. This is a major design flaw. Let me repeat --
LACK OF MODULARITY IS A MAJOR DESIGN FLAW for a system that has the far
reaching goals Squeak has -- and this design flaw percolates throughout
the entire Squeak system (and, effectively, Smalltalk-80 in general,
despite all the other wonderful things ST-80 represents). Modularity
cannot be "patched" in after the fact the way one could add a new
morphic widget or fix a bug in Celeste or add a new primitive to the VM. 

Making Squeak modular requires a complete rethinking and a significant
effort and extensive code changes and includes regenerating the base
image. These changes taken together make integration with another
ongoing stream so difficult as to be IMHO effectively impossible. That
is why I don't think such changes could not be patched in after the fact
by SqueakC. 

Effectively, once this modularity change is accomplished all development
would have to move to this new line to gain its benefits. It is likely
much development work done since the modularity rewrite would have to be
revised. The only approach I and other see is to either:
1) have SqueakC do it or 
2) have a fork and hopefully have SqueakC embrace the fork later.

The good new is, once Squeak was more modular, future upgrades would be
easier to make, and integration of patches would be much easier.

To get back to the point that started it all (Disney again choosing
Python over Squeak), the main thing Python uses to maintain enough
modularity for RAD is the notion of loading code on demand from a file
system with names referenced in import statements into a dictionary
(namespace) with qualified name references, and allowing compiled code
to share this interface. Simple, but effective. But -- the implications
for Squeak would be profound and require many scattered code changes.

I appreciate the good intent behind what you are trying to do, and I
agree very much that a fork is a bad thing because the best thing for
Squeak is to keep the community together as much as possible. But that
still leaves us with a Squeak that is not modular, and a situation
where  modularity is not happening because this particular hurdle seems
too high for anyone (short of a major (funded?) effort in a fork) to
make modularity happen short of SqueakC taking it on themselves.

Should someone have a brilliant idea that lets modularity be "patched"
in to Squeak -- I'd love to see it! Short of that, if modularity does
not become a high priority item for SqueakC, I think it will only come
about in a (needed, but sadly wasteful) fork.

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com





More information about the Squeak-dev mailing list