Hi Andreas,

I'm answering to your post, but mainly it is an answer to the whole
thread spawned by your post.

First of all, I don't know about all usages of squeak, but I guess
there's a hard line between those seeing squeak as a tool for
programming, and those seeing squeak primarily as a multimedia/teaching
tool.

It's perfectly normal and understandable, that those in the latter group
don't have a great interest in whatever the former group does, if I buy
a car I don't want to have to know about what has to be done to build
the car.

On the other hand, from following the squeak list for some time, I know
for sure, that those working on the base of squeak have always been very
aware of those who are mainly interested in end-user squeak, e.g. the
3.8 squeak release has only happened to fold back squeakland changes
into the base.

And you will understand, that those mostly interested in working with
squeak as a programming tool, just don't have the experience with the
end-user tools to know problems occurring there (let alone having the time).

I see squeak as something like a bridge, for years patchwark has been
added to the structure, so as not to disrupt the flow. Experiments have
found their way into the code base, and then have been abandoned. There
comes a time where you will have to close the bridge partly down for a
complete averhaul, lest it breaks down completely one day.

And that's exaclty what Stéphane and and his group were trying to do,
and with the blessing of those raising their voice. (Well, yes, I
remember posts about introducing Squeak instead of smalltalk).

One oversight may have been, that it has not been stated clearly enough,
that there may be rough times ahead, but I guess it was hoped that
everything would run a little smoother.

Well, they _could_ have forked their own version of squeak, and I'm sure
it would have been much easier for them, and I, for one, am really
gratefull that Stéphane tried to give his work back to the community.
(_Especially_ since there has been so few response, that he has _been_
the community, to a large degree).






Andreas Raab wrote:
> Hi Stef -
> 
> I have a few comments on your roadmap, some from a general point of
> view and some from a specific point of view. I'll give you the
> general points first. When I read your roadmap, it becomes clear that
> your major goal is to transform Squeak into something that you can do
> systems research in. Your priorities show this clearly - from MC in
> the base image, over RB, traits, new compiler, system dictionary
> refactoring is everything aimed at defining a playground for systems
> and software engineering research.

As I see it, it's about strengthening the foundation of squeak.

> _There is nothing wrong with this particular direction but *please*
> keep in mind that there are other interests in the Squeak community
> besides yours and that people with other interests have other 
> priorities. Most importantly for those "other" people is stability of
>  the base system.
> 
> During the SqC days we have often heard the complaint that Squeak 
> develops to rapidly, but none of that evolution was even remotely as
>  deep and as intrusive as you are proposing now and have been in the
> last two or three Squeak versions. Code that I have been running
> quite literally for years broke in 3.7, then again in 3.8 for
> extremely obscure side-effects of some so-called "cleaning".

Well, then it will work for the next years in those images. What about
the name of that famous OOPSLA paper? "Back to the Future", do you
_really_ want to stop reading after the first word?

> You and collegues need to understand that this represents a major
> problem for users of Squeak. And while some breakage is acceptable
> and expected in new versions there should be significant advantages
> for users in exchange for these breakages (say, like the m17n changes
> which broke a whole bunch of stuff at the advantage of being able to
> use international scripts). And I think that being able to do
> research in software engineering is generally NOT considered a
> significant advantage for those users.

Right, but everyone will profit from a strong foundation!

> It is important that you understand this issue. When I looked at 3.8
> for porting Tweak to it I was seriously appalled by many of changes
> that have crept into the system. Proliferation of base classes has
> become a significant problem over the last versions and it won't get
> any better with more extensions to the base image. Something that -in
> lack of a better word- I will call "random reclassification" of
> methods (quite honestly I do not see any difference in putting
> methods into SystemDictionary vs. SmalltalkImage except that a) the
> name SmalltalkImage sucks and b) you now have to guess which place to
> look at) does not help to improve the situation. *Please* understand
> that everytime you move a method which has been in a particular place
> for a number of years you are potentially breaking dozens of
> packages. *Please* try to understand that this is a major problem for
> anyone using such methods.
> 
> In this light ...
> 
>> - MC in the base image
> 
> 
> is a grave mistake, made worse by the lack of any consistent 
> argumentation why exactly MC would be needed in the base image
> (compared to a package loaded into full).

It's been discussed on the list for quite some time, and as much of the
partititioning work in squeak is based on MC, I think the tool for doing
the work should be in the base image.

>> In the past we created SmalltalkImage out of SystemDictionary in
>> the hope to have SystemDictionary be a nice and simple namespace
>> class. Lot of stuff has been put in coherent places
>> (SystemNavigation, SpaceTally, Changeset....) But this will not
>> work since people get used to add stuff there and Smalltalk is a
>> cool name. So the new proposal is the following one and is partly
>> implemented. Note however that it will require from us a lot of
>> work so if you are against it please say it and we will only do it
>> for us.
> 
> I wouldn't say I'm against it but I'd say that I reserve the right to
>  wait until you've got something to look at before making any
> judgement. I won't give you card blanche since I am not necessarily
> convinced that I will like what I see.

Understandable, but you must remember that they're _not_ doing this just
for fun, so giving them a basic security, that what they are doing is
heading into the right direction is only fair.

>> We plan to proceed that way:
> 
> [... snipped ...]
> 
> And I look forward to seeing what you're doing but at the same time I
>  don't see any compelling reasons why we would have to decide today 
> whether these changes would need to be in (base) Squeak 3.9.

It's called planning and open discussion, and normally considered to be
a good thing (except by governments and big corporations).


Ingo