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.
Subscribe to:
Post Comments (Atom)
FYI, Avi is Canadian. I realize that's kind of an inconvenient fact for you, but there it is...
ReplyDeleteNo not at all: Their telephone prefix shows what CAN really is, just the 51st state (maybe only partially for "le Quebec libre" le grand general DeGaulle).
ReplyDeleteCAN is much more part of the US than Austria is part of Germany and they say that the only thing that divides Austrians and Germans is their common language.
But I still apologize for having misspelled "Avi" as "Avy". Pardon!
ReplyDelete#unregistered is a notification to the object that is *has been* unregistered. It's not telling the object to unregister itself - the registry has already done so before the method is called.
ReplyDeleteThe method name is a past participle being used as an adjective ( http://rwc.hunter.cuny.edu/reading-writing/on-line/particip.html ).
If you assumption (that it *has been*...) was right, the grammar would be alright, of course. But the assumption is not correct.
ReplyDeleteOne Of the implementations contains "expire", another one "clearHandlers" and both are called in a chain of "super unregistered". All without one word of documentation, as always in Seaside.
And again:
1) I wouldn't mind if such abuses of English were the exception in Seaside. We all make mistakes and often choose wrong method names. Unfortunately, there are many similar examples.
2) I wouldn't mind either, if one of these guys said: "We made a mistake". No problem!
But they don't even acknowledge the total lack of (in-code) documentation.
When a Registry is notified that it has been unregistered, it clears all of its handlers and notifies them that they have been unregistered.
ReplyDeleteWhen a Session is notified that it has been unregistered, it marks itself as expired.
Those are the actions those classes have decided to take after they have been taken out of a registry.
Well, we could discuss now the entire construct of sessions and their "registry", which I consider to be "weird", complicated and very little obvious - from reading the code.
ReplyDeleteThis whole registration thing is a sick idea in itself. It has cost us days to remove this idiotic /Seaside/go when we started to make a demo.
The whole terminology in Seaside is not logical! They are just very poor in language.
When I tell a session to "expire", WTF do I have to unregister it? And when I send unregister(ed) why does it then send expire i it has already been unregister (as you wrote)? This does not fit together.
"When a Session is notified that it has been unregistered, it marks itself as expired."
When I send aSession an "expire" I expect that it is practically dead and will be garbaged next time and that it unregisters itself (if needed) but this is not the case. In "unregister*ed*" it sends "expire" (illogical language), not the other way around as it should be. And I have not yet mentioned the fact that garbage collection does not work in these constructs without explicit "release" code that we had to add.
Still, one could live with these stupid lingual mistake deficiencies if there was a proper in-code documentation.
But instead of finally writing one (after >7 years!!!), these idiots prefer to waste their time in explaining their code in endless mailing list discussions!
What a waste of time for both sides!
The guys who wrote this junk may be good at maths but they are lousy deadbeats when it comes to building a clear and concise framework with obvious terminology that is easy to understand.
This is about the 40th or 50th software library that I have worked into and used in my life and its *by far the lousiest*:
- in design and construction logic
- in the used terminology
- and in documentation (together with two others).
And you as an anonymous advocate also prefer to waste your time in trying to heal the pain instead of curing the disease - and that is the lousy Seaside code. So you better kick Avi's ass if you are a "well respected member" of this community. It would help all now and in the future.
My experience says that it costs at least the same amount of time to make a real product from some working code. And in software tools this percentage is probably even higher.