Let's take stock (Was: Against wastefull forks)

Andrew C. Greenberg werdna at mucow.com
Sun Mar 11 21:45:01 UTC 2001


I have found the debate about forking utterly tiring, and this will 
be my last post in that thread.  I would like to suggest that before 
slamming the status quo and arguing for what should be forked, that 
we first take stock of --and perhaps say thank you for-- what is 
already going on and in process.

Has anyone been watching what has developed lately?  In the most 
recent changesets, we have had:

"Change Set:		SegmentingChanges
Date:			5 March 2001
Author:			Dan Ingalls

Several changes that make it possible to partition a current Squeak 
3.1 image into a kernel image plus about a dozen segments.

Also includes changes to discoverActiveClasses with support for 
analyzing the specific history of each first reference to a class 
during the discovery process.

Also a number of changes that reduce the incidence of gratuitous 
references to classes that aren't really in use, thus reducing the 
need to (download and) bring in non-kernel segments.

There are still a number of kinks in this process, but it has 
produces a full current 3.1alpha image with a 4MB kernel with 16 
segments, capable of downloading a project over the internet with no 
need to bring in any of the peripheral segments."

Its been almost a year since the Environment namespace structure 
classes were implemented.  Moreover, and perhaps more interesting, 
have been the recent developments concerning ImageSegments.

Perhaps nobody has noticed, but modularity and segmentation have been 
meaningful priorities for Squeak Central for quite some time now. 
Notwithstanding the naysayers, however, its been SqC, and not the 
pro-forkers who have been building these tools.

These guys have been offering tools for those ready to pick up the 
ball and run with it for some time.  Rather than quibbling about 
forks, let's go ahead an build something meaningful.

I don't expect IBM to port Envy to Squeak for free, nor for SqC to 
build it.  Perhaps it would be nice to have, perhaps it would be nice 
for someone to build for us.  In any case, I don't see why a fork 
woudl be necessary for "a development" environment to exist or come 
to fruition.  The status quo and development environment and 
community is more than adequate to evolve there.

In the meanwhile, I am rather enjoying Squeak -- finding it generally 
adequate for what I want to do, far more adequate than other tools 
(including Python), and finding Squeak's deficiencies more of a 
challenge and enticement, than a predicate for gainsay and arguments 
about forking.

As promised, I'll now leave the thread to those of you who seem to 
enjoy the gainsay more than the system, but commend to you the 
following suggestion: if you can dream it, you can build it.  (Much 
more polite than "put up or shut up," but essentially the same 
thing).  We look forward to all of your contributions.





More information about the Squeak-dev mailing list