A roadmap for 3.9

Andreas Raab andreas.raab at gmx.de
Sun Dec 12 09:52:56 UTC 2004


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

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

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

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

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




More information about the Squeak-dev mailing list