Most business web sites outside the USA are multilingual, because the world is and always will be multilingual.
Seaside offers no support for multiple languages, which is a natural requirement for any web server, because different users (sessions) require different languages simultaneously.
Unfortunately, the same lack of language support is true for VisualWorks Smalltalk as such, which does not offer any support either for language-free code that receives its user visible text from translation libraries (the latest version I know is 7.4).
This is the old problem with Anglo-Saxons, especially with USAmericans who are trying to impose their own minimal language on other people! Language imperialism at the finest!
Therefore, my advice to new Seaside users is to take into account that it will need substantial efforts to make Seaside truly multi-lingual without having code redundancies.
The problem is simple: These naive (and often stupid in the sense of uneducated) North Americans really expect that one writes language dependent text into the code making it impossible to serve different languages from the same source code. What a stupid US ignorance ignoring and trying to suppress this wonderful diversity of different people, languages and cultures!
And the fact that the main author of Seaside, Avi Bryant, is of Canadian origin makes this ignorant mono-lingual implementation even morally worse, as he is denying the natural human rights of his own French-Canadian fellow countrymen, not to mention the many Spanish people in the US of A who are raped to use English .
Wednesday 20 May 2009
Thursday 14 May 2009
Proposal 12: Rename WATagBrush "class"
A CSS "class" is not real a class in the sense of object-oriented design. It just has "same taste" of a class.
I find this term in Seaside misleading and somewhat confusing for a Smalltalker.
Therefore, it would be much better to call this attribute and its accessors "cssClasses:". This tells exactly what it is:
a) CSS related
b) More than one are possible.
c) The term "class" is used so often in Smalltalk that this alone is another reason to distinguish this special cssClass(es).
Note: It is not good to adopt existing terms even if (or because?) they are widespread, if they are imprecise.
I find this term in Seaside misleading and somewhat confusing for a Smalltalker.
Therefore, it would be much better to call this attribute and its accessors "cssClasses:". This tells exactly what it is:
a) CSS related
b) More than one are possible.
c) The term "class" is used so often in Smalltalk that this alone is another reason to distinguish this special cssClass(es).
Note: It is not good to adopt existing terms even if (or because?) they are widespread, if they are imprecise.
Tuesday 12 May 2009
Avi Bryant's "Seaside English" language
It is indisputable that the education system of the US is one of or even the worst on this entire planet. I have seen this from many lively but dull examples on two feet during my stay in the US.
This is why many if not most US Americans don't even find their own country on a globe not to mention the many countries where their army is fighting for freedom - for the freedom of the US to exploit these foreign countries, their people and natural resources and to pollute them with Monsanto's satanic poison in return.
But until now I though that at least most US programmers knew their radically reduced version of good old English well enough to distinguish between an imperative and the past form.
Obviously, Avi Bryant and the other Seaside authors are incapable of such lingual finesse, because they create method names such as:
WARequestHandler -> unregistered
The same exists in other classes, which all do unregister something, i.e. which should be in the imperative form!
In fact, one of them sends a correct "expire", which clearly indicates the real intention of "unregistered". But again it needs reading the code to understand what is really meant.
There are many similar examples, one of which was already covered in my post "English is a difficult language"
Therefore, Mr. Bryant et al, it would help the Seaside users tremendously if you were trying to remember your school days when you should have been taught the very basics of your really very very simple language called English.
We in Europe have all given up expecting some knowledge of other languages from you, we know that almost all US Americans are too lazy and far too uneducated to learn some simple Spanish not to mention any complex language like French, German or Russian, but we still expect you to master at least this minimal quite deculturised US American version of English!
P.S. It is refreshing to read some distinguished English from USAmericans like the comments of Richard Kulisz on this blog.
This is why many if not most US Americans don't even find their own country on a globe not to mention the many countries where their army is fighting for freedom - for the freedom of the US to exploit these foreign countries, their people and natural resources and to pollute them with Monsanto's satanic poison in return.
But until now I though that at least most US programmers knew their radically reduced version of good old English well enough to distinguish between an imperative and the past form.
Obviously, Avi Bryant and the other Seaside authors are incapable of such lingual finesse, because they create method names such as:
WARequestHandler -> unregistered
The same exists in other classes, which all do unregister something, i.e. which should be in the imperative form!
In fact, one of them sends a correct "expire", which clearly indicates the real intention of "unregistered". But again it needs reading the code to understand what is really meant.
There are many similar examples, one of which was already covered in my post "English is a difficult language"
Therefore, Mr. Bryant et al, it would help the Seaside users tremendously if you were trying to remember your school days when you should have been taught the very basics of your really very very simple language called English.
We in Europe have all given up expecting some knowledge of other languages from you, we know that almost all US Americans are too lazy and far too uneducated to learn some simple Spanish not to mention any complex language like French, German or Russian, but we still expect you to master at least this minimal quite deculturised US American version of English!
P.S. It is refreshing to read some distinguished English from USAmericans like the comments of Richard Kulisz on this blog.
Seaside fools you with amateurish junk code
Never trust what you see in Seaside:
WASession->application
^parent
WASession owns the instance variables 'parent' and 'application' and for some unknown reason the user is fooled by the above code - of course without any explanation as always.
This is so extremely insane and it's only one out of many similar imbecillities in Seaside!
Now this seems like a little problem but in reality it is (and was for me) a very big problem, because this stupid Seaside bug was the reason for many wasted hours searching a bug that I thought to be in our own code.
The background: We had to introduce 'release' methods to ensure proper garbage collection. One of these was also removing the dependency between aWASession and its holder WAApplication. This is where we were so baldy fooled, because "self application" did not answer what it pretended.
You are lost in Seaside if you don't read all of the code that you are calling! Disgusting! This is the first such library that I have ever come about where one is forced to really control and read all of the (completely undocumented) code!
If the law of karma really exists, then these insane stupid Seaside developers will have to suffer badly in their next lives for what they did to their users and how they wasted our time!
These coding sins in Seaside are screaming for a most humbly "I beg your pardon, please forgive us!" to all those who were fooled by this amateurish junk code!
WASession->application
^parent
WASession owns the instance variables 'parent' and 'application' and for some unknown reason the user is fooled by the above code - of course without any explanation as always.
This is so extremely insane and it's only one out of many similar imbecillities in Seaside!
Now this seems like a little problem but in reality it is (and was for me) a very big problem, because this stupid Seaside bug was the reason for many wasted hours searching a bug that I thought to be in our own code.
The background: We had to introduce 'release' methods to ensure proper garbage collection. One of these was also removing the dependency between aWASession and its holder WAApplication. This is where we were so baldy fooled, because "self application" did not answer what it pretended.
You are lost in Seaside if you don't read all of the code that you are calling! Disgusting! This is the first such library that I have ever come about where one is forced to really control and read all of the (completely undocumented) code!
If the law of karma really exists, then these insane stupid Seaside developers will have to suffer badly in their next lives for what they did to their users and how they wasted our time!
These coding sins in Seaside are screaming for a most humbly "I beg your pardon, please forgive us!" to all those who were fooled by this amateurish junk code!
Wednesday 6 May 2009
Seaside - amateurish circle-jerk mentality ?
There were two comments given to my posts, which could explain the problems of Seaside from a completely different perspective and much better than I did:
Richard Kulisz commented my post "Seaside standing outperforms facts":
"It seems Seaside has been infected with the same amateurish circle-jerk mentality that's corrupted Squeak from which it was spawned. It also seems to me that this has little to do with national differences and everything to do with professional vs amateur efforts. In professional circles, standards vary from place to place, but in amateur circles (eg, FLOSS) they seem to be uniformly poor."
Richard also commented my post: "Laws of life in a community":
"The conscious or unconscious selection of Leaders and their defense at all costs is a normal (even if utterly repugnant, vile and disgusting) part of every community. I've been in quite a few and I've observed this behaviour in nearly all of them. The Creators always, ALWAYS get defended.
In the case of programmers, no community of programmers can ever be diverse enough to avoid appointing gods. Wiki wiki (c2) wasn't. It's because programmers are on the whole nothing but mindless robots incapable of genuinely original thought. What's worse, the overwhelming majority LIKE this status quo.
Also, in the case of programmers, the Creator is almost always going to be a member of the community. This creates incestuous inbreeding, up to and including mutated deformed offspring."
----------------------------------------
Well, Richard, thank you very much for these interesting and valuable aspects. I feel that there is a lot of truth in these words, although I cannot judge myself, because Seaside is my first and only "community project" experience. Not a good one, though. Nor did I ever use Squeak beyond a little playing.
It all sounds very logical - taking into account that most people choose being part of a herd, a malfunction that I have never suffered from.
Seeing Seasiders as amateurish sheeples is an interesting aspect, which explains the fierce rejection of my proposals by most, without even discussing the technical facts. And it also explains why my heretic blasphemy of their gods made all my good technical arguments worthless for them.
Thank you for these insights, which, in essence, is much stronger a critique than mine.
Richard Kulisz commented my post "Seaside standing outperforms facts":
"It seems Seaside has been infected with the same amateurish circle-jerk mentality that's corrupted Squeak from which it was spawned. It also seems to me that this has little to do with national differences and everything to do with professional vs amateur efforts. In professional circles, standards vary from place to place, but in amateur circles (eg, FLOSS) they seem to be uniformly poor."
Richard also commented my post: "Laws of life in a community":
"The conscious or unconscious selection of Leaders and their defense at all costs is a normal (even if utterly repugnant, vile and disgusting) part of every community. I've been in quite a few and I've observed this behaviour in nearly all of them. The Creators always, ALWAYS get defended.
In the case of programmers, no community of programmers can ever be diverse enough to avoid appointing gods. Wiki wiki (c2) wasn't. It's because programmers are on the whole nothing but mindless robots incapable of genuinely original thought. What's worse, the overwhelming majority LIKE this status quo.
Also, in the case of programmers, the Creator is almost always going to be a member of the community. This creates incestuous inbreeding, up to and including mutated deformed offspring."
----------------------------------------
Well, Richard, thank you very much for these interesting and valuable aspects. I feel that there is a lot of truth in these words, although I cannot judge myself, because Seaside is my first and only "community project" experience. Not a good one, though. Nor did I ever use Squeak beyond a little playing.
It all sounds very logical - taking into account that most people choose being part of a herd, a malfunction that I have never suffered from.
Seeing Seasiders as amateurish sheeples is an interesting aspect, which explains the fierce rejection of my proposals by most, without even discussing the technical facts. And it also explains why my heretic blasphemy of their gods made all my good technical arguments worthless for them.
Thank you for these insights, which, in essence, is much stronger a critique than mine.
Sunday 3 May 2009
Discussing Smalltalk design principles
I would like to point the readers to an interesting discussion, which can be found in the comments to this post.
There are some interesting arguments discussed for and against different forms of implementing Smalltalk code as well as contradictory perceptions of encapsulation.
There are some interesting arguments discussed for and against different forms of implementing Smalltalk code as well as contradictory perceptions of encapsulation.
Thursday 30 April 2009
Proposal 11: Ajax requests without callbacks
There are many reasons supposedly in most Seaside applications to use Ajax requests without storing callbacks. In our application we have a couple of such cases where it makes no sense to store callbacks and where callbacks cause useless overhead.
This is another reason why the class WARequest of Seaside should be enhanced, as proposed by me earlier, by request type identifiers and testing methods.
In our case, at least one of these situations will have very heavy traffic and we can therefore intercept the logic flow at a very early stage and direct it immediately to appropriate actions without having to go through the many nested loops in Seaside, which make it also very difficult to follow up logic in debugging.
Requests without callbacks save a huge amount of overhead, CPU time and memory and the make debugging easier, too.
I therefore propose:
a) Add request identifier methods to WARequest (see proposal 1)
b) Add support for Ajax requests without callbacks.
This is another reason why the class WARequest of Seaside should be enhanced, as proposed by me earlier, by request type identifiers and testing methods.
In our case, at least one of these situations will have very heavy traffic and we can therefore intercept the logic flow at a very early stage and direct it immediately to appropriate actions without having to go through the many nested loops in Seaside, which make it also very difficult to follow up logic in debugging.
Requests without callbacks save a huge amount of overhead, CPU time and memory and the make debugging easier, too.
I therefore propose:
a) Add request identifier methods to WARequest (see proposal 1)
b) Add support for Ajax requests without callbacks.
Wednesday 29 April 2009
English is a difficult language...
...apparently for some Seaside developers in the USA!
Yesterday I stumbled over the method "initialRequest:", which is implemented in a few classes. Being fairly capable of reading English, I thought that some initial request was processed. When looking at the code I found out that this was completely wrong.
In reality, the receiver is initialized with a request. Which is something very different, of course.
Now, it is indisputable that most US Americans have castrated Shakespeare's originally beautiful language to the absolute minimum and have deformed it to a horribly harsh pronunciation.
However, not seeing the difference between "initial" and "initialize" is what we in Europe would call a Freudian mistake, which leads the Seaside user into a completely wrong direction.
Therefore, I am strongly recommending these language-poor developers to more carefully select their method names and to have better somebody look at the chosen names who is still capable of using Shakespeare's language properly.
Otherwise one must assume "poor language - poor thinking"!
My proposal: Please change this misleading method name to something like "initializeFromRequest:", which really expresses what is done.
Yesterday I stumbled over the method "initialRequest:", which is implemented in a few classes. Being fairly capable of reading English, I thought that some initial request was processed. When looking at the code I found out that this was completely wrong.
In reality, the receiver is initialized with a request. Which is something very different, of course.
Now, it is indisputable that most US Americans have castrated Shakespeare's originally beautiful language to the absolute minimum and have deformed it to a horribly harsh pronunciation.
However, not seeing the difference between "initial" and "initialize" is what we in Europe would call a Freudian mistake, which leads the Seaside user into a completely wrong direction.
Therefore, I am strongly recommending these language-poor developers to more carefully select their method names and to have better somebody look at the chosen names who is still capable of using Shakespeare's language properly.
Otherwise one must assume "poor language - poor thinking"!
My proposal: Please change this misleading method name to something like "initializeFromRequest:", which really expresses what is done.
Proposal 10: Move it all to WARequest
Handling requests is one of the most important atomic tasks of Seaside, because this governs all the rest.
Currently, the knowledge about requests is scattered over different classes. Just two example out of many:
WABrowser -> initialRequest
aRequest fields at: 'class' :.............
(A string used as key and, even worse, one which is impossible to track, because there are so many.)
WAApplication handleRequest:
aRequest fields at: self handlerField..........
This violates encapsulation and it's no object-oriented design. Only the class WARequest should know about its internals, it's data, keys etc. and it should be interrogated by other classes via clear protocols, which hide all internals from these other classes.
I have mentioned this before, but because this bad design was essentially the cause for having to search for a bug yesterday I am bringing this up again.
Currently, the knowledge about requests is scattered over different classes. Just two example out of many:
WABrowser -> initialRequest
aRequest fields at: 'class' :.............
(A string used as key and, even worse, one which is impossible to track, because there are so many.)
WAApplication handleRequest:
aRequest fields at: self handlerField..........
This violates encapsulation and it's no object-oriented design. Only the class WARequest should know about its internals, it's data, keys etc. and it should be interrogated by other classes via clear protocols, which hide all internals from these other classes.
I have mentioned this before, but because this bad design was essentially the cause for having to search for a bug yesterday I am bringing this up again.
Tuesday 28 April 2009
I fucked-up Seaside again
I have made it again: I fucked-up my entire Seaside application! Rien ne vas plus!
This block has much of a diary, because I'm reporting my daily experiences with the Seaside web server library.
One of the main problems, aside from the many others, is that the logic and the control flow is so extremely scattered over different classes and very inconsistent terminology so that it is extremely hard to track down errors.
I had to make a couple of changes related to the special types of requests. As a consequence major features don't work anymore. This alone would not be a problem if it wasn't so very extremely difficult to follow the flow of actions that Seaside performs.
These problems are essentially caused by these characteristics of Seaside:
1) Very scattered responsibilities
Several different classes perform actions directly on instance variables of others, in this case of the WARequest (see also my post "Proposal 1: WARequest"). This makes it very difficult to track down what happens where and why.
Because of this alone Seaside is not really object-oriented, as the law of encapsulation is regularly violated.
2) Inconsistent terminology
Especially class and method names are inconsistent and often misleading. This makes it even more difficult to understand what is going on where.
3) Debugging is extremely difficult
And it's also very time-consuming, because Seaside always accesses the current session via signalling. This can be seen as a nice technical feature but it makes the developer's work very inefficient. More about this soon in a separate post.
I am not yet sure about the following statement, because I'm still (after several weeks) in the phase of learning Seaside, but I have the strong feeling that there are simpler, more concise and probably also more efficient ways of accessing the current session.
If I had known the full scope of these problems when the decision for Seaside was made, we would not have decided to use Seaside! It's a nightmare!
Don't expect censored language from me. I am not US American and I detest self-censoring called "political correctness". In Europe most people still speak out the truth!
----------------------------------------------------------------------------------------
Update: Problem solved!
Here is the solution: What caused yesterday's confusion was written by myself and therefore, of course, my own mistake.
However, this was still an indirect consequence from Seaside's distributed responsibilities regarding the handling of request types. To avoid this, I have added a couple of methods to class WARequest, because this class should be the only one to know about the internals and types of its data. When writing these additional methods I had a misconception about the meanings and priorities of key fields, which are spread all over other classes in the original Seaside code.
Because I consider this situation very important, I am giving a practical example in a separate post.
This block has much of a diary, because I'm reporting my daily experiences with the Seaside web server library.
One of the main problems, aside from the many others, is that the logic and the control flow is so extremely scattered over different classes and very inconsistent terminology so that it is extremely hard to track down errors.
I had to make a couple of changes related to the special types of requests. As a consequence major features don't work anymore. This alone would not be a problem if it wasn't so very extremely difficult to follow the flow of actions that Seaside performs.
These problems are essentially caused by these characteristics of Seaside:
1) Very scattered responsibilities
Several different classes perform actions directly on instance variables of others, in this case of the WARequest (see also my post "Proposal 1: WARequest"). This makes it very difficult to track down what happens where and why.
Because of this alone Seaside is not really object-oriented, as the law of encapsulation is regularly violated.
2) Inconsistent terminology
Especially class and method names are inconsistent and often misleading. This makes it even more difficult to understand what is going on where.
3) Debugging is extremely difficult
And it's also very time-consuming, because Seaside always accesses the current session via signalling. This can be seen as a nice technical feature but it makes the developer's work very inefficient. More about this soon in a separate post.
I am not yet sure about the following statement, because I'm still (after several weeks) in the phase of learning Seaside, but I have the strong feeling that there are simpler, more concise and probably also more efficient ways of accessing the current session.
If I had known the full scope of these problems when the decision for Seaside was made, we would not have decided to use Seaside! It's a nightmare!
Don't expect censored language from me. I am not US American and I detest self-censoring called "political correctness". In Europe most people still speak out the truth!
----------------------------------------------------------------------------------------
Update: Problem solved!
Here is the solution: What caused yesterday's confusion was written by myself and therefore, of course, my own mistake.
However, this was still an indirect consequence from Seaside's distributed responsibilities regarding the handling of request types. To avoid this, I have added a couple of methods to class WARequest, because this class should be the only one to know about the internals and types of its data. When writing these additional methods I had a misconception about the meanings and priorities of key fields, which are spread all over other classes in the original Seaside code.
Because I consider this situation very important, I am giving a practical example in a separate post.
Sunday 26 April 2009
Big is ugly and evil - at least in Smalltalk code
This is an old wisdom that every experienced Smalltalker knows and should be aware of. Unfortunately, there are still experienced Smalltalkers who don't practice this wisdom, mainly because they are not capable of thoroughly abstracting and delegating.
Today I came across such an example of code developed by one of our code contributors with about 6 years of Smalltalk. I had to rework this code completely to make it clean and to delegate responsibilities to those classes where they really belong.
There was a method in an UI controller class that is part of our Seaside application classes, which is supposed to create a new user login instance for certain types of requests. This involves the incoming WARequest, which contains most of the needed data.
The original implementation did all the relevant logical checking in one big method of about 20 lines of code in the UI controller instance. This method was messaging to three different model classes plus the WARequest instance.
I did the following:
1) All request related checking was moved to WARequest, which now answers to one new method "isRequestWithLoginObj". Only the request class should know about its internals and about its type of request. Alternatively, one could also delegate this to the login model, but for various reasons I preferred the first choice.
Unfortunately, all of this had to be added by us to WARequest, because the standard Seaside class does not provide any such services. In the Seaside library the responsibilities and knowledge about request internals is spread over many other classes, which directly interrogate the "fields" instVar of WARequest. Therefore knowledge of many request internals, which should really be hidden inside WARequest, is spread widely.
2) All other logical checking, whether or not a new UserLogin model is to be created, was moved to the login model class together with passing the request instance. Now these two model classes make this up entirely among themselves.
3) Two other model classes, which are related to this procedure, are no longer touched by the UI controller. Instead, only the UserLogin factory code talks directly to its related model classes.
The result:
From 20 down to just 3 lines of code left in the UI controller method, two of which are related to internals of the UI controller.
Most important is the clear delegation of responsibilities to the respective classes and the much greater modularisation of the code through potentially re-usable small methods.
I made the experience that it is much wiser to put work into re-factoring such code, because modular code is much better to maintain, much simpler to modify and therefore also cheaper over the life cycle of a project and typically also less error prone.
I wish the authors of Seaside would regularly undergo similar re-factoring, not because the Seaside methods are too big, but primarily because the responsibilities in the Seaside code are not sufficiently encapsulated in the respective classes.
See also my post: "Proposal 1: Class WARequest!
Today I came across such an example of code developed by one of our code contributors with about 6 years of Smalltalk. I had to rework this code completely to make it clean and to delegate responsibilities to those classes where they really belong.
There was a method in an UI controller class that is part of our Seaside application classes, which is supposed to create a new user login instance for certain types of requests. This involves the incoming WARequest, which contains most of the needed data.
The original implementation did all the relevant logical checking in one big method of about 20 lines of code in the UI controller instance. This method was messaging to three different model classes plus the WARequest instance.
I did the following:
1) All request related checking was moved to WARequest, which now answers to one new method "isRequestWithLoginObj". Only the request class should know about its internals and about its type of request. Alternatively, one could also delegate this to the login model, but for various reasons I preferred the first choice.
Unfortunately, all of this had to be added by us to WARequest, because the standard Seaside class does not provide any such services. In the Seaside library the responsibilities and knowledge about request internals is spread over many other classes, which directly interrogate the "fields" instVar of WARequest. Therefore knowledge of many request internals, which should really be hidden inside WARequest, is spread widely.
2) All other logical checking, whether or not a new UserLogin model is to be created, was moved to the login model class together with passing the request instance. Now these two model classes make this up entirely among themselves.
3) Two other model classes, which are related to this procedure, are no longer touched by the UI controller. Instead, only the UserLogin factory code talks directly to its related model classes.
The result:
From 20 down to just 3 lines of code left in the UI controller method, two of which are related to internals of the UI controller.
Most important is the clear delegation of responsibilities to the respective classes and the much greater modularisation of the code through potentially re-usable small methods.
I made the experience that it is much wiser to put work into re-factoring such code, because modular code is much better to maintain, much simpler to modify and therefore also cheaper over the life cycle of a project and typically also less error prone.
I wish the authors of Seaside would regularly undergo similar re-factoring, not because the Seaside methods are too big, but primarily because the responsibilities in the Seaside code are not sufficiently encapsulated in the respective classes.
See also my post: "Proposal 1: Class WARequest!
Thursday 23 April 2009
Seaside social standing outperforms facts
Valuable comments are not well visible on this blog software.
I therefore make a post from a discussion with a Smalltalk expert so that you can make up your mind what facts and arguments weight for some Seaside advocats:
Randal L. Schwartz wrote:
I will not accept your unverified statements here. I *will* accept comments made in response to your proper bug reports. If you want to make a difference to the Seaside project, please make proper bug reports, and please offer to provide patches for things that you have solutions for. Otherwise, you're tilting at windmills, with all due respect.
My answer is:
"Unverified"?
Randal, your are a Smalltalk expert, very active on the Seaside mailing list. You do know that all of my claims here are valid and reasonable, even if some may be subject to taste and personal style, of course.
That's why there is again not one word from you about my critics, only about "politics".
Beyond the background and history of this blog (see: "History of my critics"), my recent experience with the Seaside advocats on the mailing list after publishing the blog tells it all:
- A community of "experts" that has violated the law of documenting code for more than 7 years cannot be taken seriously (1)
- Almost no discussion of my critics and proposals.
- Those two or three writers who wanted to discuss my critics were made shut-up immediately by the "community".
- Social pressure replaces arguments.
- Best is this post where it says: To be taken seriously *your social standing* in the Seaside mailing list community is most important, in other words:
Facts don't really count for the Seasiders!
This blog tells the public about details, problems and deficiencies of Seaside and about my experiences - openly and most honestly - so that everybody can make up his own mind.
The Seaside advocats have had their chances - they were all refused. All you can do is take my critics seriously, first of all document Seaside properly in the code and remove at least most of the obscurities that I am listing here. And I still have a long list to publish.
I would have had a lot to contribute. First it was refused and now I will not disclose my identity, because I am risking severe commercial pressure..... I have seen that happen...
----------------------
(1) The requirement to thoroughly document code is the very first and most holy law of software development that I am not willing to discuss. This is the most widely acknowledged rule in the software industry.
Who denies this cannot be taken seriously!
---------------------------------------------------------------------------------------
Addition on the 24. April 2009 made as a comment:
Jarober wrote:
What Randal was asking for was actual bug reports, as opposed to comments in a blog or a mailing list. Seaside - like most software products - has a standard way of accepting bug reports. You seem to expect to have your reports taken as gospel without going through the standard procedure.
My answer:
Hello Jarober,
Thank you for explaining what Randal meant but I did understand that perfectly well.
The point is that this is not a matter of procedures but of acknowledging the need and justification for (at least some of) my proposals and critics.
The reaction of almost all of the mailing list writers showed me, just like the earlier history, that there is not a minimum consensus on the need for change and improvement. People seem to be happy with the current state. I am not.
Not even the need for documentation was acknowledged - neither before my blog nor now.
So what would any entries in the bug reports help if there is not the slightest understanding, agreement and approval by the Seaside advocates that his situation is unsustainable?
I had offered my help and contributions. Both were rejected. Only now this public blog disturbs your graveyard peace.
They were happy without documentation for more than 7 years! Renggli rather writes long explanations on the mailing list than add this to the code. See "Not learning from mistakes".
Frankly: It's not me that has to change attitudes. All you (plural) are after is explained in "Social standing outperforms facts".
---------------------------------------------------------------------------------------
Addition on the 25. April 2009:
Jarober wrote:
Not exactly. There's an old adage: "You catch more flies with honey than you do with vinegar".
What you're doing is yelling at people, and people don't like being yelled at. Yes, going off on a rant is enjoyable, but take it from me - it doesn't help, and it hurts a lot.
Back during my days at ParcPlace, any good points I made were completely ignored, due to the vitriol with which they were delivered. I managed to poison a number of relationships at Cincom the same way during my first couple of years here, and it's taken me years - yes years - to dig my way out of that pit.
If your intention is to offer advice that will be listened to, stop calling people names, stop saying that Seaside stinks, and just dispense with the attitude. I'm sure the venting makes you feel better, but believe me, it makes what you are saying end up completely ignored.
It doesn't matter whether you think that's right, or whether you think that's fair - it just is. You can accept that reality and start becoming effectual, or you can keep going as you are, and be completely ignored.
My answer:
Well, Jarober,
thank you for your kind explanations, but obviously we have a substantial cultural difference, because this US American attitude of yours is not mine and never will.
I am grateful to have had lots of different influences in my youth not only from my widespread family: German-Swiss, Prussian (which is a very special sort of German), a smaller part English with a little spice from Wien, another different German mentality.
Maybe the great fault of most people in the USA is that they are completely unwilling to accept other mentalities. Could be that this is one of the many great problems that the world has with the USA (that is not against you personally).
Most in Europe have learned to take the best out of each variant. That's even what we joke about in this famous story about Europe in heaven and Europe in hell.
My home country is the best example: Our mentalities differ from one valley to another and essentially we love that.
Variety id good. "Melting pot" is bad. It leads to the smallest common denominator.
I assume that this US mentality described by you has led to today's situation in the US industry, namely the car industry. This is at least what people at Opel and Ford in Germany report (I know insiders well). Immune to advice! Nothing more to say!
I don't rely any more on the Seaside mailing list, they have had their chances several times. Now those with open mind can join in to my future activities.
I therefore make a post from a discussion with a Smalltalk expert so that you can make up your mind what facts and arguments weight for some Seaside advocats:
Randal L. Schwartz wrote:
I will not accept your unverified statements here. I *will* accept comments made in response to your proper bug reports. If you want to make a difference to the Seaside project, please make proper bug reports, and please offer to provide patches for things that you have solutions for. Otherwise, you're tilting at windmills, with all due respect.
My answer is:
"Unverified"?
Randal, your are a Smalltalk expert, very active on the Seaside mailing list. You do know that all of my claims here are valid and reasonable, even if some may be subject to taste and personal style, of course.
That's why there is again not one word from you about my critics, only about "politics".
Beyond the background and history of this blog (see: "History of my critics"), my recent experience with the Seaside advocats on the mailing list after publishing the blog tells it all:
- A community of "experts" that has violated the law of documenting code for more than 7 years cannot be taken seriously (1)
- Almost no discussion of my critics and proposals.
- Those two or three writers who wanted to discuss my critics were made shut-up immediately by the "community".
- Social pressure replaces arguments.
- Best is this post where it says: To be taken seriously *your social standing* in the Seaside mailing list community is most important, in other words:
Facts don't really count for the Seasiders!
This blog tells the public about details, problems and deficiencies of Seaside and about my experiences - openly and most honestly - so that everybody can make up his own mind.
The Seaside advocats have had their chances - they were all refused. All you can do is take my critics seriously, first of all document Seaside properly in the code and remove at least most of the obscurities that I am listing here. And I still have a long list to publish.
I would have had a lot to contribute. First it was refused and now I will not disclose my identity, because I am risking severe commercial pressure..... I have seen that happen...
----------------------
(1) The requirement to thoroughly document code is the very first and most holy law of software development that I am not willing to discuss. This is the most widely acknowledged rule in the software industry.
Who denies this cannot be taken seriously!
---------------------------------------------------------------------------------------
Addition on the 24. April 2009 made as a comment:
Jarober wrote:
What Randal was asking for was actual bug reports, as opposed to comments in a blog or a mailing list. Seaside - like most software products - has a standard way of accepting bug reports. You seem to expect to have your reports taken as gospel without going through the standard procedure.
My answer:
Hello Jarober,
Thank you for explaining what Randal meant but I did understand that perfectly well.
The point is that this is not a matter of procedures but of acknowledging the need and justification for (at least some of) my proposals and critics.
The reaction of almost all of the mailing list writers showed me, just like the earlier history, that there is not a minimum consensus on the need for change and improvement. People seem to be happy with the current state. I am not.
Not even the need for documentation was acknowledged - neither before my blog nor now.
So what would any entries in the bug reports help if there is not the slightest understanding, agreement and approval by the Seaside advocates that his situation is unsustainable?
I had offered my help and contributions. Both were rejected. Only now this public blog disturbs your graveyard peace.
They were happy without documentation for more than 7 years! Renggli rather writes long explanations on the mailing list than add this to the code. See "Not learning from mistakes".
Frankly: It's not me that has to change attitudes. All you (plural) are after is explained in "Social standing outperforms facts".
---------------------------------------------------------------------------------------
Addition on the 25. April 2009:
Jarober wrote:
Not exactly. There's an old adage: "You catch more flies with honey than you do with vinegar".
What you're doing is yelling at people, and people don't like being yelled at. Yes, going off on a rant is enjoyable, but take it from me - it doesn't help, and it hurts a lot.
Back during my days at ParcPlace, any good points I made were completely ignored, due to the vitriol with which they were delivered. I managed to poison a number of relationships at Cincom the same way during my first couple of years here, and it's taken me years - yes years - to dig my way out of that pit.
If your intention is to offer advice that will be listened to, stop calling people names, stop saying that Seaside stinks, and just dispense with the attitude. I'm sure the venting makes you feel better, but believe me, it makes what you are saying end up completely ignored.
It doesn't matter whether you think that's right, or whether you think that's fair - it just is. You can accept that reality and start becoming effectual, or you can keep going as you are, and be completely ignored.
My answer:
Well, Jarober,
thank you for your kind explanations, but obviously we have a substantial cultural difference, because this US American attitude of yours is not mine and never will.
I am grateful to have had lots of different influences in my youth not only from my widespread family: German-Swiss, Prussian (which is a very special sort of German), a smaller part English with a little spice from Wien, another different German mentality.
Maybe the great fault of most people in the USA is that they are completely unwilling to accept other mentalities. Could be that this is one of the many great problems that the world has with the USA (that is not against you personally).
Most in Europe have learned to take the best out of each variant. That's even what we joke about in this famous story about Europe in heaven and Europe in hell.
My home country is the best example: Our mentalities differ from one valley to another and essentially we love that.
Variety id good. "Melting pot" is bad. It leads to the smallest common denominator.
I assume that this US mentality described by you has led to today's situation in the US industry, namely the car industry. This is at least what people at Opel and Ford in Germany report (I know insiders well). Immune to advice! Nothing more to say!
I don't rely any more on the Seaside mailing list, they have had their chances several times. Now those with open mind can join in to my future activities.
PrintString Mysterious Scriptaculous Seaside
Well, you have to be an insider to guess what that means or you read this post about some mysterious internals of Seaside.
Scriptaculous is a widespread JavaScript library, for which there is a Smalltalk interface to Seaside and which is used frequently by Smalltalkers using Seaside (as for as I know). This post is only about the interface between Seaside and Scriptaculous and this has nothing to do with Scriptaculous itself.
Today I was debugging some JavaScript code and I therefore had to frequently look into the inspector. For most classes we have modified the display messages for the inspector so that all vital information (instVars) is presented right in the inspector without having to dig into details.
I did the same to three Scriptaculous interface classes by changing the "printString" to my needs. I then continued with testing and suddenly: Rien ne vas plus! Everything was broken, nothing worked anymore.
I looked at it and found out that the authors of this Seaside to Scriptaculous interface used the "printString" for writing JavaScript, for directly converting the values of instances to JavaScript!
What a nuisance!
There is just no sense in this! Why not implement a special "asString", "asStringJS" or some "valueForJavaScript" or a "asJavaScript" or whatever. Buch why the fuck use this common printString, which is used by inspectors, debuggers and so forth and which is modified by many programmers to their taste!?
This is a self-destructive Seaside programming style. The worst I have ever seen in Smalltalk!
Scriptaculous is a widespread JavaScript library, for which there is a Smalltalk interface to Seaside and which is used frequently by Smalltalkers using Seaside (as for as I know). This post is only about the interface between Seaside and Scriptaculous and this has nothing to do with Scriptaculous itself.
Today I was debugging some JavaScript code and I therefore had to frequently look into the inspector. For most classes we have modified the display messages for the inspector so that all vital information (instVars) is presented right in the inspector without having to dig into details.
I did the same to three Scriptaculous interface classes by changing the "printString" to my needs. I then continued with testing and suddenly: Rien ne vas plus! Everything was broken, nothing worked anymore.
I looked at it and found out that the authors of this Seaside to Scriptaculous interface used the "printString" for writing JavaScript, for directly converting the values of instances to JavaScript!
What a nuisance!
There is just no sense in this! Why not implement a special "asString", "asStringJS" or some "valueForJavaScript" or a "asJavaScript" or whatever. Buch why the fuck use this common printString, which is used by inspectors, debuggers and so forth and which is modified by many programmers to their taste!?
This is a self-destructive Seaside programming style. The worst I have ever seen in Smalltalk!
Wednesday 22 April 2009
Smalltalk without inheritance
Ever heard of that? Well, it's neither the 1. April, nor am I drunk.
Parts of Seaside is Smalltalk without inheritance! That's what I just found out.
It's only a small part but still: The file library tree is searched by a very special, cryptic and really "hacked" code for method names and this code intentionally ignores inheritance.
If you want to inherit code from some super class in the Seaside file library you must implement the same accessors in every sub-class or they will be ignored.
In case you don't trust me and want to look it up yourself (2.8), have a look at these two methods:
WALibrary -> documentAt:ifAbsent:
WALibrary -> fileSelectors
The mistake is in looping through all selectors of aClass instead of just sending this famous message "perform: selector".
Also, I am quite sure that this current implementation is much slower than "perform:", which is extremely fast.
I can't see any reason for such an implementation and in my >10 years Smalltalk I have never come about such an imbecillity. Again: Seaside has no documentation in the code! If there was any sense in this fancy implementation, a warning would be the minimum one could expect. But there is nothing!
You must read and understand the very cryptic Seaside code yourself to find out what's going on - and that will cost you weeks!
Don't get me wrong: Smalltalk is the most productive and brilliant programming language but even here applies: "Give a foul a tool"!
Parts of Seaside is Smalltalk without inheritance! That's what I just found out.
It's only a small part but still: The file library tree is searched by a very special, cryptic and really "hacked" code for method names and this code intentionally ignores inheritance.
If you want to inherit code from some super class in the Seaside file library you must implement the same accessors in every sub-class or they will be ignored.
In case you don't trust me and want to look it up yourself (2.8), have a look at these two methods:
WALibrary -> documentAt:ifAbsent:
WALibrary -> fileSelectors
The mistake is in looping through all selectors of aClass instead of just sending this famous message "perform: selector".
Also, I am quite sure that this current implementation is much slower than "perform:", which is extremely fast.
I can't see any reason for such an implementation and in my >10 years Smalltalk I have never come about such an imbecillity. Again: Seaside has no documentation in the code! If there was any sense in this fancy implementation, a warning would be the minimum one could expect. But there is nothing!
You must read and understand the very cryptic Seaside code yourself to find out what's going on - and that will cost you weeks!
Don't get me wrong: Smalltalk is the most productive and brilliant programming language but even here applies: "Give a foul a tool"!
Tuesday 21 April 2009
Not learning from mistakes
Yesterday I was searching how to send files from disk in Seaside. So I consulted the Seaside mailing list, which serves as some poor documentation replacement, and I found this interesting post (bolds added by me):
On Jan 10, 2006, at 12:13 AM, goran@xxxxxxxxx wrote:
The question is: How do people serve files with Seaside? Especially static files like images? And no, you don't need to reply if you use Apache or HV2 on the side :)
I use Apache on the side :) But anyway...
I started digging of course and found WADocumentHandler - but
uncommented, as well as all the handler classes in fact, ehrm,. IMHO this is a lacking in Seaside - just a *teeeeny* bit too few class comments. :) ...and why does WADocumentHandler>>response send #text to the content stream btw?
Good question. I assume there's some good reason, but
I honestly don't remember what.
....
....
Avi (Bryant)
------------------------------------------------------------------------------------------
The facts:
1) In January 2006 Avi Bryant was politely criticized for not adding any comments
2) Avi Bryant did not remember why he had implemented something the way it was
3) He did not change his attitude since then. No in-code comments were added since then.
My comments:
1) Very friendly said. After three years I have all reasons to be no longer so polite.
2) Happens to everybody. That is why in-code documentation is so important.
3) Making mistakes is normal. Making the same mistakes continuously is stupid. Not learning from mistakes is unforgivable.
This post proves me right! And there are several similar ones.
Therefore, new Seasiders: Be very careful to join in as long as the authors make the same stupid mistakes over and over again!
See my other post about using WAExternalFileLibrary.
On Jan 10, 2006, at 12:13 AM, goran@xxxxxxxxx wrote:
The question is: How do people serve files with Seaside? Especially static files like images? And no, you don't need to reply if you use Apache or HV2 on the side :)
I use Apache on the side :) But anyway...
I started digging of course and found WADocumentHandler - but
uncommented, as well as all the handler classes in fact, ehrm,
Good question. I assume there's some good reason, but
I honestly don't remember what.
....
....
Avi (Bryant)
------------------------------------------------------------------------------------------
The facts:
1) In January 2006 Avi Bryant was politely criticized for not adding any comments
2) Avi Bryant did not remember why he had implemented something the way it was
3) He did not change his attitude since then. No in-code comments were added since then.
My comments:
1) Very friendly said. After three years I have all reasons to be no longer so polite.
2) Happens to everybody. That is why in-code documentation is so important.
3) Making mistakes is normal. Making the same mistakes continuously is stupid. Not learning from mistakes is unforgivable.
This post proves me right! And there are several similar ones.
Therefore, new Seasiders: Be very careful to join in as long as the authors make the same stupid mistakes over and over again!
See my other post about using WAExternalFileLibrary.
Malfunctioning file handling in Seaside
Today I wanted to teach my Seaside application to supply files from hard disk and to use what I had read yesterday on the mailing list. It took me the whole day and it's still not working.
The normal assumption in Seaside is that JavaScript, CSS and image files are supplied by code. This is why one needs a programmer just to change the name of a file.
Therefore, this assumption of Seaside is quite unrealistic.
The class WAExternalFileLibrary looks promising. It provides just one protocol different to its super class WAFileLibrary.
Again not one word of documentation!
Aha I thought, finally a good implementation! I was badly disappointed within minutes.
I had to read and understand the whole code in order to assume what I would have to do to make it work. I did that but it still does not work.
Now, I have to admit, I am not a genius, I'm just an average experienced Smalltalker with >10 years of Smalltalk practice. That's probably too little to master Seaside.
Georg Heeg calls it a bug
I then used the search engine to try to find out what's going on and one of the first hits was a comment on the website of Georg Heeg in Dortmund. To those who don't know the name, Heeg is worldwide among the handful of most experienced Smalltalk companies with the very best technical reputation. They have been the representative of Park Place for the German language countries ever since I got to know Smalltalk and that was in the mid 1980-ies. So they should really know!
In a very friendly and polite way it says there that the file handling of Seaside is buggy and was constructed under misleading conceptual assumptions.
In my plain words: It's a crap!
But read yourself!
In the meantime I have succeeded to supply at a least file name to the response object but for some reason the supplied code does not read the file. I have to go very deep inside the low-level code to find out why and to fix this bug.
This lousy implementation of Seaside is costing us weeks and months! Be prepared for many adventures when you choose Seaside. It's a pity because many concepts are really good.
Addition at 23:00: It finally works! But only after digging deep into the internals and then refactoring much of this crap code.
The normal assumption in Seaside is that JavaScript, CSS and image files are supplied by code. This is why one needs a programmer just to change the name of a file.
Therefore, this assumption of Seaside is quite unrealistic.
The class WAExternalFileLibrary looks promising. It provides just one protocol different to its super class WAFileLibrary.
Again not one word of documentation!
Aha I thought, finally a good implementation! I was badly disappointed within minutes.
I had to read and understand the whole code in order to assume what I would have to do to make it work. I did that but it still does not work.
Now, I have to admit, I am not a genius, I'm just an average experienced Smalltalker with >10 years of Smalltalk practice. That's probably too little to master Seaside.
Georg Heeg calls it a bug
I then used the search engine to try to find out what's going on and one of the first hits was a comment on the website of Georg Heeg in Dortmund. To those who don't know the name, Heeg is worldwide among the handful of most experienced Smalltalk companies with the very best technical reputation. They have been the representative of Park Place for the German language countries ever since I got to know Smalltalk and that was in the mid 1980-ies. So they should really know!
In a very friendly and polite way it says there that the file handling of Seaside is buggy and was constructed under misleading conceptual assumptions.
In my plain words: It's a crap!
But read yourself!
In the meantime I have succeeded to supply at a least file name to the response object but for some reason the supplied code does not read the file. I have to go very deep inside the low-level code to find out why and to fix this bug.
This lousy implementation of Seaside is costing us weeks and months! Be prepared for many adventures when you choose Seaside. It's a pity because many concepts are really good.
Addition at 23:00: It finally works! But only after digging deep into the internals and then refactoring much of this crap code.
Monday 20 April 2009
Proposal 9: Improving Seaside class trees
There are different types of requests handled in Seaside and at least two types are handled by classes in completely separate class trees. This is true (at least) for WARequest and for HTTPGet, which essentially do the same (respond to user requests) but are completely separate and share no code at all.
Of course, I understand that this has probably historical reasons as one is from Seaside and the other one probably from Swazoo and that these are separate projects.
Nevertheless this is no good design and it should be changed over time.
We had to enhance various classes with the same code (how uly) in order to fulfill some of our needs. No chance to inherit. Several changes were (and probably still will be) related to these two essential classes.
We had to duplicate various code to achieve this. And redundant code is something we seriously hate!
Unfortunately, this is another prove that Seaside has a very low degree of "object-orientability".
Also, it would be most useful if the protocols between these two different but very closely interconnected class trees were aligned (but please use some better semantics than currently in Seaside).
Of course, I understand that this has probably historical reasons as one is from Seaside and the other one probably from Swazoo and that these are separate projects.
Nevertheless this is no good design and it should be changed over time.
We had to enhance various classes with the same code (how uly) in order to fulfill some of our needs. No chance to inherit. Several changes were (and probably still will be) related to these two essential classes.
We had to duplicate various code to achieve this. And redundant code is something we seriously hate!
Unfortunately, this is another prove that Seaside has a very low degree of "object-orientability".
Also, it would be most useful if the protocols between these two different but very closely interconnected class trees were aligned (but please use some better semantics than currently in Seaside).
History of my critics
My critics are very straightforward and some of my words are quite rude. I know that and this is not my normal style.
But there are situations when wrong politeness doesn't bring you any further. This is here the case.
I am not disclosing all of the details of the history behind this blog but I first tried it the conventional way and I even contacted Lukas Renggli on the phone. The reactions by the mailing list and by Herr Renggli were quite similar and showed that there was no interest in improving documentation and coding style.
My proposals to contribute documentation and code were simply rejected!
Through this and over time I had to get to the conclusion that there must be well hidden commercial interests behind this attitude. I don't mind people making money but I think that one should not pretend being the Samaritian but in reality act just to the opposite. This was the case. Maybe I'm wrong with my assumptions but this is my impression that I gained from my previous attempts to improve Seaside.
There is no excuse for missing documentation - after about 7 years in the project!
Therefore, please see this blog - which is certainly using some unfriendly phrases - as the attempt to put public pressure on these extremely self assured advocates and developers who have been totally immune to advise.
My only goal is to have Seaside improved, because we have invested far too much in Seaside and have lost a lot of time and money because of the criticised deficiencies.
Remember: My own offers to contribute were completely rejected!
But there are situations when wrong politeness doesn't bring you any further. This is here the case.
I am not disclosing all of the details of the history behind this blog but I first tried it the conventional way and I even contacted Lukas Renggli on the phone. The reactions by the mailing list and by Herr Renggli were quite similar and showed that there was no interest in improving documentation and coding style.
My proposals to contribute documentation and code were simply rejected!
Through this and over time I had to get to the conclusion that there must be well hidden commercial interests behind this attitude. I don't mind people making money but I think that one should not pretend being the Samaritian but in reality act just to the opposite. This was the case. Maybe I'm wrong with my assumptions but this is my impression that I gained from my previous attempts to improve Seaside.
There is no excuse for missing documentation - after about 7 years in the project!
Therefore, please see this blog - which is certainly using some unfriendly phrases - as the attempt to put public pressure on these extremely self assured advocates and developers who have been totally immune to advise.
My only goal is to have Seaside improved, because we have invested far too much in Seaside and have lost a lot of time and money because of the criticised deficiencies.
Remember: My own offers to contribute were completely rejected!
Proposal 8: Use symbolic file names
Not only is the current file handling implementation of Seaside very inefficient (see proposal 7), but it also requires sending long path names to the browser and back.
This makes little sense, it is wasting bandwidth and CPU performance in an environment, which needs the fastest responses possible.
In the current implementation Seaside is not fast.
This implementation also makes the software relatively inflexible, because practice shows that people tend to include these absolute path names in strings, that constitute CSS or JavaScript. (This is not the fault of Seaside, of course, but a normal human reaction resulting from Seaside's design.)
This problem could be very easily solved as a side-effect of my proposal 7, if one only sends the real or symbolic file names without any paths to the browser.
When a file request comes in, these symbolic file names (of CSS, JavaScript, images etc) are used for a look-up in the dictionary mentioned in proposal 8. The library path and the related method name come from this dictionary. All it needs is one:
classFromDict perform: methFromDict and it's all done.
- Much faster than today
- Much simpler to implement and change
- Shorter file strings sent out (not a must, but de-facto)
- Symbolic file names can be switched depending on user or system settings
- Simpler to debug
- and a few more.
Of course:
- The new static must be reset before starting an app
- It must provide lazy init (see my post: "To lazy for lazy initialization")
This makes little sense, it is wasting bandwidth and CPU performance in an environment, which needs the fastest responses possible.
In the current implementation Seaside is not fast.
This implementation also makes the software relatively inflexible, because practice shows that people tend to include these absolute path names in strings, that constitute CSS or JavaScript. (This is not the fault of Seaside, of course, but a normal human reaction resulting from Seaside's design.)
This problem could be very easily solved as a side-effect of my proposal 7, if one only sends the real or symbolic file names without any paths to the browser.
When a file request comes in, these symbolic file names (of CSS, JavaScript, images etc) are used for a look-up in the dictionary mentioned in proposal 8. The library path and the related method name come from this dictionary. All it needs is one:
classFromDict perform: methFromDict and it's all done.
- Much faster than today
- Much simpler to implement and change
- Shorter file strings sent out (not a must, but de-facto)
- Symbolic file names can be switched depending on user or system settings
- Simpler to debug
- and a few more.
Of course:
- The new static must be reset before starting an app
- It must provide lazy init (see my post: "To lazy for lazy initialization")
Proposal 7: On inefficient Seaside file handling
During my work today I detected how inefficiently Seaside handles file requests.
I was deeply shocked to see this highly complicated implementation, which over and over again makes the Smalltalk VM busy with inefficient operations, which could easily be handled in a much simpler fashion.
It does not need to be discussed that a web server must be extremely efficient and fast. This is not the case for Seaside!
As I was corrected by a comment, Seaside is not a web server in the precise technical sense. That is correct. Nevertheless, one generally speaks also of PHP as a web server although typically the actual server work is done by a front-end Apache. Therefore, I still stick to this term "web server" for Seaside even if it is not absolutely precise.
When a file requests comes in, the class WAFileHandler loops recursively through all the subclasses of all of those library classes, which were registered as "root classes" and executes aBlock on each of them.
This is not only highly inefficient and wasting a lot of CPU performance but it is also very difficult to debug (like Seaside in general) and to step through. Probably another intention to keep Seaside as a cryptic black box!
My concrete proposal, which is by no means perfect but involves minimum changes to the current situation: Introduce a static in class WAFileHandler, which answers a correlation (library name and method name) for every incoming file request.
A dictionary look up is extremely fast in Smalltalk (at least in VisualWorks) and certainly multiple times faster than the current implementation. At the same time one could also solve the problem that I am discussing in my next proposal.
That has another good side-effect: It would be much easier than today to switch between different libraries - even at run-time when a user wants to select his user-specific skin.
I was deeply shocked to see this highly complicated implementation, which over and over again makes the Smalltalk VM busy with inefficient operations, which could easily be handled in a much simpler fashion.
It does not need to be discussed that a web server must be extremely efficient and fast. This is not the case for Seaside!
As I was corrected by a comment, Seaside is not a web server in the precise technical sense. That is correct. Nevertheless, one generally speaks also of PHP as a web server although typically the actual server work is done by a front-end Apache. Therefore, I still stick to this term "web server" for Seaside even if it is not absolutely precise.
When a file requests comes in, the class WAFileHandler loops recursively through all the subclasses of all of those library classes, which were registered as "root classes" and executes aBlock on each of them.
This is not only highly inefficient and wasting a lot of CPU performance but it is also very difficult to debug (like Seaside in general) and to step through. Probably another intention to keep Seaside as a cryptic black box!
My concrete proposal, which is by no means perfect but involves minimum changes to the current situation: Introduce a static in class WAFileHandler, which answers a correlation (library name and method name) for every incoming file request.
A dictionary look up is extremely fast in Smalltalk (at least in VisualWorks) and certainly multiple times faster than the current implementation. At the same time one could also solve the problem that I am discussing in my next proposal.
That has another good side-effect: It would be much easier than today to switch between different libraries - even at run-time when a user wants to select his user-specific skin.
Proposal 6: Seaside stop lying to us!
Seaside seems designed and coded intentionally in a very cryptic style presumably with a goal to make it difficult for new users to understand it and to become productive without consultancy of specialists!
Here is another argument:
There are plenty of methods with extremely misleading names and this is, apart from the totally missing documentation, a main reason why it will be very difficult, labourious and time-consuming for new users to really understand and properly use Seaside!
Here is a perfect example:
In the class WARenderContinuation there is the method "newHtmlRoot:". From general Smalltalk conventions one would expect that this answers some new instance with data of the HTML root.
That is not false but not correct either, because unfortunately this method does a lot more: It starts a main generation loop through all child classes and sends them the very important message "updateRoot:"
When reading the message "newHtmlRoot" one would never expect that this factory method also immediately performs such important and vital actions, which are hidden behind a false name. In most libraries it is common practice to keep factory methods clean from such important actions.
I consider this extremely bad style and it makes me very angry that they are stealing my time with such highly individual and extremely uncommon bundling of functionalities behind false and lying method names! If at least they had given it some correct name like "newHtmlRootAndCollectFiles:" then I would just argue about this fancy but at least honest method name.
By the way: the method name "updateRoot:" is also a bad choice in my view. What it really does is collect references to script and css files etc, which are added to the new WAHtmlRoot instance that is created in newHtmlRoot:.
The semantics of "update" imply that some content is changed with some newer content (more "up-to-date"). This is not the case here. What happens is that some data is collected and added for the first time to that new instance. That is clearly not an update!
In my view, something like "collectFilesForRoot" or "initializeRootWithFiles" would be much clearer and much simpler to understand.
I would not discuss this if there were not many dozens of other wrong names. Nobody always and immediately finds the right words. That is why I regularly change ("update") method names when I see that they were not well selected or because their purpose and actions have changed over time.
I don't know why the authors of Seaside have made such a bullshit (remember: I promised open words and no false politeness)! I can only think of three reasons:
1) Either their goal was to sell their consultancy by making it hard for new users to become productive without external consultancy!
2) Maybe these people are verbally so limited in their capabilities of expressing their thoughts that they simply couldn't do any better. This would not be unusual for highly mathematical people and it is by no means any disqualification. I have never met anybody who is equally good in mathematical and in verbal logic. I myself have often my great problems with maths, for example, but never with open words.
3) Or these people are so self-assured and regards themselves so ingenious that they just give a shit on what other people think and don't understand.
I don't know but I would bet on a combination of the first and the third reason.
In any case, I think that these many substantial problems must be resolved quickly to make Seaside easily usable. Currently, this is unfortunately not the case.
For a quick start it would help a lot if all classes and methods had clear and concise documentation inside the code.
Unfortunately, there is almost nothing!
Here is another argument:
There are plenty of methods with extremely misleading names and this is, apart from the totally missing documentation, a main reason why it will be very difficult, labourious and time-consuming for new users to really understand and properly use Seaside!
Here is a perfect example:
In the class WARenderContinuation there is the method "newHtmlRoot:". From general Smalltalk conventions one would expect that this answers some new instance with data of the HTML root.
That is not false but not correct either, because unfortunately this method does a lot more: It starts a main generation loop through all child classes and sends them the very important message "updateRoot:"
When reading the message "newHtmlRoot" one would never expect that this factory method also immediately performs such important and vital actions, which are hidden behind a false name. In most libraries it is common practice to keep factory methods clean from such important actions.
I consider this extremely bad style and it makes me very angry that they are stealing my time with such highly individual and extremely uncommon bundling of functionalities behind false and lying method names! If at least they had given it some correct name like "newHtmlRootAndCollectFiles:" then I would just argue about this fancy but at least honest method name.
By the way: the method name "updateRoot:" is also a bad choice in my view. What it really does is collect references to script and css files etc, which are added to the new WAHtmlRoot instance that is created in newHtmlRoot:.
The semantics of "update" imply that some content is changed with some newer content (more "up-to-date"). This is not the case here. What happens is that some data is collected and added for the first time to that new instance. That is clearly not an update!
In my view, something like "collectFilesForRoot" or "initializeRootWithFiles" would be much clearer and much simpler to understand.
I would not discuss this if there were not many dozens of other wrong names. Nobody always and immediately finds the right words. That is why I regularly change ("update") method names when I see that they were not well selected or because their purpose and actions have changed over time.
I don't know why the authors of Seaside have made such a bullshit (remember: I promised open words and no false politeness)! I can only think of three reasons:
1) Either their goal was to sell their consultancy by making it hard for new users to become productive without external consultancy!
2) Maybe these people are verbally so limited in their capabilities of expressing their thoughts that they simply couldn't do any better. This would not be unusual for highly mathematical people and it is by no means any disqualification. I have never met anybody who is equally good in mathematical and in verbal logic. I myself have often my great problems with maths, for example, but never with open words.
3) Or these people are so self-assured and regards themselves so ingenious that they just give a shit on what other people think and don't understand.
I don't know but I would bet on a combination of the first and the third reason.
In any case, I think that these many substantial problems must be resolved quickly to make Seaside easily usable. Currently, this is unfortunately not the case.
For a quick start it would help a lot if all classes and methods had clear and concise documentation inside the code.
Unfortunately, there is almost nothing!
Saturday 18 April 2009
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.
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.
Constructive comments
Remember: My only goal is to bring Seaside further and that works only by breaking up these crusted structures that have not succeeded in at least documenting their code in some seven years or so!
Therefore, I am taking the freedom to publish interesting and constructive postings from the Seaside mailing list on my blog.
Here is the first one to which I would agree in most aspects (bold added by me, otherwise no changes or omissions):
--------------------------------------------------------------------------
Hi "Smalltalkers"!
I can well remember Stephane Ducasse's closing words on last ESUG, when he said, that time is come for all Smalltalk users and companies to throw all there knowledge and efforts together to achieve the same aim, making Smalltalk more public and modern again.
A lot of smalltalk using companies suffer the same problems. On the costumer side it's hard to sell such an "old" programming language with outdated UI, large lack of advertisement and sometimes outdated non fancy UI implementation support. And on the other side the very hard task to find and get young already skilled Smalltalk developers.
I have the impression that some guys need to be brought back down on earth.
Seaside is a Open Source project which is squeak based. If I would blame the Seaside development team for working inacurate, regarding coding conventions, I could blame a lot of Squeak-Based projects on that. Some things like instance variable accessing is typically done without accessor- and getter-methods within Squeak.
I don't like that too, but to be honest, I don't have the time to offer a overworked version to the coreteam. I guess I'm not the only one here...
It's definetly true that Seaside is one of the most interesting projects in the Smalltalk market right now, giving companies the chance to offer something new and up-to-date.
But I also think it's merely impossible to develop a smalltalk project in squeak with the abillity to fullfill all advantages of the ported target systems, like VW, VASmalltalk, Gemstone and Dolphin...
It's the business of Cincom, Instantiations, Gemstone, ObjectArts and projects using Seaside for many years now, to support and influence and support actual Seaside development in squeak to assure the usability and optimization of Seaside Core.
You can't offer the world a kind of combination of domestic animal that produces eggs, wool, milk and can be grilled, or as we say in Germany "eine Eierlegendewollmilchsau" and additional to that: "for free".
Seaside is not a completed proprietary product, but everybody expects a robust in changes and optimal basis for writing a new next gerneration 15 years lasting Webapplication framework for the own product family.
Seaside is a sparetime project and it's a democratic project. Everybody can join the Coreteam and can expend time to push it forward.
Well, I'm happy for everyone beeing able to get some money out of Seaside. And I' m sure the whole Smalltalk community would be glad about more Seasiders and Seaside-Profiteers helping Smalltalk to become more interessing to newcomers again and support others to get a hand on Seaside.
Blogs like onsmalltalk.com for example, are worther than comments in alternating alpha release classes.
Thank's to everyone presenting, writing tutorials, books, blogs and thanks to the coreteam for the help and advice you gave to me past month!
Thanks Cucumber for speaking out load what you think. There are several point's I often have in mind reading over "Squeak-Code", but some points might be hard to be solved just because nobody knows, where the Seaside is heading to.
The actual effords in seperating plattformdependent coding from seasidecoding is an improvement I really appreciate. It clearly shows that these guys are willing to give a larger community an access to Seaside. I could imagine that this is a lot harder than just staying in Squeak.
Profit in mind or not, I don't care. They deserve it.
--------------------------------------------------------------------------
My comments:
That sounds very much different from the many flames from the men in the barrel against me in their sun. See the "friendly" and constructive comments to my post about "Laws of life in a community", which I have published all, of course. In German one says: "The beaten dogs are the loudest in howling".
To Squeak:
I know too little about Squeak to make a judgement about its technical internals but I think that most of my proposals platform independent. Using symbols, using getter methods, using honest and concise namings, and especially documenting the code is definitely completely independent of any platform!
It's just a matter of good style and proper engineering!
I started this initiative with the goal to bring Seaside (and in a certain respect also Smalltalk) a good step forward and I was offering my help from the very beginning (which was rudely rejected). Also, most of the comments on the mailing list prove that the primary Seaside advocates feel very much disturbed by my initiative. That is good, because it's a prerequisite for breaking up these very crusted structures who badly failed to even document their code.
I again unconditionally invite all Smalltalkers of "good intention" to join in and to collaborate with me to bring our common tool major steps ahead. Maybe, this will be in competition to the "official Seaside" for a while, but competition is always good for business.
Therefore, I am taking the freedom to publish interesting and constructive postings from the Seaside mailing list on my blog.
Here is the first one to which I would agree in most aspects (bold added by me, otherwise no changes or omissions):
--------------------------------------------------------------------------
Hi "Smalltalkers"!
I can well remember Stephane Ducasse's closing words on last ESUG, when he said, that time is come for all Smalltalk users and companies to throw all there knowledge and efforts together to achieve the same aim, making Smalltalk more public and modern again.
A lot of smalltalk using companies suffer the same problems. On the costumer side it's hard to sell such an "old" programming language with outdated UI, large lack of advertisement and sometimes outdated non fancy UI implementation support. And on the other side the very hard task to find and get young already skilled Smalltalk developers.
I have the impression that some guys need to be brought back down on earth.
Seaside is a Open Source project which is squeak based. If I would blame the Seaside development team for working inacurate, regarding coding conventions, I could blame a lot of Squeak-Based projects on that. Some things like instance variable accessing is typically done without accessor- and getter-methods within Squeak.
I don't like that too, but to be honest, I don't have the time to offer a overworked version to the coreteam. I guess I'm not the only one here...
It's definetly true that Seaside is one of the most interesting projects in the Smalltalk market right now, giving companies the chance to offer something new and up-to-date.
But I also think it's merely impossible to develop a smalltalk project in squeak with the abillity to fullfill all advantages of the ported target systems, like VW, VASmalltalk, Gemstone and Dolphin...
It's the business of Cincom, Instantiations, Gemstone, ObjectArts and projects using Seaside for many years now, to support and influence and support actual Seaside development in squeak to assure the usability and optimization of Seaside Core.
You can't offer the world a kind of combination of domestic animal that produces eggs, wool, milk and can be grilled, or as we say in Germany "eine Eierlegendewollmilchsau" and additional to that: "for free".
Seaside is not a completed proprietary product, but everybody expects a robust in changes and optimal basis for writing a new next gerneration 15 years lasting Webapplication framework for the own product family.
Seaside is a sparetime project and it's a democratic project. Everybody can join the Coreteam and can expend time to push it forward.
Well, I'm happy for everyone beeing able to get some money out of Seaside. And I' m sure the whole Smalltalk community would be glad about more Seasiders and Seaside-Profiteers helping Smalltalk to become more interessing to newcomers again and support others to get a hand on Seaside.
Blogs like onsmalltalk.com for example, are worther than comments in alternating alpha release classes.
Thank's to everyone presenting, writing tutorials, books, blogs and thanks to the coreteam for the help and advice you gave to me past month!
Thanks Cucumber for speaking out load what you think. There are several point's I often have in mind reading over "Squeak-Code", but some points might be hard to be solved just because nobody knows, where the Seaside is heading to.
The actual effords in seperating plattformdependent coding from seasidecoding is an improvement I really appreciate. It clearly shows that these guys are willing to give a larger community an access to Seaside. I could imagine that this is a lot harder than just staying in Squeak.
Profit in mind or not, I don't care. They deserve it.
--------------------------------------------------------------------------
My comments:
That sounds very much different from the many flames from the men in the barrel against me in their sun. See the "friendly" and constructive comments to my post about "Laws of life in a community", which I have published all, of course. In German one says: "The beaten dogs are the loudest in howling".
To Squeak:
I know too little about Squeak to make a judgement about its technical internals but I think that most of my proposals platform independent. Using symbols, using getter methods, using honest and concise namings, and especially documenting the code is definitely completely independent of any platform!
It's just a matter of good style and proper engineering!
I started this initiative with the goal to bring Seaside (and in a certain respect also Smalltalk) a good step forward and I was offering my help from the very beginning (which was rudely rejected). Also, most of the comments on the mailing list prove that the primary Seaside advocates feel very much disturbed by my initiative. That is good, because it's a prerequisite for breaking up these very crusted structures who badly failed to even document their code.
I again unconditionally invite all Smalltalkers of "good intention" to join in and to collaborate with me to bring our common tool major steps ahead. Maybe, this will be in competition to the "official Seaside" for a while, but competition is always good for business.
Proposal 5: Too lazy for lazy initialisation?
This is rather a general Smalltalk subject than solely related to Seaside but it is still an important subject that strikes us regularly.
The general Smalltalk concept assumes that a class is filed into an image and that during this file-in process various initialisations are performed, which henceforth stay valid during the entire life cycle of a class inside an image.
I am absolutely sure from our own experience that this is a very bad concept, which caused us a great number of wasted working days for fixing the results of this unrealistic assumption.
I don't want to waste your and my time on discussing why this initialisation at file-in time often doesn't work. The plain fact is that this is not sufficient and there are very many good reasons for it.
Therefore, I state the requirement that in general all variables but especially all statics and class variables must perform lazy initialisation, which is the only way to safely ensure that their values are correct when they are used for the first time.
Of course, this requires using getter methods as I already demanded in my porposal 4.
Expecting a programmer to think of manually initializing classes, which is often found in how initialize methods are implemented, is completely unrealistic. This must be automated and securely insured that all unneeded variables are in the expected state when a class is used.
All of our own classes work exclusively with lazy initialisation and I can't remember a single case where this simple and absolutely secure procedure did not fit.
For all imported libraries we have gone through the hard way of writing special initialisation methods that ensure that all statics and class variables are properly initialised when an image is started (typically the application). Additionally, we had to change many situations where instance variables were not properly initialized, which was typically due to implementation mistakes (we all make mistakes and this is why lazy initialisation is the by far securest form).
I have never come about any good arguments against lazy initialisation and from my really comprehensive experience (even beyond Smalltalk) I know for sure that there is no alternative.
Therefore I am asking not only the authors of the Seaside library but all Smalltalk class library developers in general to please adhere to lazy initialisation especially for statics and class variables.
You will save all of us who are using your libraries an awful lot of time!
The general Smalltalk concept assumes that a class is filed into an image and that during this file-in process various initialisations are performed, which henceforth stay valid during the entire life cycle of a class inside an image.
I am absolutely sure from our own experience that this is a very bad concept, which caused us a great number of wasted working days for fixing the results of this unrealistic assumption.
I don't want to waste your and my time on discussing why this initialisation at file-in time often doesn't work. The plain fact is that this is not sufficient and there are very many good reasons for it.
Therefore, I state the requirement that in general all variables but especially all statics and class variables must perform lazy initialisation, which is the only way to safely ensure that their values are correct when they are used for the first time.
Of course, this requires using getter methods as I already demanded in my porposal 4.
Expecting a programmer to think of manually initializing classes, which is often found in how initialize methods are implemented, is completely unrealistic. This must be automated and securely insured that all unneeded variables are in the expected state when a class is used.
All of our own classes work exclusively with lazy initialisation and I can't remember a single case where this simple and absolutely secure procedure did not fit.
For all imported libraries we have gone through the hard way of writing special initialisation methods that ensure that all statics and class variables are properly initialised when an image is started (typically the application). Additionally, we had to change many situations where instance variables were not properly initialized, which was typically due to implementation mistakes (we all make mistakes and this is why lazy initialisation is the by far securest form).
I have never come about any good arguments against lazy initialisation and from my really comprehensive experience (even beyond Smalltalk) I know for sure that there is no alternative.
Therefore I am asking not only the authors of the Seaside library but all Smalltalk class library developers in general to please adhere to lazy initialisation especially for statics and class variables.
You will save all of us who are using your libraries an awful lot of time!
Laws of life in a community!
On the Seaside mailing list, there were and are violent arguments against this blog. Here is what I answered to one of them about the mechanics of a community:
I fully understand you:
There is finally somebody daring to frankly criticise the gods of Seaside in very open words and with some good arguments and he is not willing to make the Kowtow in front of the Seaside emperors!
That's an unexcusable sin!
But as long as somebody refuses to document their work, it's extremely hard for me to take them seriously. There has never been any excuse or confession by the authors that it was/is a great mistake not to document.
If they were saying clearly: If you want to understand Seaside then you must hire me, it'd be fine for me. But I hate lies and dissimulations.
Instead of writing many posts on the mailing list, they should rather make their homework and properly document Seaside. Or openly charge for it. Fair enough!
Just one example concerning this:
"Technically I don't share your view about any of the problems you mention as "massive problems"."
Even if you don't consider my issues "massive" why don't you at least admit that I am making some serious points?!
Or don't you want to be blamed like some other writer on the mailing list who was immediately corrected for showing some understanding for my points?! He was made shut-up.
This is why I am getting discrete emails from people who partially or even essentially agree but who don't want to expose themselves opposing openly to this "community".
We have this typical community situation:
You all stick together because I am disturbing your circles. I am standing in your sun while you are the Diogenes in the barrel who says: "Go our of my sun".
I am most constructive on my blog. Why don't you join in?! Could be anonymous so that you won't get beaten by the others of this community.
You - and everybody else - are welcome!
Greetings from Mr. Cucumber
I fully understand you:
There is finally somebody daring to frankly criticise the gods of Seaside in very open words and with some good arguments and he is not willing to make the Kowtow in front of the Seaside emperors!
That's an unexcusable sin!
But as long as somebody refuses to document their work, it's extremely hard for me to take them seriously. There has never been any excuse or confession by the authors that it was/is a great mistake not to document.
If they were saying clearly: If you want to understand Seaside then you must hire me, it'd be fine for me. But I hate lies and dissimulations.
Instead of writing many posts on the mailing list, they should rather make their homework and properly document Seaside. Or openly charge for it. Fair enough!
Just one example concerning this:
"Technically I don't share your view about any of the problems you mention as "massive problems"."
Even if you don't consider my issues "massive" why don't you at least admit that I am making some serious points?!
Or don't you want to be blamed like some other writer on the mailing list who was immediately corrected for showing some understanding for my points?! He was made shut-up.
This is why I am getting discrete emails from people who partially or even essentially agree but who don't want to expose themselves opposing openly to this "community".
We have this typical community situation:
You all stick together because I am disturbing your circles. I am standing in your sun while you are the Diogenes in the barrel who says: "Go our of my sun".
I am most constructive on my blog. Why don't you join in?! Could be anonymous so that you won't get beaten by the others of this community.
You - and everybody else - are welcome!
Greetings from Mr. Cucumber
Proposal 4: Documention - the Holy Grail
This is the absolute topmost and primary subject!
I have mentioned this before and I'm here giving some more details on what a good documentation should comprise of. Here I am only discussing the internal documentation, leaving general overviews and tutorials etc. completely aside.
1) Class comments
This is the most rudimentary documentation, which gives programmers an overview on the purpose and the responsibility of a particular class. This together with a clear and concise class name is absolutely mandatory in order to understand what a class does. It is not acceptable to force a user (programmer) to read the code in order to acquire the knowledge of what a class does. This is currently the case in Seaside.
For several reasons it has proven to be very practical to put the class comments into a separate method, which should be in a separate category. In my view this is far better than placing the comment into the class comment view (which is the default in VisualWorks).
There are many advantages in putting the comment into separate methods, which contain nothing but the comment and which have the same method name through old all class.
We are using the following convention, which applies to absolutely every (of our and most of the imported) classes:
In category "documentation" on the instance side there is a method called "documenationOnClass", which holds the documentation for this class.
In many cases there are additional methods in the same category, which then start with something like "documentationOnBlahBlah" where "BlahBah" characterises a particular subject, which is worth having its own separate documentation method.
The class comments should be short, concise but complete. This is difficult to achieve, I know!
Another advantage of these class documenting methods is that they can be exported easily and made available to new members of the team or used for a separate plain text documentation. However, in such cases it is always wise to keep the original texts inside the code, because life experience shows that external documentation is typically not updated when changes are made to a system.
2) Documenting instance variables
The standard practice in VisualWorks adds the instance variables to the class comment view.
I don't think that this is a good idea, especially since many instance variables are not handled as instance variables in the technical sense but are rather stored in some dictionary. In fact, we primarily use dictionaries for user application data, because they are far more flexible and easier to configure. There is hardly any speed difference in VW. Dictionaries are extremely fast.
We are documenting all instance variables in their getter methods.
This has been a good practice for my teams for far more than 20 years (I was in OOD technology for many years before my Smalltalk times). As I wrote before, we are typically not using instance variables directly in the code but we almost always access them via get and set methods (with some very few and well justified exceptions like for Semaphores or in the very rare cases where instance variables should be protected from being accessible from outside a class).
We always place the instance variable documentation into the getter methods. The setter methods typically do not contain any regular documentation except in cases where some special handling is implemented.
This has proven to be practical also because one looks at the getter methods far more often than at the setter methods.
3) Documenting methods in general
Now, let us face the facts: Many Smalltalkers believe that because their language and development environment is so brilliant and because they themselves are so brilliant as well, there is no need to document their code!
This is stupid ignorant bullshit!
Documenting Smalltalk code is just as mandatory as for code in any other language!
By the way: You can call me intolerant or whatever else you prefer but this subject is something that I am not willing to discuss, because I consider this the highest and most holy rule of software development at all! And you can take it very personal if I am stating that I cannot take anybody seriously who objects to comment his code!
Virtually every method must be documented!
The documentation text may not consist of the method name itself but it should substantially enhance the semantics of the method name. Ideally, the method name explains already the most important facts but in reality this is often not the case. This is where the method documentation comes in.
The way of phrasing this method documentation should be as consistent throughout the entire system as possible. The words themselves should be short, concise but still complete and cover all important aspects.
The method documentation must under all circumstances tell what the method answers.
Ideally, this method documentation should fully explain what a method does without having to show the code itself.
4) Special documentation inside methods
There are regularly cases where methods, especially longer multi-line methods, need additional documentation of certain statements. This is especially the case where the reason for a statement is not obvious and requires knowledge of outside or additional facts or circumstances.
Such special documentation should be placed above the respective lines of code, typically with an empty row above, so that it is clearly visually separated from the rest of the code. All other rules for documentation apply accordingly.
Please remember the first commandment:
Thou shall document thy code!
I have mentioned this before and I'm here giving some more details on what a good documentation should comprise of. Here I am only discussing the internal documentation, leaving general overviews and tutorials etc. completely aside.
1) Class comments
This is the most rudimentary documentation, which gives programmers an overview on the purpose and the responsibility of a particular class. This together with a clear and concise class name is absolutely mandatory in order to understand what a class does. It is not acceptable to force a user (programmer) to read the code in order to acquire the knowledge of what a class does. This is currently the case in Seaside.
For several reasons it has proven to be very practical to put the class comments into a separate method, which should be in a separate category. In my view this is far better than placing the comment into the class comment view (which is the default in VisualWorks).
There are many advantages in putting the comment into separate methods, which contain nothing but the comment and which have the same method name through old all class.
We are using the following convention, which applies to absolutely every (of our and most of the imported) classes:
In category "documentation" on the instance side there is a method called "documenationOnClass", which holds the documentation for this class.
In many cases there are additional methods in the same category, which then start with something like "documentationOnBlahBlah" where "BlahBah" characterises a particular subject, which is worth having its own separate documentation method.
The class comments should be short, concise but complete. This is difficult to achieve, I know!
Another advantage of these class documenting methods is that they can be exported easily and made available to new members of the team or used for a separate plain text documentation. However, in such cases it is always wise to keep the original texts inside the code, because life experience shows that external documentation is typically not updated when changes are made to a system.
2) Documenting instance variables
The standard practice in VisualWorks adds the instance variables to the class comment view.
I don't think that this is a good idea, especially since many instance variables are not handled as instance variables in the technical sense but are rather stored in some dictionary. In fact, we primarily use dictionaries for user application data, because they are far more flexible and easier to configure. There is hardly any speed difference in VW. Dictionaries are extremely fast.
We are documenting all instance variables in their getter methods.
This has been a good practice for my teams for far more than 20 years (I was in OOD technology for many years before my Smalltalk times). As I wrote before, we are typically not using instance variables directly in the code but we almost always access them via get and set methods (with some very few and well justified exceptions like for Semaphores or in the very rare cases where instance variables should be protected from being accessible from outside a class).
We always place the instance variable documentation into the getter methods. The setter methods typically do not contain any regular documentation except in cases where some special handling is implemented.
This has proven to be practical also because one looks at the getter methods far more often than at the setter methods.
3) Documenting methods in general
Now, let us face the facts: Many Smalltalkers believe that because their language and development environment is so brilliant and because they themselves are so brilliant as well, there is no need to document their code!
This is stupid ignorant bullshit!
Documenting Smalltalk code is just as mandatory as for code in any other language!
By the way: You can call me intolerant or whatever else you prefer but this subject is something that I am not willing to discuss, because I consider this the highest and most holy rule of software development at all! And you can take it very personal if I am stating that I cannot take anybody seriously who objects to comment his code!
Virtually every method must be documented!
The documentation text may not consist of the method name itself but it should substantially enhance the semantics of the method name. Ideally, the method name explains already the most important facts but in reality this is often not the case. This is where the method documentation comes in.
The way of phrasing this method documentation should be as consistent throughout the entire system as possible. The words themselves should be short, concise but still complete and cover all important aspects.
The method documentation must under all circumstances tell what the method answers.
Ideally, this method documentation should fully explain what a method does without having to show the code itself.
4) Special documentation inside methods
There are regularly cases where methods, especially longer multi-line methods, need additional documentation of certain statements. This is especially the case where the reason for a statement is not obvious and requires knowledge of outside or additional facts or circumstances.
Such special documentation should be placed above the respective lines of code, typically with an empty row above, so that it is clearly visually separated from the rest of the code. All other rules for documentation apply accordingly.
Please remember the first commandment:
Thou shall document thy code!
To Avi Bryant: Pride goes before a fall
The reasons for starting this blog have just been justified again by the posting of Avi Bryant on the Seaside mailing list:
First he cites parts of my posting about using "newBlahBlah" and then comes this:
"Gee. I better go and look at some of those 25 year old classes to see what conventions, in fact, the forefathers at PARC were using. Let's look in Squeak, which is the closest modern equivalent to the original Smalltalks."
Clearly, this rather young guy feels to stand far above what had been done in the dark ages "25 years ago". He feels wiser.
He then shows three examples that work without new:
Point x: y:
Association key: value:
Fraction numerator:denominator:
Then more polemics: "Never mind, though, Dan Ingalls is probably some bright young guy with little experience. Maybe you should set him straight?"
Here is my answer:
The basic classes are a very different subject, because everybody must learn their protocols who wants to program in Smalltalk at all.
This is not the case for Seaside or rather: it should not be the case. And therefore Seaside is a very different situation.
In the basic class library there are many good reasons for not using "new" although even there are some cases that could be subject to critics like the frequent "on:" which I find rather bad, because one cannot track its senders. As we all know, tracking senders by class names is always much more cumbersome and often impossible, because class names in Smalltalk are often contained in variables, thus tracking them becomes impossible.
Avi Bryant globally refuses to even discuss my point, which should be obvious to every open-minded Smalltalker. Well, he is definitely not one of them.
Mr. Bryant, your arrongancy stinks!
And because of that you are absolutely immune to advice. This is exactly what I had expected and good reasons why I choose this form of an anonymous blog. You proved me right. Your attitude does not serve the Seaside community!
Unfortunately!
First he cites parts of my posting about using "newBlahBlah" and then comes this:
"Gee. I better go and look at some of those 25 year old classes to see what conventions, in fact, the forefathers at PARC were using. Let's look in Squeak, which is the closest modern equivalent to the original Smalltalks."
Clearly, this rather young guy feels to stand far above what had been done in the dark ages "25 years ago". He feels wiser.
He then shows three examples that work without new:
Point x: y:
Association key: value:
Fraction numerator:denominator:
Then more polemics: "Never mind, though, Dan Ingalls is probably some bright young guy with little experience. Maybe you should set him straight?"
Here is my answer:
The basic classes are a very different subject, because everybody must learn their protocols who wants to program in Smalltalk at all.
This is not the case for Seaside or rather: it should not be the case. And therefore Seaside is a very different situation.
In the basic class library there are many good reasons for not using "new" although even there are some cases that could be subject to critics like the frequent "on:" which I find rather bad, because one cannot track its senders. As we all know, tracking senders by class names is always much more cumbersome and often impossible, because class names in Smalltalk are often contained in variables, thus tracking them becomes impossible.
Avi Bryant globally refuses to even discuss my point, which should be obvious to every open-minded Smalltalker. Well, he is definitely not one of them.
Mr. Bryant, your arrongancy stinks!
And because of that you are absolutely immune to advice. This is exactly what I had expected and good reasons why I choose this form of an anonymous blog. You proved me right. Your attitude does not serve the Seaside community!
Unfortunately!
Friday 17 April 2009
Proposal 3: Stick to Smalltalk naming conventions
The authors of Seaside violated the general Smalltalk naming conventions in a huge number of cases! Actually, they far more often violate them than adhered to them.
One of the great things about Smalltalk is that most of the developers of class libraries adhere to common coding conventions. That makes it much easier for others to reuse these class libraries. This is one of the most powerful "de facto" features of Smalltalk!
One of the most commonly used and undisputed convention says that a factory method, which creates a new instance, should start with the word "new".
This common convention is consistently ignored in Seaside!
This is very very bad style! Absolutely amateurish and far away from "engineering"!
This extremely bad habit makes it very difficult for a user (developer) of the Seaside library to understand the code. It forces the developer to look up the code, typically over several methods, to understand what is really going on.
Actually, these wrong method names really lie to us! And there are far more such cases than discussed here.
In most cases, the method names just don't say what they do! And the worst situation of this is regarding factory methods!
For example: in WATree root: anObject really creates a new instance! How the fuck shall one know this?
This is against all Smalltalk rules! I have to read to code to know what's going on.
Must better would be:
WATree -> newWithRoot: anObject
This makes clear:
a) A new instance is created.
b) The root is set.
Why the hell can't you adhere to what the great majority of Smalltalkers has been successfully doing for more than 25 years?!
Therefore, I strongly urge you to finally adhere to what is commonly regarded as Smalltalk convention! You are definitely not any cleverer or better than the forefathers of Smalltalk at PARC (and, of course, neither am I)! You are most likely some bright but rather young guys with little experience.
So forget your pride and try to learn from the elder Smaltalkers
(I mean the general conventions. They are good and make much sense!).
Please do rename all factory methods to start with "newBlahBlah" instead of just using what you had in your mind when first writing this code.
A general recommendation from my experience:
Polymorphism is a great thing - but not always! Polymorphism for methods like "new" or "initialize" hurts more than it helps, because it is almost impossible to track the senders, because there are simply far too many!
Therefore, it has proven to be a good practice to combine the general convention "new" with some information about what is created or initialized. This can either be a shortcut of the class, which receives this message, or some other essential information related to this factory method.
In such cases it is very simple to track down the senders without having to go via the class names, which is often not so precise and which is always very much slower (at least in VisualWorks and in our images, which have typically between 60 and 80 MB in the development versions.
...more to follow soon! I have a very long list to go through!
One of the great things about Smalltalk is that most of the developers of class libraries adhere to common coding conventions. That makes it much easier for others to reuse these class libraries. This is one of the most powerful "de facto" features of Smalltalk!
One of the most commonly used and undisputed convention says that a factory method, which creates a new instance, should start with the word "new".
This common convention is consistently ignored in Seaside!
This is very very bad style! Absolutely amateurish and far away from "engineering"!
This extremely bad habit makes it very difficult for a user (developer) of the Seaside library to understand the code. It forces the developer to look up the code, typically over several methods, to understand what is really going on.
Actually, these wrong method names really lie to us! And there are far more such cases than discussed here.
In most cases, the method names just don't say what they do! And the worst situation of this is regarding factory methods!
For example: in WATree root: anObject really creates a new instance! How the fuck shall one know this?
This is against all Smalltalk rules! I have to read to code to know what's going on.
Must better would be:
WATree -> newWithRoot: anObject
This makes clear:
a) A new instance is created.
b) The root is set.
Why the hell can't you adhere to what the great majority of Smalltalkers has been successfully doing for more than 25 years?!
Therefore, I strongly urge you to finally adhere to what is commonly regarded as Smalltalk convention! You are definitely not any cleverer or better than the forefathers of Smalltalk at PARC (and, of course, neither am I)! You are most likely some bright but rather young guys with little experience.
So forget your pride and try to learn from the elder Smaltalkers
(I mean the general conventions. They are good and make much sense!).
Please do rename all factory methods to start with "newBlahBlah" instead of just using what you had in your mind when first writing this code.
A general recommendation from my experience:
Polymorphism is a great thing - but not always! Polymorphism for methods like "new" or "initialize" hurts more than it helps, because it is almost impossible to track the senders, because there are simply far too many!
Therefore, it has proven to be a good practice to combine the general convention "new" with some information about what is created or initialized. This can either be a shortcut of the class, which receives this message, or some other essential information related to this factory method.
In such cases it is very simple to track down the senders without having to go via the class names, which is often not so precise and which is always very much slower (at least in VisualWorks and in our images, which have typically between 60 and 80 MB in the development versions.
...more to follow soon! I have a very long list to go through!
Proposal 2: Remove all namespaces
Important addition on 19.04.09: James Robertson of Cincom pointed out in his blog that the speed of namespaces has improved in VW 7. I cannot comment this (but I trust him), because we are not on VW 7. Therefore, please keep in mind that my following comments apply only to older VW releases.
-------------------------------------------------------------
A technical foreword: The sequence of my postings does not reflect the importance of the subjects.
In VisualWorks accessing classes by their namespaces bindings is very slow!
Unfortunately, both Seaside as well as the Swazoo classes use namespace bindings. This is in some cases needed, because the authors of these classes refuse to use a stringent naming convention for their classes like in the WABlahBlah cases, which is good but not yet applied to all classes.
When testing our application I was wondering why making a timestamp took such a long time! I found out that the reason was solely in the use of namespace bindings throughout many classes (primarily Swazoo and ported Squeak classes).
I have removed these namespace bindings and this decreased the time by more than 70% !!!
Therefore, I recommend you to make these changes:
1) Rename all classes to follow a stringent naming convention. The first two or three characters must under all circumstances start with a homogeneous number of characters, which identify the application. WABlahBlah is good. But it must apply to all classes.
2) Remove all usages of "Namespace.ClassName". This is slow. The class name alone will be sufficient.
3) We find it cleaner to never store the expressive class name but to use symbols like in: #XYZMyClass asClass. This avoids undeclareds when a system is configured in different versions, which might not comprise of all classes (frequently the case for us). In such cases and for speed purposes a static in class String does perfectly well, which translates "asClass" to the wanted class. But, of course, this is more a matter of taste.
Two remarks:
1) This does not contradict my previous statement that execution speed (generally) does not matter. There was more involved than mentioned above and on a heavily used server this accumulates to simply a lot of wasted time.
2) A long time ago we have made an enhancement to compensate this VisualWorks performance problem so that we can send a message "asClass" to every symbol and string. It's a hack but very useful and very much quicker than going through the normal "binding value" thing. We have simply added a static to class String, which holds a dictionary where the keys are the class symbols and the values are the classes. This has improved the entire speed of our application considerably!
...more to follow soon!
-------------------------------------------------------------
A technical foreword: The sequence of my postings does not reflect the importance of the subjects.
In VisualWorks accessing classes by their namespaces bindings is very slow!
Unfortunately, both Seaside as well as the Swazoo classes use namespace bindings. This is in some cases needed, because the authors of these classes refuse to use a stringent naming convention for their classes like in the WABlahBlah cases, which is good but not yet applied to all classes.
When testing our application I was wondering why making a timestamp took such a long time! I found out that the reason was solely in the use of namespace bindings throughout many classes (primarily Swazoo and ported Squeak classes).
I have removed these namespace bindings and this decreased the time by more than 70% !!!
Therefore, I recommend you to make these changes:
1) Rename all classes to follow a stringent naming convention. The first two or three characters must under all circumstances start with a homogeneous number of characters, which identify the application. WABlahBlah is good. But it must apply to all classes.
2) Remove all usages of "Namespace.ClassName". This is slow. The class name alone will be sufficient.
3) We find it cleaner to never store the expressive class name but to use symbols like in: #XYZMyClass asClass. This avoids undeclareds when a system is configured in different versions, which might not comprise of all classes (frequently the case for us). In such cases and for speed purposes a static in class String does perfectly well, which translates "asClass" to the wanted class. But, of course, this is more a matter of taste.
Two remarks:
1) This does not contradict my previous statement that execution speed (generally) does not matter. There was more involved than mentioned above and on a heavily used server this accumulates to simply a lot of wasted time.
2) A long time ago we have made an enhancement to compensate this VisualWorks performance problem so that we can send a message "asClass" to every symbol and string. It's a hack but very useful and very much quicker than going through the normal "binding value" thing. We have simply added a static to class String, which holds a dictionary where the keys are the class symbols and the values are the classes. This has improved the entire speed of our application considerably!
...more to follow soon!
Proposal 1: Class WARequest
With this posting I am starting a series of concrete proposals for improving Seaside. Of course, the documentation has absolutely the topmost and very first and highest priority, because:
There is never any excuse for not documenting!
In my view class WARequest is of the most important classes, especially in debugging and while getting to know the functionality of the system. This is why I start with this class.
I therefore propose to enhance this class as follows:
1) All responsibilities to WARequest
Among experienced Smalltalkers it should be out of any discussion that responsibilities about implementation details (how and where to store data) are solely responsibilities of the respective class.
In Seaside, this is not the case. Instead, the knowledge about internals of WARequest is regularly and frequently spread over many other classes.
See my example further below where a request is tested for some state. You will find many such tests in different classes and this is just very bad coding style.
It is programming at best with objects (or may be programming around objects) but not object-oriented programming!
Therefore, all such method that are checking or manipulating data inside WARequest must be moved into WARequest, which responds by a Boolean answers or via delivering or accepting the data.
2) Introduce states of requests
In the beginning it was extremely difficult for us to find out where what happens inside Seaside,which was worsened by the fact that no stringent naming conventions for the methods were used (that is another subject not for now).
This essential class WARequest must be enabled to answer its states, i.e. what type of request it is etc. All of this must be checkable via testing methods in a stringent syntax like "isReqestBlahBlah" so that it is easy to find out all available test methods.
3) Add a language code
As for the moment I'm leaving out all my heavy claims on this Anglo-Saxon ignorance about multilingualism. Also, the language code is even more important in WASession, but I will come to that later.
Add an instance variable to WARequest, which can be interrogated by all consumer methods, which need to process or query the requests instance. Many of these are language dependent (Anglo-Saxons: You are not alone in this world and this world is not yours!) and it is often simpler to ask the request instead of the session. Also, the requests can be often reached directly while the current session needs this fancy event, which is much more difficult to use while debugging (and also slower).
4) Add a starting and ending time
We have invested some work in a set of classes, which are recording not only the time but also the events (including menus, forms, errors, missing translations etc), which are processed through a request. In order to be able to report such data, the request must be able to deliver its starting and its ending time, which (in our case) will be recorded when the response is sent to the client.
5) Use setter and get a methods only!
I know that this is an academic subject, to which many Smalltalkers will oppose, but in our work we hardly ever use instance variables directly even inside a class. I personally consider this as bad style (with some very few exceptions like Semaphores). Getters and setters are very much better in many respects!
In concrete words, this does not mean what is implemented today: aRequest fields at: #someValue -> very bad!
But instead this means one of these three much better tractable versions:
a) aRequest fieldsAt: #someValue
b) aRequest get: #someValue
c) aRequest someValue
where the third one has the advantage that the implementation of the storage of this symbol inside WARequest is even better hidden. We have implemented b) and c) depending on the situation.
6) Accessors for nativeRequest
Often one needs to query the instance of nativeRequest, which sits inside WARequest. This is an implementation detail, which should be hidden inside WARequest without consumers (other classes) having to know this internal of WARequest.
Therefore, I recommend you to include accessor methods to WARequest for all services supplied by the nativeRequest, so that consumers only have to deal with WARequest.
7) Accessors for other internals
Of course, the same as stated in 6) is true for all other instances held by WARequest in its instances. It is never good to let foreigners (classes outside WARequest) know about implementation details inside another class!
To reming you: This is what is called encapsulation in the schooldays for Smalltalk. The authors of Seaside have forgotten most of these lessons.
8) All WARequest key fields on the class side
There are various keys handled essentially (not only but mainly) by WARequest. Currently, they are spread all over many places in several other classes. Very bad!
Create unique accessors with the stringent naming syntax (proposed: requestkeyForBlaBlah) on the class side of WARequest. All other classes where these keys are used, must refer to these unique identifiers. Alternatively and a little bit more liberally one could use these identifiers as symbols elsewhere, but I would prefer the first version (we have done it that way).
9) Testing methods for all WARequest keys
in order to ease the life of consumers of WARequest, there should be testing methods with the stringent syntax (isRequestForBlahBla) inside class WARequest. I've shown this already in my first example further below.
Résumée:
Please see this as my first very constructive contribution to improving Seaside.
I hope that the critical voices in the mailing list who knew nothing better then making their fun about my blogging will now start to understand slowly that I mean it very seriously and that my proposals come from a very long time in the software industry.
Best regards from Mr. Cucumber
(as you called me in the mailing list)
(my gilfriend happily agrees *ggg*)
...more to come soon!
There is never any excuse for not documenting!
In my view class WARequest is of the most important classes, especially in debugging and while getting to know the functionality of the system. This is why I start with this class.
I therefore propose to enhance this class as follows:
1) All responsibilities to WARequest
Among experienced Smalltalkers it should be out of any discussion that responsibilities about implementation details (how and where to store data) are solely responsibilities of the respective class.
In Seaside, this is not the case. Instead, the knowledge about internals of WARequest is regularly and frequently spread over many other classes.
See my example further below where a request is tested for some state. You will find many such tests in different classes and this is just very bad coding style.
It is programming at best with objects (or may be programming around objects) but not object-oriented programming!
Therefore, all such method that are checking or manipulating data inside WARequest must be moved into WARequest, which responds by a Boolean answers or via delivering or accepting the data.
2) Introduce states of requests
In the beginning it was extremely difficult for us to find out where what happens inside Seaside,which was worsened by the fact that no stringent naming conventions for the methods were used (that is another subject not for now).
This essential class WARequest must be enabled to answer its states, i.e. what type of request it is etc. All of this must be checkable via testing methods in a stringent syntax like "isReqestBlahBlah" so that it is easy to find out all available test methods.
3) Add a language code
As for the moment I'm leaving out all my heavy claims on this Anglo-Saxon ignorance about multilingualism. Also, the language code is even more important in WASession, but I will come to that later.
Add an instance variable to WARequest, which can be interrogated by all consumer methods, which need to process or query the requests instance. Many of these are language dependent (Anglo-Saxons: You are not alone in this world and this world is not yours!) and it is often simpler to ask the request instead of the session. Also, the requests can be often reached directly while the current session needs this fancy event, which is much more difficult to use while debugging (and also slower).
4) Add a starting and ending time
We have invested some work in a set of classes, which are recording not only the time but also the events (including menus, forms, errors, missing translations etc), which are processed through a request. In order to be able to report such data, the request must be able to deliver its starting and its ending time, which (in our case) will be recorded when the response is sent to the client.
5) Use setter and get a methods only!
I know that this is an academic subject, to which many Smalltalkers will oppose, but in our work we hardly ever use instance variables directly even inside a class. I personally consider this as bad style (with some very few exceptions like Semaphores). Getters and setters are very much better in many respects!
In concrete words, this does not mean what is implemented today: aRequest fields at: #someValue -> very bad!
But instead this means one of these three much better tractable versions:
a) aRequest fieldsAt: #someValue
b) aRequest get: #someValue
c) aRequest someValue
where the third one has the advantage that the implementation of the storage of this symbol inside WARequest is even better hidden. We have implemented b) and c) depending on the situation.
6) Accessors for nativeRequest
Often one needs to query the instance of nativeRequest, which sits inside WARequest. This is an implementation detail, which should be hidden inside WARequest without consumers (other classes) having to know this internal of WARequest.
Therefore, I recommend you to include accessor methods to WARequest for all services supplied by the nativeRequest, so that consumers only have to deal with WARequest.
7) Accessors for other internals
Of course, the same as stated in 6) is true for all other instances held by WARequest in its instances. It is never good to let foreigners (classes outside WARequest) know about implementation details inside another class!
To reming you: This is what is called encapsulation in the schooldays for Smalltalk. The authors of Seaside have forgotten most of these lessons.
8) All WARequest key fields on the class side
There are various keys handled essentially (not only but mainly) by WARequest. Currently, they are spread all over many places in several other classes. Very bad!
Create unique accessors with the stringent naming syntax (proposed: requestkeyForBlaBlah) on the class side of WARequest. All other classes where these keys are used, must refer to these unique identifiers. Alternatively and a little bit more liberally one could use these identifiers as symbols elsewhere, but I would prefer the first version (we have done it that way).
9) Testing methods for all WARequest keys
in order to ease the life of consumers of WARequest, there should be testing methods with the stringent syntax (isRequestForBlahBla) inside class WARequest. I've shown this already in my first example further below.
Résumée:
Please see this as my first very constructive contribution to improving Seaside.
I hope that the critical voices in the mailing list who knew nothing better then making their fun about my blogging will now start to understand slowly that I mean it very seriously and that my proposals come from a very long time in the software industry.
Best regards from Mr. Cucumber
(as you called me in the mailing list)
(my gilfriend happily agrees *ggg*)
...more to come soon!
Ethical discussion
Lukas Renggli just made this posting to the Seaside mailing list:
--------------------------------------------
Please ignore this guy and the posts he is writing. He is a troll. Indeed, he was calling me yesterday on my work phone. Without introduction he was insulting me and the whole Seaside community. He eventually hung up without having identified himself and without letting me finish my explanations.
Cheers,
Lukas
--------------------------------------------
I have to put things right, because there are a few lies in these words:
1) "He is a troll"
I take Seaside most seriously. We have invested a lot of time and money and cannot afford to continue having massive problems because of the undocumented and badly designed code in Seaside.
2) "he was insulting me and the whole Seaside community"
That is blunt lie! After saying my name, I started my phone call with these words: "We have now been working with Seaside for several months and in my 10 years of Smalltalk experience I have never come about such an undocumented and in major parts badly designed code. I offer you my help in documenting and improving Seaside, because it is very important for us."
The immediate response of Lukas Renggli, without asking any questions or wanting to know my ideas, was to tell me "to choose Ruby, because Seaside is one of the best pieces of Smalltalk around".
He showed to be completely immune to advice ("beratungs-resistent").
3) He eventually hung up without having identified himself
This is another blunt lie! I introduced myself at the very beginning of the phone call.
4) ...and without letting me finish my explanations.
The third blunt lie! After Herr Renggli made very clear that there was neither a need nor any interest for improvements and collaboration I told him that I have rarely met such an arrogant person and I then hung up, simply because it was clear that this would not lead to anything at all.
Let me make clear: Seaside is extremely important for us and I am just not willing to continue to live with the compromises resulting from my critics.
I am not doing this here for fun! I see this going public as the only way to put some pressure on this rather "conspirative" community who is not open to outside critics. And many of these people consider themselves as experienced Smalltalk gurus who neither need documentation nor advice.
Otherwise they would have documented in the first place. The reactions on the mailing list so far show well that I am right.
--------------------------------------------
Please ignore this guy and the posts he is writing. He is a troll. Indeed, he was calling me yesterday on my work phone. Without introduction he was insulting me and the whole Seaside community. He eventually hung up without having identified himself and without letting me finish my explanations.
Cheers,
Lukas
--------------------------------------------
I have to put things right, because there are a few lies in these words:
1) "He is a troll"
I take Seaside most seriously. We have invested a lot of time and money and cannot afford to continue having massive problems because of the undocumented and badly designed code in Seaside.
2) "he was insulting me and the whole Seaside community"
That is blunt lie! After saying my name, I started my phone call with these words: "We have now been working with Seaside for several months and in my 10 years of Smalltalk experience I have never come about such an undocumented and in major parts badly designed code. I offer you my help in documenting and improving Seaside, because it is very important for us."
The immediate response of Lukas Renggli, without asking any questions or wanting to know my ideas, was to tell me "to choose Ruby, because Seaside is one of the best pieces of Smalltalk around".
He showed to be completely immune to advice ("beratungs-resistent").
3) He eventually hung up without having identified himself
This is another blunt lie! I introduced myself at the very beginning of the phone call.
4) ...and without letting me finish my explanations.
The third blunt lie! After Herr Renggli made very clear that there was neither a need nor any interest for improvements and collaboration I told him that I have rarely met such an arrogant person and I then hung up, simply because it was clear that this would not lead to anything at all.
Let me make clear: Seaside is extremely important for us and I am just not willing to continue to live with the compromises resulting from my critics.
I am not doing this here for fun! I see this going public as the only way to put some pressure on this rather "conspirative" community who is not open to outside critics. And many of these people consider themselves as experienced Smalltalk gurus who neither need documentation nor advice.
Otherwise they would have documented in the first place. The reactions on the mailing list so far show well that I am right.
To document or not to be
The first of the 10 commandments for software developers says:
"Thou shall document thy code"!
And this is unfortunately also the most frequently violated rule! Which also applies to Smalltalk developers!
The Seaside authors have constantly violated this rule!
There is virtually no documentation inside the code or for the classes. This is even worsened by the fact that many class names, method names and instance variable names are simply wrong. They don't do or deliver what their names promise. They are misleading any potential user of the Seaside library and stealing their time!
I think that this cannot be tolerated!
If one wants to build products on Seaside, there must be some good documentation inside the code, which allows a developer to understand quickly what is going on without reading the code.
I think that it is very amateurish and ignorant not to document such a complex class library at all! There is no excuse for it!
I can only assume that it is either or both of these reasons:
The authors planned to sell their experience and advise instead of providing a documentation. I think that this would be fair enough provided that it is openly stated (which it is not).
Alternatively it could be this frequently found ignorance of primarily younger and rather mathematically minded developers who just ignore elder people's experience that it always pays back to invest into proper documentation even for the original developer himself. Many of these mathematical people have simply problems to express their thoughts in clear words.
In my team and my work such an ignorance was never tolerated! And I am not willing to waste my time discussing this unconditionally mandatory requirement of documenting code!
By the way: The original PARC Smalltalk library was and still is a piece of art and the perfect example for well documented and concise code. Unfortunately, the newer VW classes are nowhere near this high standard.
Lucas Renggli was most ignorant when I offered my help to document Seaside. See more in: "On the darker side of Seaside".
I therefore propose a Seaside documentation community to exchange our documentation work. My team and I have already done a lot in this respect and I am offering this to everybody who is willing to contribute to this vital subject.
Of course, I also invite the Seaside authors to collaborate with us in this respect. Just drop me a line and I will come back to you with my proposals.
"Thou shall document thy code"!
And this is unfortunately also the most frequently violated rule! Which also applies to Smalltalk developers!
The Seaside authors have constantly violated this rule!
There is virtually no documentation inside the code or for the classes. This is even worsened by the fact that many class names, method names and instance variable names are simply wrong. They don't do or deliver what their names promise. They are misleading any potential user of the Seaside library and stealing their time!
I think that this cannot be tolerated!
If one wants to build products on Seaside, there must be some good documentation inside the code, which allows a developer to understand quickly what is going on without reading the code.
I think that it is very amateurish and ignorant not to document such a complex class library at all! There is no excuse for it!
I can only assume that it is either or both of these reasons:
The authors planned to sell their experience and advise instead of providing a documentation. I think that this would be fair enough provided that it is openly stated (which it is not).
Alternatively it could be this frequently found ignorance of primarily younger and rather mathematically minded developers who just ignore elder people's experience that it always pays back to invest into proper documentation even for the original developer himself. Many of these mathematical people have simply problems to express their thoughts in clear words.
In my team and my work such an ignorance was never tolerated! And I am not willing to waste my time discussing this unconditionally mandatory requirement of documenting code!
By the way: The original PARC Smalltalk library was and still is a piece of art and the perfect example for well documented and concise code. Unfortunately, the newer VW classes are nowhere near this high standard.
Lucas Renggli was most ignorant when I offered my help to document Seaside. See more in: "On the darker side of Seaside".
I therefore propose a Seaside documentation community to exchange our documentation work. My team and I have already done a lot in this respect and I am offering this to everybody who is willing to contribute to this vital subject.
Of course, I also invite the Seaside authors to collaborate with us in this respect. Just drop me a line and I will come back to you with my proposals.
Subscribe to:
Posts (Atom)