Why is Smalltalk Dead?

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

by Permit • 11 years ago

87 61 11 years ago

tempodox3• 11 years ago

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

lucian1900• 11 years ago

That's largely because Smalltalk was designed to actually be an OS. That didn't quite pan out.

david9274• 11 years ago

It didn't pan out -- but it was the right idea. The "final language" that we will all eventually use will be an abstraction that is both language and OS.

WalterGR2• 11 years ago

    Beyond the fact that I wouldn't use a language without a native code
    compiler, the worst obstacle seems to be that you can't integrate
    Smalltalk into other OSs. You have to “boot” into a Smalltalk
    universe and do everything in its terms.

All Smalltalk implementations work like this?

rjsw• 11 years ago

I think GNU Smalltalk is closer to how other languages work.

DougMerritt• 11 years ago

All Smalltalk implementations work like this?

People are telling you about recent exceptions. The historical answer is "yes, all of them."

david-given5• 11 years ago

Absolutely --- even today, if you fire up an implementation like Pharo, what you get is a Smalltalk VM in a window, complete with its own custom windowing system. I don't want a Smalltalk windowing system. I've got one already, thanks.

It gets worse when you actually try to write substantial amounts of code; because Smalltalk doesn't store source in files, and everything's built in to images, you don't get to use standard source control workflows. The last time I looked at Smalltalk, it had its own VCS called Monticello. That's showstopping, for me. (Although I notice that Monticello seems to have git integration these days.)

There are a few command-line Smalltalks around, GNU Smalltalk being the most well-known. It's so much nicer to work with as it integrates well with the command line. It's a bit crufty and unloved, unfortunately, and even though it has a JIT the speed doesn't seem to be great.

eggy• 11 years ago

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

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

Edit: added link

marktangotango• 11 years ago

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

chazu• 11 years ago

muO looks fascinating, thanks for introducing me to it.

pron3• 11 years ago

I wouldn't use a language without a native code compiler

You mean an AOT native code compiler? Is that for ops reasons or what? Because JITs produce better code than AOT compilers (perhaps other than for low-level languages, where there isn't much more to optimize).

tempodox3• 11 years ago

Why does it make a difference? Is there a Smalltalk with JIT-only but no AOT?

But even if, as long as I can't run the binary in Unix, it's pointless.

zamalek2• 11 years ago

I very much agree with this. The way that Smalltalk is typically implemented (VM/OS) solves some very tricky problems that almost nobody has.

Taking for example the main solution that it features: allowing for portability by running everything inside of a VM. This is an incredibly smart idea, however, it results in apps that don't 'glue' well with the actual OS. Furthermore, even the worst-case language for portability, C, does a pretty damned good job at being portable if the developer is disciplined.

On the fly editing? Awesome idea, really smart. Just don't go anywhere near my production servers with live editing.

That's what Smalltalk is to me: a bag of really smart ideas that nobody ever asked for in the first place. Really, ObjC is what Smalltalk could have been had the word "no" been used more frequently. It's a good example of what happens if someone doesn't realize that "less is more."

lispm2• 11 years ago

allowing for portability by running everything inside of a VM

like Java

Btw., it's Smalltalk, not SmallTalk.

pron3• 11 years ago

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

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

mbrock2• 11 years ago

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

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

simonh• 11 years ago

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

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

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

masklinn3• 11 years ago

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

Smalltalk predates pretty much all of "the toolchain", the first "real" version of Smalltalk is contemporary to UNIX Version 2. That's the one which added `echo`, and was installed on 10 machines. Smalltalk-72 predates both Emacs and VI ('76), "the toolchain" at the time was qed.

recuter• 11 years ago

The Early History of Smalltalk: http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

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

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

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

EliRivers3• 11 years ago

Smalltalk lives on in Objective-C :)

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

masklinn3• 11 years ago

Smalltalk lives on in Objective-C :)

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

yoz-y• 11 years ago

However I'd argue that Objective-C is slowly dying. I do not think that there will be much changes done to it in the future except for those making Swift interface better.

Of course I could be completely wrong and maybe Apple will support both forever and use Objective-C to make the said frameworks and promote Swift as an interface to it.

andrewl• 11 years ago

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

hodwik• 11 years ago

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

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

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

rbonvall• 11 years ago

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

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

pherq• 11 years ago

The similarities between Ruby and Smalltalk basically consist of them sharing the notion that everything is an object, every operation is (or, in the case of Ruby, can be) a message sent to an object. Ruby has some control structures like if, while, etc. that Smalltalk didn't, however it's got the basics (blocks, methods, classes) that allow you to directly translate Smalltalk code into Ruby (it has things like if_true, if_false, etc. that were how you did conditionals in Smalltalk, even if the idiom would be to use the special if form).

Python doesn't quite fit as well, since it doesn't have arbitrary anonymous code blocks (lambdas are a bit limited), and classes aren't as open once they've been created (I think?).

The big difference is that Ruby is a language that runs on regular machines, calling out to C routines to interact with an external OS, whereas Smalltalk is an integrated language and OS that run together (similar to lisp on the lisp machines).

kabdib• 11 years ago

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

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

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

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

david-given5• 11 years ago

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

http://amber-lang.net/

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

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

brudgers• 11 years ago

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

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

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

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

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

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

mocana• 11 years ago

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

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

protomyth• 11 years ago

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

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

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

Ace17• 11 years ago

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

dwarman• 11 years ago

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

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

Why is Smalltalk Dead?

Related Stories