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
|