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.
Subscribe to:
Posts (Atom)