Hi Stef -

Oh my dear ... I really don't quite understand what I did to get the 
reactions that actually resulted from my post (this has almost the quality 
of a troll) since I was trying to essentially point out two relatively 
simple things:

a) Let's keep stability at the base a top priority. I am not at all opposed 
to "enabling evolution" (to precise difference to doing research escapes me 
but I'm trying to find consensus with what you wrote) but I think there have 
been a variety of situations in which a bit of reflection and a little extra 
thought would have dramatically helped to avoid problems.

b) I don't like the idea of MC in the base image.

That's all. A few specific notes:

> We thought that without MC in the base image, we cannot manage Sunit and 
> other packages. So without MC we are stuck.

You can still manage it via updates and change sets. For a user of Sunit not 
much would change; a developer of Sunit can load Monticello first or just 
use the "full" image anyway.

> But again this is quite simple if the community does not:
> - read what we are doing in time (and not one year after) how can we 
> react?

Sigh. I thought this is what we were doing here. I really didn't write my 
message to piss you off (although I clearly managed to) but rather because I 
felt that we need to manage these issues a little better.

> > a) the name SmalltalkImage sucks
>
> Good to hear after all the discussions that we got some months ago.

Actually, I said from day one that I would use the name "Squeak" (which 
might be an instance of SmalltalkImage for god's sake) if I felt anything 
needs a new home.

> But we do not ask for a card blanche, we ask for an analysis and a 
> consensus, because we will not spent time on something that one guy
> like you can say after 6 months of work: oh this is just a
> reclassification of methods
> Come on are you serious?
> Is it the way that this community wants to work?

I am actually dead serious. Because this is the way in which the community 
actually *does* work. When was the last time that the community has approved 
changes beforehand? Yes, there are often discussions about what to do, and 
what would be useful in the community but when push comes to shove people 
will reserve the right to say "no" even after the code has been written, and 
even after people have said "we want it".

Cheers,
  - Andreas

----- Original Message ----- 
From: "stéphane ducasse" <ducasse at iam.unibe.ch>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Sunday, December 12, 2004 3:03 AM
Subject: Re: A roadmap for 3.9


Hi andreas


you really confuse our point. We are not talking about enabling
research we are talking of making sure that the system
can evolve which is different.

> 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.

Absolutely wrong.

We thought that without MC in the base image, we cannot manage Sunit
and other packages. So without MC we are stuck.


> 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.

This is not about research this is about been able to have
security
mops
language extensions such as the Tweak primitives without hacking the
compiler in the corner.
but apparently everybody prefers patches over simple code

> 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.

but we know that.

> 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".

Give some examples.
Note that during years cruft accumulated in Utilities and in
SystemDictionary so adding shit on shit and been cumulative is
clearly a sign of long term death. Take 3.4 and browse SystemDictionary
or Utilities

But again this is quite simple if the community does not:
- read what we are doing in time (and not one year after) how can we
react?
- like what we are doing we will simply work on our own system and be
certainly much more productive.

> 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.

What is fun is that the motto of alan is inventing the future, but how
can you invent something by only patching
little stuff there and there. Ask nathanael how time it would have
taken him to implement traits in a clean Squeak
vs. the one he had. He told me that he spent all his time fixing the
system, the compiler.... and I trust him since
he is excellent.

This is by not changing (even if we are aware that this can have impact
and that we want to limit the impact of other others)
that Squeak will improve. Look at new mop, new ide, new ideas are
coming from java or other languages and this is not
because we have some cool assets such as seaside or croquet that this
will change radically the problem. If the system is bloated then it
gets into your way to create new assets.

> 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

What I like with you is that the way you reduce that. I spent a lot of
time trying to remove junk and classify a bit the mess in
systemDictionary. SystemDictionary is a namespace and not a junk place
but I got the message, all the time I spent cleaning that was not  for
fun or for research point of view just because each time I opened the
system I nearly fainted and because I was fed up  to say to my students
"do not look at that this is crap" because else they would not
understand that we would like smalltalk.

> a) the name SmalltalkImage sucks

Good to hear after all the discussions that we got some months ago.

> and b) you now have to guess which place to look at) does not help to 
> improve the situation.

Because we had to do it slowly to avoid to break.
Now if this wonderful community would have CLEARLY state ok let us
clean it for real then this would be fixed.
But the fact that we have to do it small pieces by small pieces make
everything harder for us too.

> *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.

But you have deprecated methods so normally the transition should be
smoother.

> 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).

Because we cannot manage the in image packages. So in that case we
should not have in image packages. But nobody
manage the image anymore so this is even simpler.

>> 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.

But now we will have a discussion in the group here to see what we will
be doing.
And I'm not convinced that we will continue to help Squeak. especially
if this is to get this kind of message after
all the energy that we spent to pay attention to other people.

Because andreas you have also to understand that this is much more bold
and rewarding to build hyper new fancy
stuff than but changing the color of the facade (I'm exaggerating here
of course) is much easier that renovating the fundations.

>> 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.

But we do not ask for a card blanche, we ask for an analysis and a
consensus, because we will not
spent time on something that one guy like you can say after 6 months of
work: oh this is just a reclassification of methods
Come on are you serious?
Is it the way that this community wants to work?


Stef

>
> Cheers,
>  - Andreas
>
> ----- Original Message ----- From: "stéphane ducasse" 
> <ducasse at iam.unibe.ch>
> To: "The general-purpose Squeak developers list" 
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Thursday, December 09, 2004 4:38 AM
> Subject: A roadmap for 3.9
>
>
>> hi all
>>
>> I have been discussing with marcus/alex and also thinking about that 
>> after my remarks on andreas remarks related to
>> changes, interfaces/ cleaning vs changes. So to avoid get frustration 
>> from all the parts and to state clearly what is our
>> plan for 3.9 we would like you to read the following and let us know. 
>> Depending on the reactions, we (the guys from berne) may decide to 
>> produce our own stream, because we must work too ;). But we understand 
>> that other people cannot deal with a system changing. But in that case we 
>> should draw the consequences.
>>
>> Our part that we will work on for 3.9 is to get the system improved from 
>> a developers point of view. We
>> think that having a good foundation is important for everybody.
>>
>> The overall idea is to slowly improve one aspect of Squeak: The idea to 
>> have a System to build the next
>> System with.
>>
>> This has lots of consquences, one is that you want the system to be in a 
>> shape that e.g., students that are not yet
>> complete Squeak experts can start to do experiments with it on a quite 
>> deep level, e.g., change the compiler or
>> add a feature to the Browser.  Another aspect is to have a System for 
>> research. The Traits project has been hugely
>> successful, but it has shown that Squeak does have real problems if you 
>> use it for stuff like that. If Squeak is supposed
>> to be the system of choice for research like this, we need to fix those 
>> problems, we need to make sure that the
>> lessons learned from those projects get fed back into the system. (One 
>> example is the change-notification that was added to 3.7, it is a direct 
>> result of the Traits project)
>>
>> All this does not mean that 3.9 will only be about that stuff: We surely 
>> want to see e.g. the work of Diego beeing
>> included, also any changes that other people would need are welcome.
>>
>> For our perspective here what we would like to have: we put in (p) the 
>> code that  will be in external packages,
>> which likely will be "full".
>>
>> - services
>> - new preferences pane
>> - OB (p?) + browseUnit new version
>> - MC in the base image
>> - rbengine (p)
>> - shout (p)
>> - SqueakMap II (yes we want it)
>> - eCompletion or another package
>> - keybinding
>> - traits
>> - new compiler framework of anthony adapted by marcus to produce
>> not full block. Note that for Etoy the old compiler will still be in the 
>> image so from that point of view
>> it should not have an impact.
>> - refactoring of systemDictionary. (see below this point)
>>
>> We are sure that we forgot something but this is what we have on top of 
>> my head.
>>
>> Now for systemDictionary here is the situation and here is where we would 
>> like to be after 3.9
>>
>> 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.
>>
>> from a user point of view we want to have:
>> only one class: SmalltalkImage/SystDict for all the image related 
>> services
>> (VM pluggins, ....) but the namespace behavior will be delegated to 
>> Namespace.
>>
>>        All the previous code referencing Smalltalk will work but with 
>> deprecation for the namespace interface.
>>
>> From the language programmer point of view:
>> there will be a namespace that can be used for experimentation
>> this class will replace the environment class of dan that is now obsolete
>>
>> We plan to proceed that way:
>> - create a class namespace with a new interface (done)
>> - delegate from systemDictionary to this new class (done but not 
>> published)
>> - deprecate all the namespace method of systemDictionary (but we likely 
>> want to keep them for some time)
>> - fix all the in image senders of Smalltalk as a namespace to use the new 
>> class (using self environment for example).
>> (partly done over the previous years)
>> - merge back SmalltalkImage into SystemDictionary: the idea here is to 
>> not have SystemDict as a subclass of Dictionary
>> - have Smalltalk pointing to an instance of this new entity, so that 
>> everybody is happy.
>>
>>
>>
>> Stef and Marcus
>>
>>
>>
>
>