What Killed Smalltalk?

http://pointersgonewild.com/2015/08/20/what-killed-smalltalk/

by Garbage • 11 years ago

104 185 11 years ago

acqq• 11 years ago

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

One maintained Smalltalk implementation with GUI that can be tried:

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

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

and that C easily links and calls Fortran routines.

detaro• 11 years ago

You can run squeak in the browser: http://bertfreudenberg.github.io/SqueakJS/

Another one is 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.

bfung• 11 years ago

Doesn't seem as dead as the article suggests. In addition to squeak:

http://pharo.org/ http://www.strongtalk.org/

One of the more impressive things I've seen in the past (like 5 years ago?) was DabbleDB (https://en.wikipedia.org/wiki/Dabble_DB), also written in smalltalk (the company / app was acquired, see https://news.ycombinator.com/user?id=avibryant)

david-given10• 11 years ago

Also see Amber, which is not technically a Smalltalk but fakes it very convincingly. It runs in a web browser, compiling to Javascript.

http://amber-lang.net/

Load up that page and press the button, and a Smalltalk IDE will pop up for you to play with. (It sounds like an amazing way to write web apps, actually, as it supports writing changes back to the server; but the backend infrastructure is heavier-weight than I'm happy with.)

mmagin• 11 years ago

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.

DonaldFisk2• 11 years ago

Visual C++? Or Visual Basic?

rhodysurf• 11 years ago

Visual C++ came after regular C++

goldfire• 11 years ago

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).

vezzy-fnord3• 11 years ago

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-...)

sanderjd6• 11 years ago

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.

AceJohnny22• 11 years ago

From trying multiple times to give Smalltalk a spin, this has been my thought as well. It has a bootstrap problem, where it's hard to integrate it with the rest of the software ecosystem. I'm sure there are solutions to that, but they aren't advertized as well.

pjmlp4• 11 years ago

You could generate an executable with a pruned image. At least with the commercial Smalltalks.

BuildTheRobots• 11 years ago

(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-given10• 11 years ago

I'd have to agree. I have never wanted to write a program that would run inside a Smalltalk environment. I have never wanted to use a Smalltalk environment --- every time I've tried one I end up ragequitting after a few minutes because of the ghastly nested windowing system.

And I love Smalltalk, as a language. I want to write programs in it, and use it more, and get stuff done in it, but I'll be damned if I'll fight Squeak's windowing system and bizarre VCS.

Right now the only way I have to run Smalltalk is via Gnu Smalltalk, which is a bit old and cranky and not very fast. This makes me very sad.

(I wonder if I could translate Smalltalk source in to Lua and push it through LuaJIT...)

igouy24• 11 years ago

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

igouy24• 11 years ago

>but it doesn't work great at the application level.<<

And yet --

A very large Smalltalk application was developed at Cargill to support the operation of grain elevators and the associated commodity trading activities. The Smalltalk client application has 385 windows and over 5,000 classes. About 2,000 classes in this application interacted with an early (circa 1993) data access framework. The framework dynamically performed a mapping of object attributes to data table columns.

Analysis showed that although dynamic look up consumed 40% of the client execution time, it was unnecessary.

A new data layer interface was developed that required the business class to provide the object attribute to column mapping in an explicitly coded method. Testing showed that this interface was orders of magnitude faster. The issue was how to change the 2,100 business class users of the data layer.

A large application under development cannot freeze code while a transformation of an interface is constructed and tested. We had to construct and test the transformations in a parallel branch of the code repository from the main development stream. When the transformation was fully tested, then it was applied to the main code stream in a single operation.

Less than 35 bugs were found in the 17,100 changes. All of the bugs were quickly resolved in a three-week period.

If the changes were done manually we estimate that it would have taken 8,500 hours, compared with 235 hours to develop the transformation rules.

The task was completed in 3% of the expected time by using Rewrite Rules. This is an improvement by a factor of 36.

http://portal.acm.org/citation.cfm?id=604258

mark_l_watson• 11 years ago

How about writing web apps in Pharo (or Squeak)? There are several nice frameworks, Seaside just being on of them.

coldtea9• 11 years ago

How is it any different than requiring a runtime (e.g. Java or NET)? That you also distribute the image? That's not that big a difference distribution-wise.

justaaron4• 11 years ago

depends upon your definition of application... a machine-consuming set of processes working together, possibly across a distributed network? ummm yeah perfect. smalltalk, erlang, and a handful of other candidates... Java would be considered "experimental" in such environments, as supervisory trees etc are not inherent.

building "apps" for desktop or mobile? ok, you got me there... smalltalk is probably not apropo...

AnimalMuppet3• 11 years ago

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

I don't think she condemned Smalltalk for being idealistic. I think she said that Smalltalk condemned itself to irrelevance by being idealistic. And, yes, that's a danger for the currently trendy functional languages, too.

If your language is harder to get real work done in than the alternatives, your language won't get used. So if your commitment to your version of "purity" is making it harder for your language to be used in the wider programming world, then you are dooming your language to irrelevance. And that's your choice, if you want to make it. If you want your ideas to be useful to people, though, you have to care about making your language usable by people for the tasks that people need to do.

vezzy-fnord3• 11 years ago

Unfortunately the ultimate implication of this argument is to largely rehash the same old ideas and biases that most programmers are mentally comfortable with, and never really push any boundaries. This is the vicious cycle we're stuck in now, and it must be broken eventually.

chriswarbo3• 11 years ago

If you want your ideas to be useful to people, though, you have to care about making your language usable by people for the tasks that people need to do.

I would make a distinction between ideas and languages. Ideologically "pure" languages force us to re-think the assumptions we make in other languages. For example, as a language Haskell could have abandoned purity in order to perform side-effects in the correct order; instead it stuck to its guns and eventually monads, applicative functors, arrows, algebraic effect handlers and all kinds of other techniques were discovered to overcome the problem in a "pure" way. Regardless of whether Haskell is "usable by people for the tasks that people need to do", the fact that it exists and remained "pure" has lead to better libraries in other languages (eg. LINQ).

Likewise for Lisp (garbage collection, higher-order functions, macros, s-expressions, etc.), Scheme (tail-call optimisation, call-cc, the "Lambda the Ultimate" papers, etc.), Smalltalk (message-passing, doesNotUnderstand, etc.), Self (prototypes, morphic, etc.), and so on.

Whether these languages are useful day-to-day doesn't really matter. More important is that their purity forced smart people to look at the world in a new way, which has lead to all kinds of ideas which are being adopted in more pragmatic languages like Python, Javascript, etc. either at the language level or at the library level.

igouy24• 11 years ago

>If your language is harder to get real work done in than the alternatives, your language won't get used.<<

It wasn't; it did.

coldtea9• 11 years ago

If your language is harder to get real work done in than the alternatives, your language won't get used.

Both statements couldn't be further from the truth about Smalltalk.

It was far easier to get real work done (still is over many languages) and it had a decent following, considering compilers were commercial, people avoided so dynamic languages for C/C++ at the time, and it was pro-internet.

bsdetector3• 11 years ago

If the reason for Smalltalk's failure is simple pragmatism, how could anybody's argument rise above that level?

The "blank canvas" features of Smalltalk like the image, monkey patching, edit and resume, modifying individual object instances, retry, and so on are wonderful for experts and just terrible chaos for everybody else.

When you are designing a language, the thing to keep in mind is that an expert can create a masterpiece even from a Java-style "connect the dots" language, they just don't like to, but when using a language designed for experts the common programmer struggles to even create something common.

vezzy-fnord3• 11 years ago

Smalltalk wasn't designed for experts, quite the opposite. That was a major intention, part of a line of efforts to remove the artificial segmentation between user and programmer.

adamc• 11 years ago

I think there is an in-between ground not covered by your comment. Good languages tickle (some class "foo" of) programmers in ways that tend to expand their repertoire. Many of those expansions enable better approaches to system design.

It may be true that "experts" could do it even in Java, but many "foo-level" programmers would just do it the Java-way in Java, but can appreciate the better features of a better language in context.

It's also probably true that many programmers will struggle with foo-level features. That harkens back to Vanier's LFM and LFSP essay: http://www.paulgraham.com/vanlfsp.html. Having seen LFM approaches to systems over the years, I'm skeptical that it is the right approach for anything with much complexity. YMMV.

pron• 11 years ago

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

They're only trending in hype -- not adoption.

gmfawcett• 11 years ago

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.

ch4s3• 11 years ago

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• 11 years ago

What changed in the subsequent 6 years?

kachnuv_ocasek• 11 years ago

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.

tachyonbeam• 11 years ago

Racket is its own language now, it isn't Scheme per-se. They've split apart because of disagreements over which direction the language should take.

pmelendez2• 11 years ago

True... it does include R5RS though, and I think it does include lot of libraries for that too.

xrange9• 11 years ago

...is this the string library you are referring to?

http://docs.racket-lang.org/reference/strings.html

...or something more extensive?

sigzero2• 11 years ago

I am not sure what you are getting at? More extensive? Those are basic string functions.

muuh-gnu• 11 years ago

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

iopq• 11 years ago

Scheme is a "Lisp implementation", it's just not a "Common Lisp implementation"

elibarzilay2• 11 years ago

From 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.

xrange9• 11 years ago

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

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

WalterGR• 11 years ago

Also see

Why is Smalltalk Dead?

https://news.ycombinator.com/item?id=10071681

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

cwp3• 11 years ago

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

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.

e12e2• 11 years ago

I wonder if Smalltalk doesn't have much larger community now, than it did in the 80s. Sure, other languages are bigger still -- but if we have, say a thousand times as many Smalltalk programmers today, as in 1980 -- then hopefully the language will keep getting better. Especially since there are now a few Free/open source implementations, tutorial/books and frameworks.

wvenable3• 11 years ago

SmallTalk was taught as a course when I was at University in the 90s. I doubt that's the case now even though conceptually it's a good language in a CS education. We also had courses with functional languages (at that time ML) and Lisp was taught with AI.

xrange9• 11 years ago

Hmm, I wonder if Pharo/Squeak publish their download numbers? Is the recent uptick in smalltalk articles on HN an indicator in increasing interest in the language (even though they've been mostly harsh).

duaneb• 11 years ago

Scheme is actually used quite a few places, just not as much as a general purpose implementation language.

I would say that smalltalk is way more "dead" in the sense that news doesn't make waves the same way scheme news does.

xrange9• 11 years ago

Scheme is actually used quite a few places

Don't leave us hanging, I'm sure lots of people would like to know of Scheme success stories besides Jak and Daxter.

http://c2.com/cgi/wiki?LispInJakAndDaxter

wvenable3• 11 years ago

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.

cwp3• 11 years ago

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.

rbehrends• 11 years ago

Ruby, Python, and Lua were all created in the early nineties, when the alternatives were Tcl and Perl. And it still required each of them a decade or more to take off.

This was also at a time when most programming languages did not have free implementations and companies actually sold compilers and interpreters. The programming language landscape was totally different back then.

Itaxpica• 11 years ago

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

Rust and Go seem to fall pretty firmly in to that category as well.

coldtea9• 11 years ago

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

We don't know that. I mean it's not like ObjC, where the main pusher and motivation to adopt it was Apple having it for OS X (as evident by the relative lack of adoption of ObjC in Linux, NextStep etc).

Swift does have got people genuinely interested to use it even outside the Apple ecosystem, they just don't have the chance to, yet.

ljw10015• 11 years ago

don't capitalize the T. Just Smalltalk. It's cleaner

coldtea9• 11 years ago

Sigh. Nothing killed Smalltalk. It's not dead. Neither is Scheme. Yeah, both of those languages have pretty small communities

That's how we define "dead" for languages: "pretty small communities".

but that's viable in the Internet Age.

Viable to exist and continue having small communities. But not viable for what matters to lots of people, mainly being able to use them for their company/projects with great support from various sources, documentation, books, new releases and bug fixes commining round the clock, and answers for their questions on Stack Overflow.

justaaron4• 11 years ago

Oh stop picking his reply apart when you exactly what his point is: if you consider smalltalk "dead", and you are "going to invent a cool new language" then you can probably get into the BACK of the popularity line, after REBOL or whatever, as basically you aren't worthy... not even close to worthy...

in a nutshell, a still-revered, still-used (niche public) language built by people with an actual high-level concept (TDD) from the academic world with the support of much of industry at the time, said language probably can safely stay on it's pedestal despite such a fluff-brained "analysis" as linked article purports to provide...

i mean the central point of this article is: "I'm going to make a language that will be big and smalltalk is a convenient hoity toity strawman for me to knockdown"

weak.

doublec• 11 years ago

Self gets used by the enthusiasts in production, for a suitable definition of production. I believe the Self website is served by a webserver written in Self for example. I've also served my blog in the past from a Self webserver.

I found the comment in the post about how a few lines of code would be better than the object interactions in the GUI interesting. I thought this would be the case when I started using Self too but even with the GUI you still write code. The method bodies for example are all textual code that feels like programming in any other language.

Where the GUI excels is exploring systems, prototyping designs - and then refactoring the design towards a production implementation. It also makes the applications 'live' for users. They can drill down into the application objects and see how things work. The line between OS, application, and development is very blurry in Self.

russellallen• 11 years ago

Yep, the Self website is running on a Self webserver (which is itself running on a half written Self cloud). Seems to be fairly stable, all things considered.

_ph_• 11 years ago

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.

xrange9• 11 years ago

My favorite scheme antecdote:

http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=...

david-given10• 11 years ago

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• 11 years ago

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

david-given10• 11 years ago

Amber has a really nice interactive tutorial:

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.

xrange9• 11 years ago

Maybe start with "Smalltalk 80: The Language", and just read the first three chapters:

http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....

Also available for $1.89 (plus shipping) used from Amazon:

http://www.amazon.com/Smalltalk-80-Language-Adele-Goldberg/d...

igouy24• 11 years ago

Perhaps "I Can Read C++ and Java But I Can’t Read Smalltalk"

pdf 10 pages

http://www.eli.sdsu.edu/courses/spring01/cs635/readingSmallt...

wvenable3• 11 years ago

Smalltalk is a lovely, lovely language. It's fantastically simple... learning the library is another matter.

I think that's a fundamental issue. On the surface, Smalltalk seems very simple and easy to grasp but as you delve deeper and deeper it gets harder to follow and more magical. Examining how the underlying platform worked made my head spin. I went from a Smalltalk proponent to a detractor the more I learned about it and used it.

I think that's the fundamental problem with every "simple" language; it just forces the complexity to spill out into another layer.

threatofrain• 11 years ago

The simpler something is, the more you have to build yourself, though the likelihood is that you'll have to learn some library.

coliveira• 11 years ago

That's a horrible reason to hate a language. Every language has layers of complexity. In C++ or Java the complexity is in the compiler, the library and the runtime. In Smalltalk it just happens that the layers are available to everyone to inspect. You are free to inspect or ignore it, but the complexity never really goes away even if you don't see it.

incepted• 11 years ago

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.

You're aware that these are extremely subjective attributes, right?

Most people not using Smalltalk (or who tried it and decided to not use it) will argue that Smalltalk is anything but clear, simple or even usable (seriously, even Pharos or Squeak have the usability of late 90s IDE's).

And of course, there's the fact that Smalltalk is dynamically typed, a class of languages that's fast headed for extinction.

AceJohnny22• 11 years ago

Smalltalk is dynamically typed, a class of languages that's fast headed for extinction.

I'm going to go out on a limb here, and chalk that one up in the "famous last words" column. :)

david-given10• 11 years ago

Note that I was talking about the language, not the environment! I totally agree that Smalltalk IDEs and the general development workflow is poor (and is most likely the reason why it's so little known).

ljw10015• 11 years ago

How is learning the library difficult? Or more difficult than learning libraries in any other language?

WaxProlix• 11 years ago

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?

arnsholt• 11 years ago

You could call it a continuation, I guess, but continuations don't generally persist between separate invocations of your programming. The image is a file that can be passed around and when you open/execute (or whatever you want to call it), the program resumes where you left off.

This is how most Lisp applications are distributed as well. Starting from a clean image (that is, one containing only the language standard library) you build up the initial state of your app by compiling the source files, and then dump the whole shebang as an image.

david-given10• 11 years ago

It's baked into the VM.

When they say that in Smalltalk, everything's an object, they're seriously not kidding. Everything is an object, including compiled code, stack frames, execution contexts, threads, etc. A traditional Smalltalk system uses an object table, where all object pointers are really references to a slot in the table; this allows the garbage collector to move objects around in memory easily.

This means that it becomes trivial to dump everything out to disk, reload it later, update the object table, and suddenly the entire state of your system is restored (ignoring host OS resources, of course, but traditionally Smalltalk didn't use an operating system).

I did have a handy sample for GNU Smalltalk that would snapshot an image containing a running thread which, when the thread was reloaded, would seamlessly resume but, er, I seem to have lost it.

cwp3• 11 years ago

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.

area51org• 11 years ago

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.

xrange9• 11 years ago

Ruby, at least, performs quite well.

Are you talking absolute performance (as in machines are faster now, so speed has become less important) or relative performance (compared to performing the same task with a different interpreter/complier)?

https://benchmarksgame.alioth.debian.org/u32/benchmark.php?t...

pmelendez2• 11 years ago

Is it though?

I still see them on the tail in terms of performance:

http://benchmarksgame.alioth.debian.org/u32/performance.php?...

Here comparing with Racket ( not even Java, C#, C++ or C)

http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...

matthewmacleod• 11 years ago

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...) or 30x slower than Javascript on V8 (http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...). 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• 11 years ago

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

brudgers• 11 years ago

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.

DonaldFisk2• 11 years ago

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• 11 years ago

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.

skywhopper• 11 years ago

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.

d0m• 11 years ago

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

coldtea9• 11 years ago

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.

mscharrer• 11 years ago

I really like C++, but I think it mainly won because it was friendly to the huge number of programmers that already had years of experience with C at the time. Easy use of existing C projects was also a huge benefit.

dxedxaede2• 11 years ago

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.

claystu3• 11 years ago

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

dxedxaede2• 11 years ago

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.

sebastianconcpt2• 11 years ago

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

notdeadSTer5• 11 years ago

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.

igouy24• 11 years ago

>You could outfit entire teams with Borland or MS tools for the price of a single seat license for Smalltalk in the 80s or 90s.<<

Different Smalltalk implementations, different prices:

https://books.google.com/books?id=wJswszKTwl4C&pg=RA1-PA43&l...

>Then Java came along, and it was free.<<

Free and The-Future-of-the-Internet TM.

----

There is an important technical / licensing / business problem with Smalltalk that has not been mentioned -- lack of library standardization.

Apart from a few core classes, each Smalltalk implementation had different class names and method names for things that once-upon-a-time were special but quickly became commonplace -- like windows and menus and …

So you could never hire a "Smalltalk" developer: you hired a VW developer or a Smalltalk/V developer or a VA developer and waited for them to get up to speed with an unfamiliar environment.

notdeadSTer5• 11 years ago

Notice ParcPlace's offering is more than 7x that of MS or Borland. I believe both it and Digitalk's competitively-priced alternative were merged into a single product after PP and Digitalk merged.

hosh3• 11 years ago

I'm a Rubyist. I've never written a serious software with Smalltalk, but I love the core ideas of Smalltalk.

I'm not convinced this is the end of Smalltalk. Given the increasing interest in virtual reality (the Rift, Magic Leap, HoloLens, et. al), I think there will be a significant interest in being able to directly program an immersive VR environment.

I think Pharo and the quiet work on Open Cobalt will surprise people once people start looking for ways to live-edit things in a VR environment, and the kids in the upcoming generation gets a hold of it.

notdeadSTer5• 11 years ago

That's nice of you to say, but I think Smalltalk will probably remain unpopular because it's too different (image-based environment), too powerful (in the Lisp sense, where you can modify core parts of the system while it's running, including the compiler), and worst of all, it's now old, and most developers aren't interested in old tech.

asveikau• 11 years ago

mocking it for not having any conferences of its own

As someone who has not worked in ruby, I have to say that this reads like great parody of the ruby community as seen from an outsider perspective.

Tloewald2• 11 years ago

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.

agumonkey2• 11 years ago

It's weird, I've read stories about Visual Age for Java being better (UX, speed) than the first versions of Eclipse. Unless early Eclipse were unbearably slow, I took it as a sign that ST was solid for complex programs.

notdeadSTer5• 11 years ago

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.

igouy24• 11 years ago

>I suspect it was performance, cruft, and aesthetics… 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…<<

So incompetent programmers ?

steveklabnik• 11 years ago

... I'm not sure which tweets you're talking about, exactly, but I have a lot of respect for Smalltalk. Some of my earliest programming was in Hypercard, which used a derivative of it. Smalltalk Best Practice Patterns is a favorite book of mine.

The only thing I can think of was quoting that old adage, "In an OO codebase, everything happens somewhere else," which was said by a prominent Smalltalker but is about far more than Smalltalk.

I don't use Smalltalk personally because its greatest strength, the image, is also its greatest weakness, a very unusual development environment. Vim keybindings are basically part of my DNA by now, and it's much harder to share code without a textual representation.

peter303• 11 years ago

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.

igouy24• 11 years ago

May 1988, Smalltalk/V286 was viable on commodity hardware.

http://sdmeta.gforge.inria.fr/FreeBooks/SmalltalkVTutorial/S...

rjsw3• 11 years ago

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.

igouy24• 11 years ago

Apparently $150 to businesses.

"Apple Team Developing Maclike Smalltalk"

https://books.google.com/books?id=Dj8EAAAAMBAJ&pg=PA28&lpg=P...

wangii• 11 years ago

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).

igouy24• 11 years ago

It's less dramatic -- languages thrive or fade away ;-)

59nadir2• 11 years ago

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).

amiramir• 11 years ago

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.

igouy24• 11 years ago

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

ljw10015• 11 years ago

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.

What Killed Smalltalk?

Related Stories