
If Smalltalk Is So Good Why Does Nobody Use It - CapitalistCartr
http://c2.com/cgi/wiki?IfSmalltalkIsSoGoodWhyDoesNobodyUseIt
======
taylodl
I worked on two Smalltalk projects in the early 90's at two different
companies. Both efforts were abandoned for C++. Some of the issues we
encountered at the time:

* Numerical computation was too slow. Numbers used to be objects and all numerical computations followed object messaging. Ouch! This was eventually remediated but not before we'd dropped Smalltalk.

* Garbage collection was S-L-O-W. Your workstation would randomly freeze 30-60 seconds. It was that bad.

* The built-in windowing environment was an albatross in the early days of Windows and OS/2\. Customers wanted a native look-and-feel not the weird (to them) Smalltalk window manager.

* Not everyone had yet bought into object-oriented programming, much less making everything an object. This was really bizarre at the time - even code was an object. Makes sense now, but few people were thinking that way then.

* It was strange. C++ seemed safer since everybody at the time knew and was comfortable with C programming. Little did we know the pitfalls awaiting us when using C++! :)

In the end I think the Smalltalk experience left such a bad taste in
everyone's mouth that when these issues were resolved no one was interested in
going back and giving Smalltalk a second look. Nowadays Smalltalk lives on in
Objective-C. In fact one the shops I was in abandoned Smalltalk for
Objective-C, which is one of the few instances I know of people using
Objective-C outside of the Apple ecosystem.

~~~
davelnewton
The windowing system depended on the flavor of Smalltalk; Smalltalk/V Windows,
which I used circa 1991-1992 used the native GUI. I forget what I was using on
our Unix boxes, but it used X (or possibly Motif, I forget).

------
Tloewald
The question is moot -- Smalltalk isn't so good.

Back in the 90s we were developing sales force automation software in VB3
(ugh!) which was by no means wonderful. Our stuff ran far faster on modest
hardware than similar Smalltalk software running on (by the standards of the
time) ludicrously powerful hardware. Delphi, when it came out, was far, far
better still.

Smalltalk also seems to have accumulated annoying cruft faster than it got
useful. Another large Smalltalk project I was involved in (as a UI designer)
suffered from multiple incompatible class hierarchies. I wanted to make
different controls that did similar things look similar, but it was impossible
because some controls inherited from a 1-bit graphical library and couldn't be
rendered in color, others from a 4-bit graphical library and couldn't be
rendered in 256 colors, and others didn't respond to certain events in certain
ways (e.g. action on mousedown instead of mouseup). It was an absolute
nightmare.

The language may be fine, but the implementations of it were slow and bloated,
and the class libraries were a disaster area. (Of course, the main company
pushing Smalltalk at the time was IBM, which probably says something.)

~~~
agumonkey
Even IBMers didn't really like it. I heard similar stories of complexity over
dynamicism turning into a 'Message Not Understood' fest. Maybe they didn't
really understand the language.

------
jrochkind1
I'd say there are two currently popular languages that are significantly
influenced by Smalltalk: ruby and ObjC.

They are both quite different languages, but both very heavily influenced by
smalltalk.

ObjC is mainly popular because it's the language you have (or until recently
had) to use to write for iOS -- although many developers come to like it for
itself, and it certainly has been succesful at Getting Things Done. (I believe
iOS itself is written in it as well, if not OSX too?)

Ruby had no such vendor lock-in, so the only reason to use it originally was
if you liked it, although at this point the large library of open source
available for it encourages it's use. (Of course people had to like it enough
to write that open source for it, something got the ball rolling and kept it
rolling)

Both ruby and ObjC take different things (with some overlap), but there are
some things that _neither_ takes from Smalltalk. Looking at the things neither
takes from smalltalk (eg the "program as image" that means you can't just use
a text editor to inspect or use effectively in a generic version control
system)... probably suggests some possible answers to why smalltalk hasn't
been more successful.

I am not familiar enough with Smalltalk to be confident in my suspicions, but
comparing to the more popularly succesful languages ruby and ObjC is probably
a fruitful avenue to answer that question.

------
snuxoll
I don't use it because at this point it's alien in the world of modern
computers. Back when Smalltalk was in its prime it wasn't just a programming
language, it was essentially your operating system, complete with its own
graphics system, window manager, etc. This hasn't changed, but instead of
being the basis of your system it's essentially another OS running on top of
whatever your poison of choice is.

I think today the concept of the Smalltalk image and workspace has pretty much
killed it, not the language itself. I use git for version control, I use GNOME
as my desktop environment and IntelliJ as my IDE of choice, trying to do
anything in smalltalk requires I transport myself back to the 90's.

GNU smalltalk is the closest we have to a smalltalk implementation that works
well in modern computing environments, but there's a big lack of interest in
the project.

------
protomyth
I liked Smalltalk and saw it used well and used badly, but I don't think it is
anything about Smalltalk that was the problem. It was the Smalltalk vendors
that mostly screwed it up. Thousands of dollars per seat just wasn't worth it.
It didn't help that some companies regarded it as "secret weapon" and kept its
use hush-hush (I've heard the same thing about APL derivatives, but have no
idea if that is just urban legend).

I figured if someone had built a VB like environment for Windows and priced it
at $99, it would have done well. Closest I saw was Dolphin, but they did the
old "database connection extra" crud. I wonder how many development
environments have died due to that one pricing checkbox.

Smalltalk could be fast. Smalltalk/X was pretty speedy.

(PS - totally ignoring the native platform look and feel was foolish in the
extreme)

~~~
dfox
I'm not sure whether native look and feel is ever important point. At the
moment I cannot think of any enterpise-ish application that does not ignore
native platform look and feel.

And for both Delphi and now .NET, there is significant market for third party
components that look purposefully non-native.

~~~
protomyth
I think the native look and feel is important because the emulated interface
always seem to have flaws and added to the training cost of users. Each new
version of Windows would bring problems for the emulated interfaces where the
tools using the native widgets didn't have the same problem. Worse, something
like Squeak which is basically running a foreign OS in a window with garish
colors.

I know a lot of enterprise apps go off into the weeds, but their success is
driven by external factors. Successful tools really need to appeal to a broad
group of developers.

I really think a native widget version of Smalltalk that included the database
access could have done a fine job, but it always seemed with Smalltalk that
the NIH syndrome was so high and they could build their own things better. Its
like they didn't respect any platform they were running on.

------
killertypo
I worked in a Smalltalk shop, smalltalk is not that great. I've discussed it
at length, my problems with it. As a language it is impressive what they built
at the time. In practice it was a terrible pain in the ass with tons of
"ravioli" code everywhere. The language has no qualms with letting you wreck
havoc within the standard base classes, which makes integrating anothers code
almost impossible.

~~~
killertypo
Oh I do want to add that it is a language behind a paywall as well. Which i
find rather strange. Being charged as a customer to one) use their language
and two) being charged per user we allowed into the environment.

Because Smalltalk is an enclosed runtime (similar to Java, but much worse). We
had to tell them how many users would be using non-developer editions of the
runtime and they charged us for that.

~~~
pjmlp
I don't find that strange, as I remember the days we had to pay for every
single one of our tools, including distribution royalties.

Open source kind of killed this way the industry used to work forcing
companies to find other ways of revenue, except for big corporations that kind
of still work this way.

~~~
killertypo
_cough_ borland _cough_ :) Oh I guess, i just felt it was strange that Cincom
still charges a significant amount of money to run their stuff, per seat and
per server pricing.

When you look at the market of tools today. Historically speaking, they were
par for the course.

~~~
protomyth
There is a big difference in pricing between Borland and Smalltalk vendors. I
remember the Turbo Pascal / Turbo C pricing and how it really made quality
compilers accessible. Smalltalk never had that revolution.

Anytime you need to "call for pricing", you know its going to cost.

------
poulsbohemian
Put simply: because the things that made Smalltalk great are now part of
modern stacks. Dependency management, interactive development tools, object-
browsing IDEs, plus virtual machines improved significantly. Why go back to
Smalltalk when we have all of these things with the language of our choice
today?

~~~
masukomi
Because smalltalk integrates those things together better than any other
language / environment that has them?

~~~
poulsbohemian
Don't get me wrong - I'm thankful that I got to use Smalltalk in my career. It
was incredibly expressive and productive - maybe the most productive I've ever
been. But, time marches on. There are simply more people working today on
python / node / <pick_your_favorite_here> to maintain and improve those tools
plus making it easier to find a <language> programmer over a Smalltalk
programmer.

------
agentultra
I like the idea of it.

I recently tried out Pharo with a simple, achievable goal in any language
worth using these days: fetch a document from a website, parse it, and display
all the href's with titles. It was a very pleasing experience!

I basically evaluated the code I'd expect to use to fire up this application
in a scratch area. Naturally it didn't work. It dropped me into an interactive
debugging session. From there I just started writing and compiling the missing
methods and objects. I kept doing this until my original evaluation just
started working. No recompilations or context switches between editors and
compilers and the like. Best of all I could just close down the image and take
a break. When I booted it back up everything was right where I left it.

If given the opportunity to use it on a project I'd give it a shot. It was one
of the most refreshing computing experiences I've had since I got hooked on
Common Lisp.

------
stevedekorte
Cost. Smalltalk was proprietary and very expensive. Had the Smalltalk houses
made open source free versions and monetized with consulting instead of
software sales, I suspect things would be different.

The technical issues people cite are not so different with the dynamic
languages that were much more successful (Perl, Python, Ruby, Objective-C,
etc).

------
shenoyroopesh
A lot of people point out here Smalltalk is not great. I personally don't know
either ways, because I haven't used it.

However, I do want to point out that adoption and quality need not be
correlated. Haskell, for e.g., was relatively obscure till recently (and even
now I would say very few people use it). But it is absolutely amazing compared
to most mainstream languages.

The article linked makes some excellent points about business and other
considerations and how it influences adoption of any language/tech (other than
the quality itself).

The question itself can be reframed either as "Is Smalltalk good?" or "Why
does noone use Smalltalk?"

~~~
imanaccount247
As a haskell user, I would say that you're overstating how amazing it is. The
language is certainly fantastic, but the tools are so awful that it almost
makes me willing to use go! GHC takes ages to compile code, as well as easily
a couple of GB of RAM. When you're longing for the days of C++ because your
build time was so much faster, something is seriously messed up. Cabal mostly
stinks, ocaml's cabal inspired packager is far better despite being much newer
and having fewer resources invested into it.

The community is borderline insane when it comes to style, so you basically
have to use a huge complicated emacs setup with a bunch of plugins just to be
able to produce code that meets the bizarre style guides without manually
messing with spaces all the time. That last point shouldn't matter since for
your own code you can just pretend it is a normal language, but as soon as you
want to make a change to an open source library you're stuck.

Much of this is similar to smalltalk, where the language itself was good, but
trying to use it would drive you mad.

~~~
dragonwriter
> GHC takes ages to compile code, as well as easily a couple of GB of RAM.
> When you're longing for the days of C++ because your build time was so much
> faster, something is seriously messed up.

IMO, that's only true if what you get out of the compiler provides the same or
less value as what you get out of the compiler for competing options. OTOH,
the whole reason people choose Haskell over other languages is value-add from
Haskell's compilation process. Spending some clock cycles at build time for
that is, IMO, worth it.

~~~
imanaccount247
You are assuming that it is necessary to take many minutes and GBs of RAM to
compile haskell code. There is no reason to believe that is so. Especially
since other haskell compilers are much faster. It is 100% certain that GHC
contains at least one memory leak that has been unaddressed for years. Simply
put, absolutely nobody has put any effort into making GHC fast. Only into
making it produce fast output. Ocaml gives you 90% of the benefits of haskell
with 10% of the compile time (actually faster than that, but close enough).

~~~
dragonwriter
> It is 100% certain that GHC contains at least one memory leak that has been
> unaddressed for years.

That's clearly a problem.

> Simply put, absolutely nobody has put any effort into making GHC fast. Only
> into making it produce fast output.

OTOH, as annoying as it may be to developers, on the assumption that code will
be run more frequently than it will be built, that seems like priorities being
in the right place.

------
andywood
A lot of times people like the idea of a thing more than the thing.

Meanwhile, a lot a people hate on C++, which they're only able to do because
they learned its nuanced spec, which they only did because it had already
reached critical mass in the wild, because it worked everywhere and was,
despite the complaints, comprehensible, if hard to get perfect in the
language-lawyer way.

~~~
jonahx
This argument reduces to saying that anything popular and widely used _is_
actually better than anything unpopular but beloved by language enthusiasts.
This simply isn't the case. Many, many factors beyond merit contribute to
language popularity and usage.

~~~
JoeAltmaier
You have to have a metric for 'better'. If its 'utility' then yes something
popular is better than something unused.

~~~
drivingmenuts
Thus my motto for PHP: It's better than nothing at all. Usually ... FML.

~~~
ww520
Despite its warts PHP does have very valid merits that make it popular.

------
nickik
Maybe Self was the best chance. We all know that java has won, but Self could
have been Java (and thus the success of smalltalk). Maybe my understanding of
this history is imcomplety, if it is please help me out.

Java should never have reached where it is today. Im not hatting on java btw.
Just historiclly speaking, java was a embeded language that was pushed for the
internet. At the same time Sun had the well advanced Self project in
devlopment. One of the major reasons that java was selected was its small
stack based bytecode.

Self was the hotbed of compiler research and could run rings around java. Self
is a small language and you need less lines of code then java. Self would
probebly not have been much heavier on the wire.

So why did the people at sun push Java and not Self? I can not explain it. The
only explaition, is that they just did not know what they have. Anybody has a
better idea, is there something I completly misunderstand?

~~~
ltta
Java probably won because of its C-inspired syntax. At that point smalltalk
was falling behind and C++ started to take off. To me Java was always meant as
a better C++. At least that is my guess.

A lot of the people behind Self went on to work on the JVM JIT and later the
Chrome V8 engine. Self produced many influential ideas in the JIT space like
polymorphic inline caches and deoptimization and stack rewriting. Some of the
papers published by the Self group at UCSB are fascinating.

~~~
nickik
The syntax is something, but they could easly have written another parser for
sell and make it look very C like. That would have been 100x less work.

Many of the people that worked on Self later worked on Strongtalk, that was
bought and is the bases for the current JVM, and yes now everything that was
in Self is in the JVM.

So my point is, why not just start where they ended up anyway. In one of David
Ungars talks he said something like "they probebly just didn't know what they
had". Thats about the only thing that makes sence, but maybe somebody knows
more then me.

------
zamalek
The reason I don't is because it takes its philosophy too seriously. My
absolute top nit-pick with that philosophy is: it doesn't compile to an
.exe/elf.

Using Squeak as an example, it is very-much a virtual __machine __. If I want
to work on a new project, I might have to create a new VM image or something.
It 's like an OS and language boiled into one thing, which simply doesn't
work.

There are more classical approaches to SmallTalk these days, but most of the
literature on the language is oriented toward the Squeak approach; dedicating
half the bloody book to working within the OS! Just let me use Vim, I don't
want to use your shoddy editor!

------
ltta
Smalltalk is a little shrewd in some ways as outlined here. Self has already
been mentioned as a great alternative (and the related papers are amazing IMO
and influence most modern JITs).

But there are some other really interesting alternatives that IMO keep with
the spirit: Io (io-lang.org), Ioke (defunct now, ioke-lang.org - some awesome
ideas IMO) and Squeak which is being actively developed.

I'd recommend checking out some of these, I think you can easily install io
via brew on Macs and used to be able to install joke as well. They improve
syntax and/or add significant language features.

~~~
staypufd
The Java HotSpot compiler was originally worked on for Smalltalk before SUN
bought the company. It along with the ideas from SELF certainly helped improve
JIT systems and dynamic compilation solutions in the late 90's and all thru
the early 2000's

------
vixen99
I haven't checked others but the publishers O'Reilly offer something like
8,000 titles related to IT. Open to correction but I can't see a single one on
Smalltalk or Pharo. Is this simply because no publisher can see any return on
investment? What do the Pharo developers think about this?

------
ha292
The consultants who can sell it to gullible managers have moved on to selling
something else.

~~~
dschiptsov
That something else was Java.

One of the answers could be that almost every OO language borrowed some
concepts form Smalltalk and implemented them in a less "cryptic" (or esoteric)
way. Take a closer look at that Objective-C. Erlang's (non-OO) modules and
message-passing primitives were also influenced by Smalltalk.

------
dendory
Kinda reminds me of LaTeX. It's my favorite way to write documents ever since
I learned the language, it's so much more precise than word processors, but
most people still defaults to them.

------
staypufd
Smalltalk was and is used for many advanced, super complex and difficult to
understand requirements based systems. Much as Lisp and Scheme are. It sprang
the ideas of full OO onto the programming community, it's guru's brought us
Agile development techniques, Refactoring tools, ChangeSets (Git has this
now), Everything is an Object and many other ideas and concepts prevalent in
today's languages and tools. Many languages freely admit the inspiration of
Smalltalk to their ideas and have expanded on Smalltalk's ideas. Some people
have continued to expand Smalltalk itself. Even it's original creator (Alan
Kay) hopes for a better system than Smalltalk, but even recently he says he
hasn't seen it yet and has called Lisp the "the greatest single programming
language ever designed".

Company's like JPMorgan (Currency Trading), Booz Allen & Hamilton (Currency
Trading), Sprint (Network Topology and Configuration), Digital Switch Corp
(now Alcatel) (Digital Cross Connect), TenX Technologies (C source code
maintenance and analysis tool), American Express (Full IDE for a custom in-
house Credit processing language) and Nortel (Meridian PBX line Configurator
as well as Configurator for the Nortel Wireless Modules used in cell towers)
have used Smalltalk to great ends and gotten competitive advantages and
accomplished great things with Smalltalk.

There were lots of others projects that used Smalltalk to create systems that
they had failed at previously or did not want to tackle due to the enormous
complexity. OO and specifically Smalltalk gave them a way to implement these
systems in an Agile way, long before Agile Manifesto was dropped onto the
world. Remember ST at the time embodied the most mature implementations of the
OO paradigm and it's power was not meet for many years. No other language gave
the bang for the buck overall. C++ was still being standardized thru the early
90's. At the time and up until Borland shipped their Turbo C++, most compilers
were incompatible with one another and/or generated C code because they were
based on ATT's C-front system, which itself was being fluidly developed.

I worked on those examples listed above for those companies and knew of many
others working on other projects. I also happened to work with C++ from
1989-1993 while porting tools such at SUN Tooltalk and SUN Net License to
IBM's AIX boxes as well as Porting the Mentor Graphics ECAD products and core
libraries to AIX and DEC Ultrix and OSF/1\. We had 14 hour compile times, even
with 128 Meg of memory (which at the time was huge) using the $150K box on my
desk. I had also worked with Obj-C on the NeXT systems and IBM RT system and
several OO Lisps including CLOS.

Each of those systems had good points and enabled different things, but
Smalltalk and the tools it provided and the amazing productivity that we were
able to accomplish was amazing. Fixing bugs in the debugger, stepping back one
call on the stack-trace and continuing on (no stopping the whole program and
starting again) [Fix and Continue that worked every time, not just some of the
time like the C++ and Java versions), adding capabilities to the system
itself, being able to inspect and see anything at any time, seeing all the
code for the system and adding to that were amazing and still are.

The title is misleading in that "Nobody" is not the right word for the title.
It's safer to say "few" people use it. But those that do have reasons as
diverse as why there are so many languages that programmers use now and why
the number of languages being created is going up. We as programmers use
languages for many reasons, including their relative power, alignment with our
own thought processes, libraries available, community, religion, syntax
preference, etc.

Don't buy into group thought when looking at any language. I also think that
no one language is going to solve all your problems. Much like we have AWK,
SED, etc. we can use the language that helps us in that moment. Smalltalk is
just one of those languages that is available and for many uses it still is
very applicable.

Sam Griffith Jr.

~~~
vixen99
"it's guru's brought us"? I think you mean "its gurus brought us".

------
goshx
It might just be waiting for the creation of the framework that will make it
sexy and popular... like what Rails did to Ruby.

------
fleitz
For the same reason more people use lottery tickets than index funds for
retirement

