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".
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.
You aren't wrong. Objective-C is dying. The huge machine that nursed the frail, nearly-forgotten language back to health -- and then pumped it full of steroids and made it a monster -- has been disconnected, and hooked up to Swift, instead.
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.
I knew I'd read something on the subject. Brad Cox, in his book "Object Oriented programming", discusses the influence Smalltalk-80 had on how he designed Objective-C, when he was creating it.
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.
For me, the most Smalltalk-like aspect of it was that I could send any message to any object. This was radically unlike, for example, C++, where I could only call functions on objects when those functions actually existed.
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.
You can do the same in ruby, or with lisp. Objective-C doesn't provide a REPL for constant feedback, you find that in ruby, lisp and python. It lives more in those languages than in ObjC.
I don't know Ruby or Lisp, but Python, at least, doesn't like it if you call methods on nil. Smalltalk and Objective C both let you do that (they do nothing and return nil).
> I don't know Ruby or Lisp, but Python, at least, doesn't like it if you call methods on nil.
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
> Smalltalk let you do that (they do nothing and return nil).
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.
In Ruby, nil is the singleton object of NilClass, and you can call method on it like any object -- heck a key way of distinguishing it from False is that they respond differently to .nil?
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.
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.
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."
The Java way of VM is not the Smalltalk way of VM :). "VM" has become quite an ambiguous term - the Smalltalk VM is closer to (not exactly like) a Xen/VMWare-like VM: Smalltalk avoids the OS by having its own "OS."
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.
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.
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.
The other day I fired up GNU Smalltalk and did some basic scripting with it. I'd forgotten how nice a language Smalltalk is to work in, although the standard library is a bit archaic.
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.
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.
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.
Does anyone think this "final language" thing is realistic at all?
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.
> Remember, there were hundreds of search engines, and it looked like it would forever be that way, until Google came along.
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.
> 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).
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`.
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.
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.
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.
> 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.
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.
> 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.
Yeah, I guess there are strong such reasons why the Unixy model won over Smalltalk (and Lisp) when it comes to the basic O/S level.
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?
> That sort of thing wasn't feasible with Smalltalk.
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.
> The Genera Lisp Machines had compilers for C, Ada and Pascal available.
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'...
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.
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.
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.
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.
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).
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.
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.
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.