
What Killed Smalltalk? - Garbage
http://pointersgonewild.com/2015/08/20/what-killed-smalltalk/
======
david-given
Smalltalk is a lovely, lovely language. It's _fantastically_ simple --- it's
got about four syntactic elements: you can call methods, you can declare and
assign variables, you can create closures (called blocks in the Smalltalk
world), and you can return from methods. That's about it. There's no control
flow --- you do that through passing blocks into methods. You can learn the
entire language in five minutes.

Of course, learning the _library_ is another matter. But it's always depressed
me that nearly forty years later, our high-tech and ultrafast dynamic
languages still cannot hold a candle to Smalltalk for clarity, simplicity and
usability.

(And the way that every time they invent a new feature, chances are Smalltalk
had it in 1980. Better.)

~~~
jasoncapriati
I'm intrigued. Can you point to a book or guide that expands this further, is
beginner friendly and not 300 pages? Thanks!

~~~
david-given
Amber has a really nice interactive tutorial:

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

It's actually running in your browser, and the whole thing is a live coding
environment in disguise. Well worth a play.

~~~
rufugee
First thing I get when clicking "DoIt" in Chrome or Firefox is "Parse error on
line 1 column 47 : Unexpected character null".

Edit: turns out, I should've looked more closely. You're supposed to select
particular text before pressing the button. If you do this it works. Still,
they might want to consider a more friendly error message ;)

~~~
david-given
I think what it's trying to tell you is that you haven't selected any text
inside the edit window. (I agree it's a terrible error message.)

~~~
dragonwriter
Almost as terrible is the fact that the listed keyboard shortcut alternative
to clicking DoIt (CTRL d) actually deletes, rather than executes, the selected
text.

~~~
aiiane
In Chrome, at least, Ctrl+Shift+D works. So might be an implementation detail.

------
cwp
Sigh. Nothing killed Smalltalk. It's not dead. Neither is Scheme. Yeah, both
of those languages have pretty small communities, but that's viable in the
Internet Age.

Heck, even Self, which nobody ever used for actual shipping software (as far
as I know), still has some life in it. The latest release was last year and
runs on Linux, Mac OS X. (What, no Solaris support?)
[http://blog.selflanguage.org/2014/01/12/self-
mallard-4-5-0-r...](http://blog.selflanguage.org/2014/01/12/self-
mallard-4-5-0-released/)

Compared to Self, Smalltalk and Scheme are downright mainstream, and used in
all sorts of production software.

This is important if you're planning on inventing a new programming language.
The chances that you create the next Javascript or Java are slim to none.
Those languages are platforms that are backed by large companies. Languages
invented by enthusiastic geeks can succeed, but they don't take over the
world. Even when success does come, it's after decades as niche languages with
tiny communities.

If you consider Smalltalk and Scheme dead, be prepared to have your language
be stillborn.

~~~
wvenable
> Languages invented by enthusiastic geeks can succeed, but they don't take
> over the world.

Ruby, Python, and Lua are all obvious counter-examples to the idea that
enthusiastic geeks cannot create languages that are many orders of magnitude
more successful than SmalllTalk and Scheme. Even CoffeeScript, if you can call
it a complete language, is in the realm of that success.

The only language that has come out recently that is successful purely because
of the backing of a large company is Swift.

~~~
cwp
Actually, those are the very languages I had in mind. Perl too. Yes, they have
many more active developers than Smalltalk. But you know what? I was part of
the Ruby community before Rails, and it was tiny. That was after it had been
around for 10 years.

So I'll say it again. If you want to create a new language, go for it! But I
wouldn't sneer at Smalltalk and Scheme in the process. Those communities are
relatively small, but they're still huge compared to your brand-new language,
and they will be for decades. And if you judge language success by innovation
and influence rather than developers... well, you have even bigger shoes to
fill.

~~~
coldtea
> _Actually, those are the very languages I had in mind. Perl too. Yes, they
> have many more active developers than Smalltalk. But you know what? I was
> part of the Ruby community before Rails, and it was tiny. That was after it
> had been around for 10 years._

So? Languages might take a while to catch on. Ruby has a huge community and
lots of jobs now. And Python has had that even without something like Rails to
dominate adoption. Perl was also huge back in the day.

As a counterexample Dart is nowhere near even Ruby pre-Rails was, even though
it's from a major vendor.

And of course C, C++ etc didn't succeed because they had the backing of a
major vendor, like Java or C# did.

~~~
pjmlp
> And of course C, C++ etc didn't succeed because they had the backing of a
> major vendor, like Java or C# did

C - AT&T, UNIX vendors

C++ - Almost all C compiler vendors adopted it. CORBA and Windows Development
helped it.

~~~
coldtea
Having support from third party vendors is not the same as succeeding because
you have the backing of a major vendor (and especially one who created you),
like Java or C# or Swift.

~~~
pjmlp
C would have been a footnote in the history of programming languages if AT&T
didn't offered the code to a few universities, whose students created the UNIX
workstations like in Sun's case.

In the late 80's the language had zero value in the hobbyist world.

The few compilers that existed generated crappy code, were not even K&R
compatible and only mattered to those that had access to UNIX either at work
or university.

------
notdeadSTer
I generally like Uncle Bob, but he isn't a Smalltalker and didn't demonstrate
any insight into Smalltalk's unpopularity in that talk.

Worse, this is hardly the first or only time a prominent Rubyist ignorant of
Smalltalk has publicly attacked it. Sarah Mei did so in a talk two years ago,
mocking it for not having any conferences of its own (ESUG, Pharo Days, and
Smalltalks apparently don't count), and she and Steve Klabnik recently had fun
tweeting anti-Smalltalk quips back-and-forth.

Given that most of the non-awful stuff (where "awful" means, for example,
syntax too complicated to be described by a CF grammar or horrible
performance) they like about Ruby was lifted directly from Smalltalk, you'd
expect Rubyists to be extremely deferential and respectful towards Smalltalk
and Smalltalkers, but they aren't. Instead they're arrogant and condescending
despite being ignorant, validating all of the well-earned stereotypes of
Rubyists.

As for why Smalltalk "died" (cf. pharo.org) I would say it was too expensive,
both in licensing terms and hardware costs. You could outfit entire teams with
Borland or MS tools for the price of a single seat license for Smalltalk. Some
vendors would charge (and still charge) a percentage of your revenue forever,
which is insane. Then Java came along, and it was free.

Smalltalk also missed out on the open source revolution, not having viable
libre implementations (Pharo, GNU) until relatively recently.

~~~
Tloewald
I suspect it was performance, cruft, and aesthetics that killed it more than
price. After all, expensive things that get popular generally become cheaper
(or have cheaper versions released).

My experience with SmallTalk was that by the time it had any chance of uptake
it was already knee-deep in cruft (e.g. multiple overlapping visual class
hierarchies that would be mixed and matched within projects to devastatingly
awful effect).

In my experience (admittedly mostly dealing with IBM and IBM-sanctioned
vendors) a typical Smalltalk demo was a program that ran 10x slower than VB on
a computer with twice as much memory (and at least as good a CPU) as anyone
other than a Smalltalk coder had.

And Smalltalk programs tended to look awful and not be easily fixed (because
of the overlapping cruft issue).

I'm pretty sure that Rubyists are no more ignorant of Smalltalk than
Smalltalkers are of Simula.

~~~
notdeadSTer
> I suspect it was performance, cruft, and aesthetics that killed it more than
> price. After all, expensive things that get popular generally become cheaper
> (or have cheaper versions released).

I think performance was a huge problem (I did mention it in passing). But you
have to remember that just getting your hands on Smalltalk was difficult back
then. There were no free versions, and the commercial versions were expensive.
At least with Unix, most university workstations in the 80s had a copy, unlike
VMS. The result: a proliferation of free Unix-like OSes while the less
accessible VMS slowly fades into obscurity.

> I'm pretty sure that Rubyists are no more ignorant of Smalltalk than
> Smalltalkers are of Simula.

I don't understand the analogy. Ruby is an unoriginal Smalltalk knock-off that
compromises its purity, simplicity, and dynamicity. Rubyists should therefore
express deep admiration for Smalltalk in the same way Smalltalkers do Lisp,
but they don't. Simula was an ALGOL-60 derivative that had classes and co-
routines; by comparison, Smalltalk was nothing short of revolutionary, yet
I've never seen a Smalltalker attack it.

~~~
Tloewald
Given the most common mention of smalltalk is of it being the first OO
language and I seldom see it corrected by people who should know better. At
least Rubyiata acknowledge Smalltalk exists.

------
vezzy-fnord
Given Maxime's background notable background in JIT and optimizing compiler
research, I'm quite disappointed that her argument for Smalltalk's failure is
the simplistic and routinely thrown around canard of "pragmatism".

Why condemn Smalltalk for its idealistic vision when a lot of functional
languages that are so trending are just as idealistic?

(A few notes: there are implementations of Smalltalk these days which do not
involve graphical environments. GNU Smalltalk is the most advanced.

The assertion that textual mediums for writing code are always superior over
visually enhanced ones isn't an argument so much as a culture war. It's also
self-evidently of little weight, as the benefits of having a full-fledged
Smalltalk VM are immediately visible.

Furthermore, the idea of Smalltalk as the hermit kingdom that locks you in to
its toolset isn't as true anymore like it was in the past. Tools like
Monticello can interact reasonably well with the outside world:
[https://stackoverflow.com/questions/8244502/version-
control-...](https://stackoverflow.com/questions/8244502/version-control-for-
smalltalk-seaside))

~~~
sanderjd
> the benefits of having a full-fledged Smalltalk VM are immediately visible.

I'm not so sure they are. I've personally never been able to wrap my head
around how I would use any of the Smalltalk environments I've played with to
create and distribute something useful to a real person, entirely due to the
_necessity_ of "a full-fledged Smalltalk VM". It seems too all-or-nothing;
maybe it would work well as an entire OS, but it doesn't work great at the
application level.

~~~
BuildTheRobots
(stupid question; I know nothing about smalltalk, but:) the necessity for a
"fully fledged VM" doesn't seem to have slowed down Java adoption. Could you
enlighten me as to how/why I've entirely missed the point please? :)

~~~
david-given
The Java VM is like a virtual processor --- it lets you run an ordinary
program that's written in Java bytecode.

The Smalltalk VM is like a machine emulator --- it runs a complete Smalltalk
_system_ , complete with its own screen, GUI, multiple processes and
concurrent programs, IDE, debugger, editor, etc, all mixed together. This
typically all runs inside a single window, with its own windowing system.

It's a hangover from the days when Smalltalk would run on the bare metal of a
computer --- it was the entire operating system.

~~~
igouy
You seem to have confused the Smalltalk VM with the Smalltalk image.

Most Smalltalk implementations have 4 pieces:

\- VM like the JVM

\- sources file

\- changes file

\- image file

No it does not _" typically all run inside a single window, with its own
windowing system"_.

------
dxedxaede
How to determine the aliveness/deadness of a language:

1\. Work out what you want to build, and functionalities that you would
require. 2\. Do a search for libraries in language X. If success, go to 3 else
it is dead for you - look at another language. 3\. Look for adequate
documentation and an active, helpful community. If success, go to 4 else it is
dead for you - look at another language. 4\. Try building a quick and simple
application. If you found it enjoyable and offers something other tools you
already know don't, go to 5 else it is dead for you - look at another
language. 5\. Build something more substantial. If you still find it
enjoyable, go to 6 else it is dead for you - look at another language. 6\.
Congratulate yourself that you have discovered an enjoyable and useful tool.
And that you took the time and effort to explore the language yourself and
made an informed decision, and not just read someone's opinion and went with
it. You may also start to suspect most opinions are from people who never
actually used the language for anything more that what you just did, or
inherited a dreadful codebase.

I did all this and I found myself using Pharo about three years ago. I still
am, and I enjoy it tremendously. Also, (Pharo) Smalltalk is the most alive
language I have ever used.

~~~
claystu
What have you built with Pharo? (Genuine question...)

~~~
dxedxaede
Libraries to access Pin (pin.net.au), Stripe (not yet complete), Twilio
(almost complete). My own bindings to SQLite. Libraries to write Latex files.
Currently writing web server proxies for accessing Australian government
mandated web services. None are yet released, but I am aiming to make a
commercial service out of them so they may never be open sourced.

~~~
ZacDavies
Pin employee here, if you've built something that supports us we'd love to add
it to our integrations page.

------
xrange
So I was interested when someone noted that apparently Pharo/Squeak stumble
when it comes to unicode:

[https://www.reddit.com/r/programming/comments/3ha1gu/why_are...](https://www.reddit.com/r/programming/comments/3ha1gu/why_arent_people_using_smalltalk/cu5pf24)

...it seems like that could potentially lead people to be skeptical about an
environment/language that is touted as being highly productive, with automated
refactoring ease, unit testing, test driven development, and turtles-all-the-
way-down, etc.

------
skywhopper
I really enjoyed learning and toying around with Smalltalk and Scheme. What
killed it for me was that for all the fun abstractions, they were so isolated
in their own environment and disconnected from the operating system that it
was not apparent how you would use them for anything real. Processing files,
connecting to databases and other network resources, and interacting with the
user are core practical services that need to be front and center to get new
users to connect to your language, but if those elements are ghettoized into
awkward libraries that don't work as elegantly as the abstract parts of the
language then you aren't going to get traction, except for very specialized
purposes.

------
mmagin
It always seems like languages that typically are used in an all-encompassing
environment are at a disadvantage when it comes to widespread adoption
compared to languages that anyone can just start using in their existing OS,
with their existing GUI, editor, etc.

~~~
DonaldFisk
Visual C++? Or Visual Basic?

~~~
goldfire
Are you suggesting those as counterexamples? Neither one is an example of an
"all-encompassing environment."

"Visual C++" no longer exists, it's just part of Visual Studio now. When it
did exist, it was merely an IDE for regular C++, not any kind of separate
environment.

Visual Basic was a package including a GUI toolkit, a programming language,
and an IDE for developing ordinary Windows applications. These tools were
deployed and used as ordinary Windows applications. There was no separate
computing environment with its own windowing system, data storage mechanisms,
UI conventions, etc. And the current Visual Basic .NET isn't even that
anymore; it's just another .NET language now, where you can swap out the IDE
or GUI framework for whatever is available (including none at all if you like,
you don't need either one to have a useful VB.NET program).

------
acqq
> Not everything has to have a visual metaphor. This is again a case of
> pushing some idealistic principle too far, in my opinion.

True.

But, for example, GNU Smalltalk doesn't need GUI?

[https://www.gnu.org/software/smalltalk/manual/html_node/Tuto...](https://www.gnu.org/software/smalltalk/manual/html_node/Tutorial.html)

One maintained Smalltalk implementation with GUI that can be tried:

[http://squeak.org/](http://squeak.org/)

"Squeak is an open-source Smalltalk programming system with fast execution
environments for all major platforms. It features the Morphic framework, which
promotes low effort graphical, interactive application development and
maintenance."

For other opinions about the death of Smalltalk, there was a link to c2
resources called WhyIsSmalltalkDead on the HN just 4 days ago:

[https://news.ycombinator.com/item?id=10071681](https://news.ycombinator.com/item?id=10071681)

What I certainly agree is that the successful language has to be able to
interact with as much as possible on the host system, as efficient and as
flexible. Note that we still use Fortran code, for example, for numeric
libraries

[https://en.wikipedia.org/wiki/LAPACK](https://en.wikipedia.org/wiki/LAPACK)

and that C easily links and calls Fortran routines.

~~~
detaro
You can run squeak in the browser:
[http://bertfreudenberg.github.io/SqueakJS/](http://bertfreudenberg.github.io/SqueakJS/)

Another one is [http://pharo.org/](http://pharo.org/) (haven't tried it)

But I've worked with Squeak quite a bit in university, and the consensus
generally was: The language is really nice, and a joy to use for many things.
The environment is awful and makes working with it a pain, and since
everything is integrated so closely there are no obvious ways around that.

------
WalterGR
Also see

Why is Smalltalk Dead?

[https://news.ycombinator.com/item?id=10071681](https://news.ycombinator.com/item?id=10071681)

87 points 5 days ago 61 comments
([http://c2.com/cgi/wiki?WhyIsSmalltalkDead](http://c2.com/cgi/wiki?WhyIsSmalltalkDead))

------
DonaldFisk
Smalltalk is no more visual or tied to GUIs than C++ is. There's at least one
variant, GNU Smalltalk, which doesn't have an IDE. Squeak is a rather nice
IDE, though, and makes a good point in the way it blurs the boundary between
programming language and operating system. We've had Lisp Machines; I think a
Smalltalk machine would be cool.

You can visualize the space of programming languages as having local maxima
where, if you modify the language in any way, you make it worse. I think
Smalltalk occupies one such local maximum, Prolog another. Others are less
clear-cut.

Of course, being good doesn't equate with being popular. Java is a Smalltalk-C
hybrid and is very popular. It aimed very well at the average programmer, and
hit its target.

~~~
lispm
we had Smalltalk machines. The same hardware which ran Xerox' Lisp Machine OS
also ran Smalltalk. The processor microcode was different and it booted into
Smalltalk on the metal.

------
ljw1001
Smalltalk's death had almost nothing to do with the language itself. It died
for four reasons:

#1 was price, and especially requiring companies to pay royalties on the
software they write with your tools,

#2 was the epic mismanagement at ParcPlace/Digitalk (including the merger of
the two),

#3 is that Smalltalk was (when the web took off) pretty damn bad for writing
server-side Web applications, because of the threading model and blocking IO,
and

#4 concerns about security: the lack of high quality libraries for things like
encryption, for one thing, and more fundamentally, the way you can do
_anything_ once you're in the VM.)

The last one is the only one that's related to the tech itself. If IBM had
open-sourced VisualAge when they decided to dump it, it would probably be
fairly popular now.

------
brudgers
The premise that Smalltalk was driven by idealism over pragmatics is suspect.
We got GUI's and personal computers and object oriented languages and IDE's
because Smalltalk sliced the envelope with it's cutting edge approach.
Martin's talk was more than 35 years after the first release of
Smalltalk...it's older than C. A discussion about all the problems Uncle Bob
avoids by not using C would be both longer and duller...his talk describes why
he didn't choose Smalltalk when he replaced the pain that C++ inherited from
C...that 20 years after Smalltalk was invented he found a better option funded
by Sun, isn't all that surprising.

------
gmfawcett
The final comments about Scheme seem like a digression from the thesis. Scheme
is almost the antithesis of Smalltalk, in that only an essential core language
is provided.

I suppose she's arguing that "good is somewhere between Smalltalk and Scheme"
but the closing came across as offtopic, as if she were surprised to find that
a language famed for its minimalism was actually minimalist.

------
kachnuv_ocasek
> _Scheme doesn’t include the most basic string routines._

Whoa, really? Racket, arguably the most popular Scheme implementation, seems
to have a nice standard library with tons of implemented SRFIs. Also, it seems
to be gaining popularity (albeit slowly) not only for itself but for Lisps in
general.

~~~
muuh-gnu
> Racket, arguably the most popular Scheme implementation

Umm, NO. Racket isnt a "Scheme implementation". Racket was a Scheme as long as
they called themselves MzScheme. Then they decided that they changed too much
that a complete name change was justified in order to not confuse users.

Racket isnt a "Scheme implementation" for the same reason Scheme isnt a "Lisp
implementation".

~~~
elibarzilay
From [http://racket-lang.org/new-name.html](http://racket-lang.org/new-
name.html) \-- "Racket is a Scheme". The name change was about very different
things than "basic scheme routines", and it would be hard to find any basic
scheme implementation without any.

------
sebastianconcpt
I don't like the culture of killing things and saying that things are dead
when they still have individuals extracting value from it. I also don't find
particularly strong or appealing, the Tyranny of the Majority friendly
Argumentum Ad Populum nor the Keynesian Beauty Contests as drivers for design
language (actually for nothing in life and not only language design).

On the other hand, I do find interesting that the User Experience gets used on
language and frameworks and tooling design.

While Smalltalk never really rocked it at UI and UX, it was good enough to
inspire Steve Jobs to do the GUI of a system right (in terms of UX) on the
mackintosh.

Regardless of comunity size, I still want to see what's the next thing that
will create such degree of positive influence in these days and for the next
decadeds.

Good luck

------
_ph_
While the article raises a few good points, I got distracted by the statements
about Scheme at the end of the article. Yes r5rs might be overly minimal, but
all real-world scheme implementations contain the usual basic tool functions
like string parsing. The performance quoted of a minute for parsing a megabyte
sized file can only mean two things: either a defunct scheme was used or the
program used contained major flaws - this can happen if you are new to a
language, but this is not a useful measure of the language. Even garden-
variety byte code interpreters should do this in seconds.

~~~
xrange
My favorite scheme antecdote:

[http://philip.greenspun.com/bboard/q-and-a-fetch-
msg?msg_id=...](http://philip.greenspun.com/bboard/q-and-a-fetch-
msg?msg_id=0006XQ)

------
peter303
Although Smalltalk was early computer language from the 1970s, it could not
run efficiently on most computers until the 32bit CPUs came along in the
1990s. By then the simple C language and it's OOP hybrids dominated the coding
world.

Smalltalk came on the scene before computer operating systems were well
developed as we know them now. Hence Smalltalk did a little bit of everything-
code, GUI, OS, IDE. This an advantage in providing an unified API to all these
services. However all these services are not as well developed inside
Smalltalk as in the layered systems we have now.

~~~
rjsw
The Apple Macintosh was released in 1984, Smalltalk ran on it fairly soon
after this. The problem was that it wasn't available to the general public,
only to universities.

~~~
igouy
Apparently $150 to businesses.

"Apple Team Developing Maclike Smalltalk"

[https://books.google.com/books?id=Dj8EAAAAMBAJ&pg=PA28&lpg=P...](https://books.google.com/books?id=Dj8EAAAAMBAJ&pg=PA28&lpg=PA28&dq=digitalk+v/mac&source=bl&ots=Bn3PgQSKCY&sig=lInMZS7XOC7cwGNfB7Cnjigluik&hl=en&sa=X&ved=0CDAQ6AEwA2oVChMIpMHs_JK9xwIViy6ICh2NVgtq#v=onepage&q=digitalk%20v%2Fmac&f=false)

~~~
rjsw
Ok. My memory of it was from a bit earlier, I first saw it sometime in 1986.
You would have had to add the cost of APDA membership to the $150 stated in
your link. I found an OOPSLA conference report that described seeing a demo of
the Apple Smalltalk+MacApp product.

I also found a flyer for Smalltalk-80 on the IBM AT for $1000 from around the
same date.

~~~
igouy
I very much doubt that Smalltalk-80 was fun to use on a lowly PC-AT ;-)

This was -- USD 199.95 Smalltalk/V286 March 7, 1988.

[https://books.google.com/books?id=CD8EAAAAMBAJ&pg=PA25&lpg=P...](https://books.google.com/books?id=CD8EAAAAMBAJ&pg=PA25&lpg=PA25&dq=digitalk+smalltalk+v/286&source=bl&ots=jg-
JNM2df5&sig=zCZ6zSeRV1zcLMT_VhaK49_YWkQ&hl=en&sa=X&ved=0CFIQ6AEwB2oVChMIh-
Xi5qS9xwIVkCWICh1taQpK#v=onepage&q=digitalk%20smalltalk%20v%2F286&f=false)

~~~
rjsw
Smalltalk/V (not 286) was perfectly usable on a PC of the day, I ran it on an
Olivetti M24 with a paper white display.

The Smalltalk-80 flyer states that an 8MHz 286 was faster than a Xerox Dolphin
and 20% of the speed of a Xerox Dorado. The painful part would have been the
display, they were just using EGA (640x350) so you couldn't see much at one
time. I saw a demo of this and don't remember thinking that it was too slow.

~~~
igouy
Back-in-the-day I did not consider Smalltalk/V usable, that changed with V286
:-)

------
ch4s3
Wow that Robert Martin talk has not aged well. I couldn't imagine that being a
talk at Rails Conf now. Good info, but it feels a bit off 6 years later.

~~~
billsix
What changed in the subsequent 6 years?

------
WaxProlix
> For instance, Smalltalk had the ability to suspend running programs into a
> saved image, and resume execution later at the saved point.

I'm curious - is this just a continuation? Or is it baked into the language,
like exception handling or something? Any smalltalkers want to expound or link
to relevant docs/tutorials?

~~~
cwp
Yes, it is a continuation, although it's more comprehensive than call/cc. When
you save a Smalltalk image it serializes not only the call stack but the
entire heap. It's rather like a core dump that can resume executing.

It's typically implemented in the VM as a primitive function kind of like
posix fork(). When it returns, the entire state of the program has been saved
to disk. The return value is a boolean, which tells you if you're returning
from the original call, or resuming from the saved image.

Classical Smalltalk dialects didn't have continuations as a flow control
construct, but they did have reified stack frames, so it was possible to
implement Scheme-style continuations in a few lines of code.

------
amiramir
I programed in Smalltalk-80 from 1990-1995. I used it at Morgan Stanley to
build a derivative trading system that was distributed between London and NYC.
It was running on networed Sun Sparcstations. Traders would collaborate on the
same trading "book" across different machines. One of the big battles of
getting the system installed was persuading traders to make room and to use a
mouse to control the system.

St-80 was a great system and by way my favorite programming experience. I
remember visiting Jim Gosling to hear about Oak (which subsequently became
Java) and thinking that it was neat but a pale imitation of Smalltalk.

What "killed" Smalltak were a thousand cuts. A huge problem was the fact that
hardware in those days was slow. Our production machines had a 25 Megahertz
processor which had problems with the interpreted language that was also
painting a GUI.

For a long time St-80 would just take 100% of the puny cpu even when there was
nothing going on. Eventually there was 4-line event driven patch that cleared
that up but that did not help when the program actually did some work.

For finance double-dispatch arithmetic made things worse since even a simple
addition would result in a bunch of message sending that was cute and pure but
slow.

The monolithic image was an issue too since shipping and delivering production
code was hard. There were source control system but ultimately the image was a
hug blob that had to be shipped around. Another issue was the windowing
system. Smalltalk was its own universe and basically grew out of being the
whole environment for a machine (e.g. Xerox Star).

There were no namespaces so it was hard to segments certain kinds of code and
you'd end up fiddling with the innards of St which may have unintended
consequences.

It did not integrate with the window managers of the day (e.g. Motif) and
could not use native widgets so we had to try to style our widgets to look
like the window manager.

I think the folks at ParcPlace were great inventors and engineers (Peter
Deutsch is a god) but they were not fast enough to respond to the pressures of
the market.

I wonder what would happen if Gigahertz machines were avaible for Smalltalk
and if ParcPlace had managed to make their system have a decent package
manager and to call native widgets.

It was also hard to find engineers since C/C++ was there flavor de jour. At
Morgan Stanley there was also APL/A+/J but ultimately Java took the world over
and now then Javascript which started off as an interpreted language with a
lot less that St-80 but some times timing is everything. Moore's law helps
too.

With all that said St-80 is still the gold standard of my programming life
which included other fun systems such as Interlisp-D and NextStep.

~~~
igouy
>>For finance double-dispatch arithmetic made things worse since even a simple
addition would result in a bunch of message sending that was cute and pure but
slow.<<

Why would there be double-dispatch of 2 + 4 ?

Why would that require numeric coercion ?

------
d0m
My personal opinion is what killed most very good languages is the "elite" and
"math" aspect of them.

By elite I mean people who thought they were so much superior to everyone else
(And they were!), that they'd left the beginners and inexperienced programmers
out of the discussions and decisions. But guess what, high level people who
make decisions aren't always the best programmers, so C++ won because they had
better sales people and were more beginners and sales friendly.

By "Math", I mean that most functional books and tutorials used to only focus
on physics or maths aspect of the language, or AI.. whereas the languages who
seemed to have won the war (Think Perl, PHP at the time, or Python/Ruby) were
much more practical in how the language can be used to solve day-to-day
pragmatic problems.

I think it's changing.. and it's really nice to see amazing concepts from LISP
in the mainstream/hipsters languages..

~~~
coldtea
> _so C++ won because they had better sales people and were more beginners and
> sales friendly._

Actually C++ is far worse for beginners than Smalltalk (which is casually used
as a teaching language to kids, as Squeek etc).

The comment about "math" and "elite" show no familiarity with Smalltalk or the
environment back then.

What you say might be true for Haskell, or even CL, but it doesn't have
anything to do with Smalltalk.

------
wangii
Languages thrive or die. The successful ones are those enable(d) less capable
people at the time to do fashionable works as good as, or even better than the
professionals. It has nothing to do with anything other than marketing
strategy: find a under served market segment and empower idiots to do
mediocre+ works with little efforts. In order to achieve so, language
designers have to break old paradigms, simply because if they don't, the less
capable people at the time just don't understand, nor capable of (otherwise,
they would be professionals).

~~~
59nadir
> The successful ones are those enable(d) less capable people at the time to
> do fashionable works as good as, or even better than the professionals. It
> has nothing to do with anything other than marketing strategy: find a under
> served market segment and empower idiots to do mediocre+ works with little
> efforts. In order to achieve so, language designers have to break old
> paradigms, simply because if they don't, the less capable people at the time
> just don't understand, nor capable of (otherwise, they would be
> professionals).

Most of the (most) popular languages aren't revolutionary and they're also
weak in terms of level of abstraction.

Reading your comment, one would assume that Lisp, batteries included-Schemes,
Python, Ruby, Perl, Haskell, etc. are topping the charts. In reality, though,
people are mostly using Java, C, C++, C# and yes... Python is very popular.
It's outrun completely by languages that require far more work to do less,
however.

I don't know if I'm misreading your comment, but the above seems to stand in
contrast to your point. The most popular languages are the ones with a lower
level of abstraction, less expressive power and that require a programmer to
write/manage more to do less, meaning they make more effort for these
'mediocre+' results.

A point can be made that you think less while using these languages, but what
time you don't spend on thinking is spent on writing (and then debugging) and
I guess this is the 'less capable' part of your post, but this doesn't cover
the fact that the languages that've enabled people to leapfrog business
professionals (think Ruby + Rails being used to leapfrog professionals in web
development) have almost nothing in common with the top list of used
programming languages.

The most used programming languages remain and have pretty much always been
languages that use C syntax and don't actually push the envelope too much.
Some rankings will have PHP and JS up there with the rest of them, but these
fall neatly into the fold and are about as 'lame' as the rest of the top (with
JS trying to walk lately).

------
area51org
_don’t perform very well (see CPython, Ruby)_

Sigh. I really wish that smart people would stop spreading myths. Ruby, at
least, performs quite well. The "Ruby is slow" days are years behind us.

~~~
matthewmacleod
I'm like the biggest Ruby fan out there, but c'mon – that's just not true!

Ruby is great at many things, and it has adequate performance for many
situations -'Fast Enough', as DHH said. And with liberal use of C extensions,
I've used it in some high-performance scenarios where the expressiveness was
more beneficial than the complexity of using extensions.

But it's really not fast – up to 100x slower than Java
([http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...](http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=yarv&lang2=java))
or 30x slower than Javascript on V8
([http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...](http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=yarv&lang2=v8)).
I know these are micro benchmarks, but they're useful for comparison.

Some of this is down to the nature of the Ruby interpreter and will improve
with time (and with implementations like JRuby). Some of it is down to the
highly dynamic nature of the language. The point remains though – if you need
high performance for a particular task, Ruby may not be the best option.

~~~
cuillevel3
Ruby isn't that much slower than other slow languages. But compared to the
fast ones it is really really slow.

~~~
igouy
There's a chart for that --

[http://benchmarksgame.alioth.debian.org/u64/which-
programs-a...](http://benchmarksgame.alioth.debian.org/u64/which-programs-are-
fastest.html)

\-- but the question is always _really really slow to do what exactly?_

