Smalltalk's two-fold failure
richardkulisz.blogspot.com
richardkulisz.blogspot.com
"1 - variables are not objects." Yes, ok, they are "slots", if you like, that names and hold reference to an object. You can in every Smalltalk I've used, do metaprogramming to change an object's "shape" at runtime. That is, modify the variable definitions. And yes, if you like you can add this as a nice high-level API, such as 'thisContext addVariablesNamed: #('name1' 'name2' 'name3')'. However, be warned, Smalltalk is intended to be a Class-oriented language, so you are modifying all instances of this class, not just the one object. You can add new "attributes" to a single object, but then I wouldn't recommend using variables, but instead, roll your own framework for handling "attributes on objects", which can among other things "send messages to a [attribute] to query when it was last read from or written to".
"2 - the existence of variables is bound early at compile time, not at runtime." Yeah, by definition of being a class-oriented language that's generally considered an ok thing to do. If you really don't like it, do some metaprogramming, change the compiler, or use a language like self or javascript.
"3 - assignments and hard returns are not messages" - Interesting. Now the author is simply upset that his favourite language isn't as pure as he would like.
"4 - the unary, binary, and keyword order is not how the compiler actually evaluates anything." Yes, over the years, the compilers have gotten more complex and try to optimise things. There are corner cases where they get it wrong. Regardless of language, I always follow this rule: "If you think that perhaps someone else reading your code might not understand the order of operation, use parenthesis." I follow this rule in C, Smalltalk, even Ruby ;)...never trust a compiler.
"5 - #at:put: doesn't return self" hmmm...I don't buy his argument that it should return the receiver instead of the put argument. Its a library design decision and was made long ago. Call it cruft or bad design if you will. But I bet there is someone from the late '70s still kicking that can recall why they did it that way.
"6 - on object creation, the #initialize method isn't sent by default" I don't see this as a problem. It seems like he wants the language to behave like C++ now and guarantee some "constructor" be called. I like that Smalltalk doesn't assume I want to construct all objects this way.
"7 - when a collection triggers #grow" Don't like how a specific collection class works? Use a different one or write your own. Collections by default also won't handle concurrent access well...so write one that is thread safe. This is a minor gripe about a library, not the language.
"8 - the compiler cheats with True and False by inlining them. " The compiler cheats on lots of things and for good reason. People want code that performs well, and in days past, they cared a great deal about memory. This isn't a language issue, its what happens between the compiler and VM and is implementation specific.
"9 - there is no infinite object cloner out of the box". Also a library issue. Write your own "infinite cloner". I for one, thank our Smalltalk creators that they didn't add such a nuclear device to the core libs. I've seen enough bad code over the years without something this easily abused laying about.
The author sort of lost me when we was bashing functional languages. As nice as Smalltalk is to work with, not having side effects (functional) is truly amazing!!
I agree that 6 and 9 are very weak points.
bashing functional languages - the rants detract from the seriousness of the good points the author makes, who seems to be pushing a Common Lisp is the true way line. In fact, ideas from pure functional programming could clean up several of his exceptions: in support of this I can point to Peter van Roy's comments on PL design convergence.
I liked his declaration of 8 exceptions, followed by the listing of 9 items.
He's a bit like Erik Naggum used to be in that respect, with a lower signal to noise ratio.
The article is not incoherent and does reward the sceptical reader. I hope posting it here was useful to at least some HN readers.
More on the Kulisz phenomenon: http://c2.com/cgi/wiki?RichardKulisz
I've always been charmed by Smalltalk, though having spent years in 90% functional programming land (mostly Scheme and Clojure), I