3 ms·

Smalltalk's two-fold failure

15 points by chalst 15y ago

batterseapower 15y ago
This guy appears to be a well-known troll, which is supported by the incoherent nature of this article and the rest of his blog: http://let.sysops.be/wiki/Richard_Kulisz http://let.sysops.be/wiki/Richard_Kulisz
- masklinn 15y ago
  The article reminds me of Xah Lee's production: there seems to be kernels of truth scattered all over, but they're embedded in a great morass of nonsense, contradictions, insanity and downright trolling. I liked his declaration of 8 exceptions, followed by the listing of 9 items.
- chalst 15y ago
  There's a fair bit of flamebait in the article, but the two lists of points he raises are not trivial. 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 http://c2.com/cgi/wiki?RichardKulisz
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
jhancock 15y ago
Lets go through his "8 great exceptions": "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!!
- chalst 15y ago
  Note that his point here is not with the expressive power of Smalltalk, but with the complexity it puts in front of the programmer. Workarounds or the existence of ancient wisdom about why things are the way they are aren't really responding to the point he is making. 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. http://lambda-the-ultimate.org/node/1805 http://lambda-the-ultimate.org/node/1805
  - jhancock 15y ago
    I should also add that Smalltalk didn't "fail" for its technical faults. It failed (in an oversimplified nutshell) because the companies that owned the Smalltalks had business models of charging per developer seat and their investors would not allow them to "pivot" and drop all that revenue to plug it into a browser for free. Sun could afford to give away Java for free as there was no business model behind what started as a lab experiement. Combine this with "the Internet age is coming" mantra that hit in the mid-90s and you have a perfect storm that put a hold on enterprises moving forward with Smalltalk. The internal priorities of enterprises were either put on hold or changed to address "this new Internet thing".
edw 15y ago
If the author had been a Lisp hacker, the conclusion of this amusing polemic would have ended with the announcement of a project to create the One True Dialect. I don't see why he doesn't, though based on others' comments, it's apparently because he is a troll. I've always been charmed by Smalltalk, though having spent years in 90% functional programming land (mostly Scheme and Clojure), I

15 points by chalst 15y ago

This guy appears to be a well-known troll, which is supported by the incoherent nature of this article and the rest of his blog: http://let.sysops.be/wiki/Richard_Kulisz http://let.sysops.be/wiki/Richard_Kulisz

masklinn 15y ago
The article reminds me of Xah Lee's production: there seems to be kernels of truth scattered all over, but they're embedded in a great morass of nonsense, contradictions, insanity and downright trolling. I liked his declaration of 8 exceptions, followed by the listing of 9 items.
chalst 15y ago
There's a fair bit of flamebait in the article, but the two lists of points he raises are not trivial. 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 http://c2.com/cgi/wiki?RichardKulisz

deleted 15y ago

[deleted]

deleted 15y ago

[deleted]

jhancock 15y ago

Lets go through his "8 great exceptions": "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!!

chalst 15y ago
Note that his point here is not with the expressive power of Smalltalk, but with the complexity it puts in front of the programmer. Workarounds or the existence of ancient wisdom about why things are the way they are aren't really responding to the point he is making. 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. http://lambda-the-ultimate.org/node/1805 http://lambda-the-ultimate.org/node/1805
- jhancock 15y ago
  I should also add that Smalltalk didn't "fail" for its technical faults. It failed (in an oversimplified nutshell) because the companies that owned the Smalltalks had business models of charging per developer seat and their investors would not allow them to "pivot" and drop all that revenue to plug it into a browser for free. Sun could afford to give away Java for free as there was no business model behind what started as a lab experiement. Combine this with "the Internet age is coming" mantra that hit in the mid-90s and you have a perfect storm that put a hold on enterprises moving forward with Smalltalk. The internal priorities of enterprises were either put on hold or changed to address "this new Internet thing".

edw 15y ago

If the author had been a Lisp hacker, the conclusion of this amusing polemic would have ended with the announcement of a project to create the One True Dialect. I don't see why he doesn't, though based on others' comments, it's apparently because he is a troll. I've always been charmed by Smalltalk, though having spent years in 90% functional programming land (mostly Scheme and Clojure), I