I'd recommend checking it out, it's quite different from Smalltalk-76 (which is pretty much "modern" Smalltalk) and has some novel ideas. They may not be good ideas (after all Smalltalk-76 was very different), but they are novel!
43 points but zero comments at the time of writing this comment.
Somewhere deep in our harts, we all have a deep appreciation for Smalltalk and its legacy in programming language design, it's just that no one is actually interested to use it anymore. It's gone, it's part of the history, never to come back. People just upvote an article about it and proceed with the life.
Same can be said for (Common) Lisp, which still live its half-life in form of Clojure, but is far away from the mainstream.
Smalltalk brought both fascinating and terrible aspects.
Everything is inspectable, discoverable, interactive. Reactive programming, live objects, build stuff and see it come alive at every step. JIT makes everything fast, eventually.
But also the whole thing is one huge global mutable state. You used to be able to redefine "constants" like true by mistake. You want to save the entire system image, because now everything works, but you're not sure how exactly did you end up with it during the interactive session. Static checks and guarantees are hard to have at best.
AFAICT, initially Alan Kay tried to build something like Erlang: hence messages and protocols, objects keep their state as if they were nodes of a network. But hardware limitations did not allow yet back then, so the design changed, and was still hugely influential.
I think certain languages end up being bellwethers and test beds, without becoming industry mainstays. Haskell and OCaml don't have much industry adoption, but Rust does. APL (and even k) don't have much industry adoption but numpy and spark (admittedly both libraries) do. Smalltalk and Self don't have much industry adoption but Ruby and Python do.
I've never understood why Ruby is sometimes considered to be in the Smalltalk lineage. The syntax has some superficial similarities, but the practical use of the language is more similar to PHP.
Rails is extremely far from those dynamic Smalltalk application environments. Nothing is live. Object graphs are built up to serve a single request, then torn down immediately — a bizarre kind of kamikaze OOP. To me it's the worst of Smalltalk and PHP in one, as all the interesting aspects of dynamic typing are wasted and just become a source of bugs.
Ruby, the language, is almost as flexible and dynamic as Smalltalk. It's just that it didn't come with an integrated graphical environment like Smalltalk.
For a glimpse of "what is possible", take a look at TkInspect (1), a set of gems that I'm working on that provide some of the goodies of that GUI, like an interactive, graphical console, a live inspector, a class browser or turtle graphics.
At the moment it's not more than a toy, but it does definitely show what can be done.
The major similarities of Ruby and Smalltalk are semantic much more than syntactic (except perhaps for the existence of singleton classes). And as far as Rails is concerned, well, it probably wasn't written by a Smalltalker, but I fail to see how the existence of some specific framework changes how Ruby should be perceived as a language of its own.
I think most people would agree that the benefits of Smalltalk the language are inextricable from the runtime environment and GUI.
Ruby has no such thing: it's pretty much only used for Rails and plain-jane Unix scripting. It's fair to judge the language in context of its actual applications.
Although it looks like somewhere along the path with the "new" graphical browser they dropped the tag line "Smalltalk for those who can type".
Rails is a monster, and historically pretty poor ruby code quality INMHO. That said, ruby does indeed miss an "image" concept, but is quite dynamic and object oriented. Some smalltalk patterns would work well with ruby, I think.
There's also (the abandoned?) maglev ruby on top of gemstone/s object db for smalltalk.
I dunno what most people think about the benefits of Smalltalk, but I do know that people think Ruby and Objective-C are part of the Smalltalk lineage because they use the Smalltalk object model and have similar dynamic properties.
> initially Alan Kay tried to build something like Erlang
It was actually Dan Ingalls who built it (btw. 15 years before Erlang was invented); he's also the author of the referenced worth reading paper; never understood why he didn't get the Turing price.
> Dan Ingalls was the John Carmack...Kay was the Romero.
Sorry, I don't get the metaphor. It's a reference to a game I think?, but not sure which one, and I could be wrong. I'm very familiar with Ingalls and Kay, but not the other two, besides hearing Carmack's name around here sometimes.
Romero was the "frontman" for Id Software (Wolfenstein, Doom, Quake) back in the 90s. He gave the magazine interviews, attracted the hype, and claimed much of the credit for the game's success, at least in the popular press.
Carmack was the programmer who wrote the core bits that made the game possible. He didn't engage with the popular press, and when he did engage in discussions with the media or with fans, it was at a very deep and technical level.
You may also think about it in terms of Wozniak and Jobs. Point being that Alan Kay was out there, engaging the press and talking about Smalltalk's big ideas (objects, messaging, computers as medium, how they relate to children, etc.). He was the frontman. Whereas Dan Ingalls deserves the bulk of the credit for actually writing Smalltalk.
Fun fact: Ingalls wrote early Smalltalk versions... in BASIC.
It's on page 4 of this article: "I immediately went home myself and wrote a simulation of Alan’s interpreter in Basic (the only language to which I had easy access at home), as a proof of concept." (referring to Smalltalk-72)
Ok thanks. No, it's not a joke. Don't know why you would think that. I'm getting strong signals here that Carmack/Romero are supposed to be a lot better known than Ingalls/Kay. Even though this is a Smalltalk discussion! (I've never been that much into computer games, besides occasionally writing them, and have always loathed "first-person shooter" games. Maybe that explains something.)
Surely, Smalltalk did have some adoption, and a huge influence! The JIT that made the JVM fast was adopted from Smalltalk! All the GUI stuff was heavily influenced by Smalltalk. Etc.
But there were and are much fewer Smalltalk jobs in the industry than C++ jobs (though the Smalltalk jobs paid better).
Much like there were more number-crunching C++ jobs than APL or k jobs, up until some key ideas of APL were made available wrapped in Python, and numpy jobs skyrocketed. Maybe something similar will happen to some key Smalltalk ideas!
> The JIT that made the JVM fast was adopted from Smalltalk
No, that was technology developed for the Self programming language which didn't have much in common with ST (see e.g https://dl.acm.org/doi/10.1145/1238844.1238853, there is also an interesting talk by Ungar and Smith). The same technology was also used for an ST dialect (Strongtalk) which was quickly discontinued in favor of Java Hotspot. The influence of ST is generally overstated.
A key development in dynamic compilation happened in Xerox PARC to allow Smalltalk to run well on commercial workstations:
https://dl.acm.org/doi/10.1145/800017.800542
"Efficient implementation of the smalltalk-80 system" by L. Peter Deutsch and Allan M. Schiffman in POPL '84: Proceedings of the 11th ACM SIGACT-SIGPLAN symposium on Principles of programming languages, January 1984, Pages 297–302
This motivated the creation of the ParcPlace spinoff to commercialize this technology. It was not the first JIT, but quite a few modern ones were inspired by it.
Self started out as one of the "Smalltalk-86" projects at Xerox PARC with Randy Smith collaborating with Berkeley's David Ungar. It was supposed to be a simpler and purer Smalltalk even if that made practical implementations impossible. But with David Ungar becoming a professor at Stanford, he found students that helped him make it possible, and eventually even much faster than existing Smalltalks. Craig Chambers worked on type inference for Self 1 and 2 and then Urs Hölzle worked on adaptive compilation with type feedback for Self 3 and 4.
https://dl.acm.org/doi/10.1145/191080.191116
"A third-generation SELF implementation: reconciling responsiveness with performance" by Urs Hölzle and David Ungar in OOPSLA '94: Proceedings of the ninth annual conference on Object-oriented programming systems, language, and applications, October 1994, Pages 229–243
This is the technology that became "Hot Spot" for Java. But very few virtual machines have this level of sophistication.
> Everything is inspectable, discoverable, interactive. Reactive programming, live objects, build stuff and see it come alive at every step. JIT makes everything fast, eventually.
And yet we suffer the experience of web "apps" like Gmail, which have some similar properties (which I'm reminded of every time I hit shift-ctr-c rather than ctrl-c to copy something in office365/Outlook - and the dev tools pop up).
"Same can be said for (Common) Lisp, which still live its half-life in form of Clojure, but is far away from the mainstream."
He says, on site written in Lisp, siting a language that proves the invalidity of his own statement.
For what its worth, while Lisp has never been a language with a big following in commercial development due to its focus on exploratory programming rather the delivering a "finished product", it's user base has actually been growing in the last 20 years or so.
Both Smalltalk and Lisp are still actively, though not widely, used. I think those of us who still use them, and a handful of other languages, just got tired of the language wars and inevitably making the same old arguments vs whatever the language(s) of the moment are. So when we see an article like this bubble up, it's a quick upvote and then move along.
Yeah, they tend to be the ones that most "affect the way you think about programming"! And inspire the most ardent love/devotion. The beauty of simplicity.
The Pharo folks are actually doing quite a decent job on getting people interested in the language, IMHO. They even organized a MOOC, that got me started on the Smalltalk branch of languages some months ago. See https://mooc.pharo.org/
I have actually used Squeak in production for a simple web app when I was freelancing. I used https://github.com/seasidest/seaside as framework which is still going strong.
Sure that was like 10 years ago and the app is long gone but I can totally see the use for Pharo/Squeak in a green field project even today. The parts are all there. It is super easy to get started, you download an image and have an whole development system set up. No setting up the tooling, no hunting for extensions for you IDE, nope the language already comes with an IDE that is superior to anything your are likely to have ever seen.
Agreed. I’m no software historian, but Smalltalk has always fascinated me. I even spent a fair amount of time in the Pharo community as I was learning to code. Eventually I left for Python and Django and the robust communities they have.
I think it is easier to use Common Lisp in a product than Smalltalk. I work on a Common Lisp package that just builds into a command-line application, the user can't tell what language it is written in.
This has been posted a few times and never attracted more than a couple of comments, I don't know why. I found it a fascinating account and amazingly full of detail considering the start of the story was well over 40 years ago. Check out Dan Ingalls on Wikipedia; he is responsible for a great number of innovations over the years
Thankfully this was posted again, because I haven't seen this document before. And I'm saddened if Dan Ingalls doesn't attract more attention.
Dan Ingalls seems to be this unsung hero that does not get mentioned often enough in my opinion. Admittedly, when I first learned about him from FLOSS Weekly podcast[0], I've been a bit of a fanboy. Since then I have read and listened his interviews and lectures that I have been able to find. He seems to be a very modest man with a lot of interesting anecdotes.
The whole era when Smalltalk was invented is fascinating. I'm currently reading through the book "The Dream Machine" just to learn more about the Xerox PARC, Alan Kay, Dan Ingalls and his involvement in Smalltalk and related innovations.
My only comment was gonna be that Squeak was released 25 years ago and the paper should probably include some of the other spiritual successors like Pharo, etc. But I've never done any more than dabbled in Smalltalk, Squeak, or Pharo, so I didn't feel sufficiently qualified to make that suggestion.
Dan only talked about the systems he worked on personally. There were many Smalltalks in the past that he didn't mention (Little Smalltalk, Smalltalk V, Smalltalk/X, SmalltalkAgents, VisualAge, Dolphin, Smalltalk MT, etc). Though Cuis and Pharo built on his work, he was not involved with them.
While its syntax may fit on a post card, I have never seen an introduction to its semantics as intuitive as this site and presentation provides for Javascript: http://latentflip.com/loupe/
The syntax fits on a postcard, but even the introductory books on Pharo or Squeak are not intuitive at all. Python was much easier for me. Syntax isn't everything.
> it's just that no one is actually interested to use it anymore
Heeey, I'm learning Dolphin right now! It still looks like one of the easiest ways for doing Windows front-ends to stuff. A shame it's not been updated for 64 bits yet, though.
Unfortunately I think that it's even worse than that: the STEPS project created intriguing demo of a text editor written in a very little number of lines compared to traditional applications.
Nice? No! Nobody has managed to reproduce the demo :-( and I think that being written partly in Smalltalk is one of the cause..
My take is that it still commands a lot of mindshare because it has a reputation for having been a better kind of object-oriented programming, and that nostalgia is being exacerbated by OOP's poor reputation nowadays.
I started learning Pharo recently, and, TBH, I don't think that's a misplaced sentiment. Programming in Pharo really is a different experience from programming in C++ or Java. The differences go deep. You know how sometimes there's this advice that in OOP you should avoid using if and switch statements, and instead use polymorphism? Well, Smalltalk doesn't even have if or switch statements. Instead, the True and False classes have methods like `ifTrue:` and `ifTrue:ifFalse:` that accept blocks (Smalltalk speak for a lexically scoped closure) as their arguments, and conditionally execute them.
So, right there, that's more than one mental shift from how most of us are used to thinking about things. First off, if you ever thought that higher-order functions were a functional programming thing, well, here's the counterexample. The language for which the term "object-oriented programming" was coined wouldn't be able to do anything useful without them, because it needs them to implement fundamental control structures. And second, it's true, you really don't need traditional if-statements in OOP. They're a procedural programming thing, and, at least in some respects, OOP really is better off without them. For example, in Smalltalk you can implement a system for trivalent logic and (compiler optimizations aside) it wouldn't be at any particular disadvantage compared to Boolean logic.
The other thing that strikes me is that I'm pretty sure that, at its core, Smalltalk is a smaller language than Scheme. Not necessarily in terms of library size (Smalltalk doesn't an equivalent to the RxRS standards, so I'm not sure this is even a comparison you can reasonably make), but in terms of the number of features that need to be built into the interpreter itself. I haven't done a methodical comparison, but my impression is that Smalltalk's core language has maybe half as many features as Scheme's.
It also is very much alive, even if it doesn't command the same mindshare that it once did. The standard-bearer I'd point people to nowadays is Pharo, which isn't technically a Smalltalk (in the same way that Racket isn't technically a Scheme), but its team has spent a lot of time working on things that a contemporary developer would expect (e.g., playing nice with Git) that you don't necessarily get with other varieties. The official MOOC is very well done and something you can breeze through pretty quickly.
My own personal take is that the thing that his holding Smalltalk back is the image-based development. Smalltalkers get very tetchy when people criticize this, perhaps even more so than lispers do about s-expressions. My personal take is that image-based development does enable a lot of very cool things, and working in an integrated development environment that is actually integrated does give you an incredible sense of power. I can see why it's a hill the community is willing to die on. But, it is a hill on which they will die. Image-based development jumbles together source code, application state, and IDE state in a way that creates collaboration challenges comparable to the ones people complain about in notebook-based development, except perhaps even more so. And, while I haven't actually tested this, I'm guessing that Squeak and Pharo both interact poorly (perhaps even not at all) with screen readers, which would - and should - be a hard stop for many workplaces.
"The fact that Smalltalk proved to be an excellent prototyping tool should not be surprising, as Smalltalk’s developers had themselves used the system in this manner. … While we have have found the Smalltalk language a very effective tool for building complex systems, we believe it is currently unrealistic to expect that an excellent rapid prototyping system can also be an excellent application delivery system. If Smalltalk is to be widely used to develop production applications, then the language, its development environment, and its implementations need to be re-engineered for that purpose."
This echoes what I occasionally daydream of: A Smalltalk-like development environment, written in Smalltalk, that maintains a clear separation between the application you're working on, and the application you're working in.
And then let the environment run headless and export a language server and debugging API that lets me get most the practical benefit without having to leave my favorite editor, and also integrates more easily with existing build tools, stuff like that. Right now, Smalltalk effectively wants to either be the prima ballerina, or have no part in the production. That's a real difficult line to try to hold in the modern software landscape.
That said, it's still a great language, and one of those rare ones that I'd encourage everyone to learn, because it will change the way you think about programming.
If only they had a open source, full featured version released earlier, probably we would be living in a better software world today. But its early success made people greedy, bent on charging costly licenses, prohibitive to the individual developer. When Squeak was open sourced in 1996, it was already too late, Java and C++ took over, OOP got a bad rep, and we got drowned in incidental complexity.
"open source" in 1995 was very different to how it is now. There was GNU stuff and the Linux kernel and not a lot else. Now it's a zillion different dev environments and whatnot, but buying commercial tools for software development was far more common then than it is now.
I'd recommend checking it out, it's quite different from Smalltalk-76 (which is pretty much "modern" Smalltalk) and has some novel ideas. They may not be good ideas (after all Smalltalk-76 was very different), but they are novel!