Hello Andreas,

Sunday, December 12, 2004, 3:52:56 AM, you wrote:

AR> During the SqC days we have often heard the complaint that Squeak
AR> develops to rapidly, but none of that evolution was even remotely
AR> as deep and as intrusive as you are proposing now and have been in
AR> the last two or three Squeak versions. Code that I have been
AR> running quite literally for years broke in 3.7, then again in 3.8
AR> for extremely obscure side-effects of some so-called "cleaning".
AR> You and collegues need to understand that this represents a major
AR> problem for users of Squeak. And I think that being able to do
AR> research in software engineering is generally NOT considered a
AR> significant advantage for those users. It is important that you
AR> understand this issue. When I looked at 3.8 for porting Tweak to
AR> it I was seriously appalled by many of changes that have crept
AR> into the system. Proliferation of base classes has become a
AR> significant problem over the last versions and it won't get any
AR> better with more extensions to the base image. Something that -in
AR> lack of a better word- I will call "random reclassification" of
AR> methods (quite honestly I do not see any difference in putting
AR> methods into SystemDictionary vs. SmalltalkImage except that a)
AR> the name SmalltalkImage sucks and b) you now have to guess which
AR> place to look at) does not help to improve the situation.
AR> *Please* understand that everytime you move a method which has
AR> been in a particular place for a number of years you are
AR> potentially breaking dozens of packages. *Please* try to
AR> understand that this is a major problem for anyone using such
AR> methods.

Back in the days, code used to break all the time because of so-called
"features" added to too-closely-intertwined frameworks.

I have worked with Squeak on production code, and the amount of kevlar
spaghetti 2.8 had was intolerable already.

I have had the issues you talk about before, and IMHO it was because
of the following (including but not limited to) factors:

* lack of proper packaging mechanism

* frameworks tied together too closely

* framework code unrefactored over the years

* high average method length

* high count of class or instance methods


To me, however, by far the most irritating practice was this one:

* prototype code thrown in on the premise that "people can play
with it", topped with "if you don't like it then fix it", and if
necessary followed by "your fix breaks our stuff - fix deleted" or
"it's not the fix I envisioned - keep participating"


More directly...

... Andreas, I like the level of energy you commit to what you do.  I
appreciate that you have implemented many useful features for Squeak.
You are a successful core Squeak developer, and I hope you succeed
with Croquet as well.  Sometimes I feel you think you are the only and
most important user of the Squeak image.  What you say makes me feel
you think the Squeak image is Your Property.  I frequently feel you
have not been a landlord concerned with the needs of others.  Sometimes
when you talk about other people's work, I feel you think it must be
substandard by definition.  Sometimes, however, you do not follow
established best practices that in turn make it difficult for others
to use and maintain your code.  You also vehemently defend your right
not to follow well established practices.  I think we all want you to
be successful, and sometimes I feel you discard other people's advice
in a harsh way.


In other words:

Same As:
* dedication
* energy
* success
* adding features to Squeak

Less Of:
* code/image ownership
* negative about others' work
* negative about others' advice

More Of:
* open to constructive code reviews
* care for the needs of others
* following Smalltalk best practices
* positive leadership
* constructive cooperation with the community


Do you see these issues described?

Andres.