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