On Sat, 5 May 2001, John B. Thiel wrote:
[snip]
> Through my recent explorations with Squeak, I observe that a substantial 
> amount of valuable Contrib code is being defacto jettisoned 
> version-to-version.  (rough empirical estimate: anything not in -current 
> has about a 15% chance of working).

I'd love to know your methodology for making this observation and forming
this estimate, plus some notion of the degree of roughness/margin of
error.

I'm afraid I stand with Andrew in not sharing that view. And
"jettisoned" is a tricky term...for example, I just made a few tweaks to
the T-Gen port, which did stop working with 3.0....but it was never a
completed or polished port. But heck, this is *old* software! Furthermore,
getting it to work wasn't at all difficult. Much unused stuff is not
updated because, well, it's not used. Not all, certainly. And there are
things which drop out and pop back in.

(This no where *near* describes all that goes on, either pro or con.)

One thing to remember is that the Squeak development cycle is fast. I tend
to look at the major number changes as the "big" ones (e.g., 1.1X to 2, 2
to 3). Even there, I wouldn't be fearsomely daunted at the prospect of
moving various bodies of code from 1.1x to a 2.x image, and *certainly*
not from a  2.x to a 3.x image.

Some things are way more in flux than others. Morphic internals, for
example. There've been several interface builders which, I feel reasonable
confident, would have trouble with the changes in Morphic (although,
I haven't dorked with them, I could be wrong). OTOH, SameGame has worked
flawlessly, afaik, for almost all of the 2.x cycle. Better, if you use the
pluggable classes, you can build *UI* stuff that will just work. Not
fancy, but quite workable. Look at the IDE, Scamper, Celeste, the file
browser...T-Gen :)

Note, I've had *more* trouble moving T-Gen from Dolphin 2.x to Dolphin 4,
mostly because of my unfamiliarity ;) But moving the UI stuff isn't just a
fileout and in.

>  This is both discouraging for the 
> newcomer and hinders growth. 

Actually, I think it's exciting for the newcomer, and stimulates growth by
clearing out the underbrush. Burn the disk packs! ;)

So, c'mon. If it discourages *you*, just say so. That's a reasonable point
to make.

> Because modules do not stay viable, 
> peripheral contributors are re-implementing the same wheel repeatedly.

Examples? I have trouble even *following* what you wrote.

> Thus, I second the view that a modular and stable base are of paramount 
> importance for Squeak to emerge from   "monolithic kernel" to an 
> exponential growth platform.

Er..it looks like you mixed your something, not metaphors exactly. Why is
being an "exponential growth platform" a good thing? For all you know,
Squeak's user base *is* exponential.

Some would (falsely) claim that the image size is growing exponentially :)


>  Such features as namespaces, packages, 
> version dependency maps, autoloading... seem critically needed for this 
> direction.

Again, if you want these things, just say so. There is *no need* to invoke
the vast unwashed hordes. Aha! I just had a little epiphany...one reason
that this "Squeak is doomed/not growing fast enough/is failing" trope
drives me nuts is, aside from it putting forth false claims on
insufficient evidence, that it seems to express a lack of
self-esteem. Heck, if you like modules, even if modules would doom
commercial development with Squeak (in some possible world), it's
reasonable to want modules! If there are enough people who share your
anti-commercial want, you could have your own fork! Or maybe the main
Squeak distro will cater to you because most Squeakers like that,
regardless of commercial wants (or non-commercial wants).

I like the "exquisite personal enviroment" view of Squeak. And I think we
get to be exquisite persons when using and discussing it. Thus, it is
justification enough to put something on the table that you want it.

It's worth putting it on the table because if we *can* find something that
suites most of us, that's very cool!

Cheers,
Bijan Parsia.