A roadmap for 3.9

Marcel Weiher marcel at metaobject.com
Sun Dec 12 15:56:22 UTC 2004


On 12 Dec 2004, at 09:52, Andreas Raab wrote:



> 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.
How does this become clear to you? All I can see is a desire to create 
a cleaner base that will *not* suffer from the (huge!) problems of the 
current base. The ironic thing is that it seems to me they want to fix 
exactly the sorts of problems you are complaining about!

> 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.
Which currently is the 'stability' of ossification. We need fundamental 
changes in the base if we are going to get out of this. As far as I can 
see, the proposed changes are first steps in that direction: making 
such change even possible/thinkable.

> 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".
Hmm...from my experience with Squeak, my guess would be is that it was 
the code you were running or depending on that had/required obscure 
side-effects. Can you give an example? Getting rid of such obscurities 
is a Good Thing, but there will be some pain. Definitely will be.

> And while some breakage is acceptable and expected in new versions
Good!

> 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).
Hmm...so for every cleanup there has to be a "goodie" feature thrown 
in? Sorry, that seems utterly bizarre.

> And I think that being able to do research in software engineering is 
> generally NOT considered a significant advantage for those users.
Neither is having a good base a user-visible surface feature. However, 
a good base has an indirect benefit for users. I think you understand 
this, or why are you building your system(s) in Squeak and not Visual 
C++?  After all, the users wouldn't be able to tell the difference...
> *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.
*Please* try to think *why* this is such a major problem, and if you 
can think of a way of cleaning up the base without incurring these 
sorts: let us all know!


>> - 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).
I think this was discussed on the list quite extensively...why is it a 
"grave mistake"?

Marcel




More information about the Squeak-dev mailing list