Why is Smalltalk Dead?
c2.com
c2.com
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.
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".
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.
So, in some way, shape, or form, then. No need to be so extreme.
What I'm really saying here is that I disagree with you, and I believe you are incorrect in stating that none of Smalltalk's objectives live on in Objective-C "in any way, shape or form", and that's an example of something from Smalltalk that lives on in Objective-C.
That's false. Python likes it every bit as much as if you call methods on any other object: it works fine if you wall a method which exists on the object, raises an AttributeError if you try to access an attribute which does not exist and raises a TypeError if you try to call an attribute which isn't callable.
>>> None.__hash__()
-9223372036578437293
That is also false. While UndefinedObject responds to a fair number of messages (compared to NoneType anyway), sending an "unknown" message to `nil` will signal an exception as it would just about anywhere else (because it'll defer to the standard Object implementation of #doesNotUnderstand). You can redefine `UndefinedObject doesNotUnderstand` so that it does something (or does nothing and return `nil`), but that definitely isn't the default behaviour, and it isn't generally considered a good idea.
> That is also false.
Oops, you're absolutely right --- I was thinking of Objective C:
http://stackoverflow.com/questions/156395/sending-a-message-...
From the opening of chapter four, "Objective-C implements the dynamically bound style of object-oriented programming used in Smalltalk-80 as a set of extensions to a conventional base language, C."
Smalltalk-80 gets a lot more discussion, and there is a lot more about the influence of Smalltalk-80. My copy was printed in 1986, when the programming world looked very different, but from his own words it's pretty clear that something of Smalltalk is very much in Objective-C.
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.
Apple's bet on Objective-C was the only thing that made it broadly relevant -- but now they have moved on, and Apple is generally the type of company that does the opposite of "support both forever".
I agree that it is dying very slowly, however. You will probably still be able to write OS X apps in Objective-C in 2020, albeit with various caveats.
Ugh, I've been holding out hope for this since I first learned there was more than BASIC when I was a kid. Instead, things got more fragmented.
How many millions of hours have been wasted learning languages, frameworks or protocols which weren't used nearly as much as they were expected to be and ended up dying out? Think of how much better software could be if those hours had been spent learning things that continued to be useful.
It honestly sometimes almost makes me wish I lived in a long-ago world where we could earn a living making things out of wood with the same simple hand tools our fathers did-- tools that stayed useful, and rarely changed.
Does anyone think this "final language" thing is realistic at all? I've given up on seeing anything like it before I hit retirement age.
I do. Remember, there were hundreds of search engines, and it looked like it would forever be that way, until Google came along. It's chaos until suddenly it's not anymore.
The thing is, it's a definitely a 'hard problem', so we could normally forgive ourselves for not having solved it yet. Sadly, I'm not sure we're trying.
On the other hand, remember that Google used to be the best search engine, which was why it became the One True search engine; but now it's not so clear that it's the best for all purposes. I use DDG, for example.
(I'm not sure if this has any relevance to the analogy with the final language, except perhaps that any such language would work great until someone, or perhaps Sapir and Whorf, said "having everyone write in the same language is creating a monoculture. Imagine if we could tailor the language to the problem!")
I wish! But there are multiple sensible ways to approach a problem solution and just too many different tastes. There are good reasons for implementing different computation models, even if you made only one PL for each.
But even so, programming in significantly different programming languages isn't just a difference as simple as that. Just look at control flow. Some languages you're expressing an explicit list of steps, others you're merely writing an expression that it's free to evaluate however it wants according to certain rules.
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 a new (i.e. about five years old) syntax for defining an entire program in a text file; the interpreter loads the standard image and the compiles your script into it, which makes it very smooth to work with.
Alas, I found at least one major bug in gst while writing my 50-line script.
People are telling you about recent exceptions. The historical answer is "yes, all of them."
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.
[1] http://www.zogotounga.net/comp/squeak/sqgeo.htm
Edit: added link
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).
But even if, as long as I can't run the binary in Unix, it's pointless.
I don't know about the current state of Smalltalk, but it definitely has a JIT. Many other languages (JavaScript, all JVM languages) have JITs but not always AOT because a JIT gives much better performance.
But what difference does it make if you get a single native binary file with the runtime statically linked (like Go), or with the runtime in its own shared library (like with the JVM)? In either case you can create a native binary to launch the program if you don't want to run `vm program.file`.
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."
like Java
Btw., it's Smalltalk, not SmallTalk.
Java/.Net/etc. VM is what I (and some others) call a "runtime environment." These are far simpler than what Smalltalk provides (e.g. you don't mess about with images), once again, likely as a result of someone holding back from blue sky architecture.
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.
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.
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.
The early history of Smalltalk: http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html
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.
What I attribute more or less to "chance" (by which I basically just means the reasons are so multifarious that it's hard to say anything about them in general) is that Smalltalk didn't become more of a model for the desktop environments.
The big desktop environments are still mostly coded in C-like languages, although I guess it's changing slowly, especially with people becoming used to dynamic languages from web programming.
Of course, NeXTStep and OS X have a Smalltalk legacy, but they're not dynamic and interactive in the same way.
Another point is that since Smalltalk can be almost totally O/S independent, your images can run identically across platforms, including the entire development interface. And the development interface isn't separate from the "user" interface.
Regardless of Smalltalk's alleged death, the idea of having a system where you can interactively edit the source code of components is pretty radical, and will probably always be around. It's also kind of contrary to keeping source code proprietary, which might be an underrated reason for Smalltalk's unpopularity?
Sure it was.
The Genera Lisp Machines had compilers for C, Ada and Pascal available.
If one really wanted to have a Fortran compiler in a Smalltalk environment, s/he just needed to port it, just like Symbolics did for its Lisp Workstations.
Also Fortran and Prolog. Though added language were expensive. Usually it would also be useful to have a FPU option.
Thus a Lispm with Fortran would cost something like $100000 in the mid 80s. Which makes it possible to use Fortran, but not to an attractive price. ;-) 'Exotic systems' + software ported to exotic systems => expensive or not available. For decade the Symbolics approach was available and expensive, later it moved to 'mostly not available'...
Not true.
One effort I saw was a gigantic effort of using Smalltalk in a Very Large Insurance company. One of the tools they developed was one to read Cobol data divisions to get authoritative record formats for Smalltalk to use.
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.
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.
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.
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.
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.
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).
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.
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.