
Where Smalltalk Went Wrong (2004) - pmoriarty
http://www.ianbicking.org/where-smalltalk-went-wrong.html
======
Smalltalking
"In fact, I'd say the image is perhaps the biggest problem with Smalltalk."

There need not be a single image. You can save and load as many images as you
like. In fact, you can have thousands or hundreds of thousands of images if
you prefer. You may think I'm being uncharitable to the author by construing
his words as I did, but it's entirely appropriate given the tendency of those
ignorant of Smalltalk (like him) to speak and act as if there is some
monolithic, fragile image that everyone on a project shares and each must
strive to avoid breaking.

The Smalltalk image may seem unfamiliar or even scary at first, but it's
really little different from a standard Ruby or Python process, except that it
is serializable and contains all of the code (both compiled and in source
form), data, and execution state as objects that you can manipulate.

Further, every Smalltalk (that I know of) supports saving and loading source
code to text files and often some form of package management and source
control as well. Many Smalltalk also integrate with file-based tools quite
well. For example, you can use git with Pharo, and many Pharo developers use
Github exclusively for their development.

People citing the image as a reason for not using Smalltalk clearly don't know
Smalltalk. They're also likely hypocrites, because at some point or another
they've no doubt asked themselves why, after so many years, are programmers
still programming by the mere editing of dumb text files? Well, in part
because of your hostility to any system that isn't the mere editing of dumb
text files.

~~~
krapp
> why, after so many years, are programmers still programming by the mere
> editing of dumb text files?

Well, there's nothing wrong with text per se. Text is easy, it's simple, it's
persistent and platform-agnostic. Text based source code is portable, because
it's human readable. You could print it on paper or write it on a napkin if
you wanted. Alternatives have the potential of locking programming, and
programming knowledge, into some company's particular black box.

~~~
pjmlp
> Text is easy, it's simple, it's persistent and platform-agnostic.

You never moved away from cozy 7 bit ASCII in one single human language, I
imagine.

~~~
krapp
You would be correct, in that I have never seen source code written in Unicode
in multiple languages.

However, i'm trying to make an argument that text is fundamentally more free
than the alternatives. When I say "simple, persistent, and platform-agnostic"
I mean, literally, you don't even need a computer to deal with it, much less
an IDE. Source code is a means of communication between people, as well as
between people and a machine. Imagine how restricted the development of the
early web would have been if you _couldn 't_ just bang together some html and
javascript and put it on a server?

~~~
pjmlp
I don't need to imagine it.

Just went through the wonderful world of codepages, codemaps, ASCII 7 and 8
bit, EBCDIC and many other formats.

Text formats on mainframes, mini-computers, home micros and many other
hardware and OSes.

Text, easy?!? No it ain't.

------
fractallyte
Smalltalk is (literally) a window on an alternative computer architecture and
OS/language paradigm. There's a reason it runs on a 'virtual machine'! It's
the path that computing _could_ once have taken, the equivalent of a parallel
universe: What if computers had gone with _this_ different design; what if the
language and underlying operating system were one-and-the-same... (There was
even a initial attempt at object-oriented hardware:
[http://en.wikipedia.org/wiki/Rekursiv](http://en.wikipedia.org/wiki/Rekursiv))

Of course, Lisp is the other example of an alternative computing ecosystem:
the famous Lisp Machines, with Lispy turtles all the way down; and Interlisp,
that came closest to Smalltalk's emulation of a physical machine.

Modern Smalltalk is the environment that would have emerged from this kind of
platform. That it includes modern tooling and inter-operability (however
limited) is a huge bonus - it represents a genuine effort to coexist with the
mainstream.

That there's so much criticism of its 'image' and language syntax only drives
home the absolute grip on our thinking that Algol languages and Von Neumann
architectures have imposed. In my mind, that makes it an environment of
inestimable value.

Ecological diversity is more than good; it's _essential_.

~~~
pjmlp
There was a third window that many people tend to forget.

Mesa/Cedar, a interactive environment first done in Mesa, the Modula-2
predecessor and later on improved as Cedar, which was a system programing
language with GC!

It was a working environment similar to Interlisp-D and Smalltalk, but using
dynamic libraries, an interactive debugger, REPL and lots of nice goodies for
an Algol like language. Back when at AT&T green phosphor terminals were being
used.

Mesa was the inspiration for Lilith operating system done in Modula-2.

Similarly Cedar was the inspiration for Oberon and its derivatives.

Using Oberon felt to certain extent like Smalltalk, in a strong typed system
programming language with a GC.

But Oberon based systems had the bad luck to appear at the same time the world
was paying attention to Java and rise of VMs. So just like Plan9, only a few
of us enjoyed using such environments.

------
vezzy-fnord
_It 's not just that the syntax looks weird to people -- though that doesn't
help -- but it also looks weird to other programming languages._

Not sure if it's any consolation, but Smalltalk was the first non-ALGOL
language that I really "got", and remarkably quickly. The saying that
Smalltalk syntax fits on a postcard is no joke, see:
[http://c2.com/cgi/wiki?SmalltalkSyntaxInaPostcard](http://c2.com/cgi/wiki?SmalltalkSyntaxInaPostcard)

The hardest part is wrestling with the class libraries and getting used to the
hermit kingdom that is the image-based environment, though the community
behind Pharo and other modern Smalltalk environments have done some
interesting advances when it comes to bridging the gap, such as the Monticello
VCS for snapshotting code state to a regular file system in the form of an
archive.

That said, I haven't used Smalltalk all too extensively.

~~~
smosher_
I don't find Smalltalk's syntax bad per se, but I think there's too much of
it. When I see it, my eyes glaze over. Not because I don't understand the
concepts behind what is being represented, but because I have a hard time
getting a handle on the shape of things.

It's a matter of familiarity, and while I've spent some time looking at the
object model I haven't written a lot of code in it. So perhaps that complaint
is only really valid for newcomers. On the other hand, I still think it's a
bit convoluted since a language like Io can express much the same stuff with
less. The postcard version is something like:

    
    
        Object setSlot("foo", 12);
    

That demonstrates the entire informal BNF description at
[http://iolanguage.org/scm/io/docs/IoGuide.html#Syntax-
Expres...](http://iolanguage.org/scm/io/docs/IoGuide.html#Syntax-Expressions)

That doesn't account for [] and {} being translated to messages (with their
contents as arguments) or for the infix operator stuff (sends the operator
message—eg. +, xyzzy, etc.—to LHS with RHS as the argument) which also has
precedence. Aside from that there's nothing much going on. Everything except
infix operators always look like like regular message sends unless you're
using a DSL. I think that's shat Smalltalk ought to look like, since that's
what it's trying to be about.

Edit: Before anyone gets the wrong idea, I don't mean Smalltalk should look
like Io, but that it should have little more shape than looking like message
sends.

~~~
protomyth
and Smalltalk would be:

    
    
      Object setSlot:"foo" to:12.
    

I have always liked Smalltalk's (via Objective-C) message syntax as it put the
meaning of the function call slots where I am calling them. I hate what
they've done in Swift however.

I have toyed with a scripting language that had:

    
    
      Object.[setSlot:"foo" to:12]
    

Still not sure on that. I immensely respect the creator of Io but it didn't
click with me (my fault, not the language).

~~~
smosher_
I think you misunderstand. The Smalltalk is this:

    
    
        exampleWithNumber: x
        "[ *wall-of-text elided* ]"
        | y |
        true & false not & (nil isNil) ifFalse: [self halt].
        y := self size + super size.
        #($a #a "a" 1 1.0)
            do: [ :each |
                Transcript show: (each class name);
                           show: ' '].
        ^x < y
    

I'm talking about an Io equivalent of the "Syntax In a Postcard" link provided
above, partly reproduced here for convenience. What the code does isn't so
important as how much of the syntax it covers.

~~~
protomyth
Oh, sorry, yes, I got your meaning totally wrong.

------
protomyth
It was my understanding that GNU Smalltalk
[http://smalltalk.gnu.org](http://smalltalk.gnu.org) is text file and not
image based.

~~~
pjmlp
Using GNU Smalltalk doesn't do any justice to what means to use a Smalltalk
environment.

~~~
protomyth
True, too true, but it does ease people into the language and proves the
language is not defined by the implementation. This is important since most of
the discussion in this thread is based on the common implementation and not
the language.

~~~
pjmlp
Usually I am the first to push for comments "Language != Implementation",
however the whole Smalltalk experience only makes sense in the official
implementation of the IDE married with the language and OS.

Using an implementation like GNU Smalltalk, while valid in terms of language
implementation, leaves out the whole development experience back to the stone
age of UNIX tools.

Exactly the development experience of environments inspired by Smalltalk is
what made me always favor IDEs over vim, emacs + CLI.

~~~
protomyth
and usually I will defend the different environments, but I have to disagree
with you here. Smalltalk environments try to build their own everything.
Squeak and Visual Works do not use native widgets, heck Squeak is a horrible
UI. Both have editors that are inferior to current text editors. They have
cool attributes, but there rejection of every part of the OS is problematic.

------
tlack
I think the situation is way simpler than the author contends.

Smalltalk simply has poor workflow from the programmers perspective, compared
to what he's used to.

It may be awesome. But no one will ever know, because it's too different from
the normal developer's work flow to easily gain adoption, even if the benefits
are substantial.

Could something like Smalltalk work in such a way that the "image" is a series
of files and folders, so if something goes nuts we can do what we always do
and poke around in the data?

Could automatic code reloading and online introspection be applied through a
more traditional client (debugger) - server (running process) setup?

Something like that may have a better chance. This machine ain't got time to
slow down and make repairs.

~~~
CookWithMe
> Could something like Smalltalk work in such a way that the "image" is a
> series of files and folders, so if something goes nuts we can do what we
> always do and poke around in the data?

Well, speaking for Squeak: The image is just a file. You can open it and poke
around in it.

I don't recall why I had to do it exactly (did some meta-programming with
Smalltalk at university... maybe my program overwrote some fundamental
functions in Object or similar), but I don't remember it to be terribly
complicated.

Definitely not as simple as opening a JSON file, but not as hard as decrypting
the assembly of a compiled C-program or analyzing the memory of a crashed
program.

~~~
lumpypua
> maybe my program overwrote some fundamental functions in Object or similar

This is why I don't use smalltalk.

~~~
mietek
Do you use JavaScript?

~~~
lumpypua
Unfortunately.

------
sebastianconcpt
People loves spanking Smalltalk :)

I think that's good because it shows (a) is really different so is a direct
hit to the Comfort Zone on many and (b) its significative value is real,
otherwise it wouldn't annoy them to the point of talking about it.

It seems that a source of anger for some people is that Smalltalk is good
enough to get mainstream but it didn't reached really mainstream. Probably due
to the strategic mistake of not making it open source right from the start in
the 80's. This interview puts some light into what happened, who influenced
that decision and why was made:
[https://www.youtube.com/watch?v=IGNiH85PLVg](https://www.youtube.com/watch?v=IGNiH85PLVg)

If Smalltalk would have been open sourced in 1980 the world would be
different: programming would be more humane and less technologically-self-
serving.

Now we have the "pleasure" of listening people that tells you "the compiler is
your friend"

No it's not. Smalltalk rewards the creative spirit. Compilers hits it with a
hammer. That's why it's so different (Ref:
[http://www.cs.virginia.edu/~cs655/readings/smalltalk.html](http://www.cs.virginia.edu/~cs655/readings/smalltalk.html))

1984 here we go. (Ref:
[https://vimeo.com/115154289](https://vimeo.com/115154289))

~~~
horrido
This is exactly right. People are so invested in what they've learned that
they are reluctant to give it up and try something new and different. Humans
are creatures of habit.

For some reason, this has never afflicted me. I've used many languages and
environments in my time (eg, FORTRAN, Tandem TAL, C/C++/C#/Objective-C, Java,
Python, Go, and Smalltalk), and I've treated each and every one of them as a
fun opportunity to play and learn. This is my intellectual playground and
those languages are my toys! Smalltalk was completely different from
everything else I had used over 20+ years, and it still didn't phase me. Go
figure.

Today, I continue to have a warm place in my heart for Smalltalk.

------
horrido
I find this resistance to the Smalltalk environment a bit puzzling. It's
really fundamentally no different from modern IDEs and virtual machine
runtimes such as JVM. The key differentiator is the fact that every object in
the Smalltalk environment is "live" and can be examined and altered at will.
One of the great benefits from this fallout is the powerful debugger.

Rather than whining about how Smalltalk doesn't play well with existing file-
based tooling, we should focus on improving and extending the tooling for the
Smalltalk environment. We have an opportunity here to define the __future __.
Smalltalk is a break from the traditional way of doing things (the use of
files and folders is positively antediluvian!). It 's truly innovative.

The transition may incur some cost and pain now, but positive change is never
free. If you argue we should wait for a more opportune time, the question is,
"If not now, then when?" What exactly are we waiting for?

If you argue we should never change, files and folders are perfect forever and
ever, then I say we are stuck in a rut. Software engineering is off the rails.

~~~
horrido
Also, people bitch about not being able to use their favourite editors. I've
never understood this, either. In my 20+ years in IT, I've never been wedded
to any particular editor. And the way source is organized and presented in the
Smalltalk environment (via the class browser), I've never needed the power of
emacs or Eclipse or Sublime Text. Super-editors are for file-based software
development. In Smalltalk, they're rather unnecessary.

------
Tomte
I think there is really something that makes people prefer files over some
database, even though the latter has undeniable advantages.

Do you remember IBM's VisualAge for C++? It had a clear Smalltalk pedigree
(there was a VisualAge for Smalltalk first, and I think the IDE was written in
ST, but I could misremember that point).

And a "translation unit" was not a file, like in every other C++ compiler. All
translation units were entries in an internal database. And you couldn't find
the header files with a file manager search.

Some people liked it. A lot. But in the end IBM reverted to the common
approach.

~~~
pjmlp
Eclipse was Visual Age for Smalltalk reborn.

I miss Visual Age for C++.

Personally I think the biggest problem was the hardware requirements. If
memory doesn't fail me, it already required 8 MB when most PCs were still
being shipped with 4 MB.

Also I think the version to go for was the OS/2 one, which didn't help as
well.

Vague memories now, so I don't recall how it really was.

~~~
dsbw
You are correct:

VAST was in Smalltalk. VAC++ was ALSO in Smalltalk. And the first VAJAVA? Also
Smalltalk. They ultimately rewrote it in Java and it became Eclipse.

It required 8MB to be useful but 16MB (or more, which was unheard of) was
preferable.

------
weddpros
I'm not sure the image paradigm would be much of a problem today.

Virtualization is common today, Docker is very trendy, and many such tools
rely on the concept of images. Smalltalk images are similar to VM snapshots,
and not very different to Docker images.

I think the Image was one of Smalltalk's best ideas.

I used Parkplace, VisualAge and Cincom professionally, and I think the real
problem has always been the cost: Smalltalk tools were expensive, Java tools
were free.

------
bencoman2
* Being image based has traditionally been a problem for many, except now that VMWare and Xen allow you to pause your running Image, move it somewhere else and restart it running from the snapshot point, you now have for an operating system what Smalltalk has always had at an application level.

* One traditional problem with a Smalltalk Image is that it can be hard to reproduce - to get from scratch to where it has evolved to. Pharo is working hard to make a reproducible bootstrap that builds up from scratch using CI infrastructure.

* Squeak and Pharo are strong and responsive open source communities. In [pharo-dev] maillist you often see people report a problem and its fixed the next day.

* Traditional interpretive performance issues are mitigated by Cog's JIT compiler.

A good discussion on where Smalltalk went wrong - more commercial than
technical - can be found here...
[http://c2.com/cgi/wiki?WhyIsSmalltalkDead](http://c2.com/cgi/wiki?WhyIsSmalltalkDead)

------
p8092040
Q: Where did Smalltalk go wrong? A: Excessive cost of development tools at a
time when Java was free.

Java was easy for C, C++ and Pacal programmers to migrate to. It had enough
incremental benefits to justify the leap. Most importantly, Java surfaced with
inbuild support for the Internet, just when the Internet rally was building.

If Smalltalk development tools had been less costly, it would have surpassed
Java on every front. And, Smalltalk is such a joy to use.

Smalltalk is a success on the technical front. Current software technologies
are still duplicating the innovations originated in Smalltalk. Docker is the
latest, saving the state of a software solution.

Developer productivity is where Smalltalk really shines. There are many ways
to measure productivity and code quality. Ultimately, total effort per
function point is a useful one. On page 46 of [http://namcookanalytics.com/wp-
content/uploads/2013/07/Funct...](http://namcookanalytics.com/wp-
content/uploads/2013/07/Function-Points-as-a-Universal-Software-
Metric2013.pdf) a table sets out number of months to implement a 1,000
function point program. Here's a few metrics for dynamic and static
languagues:

Smalltalk 21 coding months Ruby 46 C# 51 Python 53 C++ 53 Java 53 PHP 53
JavaScript 71 C 128 Assembly 213

By these measures, Smalltalk projects will be completed in less than half the
time as projects using C#, Java or C++. Javascript centric projects will take
3x, but this is not really an apples to apples comparison.

Where Smalltalk really failed, was on the commercial side. It failed to be
adopted by a critical mass of developers. Smalltalk was used successfully, due
to tool costs, mostly in Fortune 1000 class enterprises. For my small software
company, it was a secret weapon enabling me to outperform competitors. I
didn't sell Smalltalk, I sold "solutions."

------
mark_l_watson
What hurt Smalltalk was very expensive software licenses.

I think that if something like the free Pharo system had been available 20
years ago then history would be different.

A Smalltalk license for my old Lisp Machine would have cost, if I remember
correctly, about $5K

~~~
lispm
Like $150 ($50 educational) for Smalltalk 80 on the Mac around 1985, directly
from Apple?

Which Apple open sourced as Squeak in 1996. Which then was forked into Pharo?

------
galaxyLogic
Here's my thoughts about the demise of Smalltalk, if you will. There are of
course many reasons, and as said by others it's still alive and well with
Pharo.

The first reason may be just that it was too good, too ahead of its time. A
huge programmer population already existed for C and C++ at the time Java with
its C-like syntax came around. In programming languages "incrementalism"
rules, which is easy to understand when considering how big an effort it takes
to become an expert in one.

I think Smalltalk was also a victim of its own success. It promised a huge
increase in productivity and software quality. This caused a business-war
among its few suppliers at the time (Parc Place, Digitalk) and wars are never
good.

And there's a technical reason for that too. Smalltalk is not just a language,
it is an environment with a big library built into it. Even though the class-
hierachy was mostly given by the original Smalltalk-80 there were small
differences between the vendor-provided libraries which made it hard to run a
Smalltalk application written for one Smalltalk virtual machine on another
one. Which made it more important for every Smalltalk vendor to try to tightly
own their users.

Here again ST was a victim of its own "goodness". The class-hierarchy is a
tightly-knit set of classes which allows for maximum of code-reuse, but also
means that it was not easy to combine classes from different platforms. If you
took one class from vendor X it meant that many other classes had to follow
and those could override similarly named classes in the target environment,
which again would break many other things in the target platform and so on.

In other words Smalltalk was not modular enough, it was not easy to combine
classes written on different platforms with each other. Smalltalk is not only
an "island of its own", every Smalltalk is more or less an island of its own.
Then again there's still only talk about bringing modularity to Java. But Java
has the benefit of non-diverged platform. THAT also almost happened, with
"Microsoft Java".

The ability to easily reuse large portions of the Smalltalk platforms is a
huge benefit for productivity, at the same time it hinders co-operation
between programmers working on different Smalltalk platforms.

------
dang
A follow up post is [http://www.ianbicking.org/where-smalltalk-went-
wrong-2.html](http://www.ianbicking.org/where-smalltalk-went-wrong-2.html)
(via
[https://news.ycombinator.com/item?id=8797560](https://news.ycombinator.com/item?id=8797560)).

------
CookWithMe
Back in university, I did an introductory course in Smalltalk/Squeak as well
as three seminars that used Smalltalk, two of which were group projects. (One
chair was heavily invested into Smalltalk)

I won't use Smalltalk/Squeak professionally, and I've come to enjoy functional
programming much more than OO programming (at least for non-UI tasks, which I
generally enjoy more). That said, I do not regret learning and investing time
into Smalltalk [1].

I'm dismissing the syntax-argument, as Obj-C has brought a Smalltalk-like
syntax into the mainstream [2].

The one thing that I REALLY miss about Smalltalk sometimes is the ease of
working with (stored) objects. You basically don't have to do anything. So
much CRUD - just removed. I don't know how much time I wasted debugging or
optimizing Hibernate-stuff in Java, or wrestling with CoreData in iOS.

With Smalltalks image, you just don't have to waste ANY braincycles on storing
your data [3]. If you've created the object in memory, consider it stored. If
you remove the last reference to it, consider it deleted. It's just so much
more natural (for an OO program) than working with an ORM.

However, the image in Squeak was, in fact, the most difficult thing to get
used to. The image contains not only your runtime, it is also your IDE. As an
IDE, it had some good parts (similar to a browser where you can inspect any
HTML-element, you can inspect any (visual) object with a right click), and
after a while I was kinda OK with navigating the (not file-based) code. That
said, it does neither rival a full-blown IDE nor Vim - the IDE always kept
disturbing my flow somehow. And, with limiting your methods to a maximum of 7
lines of code, you're bound to use the IDE a lot.

> It's also hard to isolate a "program" in Smalltalk -- it's all one big heap
> of code, you may have added methods to Object, who knows what.

This hasn't been my experience at all. If you use some sort of versioning (we
used SVN), you'll have to separate your code from your workspace. I don't
remeber it to be any harder than it is in a traditional environment (do a diff
before you check-in to make sure you've cleaned up everything and if your
code/unit tests use any non-code files, make sure to check them in as well).

[1] In fact, I'd recommend anyone who is serious about becoming a good
programmer to learn several (>3) distinctly different programming languages
(i.e. Java and C# are too similar to count). And Smalltalk is really
different, not only syntax-wise but conceptually a lot of stuff will broaden
one's horizon.

[2] Thankfully, it's being replaced by Swift now. I've worked with it in the
last 3 weeks, but I'm more happy to see the C-stuff go and functional
programming concepts arrive than the Smalltalk-stuff removed.

[3] Well, for a certain scale at least... not feasible for Big Data, but
sufficient for your average mobile or desktop app.

------
bencoman2
This is a very good discussion of what went wrong with Smalltalk was more
commercial than technical.
[http://c2.com/cgi/wiki?WhyIsSmalltalkDead](http://c2.com/cgi/wiki?WhyIsSmalltalkDead)

------
dalke
There should likely be a [2004] in the title. Plus, it says "half-baked" and
points to an updated version, also from 10 years ago.

~~~
mkesper
I found this one to be more interesting:
[https://news.ycombinator.com/item?id=6601748](https://news.ycombinator.com/item?id=6601748)

------
wcummings
Serious question, I'm interested in Smalltalk, is it a viable option in 2014?
Does anyone use it professionally? Personally? Open source projects?

~~~
dustingetz
This, and also I am specifically interested in if you can do modern web
development in it, and if playing with smalltalk will result in similar
epiphanies that learning multiple functional languages did.

~~~
jacquesm
It's hard to embed in your regular flow because of the image based nature. If
regular files systems and git(hub) are your thing be prepared for some drastic
adjustments.

Also, it is quite slow. But it is definitely worth a look just for the added
insights into what programming could be like.

~~~
Smalltalking
"If regular files systems and git(hub) are your thing be prepared for some
drastic adjustments."

Not so with Pharo. And "slow" relative to what? Surely not compared with Ruby
or Python, two of HN's darling languages.

