
Why is Smalltalk Dead? - Permit
http://c2.com/cgi/wiki?WhyIsSmalltalkDead
======
recuter
The Early History of Smalltalk:
[http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html](http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html)

If you have an extra hour, there's a beautifully written People's History sort
of thing by Alan Kay. SmallTalk was born out of _necessity_ and was basically
an operating system implemented in a very elegant and academic manner.

Alan had an idealistic vision of the masses not using computers as end users
do now, but as programmers. SmallTalk had a very strong educational slant.
They even tried to teach Xerox executives how to code.

I'd say it lives on in languages like Python and Ruby which are much more
pragmatic when it comes to OOP and getting stuff done. I'd also say a lot of
its charm and elegance is gone from the world. But the good ideas from it are
with us.

~~~
EliRivers
Smalltalk lives on in Objective-C :)

I learned the syntax of Objective-C from a tiny reference guide. I learned how
to _program_ in Objective-C by reading Chamond Liu's "Smalltalk, Objects, and
Design".

~~~
masklinn
> Smalltalk lives on in Objective-C :)

Not in any way, shape or form. _Some_ of smalltalk's _syntax_ lives in
objective-c, but that's it. None of smalltalk's intentions or goals do.

~~~
EliRivers
For me, the most Smalltalk-like aspect of it was that I could send any message
to any object. This was radically unlike, for example, C++, where I could only
call functions on objects when those functions actually existed.

What I'm really saying here is that I disagree with you, and I believe you are
incorrect in stating that none of Smalltalk's objectives live on in
Objective-C "in any way, shape or form", and that's an example of something
from Smalltalk that lives on in Objective-C.

~~~
segmondy
You can do the same in ruby, or with lisp. Objective-C doesn't provide a REPL
for constant feedback, you find that in ruby, lisp and python. It lives more
in those languages than in ObjC.

~~~
david-given
I don't know Ruby or Lisp, but Python, at least, doesn't like it if you call
methods on nil. Smalltalk and Objective C both let you do that (they do
nothing and return nil).

~~~
masklinn
> I don't know Ruby or Lisp, but Python, at least, doesn't like it if you call
> methods on nil.

That's false. Python likes it every bit as much as if you call methods on any
other object: it works fine if you wall a method which exists on the object,
raises an AttributeError if you try to access an attribute which does not
exist and raises a TypeError if you try to call an attribute which isn't
callable.

    
    
        >>> None.__hash__()
        -9223372036578437293
    

> Smalltalk let you do that (they do nothing and return nil).

That is also false. While UndefinedObject responds to a fair number of
messages (compared to NoneType anyway), sending an "unknown" message to `nil`
will signal an exception as it would just about anywhere else (because it'll
defer to the standard Object implementation of #doesNotUnderstand). You can
redefine `UndefinedObject doesNotUnderstand` so that it does something (or
does nothing and return `nil`), but that definitely isn't the default
behaviour, and it isn't generally considered a good idea.

~~~
david-given
>> Smalltalk let you do that (they do nothing and return nil).

> That is also false.

Oops, you're absolutely right --- I was thinking of Objective C:

[http://stackoverflow.com/questions/156395/sending-a-
message-...](http://stackoverflow.com/questions/156395/sending-a-message-to-
nil)

------
tempodox
Beyond the fact that I wouldn't use a language without a native code compiler,
the worst obstacle seems to be that you can't integrate Smalltalk into other
OSs. You have to “boot” into a Smalltalk universe and do everything in its
terms. There's no vim(1) there and all my other shell utilities are useless.
It feels like I have to re-learn everything from scratch and do it
differently, just for the benefit of using that one language. For me, that's
just too much to ask. It doesn't scale.

~~~
eggy
I agree, but I sometimes stay in Emacs all day for no good reason other than I
can - browsing, writing, email, which is like being on a different OS or
system and using its utilities, apps and compilers. I find I do the same in
Smalltalk. I am currently playing with μO (muO) music composition playground
[1]. I just go fullscreen, and I am in the Squeak world all day :) As far as
share work, the distributed image, although big, is complete and crossplaform.
I boot into different VMs the same way, with the exception that the tooling is
more common across platforms.

[1]
[http://www.zogotounga.net/comp/squeak/sqgeo.htm](http://www.zogotounga.net/comp/squeak/sqgeo.htm)

Edit: added link

~~~
marktangotango
That's a valid and easy to miss point, thanks!

------
kabdib
Really hard to collaborate with it. How do we share code between our images? I
think this was largely solved later, but...

Similarly, how do you ship code to a customer? Later there were tools
developed to pare down images, but my first introduction to Smalltalk was via
a breakout game on an Alto my division at NBS had been loaned. You could start
the game and then drop into the Smalltalk-76 environment with ^C or something
like that and start mucking around with code. Pretty much all of Smalltalk had
to come along with what you shipped.

Performance sucked for a long, long time. One of my favorite books is
"Smalltalk 80: Bits of History, Words of Advice" which describes the porting
efforts of several teams at Tektronix, Apple and so forth, and their efforts
to get _anything_ running, followed by what it took to get acceptable
performance.

Smalltalk is my favorite language that I will never be able to do real work
in. It's a shame.

------
mocana
I worked at a company that was a Smalltalk shop right through the middle of
the 0's. I personally loved Smalltalk for it's simplicity and productivity and
miss it to this day. Our company finally let go of it because: 1) We needed to
develop web applications and at the time there was no credible web app
framework. 2) Licensing was expensive and complicated. We were using
Parcplace/ObjectShare and had to deploy on Mac, Windows and different flavors
of Unix. Most of our work was for internal consumption but we would also
license our work to other companies and they had to call the ParcPlace sales
people to negotiate licenses on the runtimes. Everyone hated the hassle and
the expense. 3) While developing in Smalltalk was a dream, building and
deploying was always a big pain. 4) Java showed up. Sun pushed it hard and
aligned it with the development of the web. It was multiplatform, you could do
servlets and (cr)applets with it. And it was free!

In my personal opinion, the Java language, base libraries, and development
experience were inferior to Smalltalk in just about every way in the 0's (ok,
I welcomed static typing, but why did it take more than a decade to get
lambdas?). Even Java performance was worse than Smalltalk for a while (the
first Java releases were interpreted). But Smalltalk was a fragmented
ecosystem that did not adapt to the web and to a well-funded, well-marketed,
free competitor (Java) that offered some of the same benefits. Smalltalk was
always a niche technology. It is still alive, but the niches are smaller.

------
pron
It tried to replace the entire tool-chain instead of playing nicely with
existing tools.

While revolutionizing the entire tool-chain at once is theoretically possible,
it is also unlikely to succeed in practice. Successful tools and languages
knew how to incrementally improve things within the current system. This may
make some people angry, but that's how the world works (see the apocryphal but
not entirely untrue story about the width of a horse and the size of the space
shuttle). The reason is that decision makers need to reduce risks, and
switching everything at once is risky and stupid. Perhaps that's a Nash
equilibrium, but without something external to force a revolution, anyone
fighting that equilibrium is likely to fail.

~~~
mbrock
Smalltalk's history starts in the early seventies. Unix also tried to replace
the entire tool-chain. It just happened to succeed more widely. Though
Smalltalk has been extremely influential.

The early history of Smalltalk:
[http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html](http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html)

~~~
simonh
> Unix also tried to replace the entire tool-chain. It just happened to
> succeed more widely.

I think Unix's success is much more about actual practical reasons that mere
chance 'happening' to favour it.

Unix wasn't at all controlling and limiting in the way Smaltalk was. Unix
provided complementary tools in an open environment. If you wanted to, you
could write your own tools for Unix from the ground up starting from assembler
even. The first thing people did on Unix was port over existing languages and
tools such as Fortran from previous systems, and even to this day some of the
base math libraries are implemented in Fortran. That sort of thing wasn't
feasible with Smalltalk.

~~~
pjmlp
> That sort of thing wasn't feasible with Smalltalk.

Sure it was.

The Genera Lisp Machines had compilers for C, Ada and Pascal available.

If one really wanted to have a Fortran compiler in a Smalltalk environment,
s/he just needed to port it, just like Symbolics did for its Lisp
Workstations.

~~~
lispm
> The Genera Lisp Machines had compilers for C, Ada and Pascal available.

Also Fortran and Prolog. Though added language were expensive. Usually it
would also be useful to have a FPU option.

Thus a Lispm with Fortran would cost something like $100000 in the mid 80s.
Which makes it possible to use Fortran, but not to an attractive price. ;-)
'Exotic systems' \+ software ported to exotic systems => expensive or not
available. For decade the Symbolics approach was available and expensive,
later it moved to 'mostly not available'...

------
david-given
Incidentally, people who are interested in Smalltalk may like to check this
out:

[http://amber-lang.net/](http://amber-lang.net/)

It's a Smalltalk that runs in a browser; bolt it on to a web page and you get
a tradition Smalltalk IDE that pops up at the bottom of the page at the press
of a button. It seamlessly interacts with Javascript. There's a backend which
allows state to be saved, so it's theoretically possible to write your entire
web client using the browser as your IDE, while the client is running.

It's a bit overengineered for my taste --- the backend's quite complex and
requires node, where I'd prefer for the client to just talk WebDAV. But it's a
very interesting reinvention of Smalltalk for the modern world.

------
brudgers
After barely scraping the surface of Smalltalk, I got a feel for "Why the
hype?"...or maybe I should say why the hype isn't entirely unjustified.
Smalltalk suggested that the places where I have struggled with OOP-WTF? are
more linked to particular design decisions around particular OOP languages
than the possibilities of OOP itself.

It got me to thinking that Smalltalk is in some ways where Lisp was ten years
ago, struggling along with an aging infrastructure where the internet and
gigabytes of RAM and open-source anthropologies are mostly bolted on to a core
optimized for a time of scarcity relative to the right now. The revitalization
of Lisp as a commercial language required the equivalent of chucking the image
for Smalltalk. Clojure got rid of `cons` as the underlying abstraction.[1]
Instead of developing a standard library, and platform, and toolchain it
grafted itself onto an existing one [2].

Which is to say, I wonder if a similar tacking strategy would let Smalltalk
work its way upwind more easily than continuous patching of the Squeak image.
One price of course would be a new IDE. IMO, that's a good thing. I don't look
at plethoras of randomly located popup windows with the same sense of
wonderment I did thirty years ago...I have email, I don't really need to
manage unbounded quantities of windows, too. [Sorry for the rant].

Anyway, to me Smalltalk seems to be too much intellectual goodness to ever
really die. It just needs to continue to move toward a future where people say
"smalltalks" in the same way they can say "lisps" today.

[1]: Racket "got rid" of mutable `cons`s.

[2]: Technically, two originally then three with the browser.

------
andrewl
I read that Kent Beck said something like "I always knew one day Smalltalk
would replace Java. I just didn't know it would be called Ruby."

~~~
hodwik
I've heard it claimed a number of times that Ruby/Python are SmallTalk-esque.

Can anyone speak to that? In what ways is that so?

I've also read Peter Norvig claim that Python is a LISP with C-Syntax, so I'm
not sure what to think.

~~~
rbonvall
It seems that programmers take their favorite feature of a programming
language for comparing it to others:

If you like first-class functions, then Javascript becomes "Scheme in the
browser." If you miss having a REPL and then discover Python, it becomes "LISP
with C-syntax." If you like objects responding to arbitrary messages, then
Ruby is "Smalltalk without images" and so on.

------
dwarman
I was very enthusiastic about Smalltalk in the late 80's when I got Digitalk's
System V to play with. And one thing torpedoed its use for me - local
variables in code blocks are local to the code object, not the execution
stack, so you cannot use them for instance data in multiple instances of
persistent State Machines. I thought this was a bug, but Digitalk told me no,
it's in the language specification. Since that is my preferred way of
achieving hard Real Time event driven concurrency, I could no longer use it
and switched to hand-rolled OOP in C.

Why not C++? you might ask. The year was 1988. I needed to run on Macs as well
as PCs. The only company advertising C++ for Mac at the time was AT&T (the
purely Preprocessor implementation). When I called them to order a copy they
said "Really? C++ for Mac? You're only the sixth person ever to ask for it, so
we have not done it yet". At the same time, Objective C was similarly not
available in Windows.

------
protomyth
The technical oddities (Image, etc.) with Smalltalk are fixable, but given my
experience the vendors killed the language with high prices and "Develop a
Java solution" syndrome.

Little Smalltalk and Gnu Smalltalk both are command line implementations.
There was an attempt at a .NET version called S# that would have been based on
traditional tools.

[edit] also, F-Script was a pretty neat version for OS X that had some APL
heritage.

------
Ace17
Too much dynamicity? Ward Cunningham: "What killed Smalltalk was it was just
too easy to make a mess" (source:
[https://www.youtube.com/watch?v=YX3iRjKj7C0](https://www.youtube.com/watch?v=YX3iRjKj7C0))

