Discussing a comment

This is in response to a comment made by Stephan Eggermont to my post "Stick to Smalltalk naming conventions":

First my résumée:

Essentially, you are not discussing the pros and cons of my proposals but you're just defending what has been done in Squeak in the past. Self-defense is not a good standpoint for discussing proposals and improvements!

I myself am rarely truly content with what I see and least of all with what I have done in the past.

Stephan Eggermont said...

1 Having a consistent naming schema as part of coding conventions is basically a good thing. I am not convinced the new... convention is a good one for Seaside to use.
Why? No argument brought up!

I do think that these convention are general, i.e. apply to all systems. Second, the "new" related convention was just one of many other conventions that are violated by Seaside and just one proposal among many others that I have already made or that will come in the near future.

2 Open source projects can only handle coding conventions which are accepted by the major contributors. Decision making in an open source project is in general not democratic but meritocratic. If you want more influence, provide more value to the community. Current conventions can be found at http://www.seaside.st/community/conventions/initialization

>major contributors
Right, exactly that is my critics that they do their own very unconventional thing and good are shipped on what has been considered good practice in small talk for over 25 years!

Avy Bryant's comment is the best example: he considers himself wiser than the authors of the original basic libraries, which is generally and also by myself considered an ingenious piece of software design. It's always problem when a poult believes to be wiser than the hen! And with "hen" I don't mean myself just to make that clear.

>meritocratic
It is clear that the weight primarily depends on the reputation of the individuals in the community and not of their arguments! The responses to my substantial arguments or another proof to this old life experience.

2 When I take a good look in my Squeak images, the use of new... as a convention is not recognizable.
Which of course does not contradict my statement that it is a convention, because Squeak is a hobbyist spinoff, which is typically not used for products (primarily due to the unfortunate lack of a proper user interface).

3 Basic frameworks do not use the new... convention. (for me Seaside is a basic package, as it was the reason I switched to smalltalk)
I am answering to your very global statement just as globally with an old German saying: "A million flies can't be wrong sitting on a dunghill!" - but that doesn't also apply to me!

3 In the smalltalk literature the new... is not described as a convention.
Well, I'm not going into my big library but I am sure that your statement contradicts the reality. And again, you're not discussing the pros and cons of my proposals but just defending what has been done in the past. Not very innovative!

4 Seaside is a multi-smalltalk framework, originally coming from Squeak. It is likely to show some squeak idioms, more than VW.
Idioms in your sense is the sugar-coatied term for using difficult to understand naming conventions. In this sense you'r right.

5 Seaside has marked all instance-creation methods as such.
No, that is not true, because there are dozens of examples like the one that I brought up where one first has to read the whole code to understand that some method really creates a new instance of something and returns it. Hiding this information in the method name is simply stupid. I cannot see any arguments that speak in favour of hiding such an important fact. In no dialect whatsoever!

6 Open source projects tend to have lots of things to do, and not enough people doing them. "We are looking forward to your change set and unit tests (and documentation and new texts for the website)". They also tend to be driven by pragmatic concerns, not theoretical. How much work is involved, and what is it going to bring me (and others).
I'm simply trying to convince some major contributors to adhere to some generally acknowledged Smalltalk standards. But probably this is already asking too much!

Individuality is good and important but not in engineering!

I've always preferred French cars for their much better design inside and outside but I had often preferred that they were engineered and manufactured by Germans. Combining both would be the perfect combination! And who wants USAmerican cars!?

7 There are a number of applications depending on Seaside. If you want to break the API, please provide upgrade scripts. Your perspective (with the one commercial application in VW) is not like that of others in the community. Avi has the largest commercial Seaside application on Squeak, Lukas has lots of different applications on multiple platforms, I have lots of small project prototypes.

Continuing with old mistakes forever is always more expensive than once making a radical break. In this case the break would not even be radical, because all it needs is to introduce new accessors and new names while leaving the old ones in place for a while.

"Where there is a will there is a way"! But it seems that so far that the Seaside advocates have no interest in and no openness to any changes!

8 The example you give (WATree root:) is one where I'd consider this only a minor problem. Compared to the problem that there are several usable perspectives for using trees, meaning that I always have to take a look at the actual implementation, and that it is a rather smalltalk specific one (wouldn't have one like that in java, c# or Delphi).
This was one example out of many dozens! It's the consistent ignoring of expressive and concise method name is that strikes me. This one example, if it was an exception, would be irrelevant. But the same is the case almost all over the place.

Because of this, Seaside is extremely cumbersome to learn and how to use the library when you cannot rely on the semantics of methods and exactly that is the case in Seaside.

Seaside class, method and instance variable names regularly lie!

And this is especially bad in situations where I as the reader would have to understand that a new instance is created. This is why the old admirable Smalltalk libraries created this convention of starting a factory method with "new" - if you deny it or not. It's good, simple, clear and concise!

9 An international project can only handle issues that are in the issue tracker or on the mailing list (or come to Esug) . I've always found the mailing lists to be very responsive. Why can't I find this issue when I google for it?
You know well that the Smalltalk community is extremely small and most people are very busy with solving their own problems. This previously quoted and widespread arrogance of many Smalltalkers is one primary reason while Smalltalk is not a mainstream product.

The best example are these ignorant idiots of the old Park Place company with whom I had to make my own very negative experiences in the past when first wanting to use Smalltalk. This is a classical example for the old experience that pride comes before a fall.

Today, we all still suffer from their unrealistic greed and their nose-up in the sky!

The same happens here again: The Seaside people are not responsive to well funded requirements from practitioners (me in this case). All they are busy with its defending their own brilliance and some people were not even willing to discuss my subjects unless they knew my name! How ridiculous!

10 I have extensive experience with open source projects, and find Seaside to be the one where major contributors are most open to explain and help others.
A lot of this help would not be needed and the time saved if the authors had followed my advice and especially if they have documented their work in the first place. Why aren't you so honest to admit that?

11 In your posts, you sound like someone with a lot of stress. Why did you decide to start this blog now? Are the problems in Seaside threatening your project? Do you need more implementation time than you expected?
We have lost months due to the implementation mistakes made in Seaside and I'm just fed up with having to live with these compromises. I knew that the authors would not be responsive to my substantial critics and this has proven true by the mostly arrogant and ignorant reactions.

Yours is one of the few exceptions although I still don't see any objective arguments against my proposals from you either.

Therefore, there are three possibilities:
a) My good arguments find response with the developer community, which would certainly the best. (I'm not expecting all, of course)

b) I find a few companions to set up a professional spin-off to improve the software, to make a professionally usable and better understandable Seaside version. Competition would be good for all.

c) Otherwise we just stick to ourselves and continue as we did in the past, modifying this horrible code coming from Seaside and doing our own business as we prefer it.

But a couple of reactions, primarily via direct e-mail to me, have shown me that I'm just expressing what a lot of other primarily professional users have been thinking for a long time. I am absolutely not alone with my frustration about the ignorance and mistakes of the Seaside authors.

And your comments, for which I am thankful, have shown me again that your personal thoughts are in defending what has been done and not in discussing what can be improved and least of all in trying to be really positively critical about my proposals.

That is very unfortunate! Nevertheless, thank you again for your comments.