Richard Kulisz: Smalltalk: the Software Industry's Greatest Failure
skip to main |<br>skip to sidebar
Richard Kulisz
Systems Designer, specializing in Anarchist Democracies.
Sunday, February 27, 2011
Smalltalk: the Software Industry's Greatest Failure
Every time I think about the miserable state of the software industry, it always comes back to one thing: the Smalltalk programming language.<br>The failure of the software industry is the failure of its greatest tools, the programming languages and operating systems. The failure of programming languages is the failure of the only natural and useful programming languages, the OO languages. And the failure of OO languages is the failure of the only OO language worth speaking of, Smalltalk.<br>Programming languages started with the imperative paradigm but they rapidly bifurcated into two mutually contradictory paradigms - functional and OO. Once the bifurcation was complete, the imperative paradigm ceased to have any importance. Beyond being a tool of mentally incompetent brainwashed morons and those desperately maintaining obsolete code of course.<br>The functional paradigm rejects all notion of modifiable state and orders everything around verbs so that all sentences are verb-object-object. The functional paradigm rejects state and objects so violently that it denies subjects exist. As a direct consequence it is blatantly unnatural to the human brain, contrary to physical reality, and contrary to human consciousness. Only math lovers find the functional paradigm attractive or useful which makes it useless to the rest of humanity.<br>The object-oriented paradigm is dominated by Smalltalk. Java for example doesn't even remotely qualify as object-oriented having been conceived as a deliberately inferior and broken pseudo-OO version of Smalltalk. The problem is Smalltalk is a failure as an OO language and has definitely not passed the test of time. And I'm not talking about popularity either. I couldn't care less about popularity of programming languages among brainwashed mental incompetents.<br>The failure of Smalltalk is two-fold. First, the fact that its rules are at least twice as large as they need to be. Because for every general rule of Smalltalk that someone has to assimilate in order to master the language, there is a specific rule (an exception to the general rule) that must ALSO be memorized. There are 8 such exceptions and they are:<br>variables are not objects - you can't create a variable at runtime by having 'thisContext addVariablesNamed: #('name1' 'name2' 'name3')' and | name1 name2 name3 | is not simple syntactic sugar for the previous code, as it should be. Nor can you send messages to a variable to query when it was last read from or written to.<br>the existence of variables is bound early at compile time, not at runtime - if you try to compile a method with an undeclared variable, it triggers a compile time error, not a runtime error (and compile time warning) like it should.<br>assignments and hard returns are not messages - you can't #perform: them and 4 := 3 doesn't trigger a #doesNotUnderstand: on the basis that 4 isn't a variable.<br>the unary, binary, and keyword order is not how the compiler actually evaluates anything. So in weird cases that happen 0.1% of the time, this simple rule is broken in favour of something so complicated I can't even remember it. Why? So the compiler can make a single pass instead of 3 or 4. But who gives a shit how fast the compiler operates? Other than compiler writers, literally no one.<br>#at:put: doesn't return self - collection #at: name put: object returns the argument 'object' rather than what every other method in Smalltalk would do, which is return 'collection'. And this has been empirically proven to be harmful. Another example of the language writers creating an optimization that no user wants and every user has to work around.<br>on object creation, the #initialize method isn't sent by default so you need to override #new so it sends it - this is inconsistent with the fact Smalltalk presents meaningful nil values for all instance variables in a brand new object.<br>when a collection triggers #grow (which happens at random) it won't copy over every single instance variable it has, just some completely arbitrary subset of them. So subclassing any collection class won't work unless you fix this yourself. And students who are taught to do this are rarely taught to do it properly by walking over all instVars.<br>the compiler cheats with True and False by inlining them. If you try to subclass or redefine them, it will not work. This is actually the only flaw in Smalltalk that makes any sense at all.<br>there is no infinite object cloner out of the box. You're stuck with deepCopy which is arbitrarily limited.<br>The second way that Smalltalk is a failure is that it was woefully incomplete when it was standardized and it got extended by incompetent hacks rather than competent systems designers.<br>The three biggest areas of this failure...