Seaside is not multi-lingual

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 .

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!

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.

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.

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.

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.

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.

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"!

Four mistakes in one line of code

Here is a first and good example of the very bad coding style in Seaside. There is one line of code with four severe mistakes in it:

WARenderContinuation -> shouldRedirect: aRequest
^ aRequest isGet not or: [(aRequest fields includesKey: '_n') not]

1) There is no sense in castrating Smalltalk and forcing the developer to use a text editor for finding the occurrences of the key '_n' by placing this value into a string. Smalltalk has this great feature of showing the references to symbols! So why does one use a string for something, which is really a symbol (a key)? This is very bad style! Amateurish! Just stupid!

2) There are several places where the key '_n' is used. Therefore, the actual key should not only be a symbol but it should also be stored at one central place, in something like a config class, which acts as the holder of all such symbols. From there on, the references can be tracked easily.

3) The knowledge about where the value for this key is to be found is spread over many other classes (in this case WARenderContinuation). That is very bad, too. Only the class WARequest should know where the value for this key is implemented. Therefore, WARenderContinuation should not know anything about somebody else's instVar 'fields'.

4) The knowledge about how the value of this key is stored (in this case in a dictionary) should also not be spread over other classes. Therefore, the usage of "includesKey:" in another class is another bad mistake in this case. Solely the class WARequest should know how this key is stored in its instances.

There is a very simple solution for these bad style codings:

^ aRequest isGet not or: [
(aRequest isTypeOfRequestForRedirect) not]

All we need is one additional little method in class WARequest:

isTypeOfRequestForRedirect
^self fields includesKey: self class requestKeyForRedirect

This method hides the place and the form of storing the key inside itself and that is where it should (only) be. In this case, the key itself is taken from a central definition method on the class side, because this key is used by other methods within the class WARequest and possibly also from by classes.

Unfortunately, similar occurrences of very bad coding style are spread all over the Seaside classes.

Obviously, the authors of Seaside have not a good clue of encapsulating class behaviour and class data into the particular classes. Instead, they spread this knowledge freely all over other classes and then even in the form of strings, which cannot be tracked by the brilliant Smalltalk development environments.

This is just one example of many for the very bad coding style in Seaside. It's more "structured programming with objects" rather than object-oriented design. From my developers I would not tolerate such basic mistakes.

On the darker side of Seaside

The Seaside web server library has often been praised to give Smalltalk a new boost. This is certainly true but things look a lot different when it comes to the practical usage and implementation of Seaside.

This is why this blog is primarily discussing the darker aspects of the Seaside design and implementation besides discussing general aspects of programming in Smalltalk.

Therefore, please don't expect too much of praise from me. You will primarily read critics and a lot of concrete engineering proposals to improve your work in Seaside and Smalltalk.

Of course, I first called Lukas Renggli, the European Seaside advocate, offering my help for documentation and improvement of the "object-orientability" of the Seaside code.

Lukas Renggli showed to be totally immune to advice. He did not even listen to my arguments! After my first critics (missing doc) he immediately said that this was one of the best pieces of code that exists in Smalltalk (I will prove him wrong in this blog) and he recommended me to use Ruby if I was "incapable" of using this "brilliant" (but undocumented) code. I have rarely spoken to someone so unconditionally arrogant and ignorant.

This is how I came to write this blog.

Another subject: Don't expect me to be politically correct!

This stupid "PC" is a US American invention that nobody needs with a goal to control, manipulate and spiritually suppress open minded people by trying to enforce them to lie or at least to deny the truth. I will never allow anybody to manipulate me like that and I will speak out open and free words and withstand this dangerous epidemic political correctness.

Therefore, from me people still die and do not "pass away" (what a stupid term!) and they are victims of genocide and murder instead of "ethnical cleansing". Don't worry, this blog is not on politics but this is where one finds the most drastic examples of this mental sickness called PC.

Last technical aspect: I am dictating these texts with voice recognition, which is a very fast and efficient way to write down my thoughts but which often leads to being careless when proofreading the text. Also, English is not my primary language.