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
|