

Smalltalk's two-fold failure - chalst
http://richardkulisz.blogspot.com/2011/02/smalltalk-software-industrys-greatest.html

======
jhancock
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
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>

~~~
jhancock
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".

------
batterseapower
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>

~~~
masklinn
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.

------
edw
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

