Just yesterday I was talking with a friend who works at Instantiations [1]. They were founded in 1988, and still ship a new release every year of Smalltalk. What I find fascinating is that customers are actively building on it and seem happy.
I really wish that there was a license/version/build marketed to hobbyists:
>Call or Email for Pricing
and the upgrade pricing is four figures (per set per year I'm guessing?).
Ages ago, I actually bought a Smalltalk for Windows compiler, but never got around to doing anything with it (which I regret) --- I suppose I should try Dolphin SmallTalk....
Dad is true Smalltalk believer, used to use visual age, instantiations etc but is a happy user of pharo nowadays which is free, opensource and under active development so could give that one a try.
Whenever this story (and all the related stories about PARC) re-surface, I am (writing now in late 2026) mostly sad about the incredible language that should have 'won' .. well .. everything!
The term 'footgun' unfortunately matches all too well: something so great, so powerful yet most of the time, even in the hands of well-intended folks, proceeds to shoot oneself in the foot. I was for more than a decade a professional Smalltalk developer (Telecommunications, Financial/Derivatives) but we were replaced by technically inferior systems, mostly Java, JavaScript and even VisualBasic. The HR person at the Financial company explained (after my exit interview!) that for the cost of a single Smalltalk developer, they could hire 4 or 5 lesser experienced programmers (less cognizant of how systems actually worked!). The HR folks preferred these hires: more selection, cheaper . etc. Sigh!
Am I a horrible person to enjoy so much (schadenfreude!) the upcoming AI/LLM footgun massacre?
You're not a horrible person to enjoy that. However, the schadenfreude is only in your head. 2026 is the most amazing year of building software in human history, so far.
Well, programming feels that it will get closer Smalltalk. For webdev you get pretty mature HMR, you look at the interface and sometimes just point at things and tell a model to modify it. So pretty close to live medium +short feedback loops.
If the big labs wouldn't have the incentive of hiding the code and making you rely solely on the models, you'd probably also see more inspection tools and contextual changes when the model does them.
It depends, IMHO. If op is talking about "programming", then I think they are right. If they are talking about "development", then I think you are right.
I still don't agree. Nothing is stopping you from doing programming without AI and enjoy it like an art form just like people still paint even though they can just print. On the other hand, the amount of languages, tools, paradigms available are crazy and there's always something for everyone to enjoy.
They were the ones that almost on day one pivoted their Smalltalk offerings into Java.
Eclipse still has the Visual Age Smalltalk object browser.
If you look into OS/2 documentation, and SOM (OS/2 version of COM), you will find out Smalltalk on OS/2 had a role similar to .NET on Windows.
I think AI is the revenge of Lisp, dealing with Python without JIT, and the whole 4 GLs, CASE tooling that tried to automate programming in the 1990's, this time around it goes.
> I think AI is the revenge of Lisp, dealing with Python without JIT, and the whole 4 GLs, CASE tooling that tried to automate programming in the 1990's, this time around it goes.
Perhaps it’s because I haven’t had a coffee yet, but I’m not following/parsing this last paragraph - can you expand?
Lisp was the AI language, alongside Prolog (see Japan's 5th generation computing project).
Instead of having nice Interlisp-D and Symbolics machines with their graphical tooling, hot code reloading and machine code generation, we got Jupiter notebooks and C/C++/Fortran libraries on a pure interpreted language [0].
Additionally in the 1990's there were several efforts to move into the next level of programming, with more human like languages, CASE tooling, RUP method (with UML), most of them failed, SQL is one of the survivors, think its declarative nature.
So while not all of those ideas caught on as expected, now we get to program in natural language, use Markdown waterfall plans for agents, integrate them with Web services, seat reading email and Internet surfing until their activities are ready for review.
In low code/no code cloud platforms like Workato, Boomi and co, classical programming is already past tense.
[0] - Granted now JIT is being part of CPython roadmap, and there are some nice IDEs for Python actually.
A lot of people don't know that Smalltalk heavily influenced NeXTSTEP and Objective-C. You'll see a lot of it in Interface Builder->Project Builder->XCode with the GUI serialization (and of course Obj-C message passing and general dynamic nature).
MPS/MPL began in 1971; the Mesa name was adopted in June 1974; an Alto cross-compiler worked in spring 1975. Cedar is both a language (an extension of Mesa, e.g. by a GC, but the OO features proposed by Lampson were never implemented to my knowledge) and a development environment. I assume your claim is about the latter. The programming language doesn't have anything in common with Smalltalk, and the fundamental work even predated the latter.
We should not forget that the original Alto operating system(s) had a GUI already and was the basis of well known applications like Bravo or Gypsy; the original OS and the said applications were implemente in BCPL; and all were operational before Smalltalk-76. By Wirth's first PARC visit in 1976–77, Mesa had already become a self-hosting systems-development tool (small operating system and symbolic debugger); I'm not aware of any substantial Smalltalk influence at that time.
> I'm not aware of any substantial Smalltalk influence at that time.
You should be, because I spent hours telling you about it, in detail, with citations from the designers of the Alto and Bravo, less than two weeks ago. At the time you conceded the point and said it was not what you intended to dispute: https://news.ycombinator.com/item?id=49857855
And please note that this is again a different topic.
Last time I was talking about Wirth's OO vs. Simula OO, and the similarity of Wirth's implementation with Kay's vision. You then first extended this discussion to whether Kay directly influenced Wirth, which I responded. Then you extended the topic even more to the question whether and to what degree Cedar was influenced by Smalltalk. That was far off my interest and irrelevant for the discussion given that Wirth just took the tiling window manager, which none of the Smalltalk versions had.
Now I'm talking about the development of the Alto computer which included an OS with a GUI and two groundbreaking applications, Bravo and Gypsy (implemented on top of Bravo), all in BCPL, implementing their own interaction and presentation concepts.
The reason the Alto included a GUI at all was specifically Alan Kay's vision, as explained in the text I quoted by the people who built it. That text includes primary sources written at the time by, among other people, Cedar's main author and Bravo's main author — not only, as you imply, stories written down from memory twenty years later. It also includes primary sources from many years later, but those add to the evidence; they do not subtract from it.
I do not believe that Wirth's "OO" is a different topic. To the best of my understanding, the reason he added procedure-typed record fields in Modula-2 and retained them in Oberon was specifically in order to implement that tiling window manager, which in later versions of Mesa (and Cedar) replaced the overlapping-window GUI in earlier versions of Mesa, which came from Alan Kay's 01969 doctoral dissertation, by way of Smalltalk.
Were you two having a discussion about extensible programming languages, or an extensible discussion about programming languages? Or was it an extensible discussion about extensible programming languages after all? Maybe it all boils down to whether discussions about programming languages should use static or late binding?
> Kay's 1969 thesis has no overlapping windows; its "windows" are Sutherland–Sproull clipping viewports into a vector-display virtual screen ("the terminology follows [A Clipping Divider, 1968]", p. 40); nothing occludes or moves. Overlapping bitmap windows first appear in Smalltalk-72 on the Alto (1973–74), implemented by Ingalls. Tiling did neither come from Mesa nor from Kay; multiple tiled windows were on screen in Engelbart's NLS in 1968 (Engelbart & English, FJCC 1968, and the demo), carried into PARC by his former team (English, Irby), and are the stated model for the Mesa debugger. Procedure types in Modula-2 (1977–80, for Lilith) were taken from Mesa after Wirth's 1976–77 PARC stay, years before Cedar's tiled Viewers (1982), which Wirth saw in 1984–85.
Unfortunately, and horrifyingly, this response is [dead].
I agree with some things in it, but not others, and I will have to write a longer response later.
> Unfortunately, and horrifyingly, this response is [dead].
That's strange. I didn't do anything and it still appears on the site in my browser. Did they add "shadow bans" to HN? That was one reason for me to turn my back on Facebook (and the fact that interesting discussions suddenly disappeared later on).
There are shadowbans on HN, but you are not shadowbanned. Some assholes just flagged your comment, that's all. I appreciate the comment, and will respond to it in due course — I don't want to depend on my own memories here, but also to re-check the sources myself.
> SunView is an example of a window system that is based upon the Tools metaphor rather than the Desktop metaphor. Its users see a collection of application program windows, each of which is used to edit certain files. Smalltalk-80, Cedar, and various Lisp environments also use the Tools metaphor rather than the Desktop metaphor
> The Reactive Engine -- While Engelbart et al were developing ideas, some of which eventually found their way into Star, Alan Kay, then a graduate student, was doing likewise. His dissertation, The Reactive Engine, contained seeds of many ideas that he and others later brought to fruition in the Smalltalk language and programming environment, which, in turn, influenced Star.
> Most importantly for Star, they demonstrated the power of graphical,
bitmapped displays, mouse-driven input, windows, and simultaneous applications. This is the most visible link between Smalltalk and Star, and is perhaps why many people wrongly believe that Star was written in Smalltalk.
> Even though the machine was designed to run Star, it also ran other software. In addition to selling it as the 8010 "Star" workstation, Xerox sold it as a server machine and as an Interlisp and a Smalltalk workstation.
> Client programs can attach additional information to windows by means of named contexts, similar to property lists of LISP. Tools can be written to have multiple instances, obtaining their data from the context associated with the particular window that Tajo is notifying (passed as a parameter to the notify procedure).
> The debugger had multiple windows patterned after those of Smalltalk [Kay76]. One, a typescript window, was used for interaction with the debugger executive for setting breakpoints, examining data, etc., and another was used to show the source context at breakpoints.
There are a few others with similar one off sentences like these, telling how designers from one system got influenced by the other, while at Xerox PARC.
Thanks. Your quotes are not about the Alto system software. The Star paper is about Star (1981) and itself warns that people "wrongly believe that Star was written in Smalltalk"; your first Sweet quote credits Tajo's window contexts to Lisp property lists, not Smalltalk.
The Alto OS, Bravo (1974) and Gypsy (1975) were written in BCPL by CSL/POLOS people (Lampson, Sproull, Simonyi, Tesler, Mott); the June 1975 Alto OS manual and Alto Packages contain nothing from Smalltalk, and they had no overlapping windows or pop-up menus.
Mesa the language (MPS 1971, named 1974, self-hosting 1976) owes nothing to Smalltalk either. Sweet's "patterned after those of Smalltalk [Kay76]" refers to the Dec 1976 Mesa 1.0 debugger's optional, "experimental" window manager. It never touched compiler, binder or OS and was dropped in Mesa 4.0.
Smalltalk influence is documented for Star and for Cedar's environment goals, both 1980s. For the Alto software of 1973–75 there is none; for Mesa 1976–77 it is BitBlt plus an experimental debugger add-on. BitBlt and overlapping windows were specifically Ingalls' work, which he internally demonstrated in 1975.
Mesa and Cedar are both programming languages which have nothing in common with Smalltalk. Cedar is also a later development environment. The original post was about Smalltalk vs. Objective-C, i.e. a language comparison, and then mentioning some graphic tools as well. Thus the comment I responded to was ambiguous in different respects. That's why I asked. It has nothing to do with the discussion you referenced.
Mesa and Cedar interested me as I got into programming languages, but I was more into Trellis/Owl (and had copies of the documentation provided to me by DEC SRC after I wrote to them).
Trellis/Owl, now that's a trip down memory lane. Kilian's paper on the compiler was my entry point into doing databases for the last ~30 years, for odd reasons.
I really don’t remember much influence of smalltalk on interlisp at the time (I worked in the KSL, though I was working on 3Lisp so Interlisp was in theory just our implementation language…but of course boundaries were not what PARC was about.
All of that was common in MACLISP (MIT) and InterLISP (BBN) before PARC was founded. It was part of the lineage Alan talked about when founding PARC. DWIM was Teitelman’s PhD thesis (BTW his advisor was Minsky, which seems odd today but was normal back then).
Rochus and I were arguing about this a couple of weeks ago, and I read through a bunch of historical papers, including Teitelbaum talking about how Smalltalk influenced Interlisp-D and Lampson more or less attributing the GUI to Smalltalk: https://news.ycombinator.com/item?id=49857855
I had no idea about the Interface Builder Lisp history!
An another lot of people doesn't know that Smalltalk-76 onwards implemented the Simula 67 object model (as the first language in the given completeness), which represented a fundamental departure in that respect from Smalltalk-72. See the Ingalls 1978 and 2020 papers for more information.
I got to meet Brad Cox at college when he came to visit one of my professors (who I worked with after hours). I find it interesting that instead of the objects as tiny computers of Kay he thought of software ICs and then pulled from Smalltalk to implement those concepts in Objective-C, but in the simplest way possible (almost just combining the two side-by-side) as opposed to Stroustrup being more heavily influenced by Similar (especially as he was actually building simulations) and extending C into objects to gain performance that Simula didn’t have.
People naturally get hung up on the syntax and the interop story with existing popular languages, but it’s the object model differences between Smalltalk, Objective-C, Self, C++… that really matter.
Yes, for example, while Java was inspired by C++ for its syntax and target audience, the object model and JVM semantics are closer to Smalltalk/Objective-C than C++.
The interface/@protocol, JAR files/Bundles, services/plugins, proxy objects/categories,....
In many ways NeXTSTEP can be thought of as a “pragmatic Smalltalk environment” that traded some of Smalltalk’s dynamism for improved compatibility with the Unix ecosystem. Recall that NeXT’s original target market was higher education, which even in the 1980s started relying on Unix. This was the era of the Unix workstation, and NeXT can be considered a competitor to Sun, SGI, HP, DEC, and other Unix workstation vendors. NeXT’s differentiator was its Smalltalk-inspired object-oriented environment, built on Objective-C.
I wonder, though, what a pure Smalltalk workstation would’ve looked like, and what hardware would’ve been necessary to make it fast. After all, the late 80s were the era of Lisp machines, though Lisp machines were much more expensive than NeXT cubes ever were. If I recall correctly, Smalltalk on the Xerox Alto was slow, but David Patterson (of RISC fame) had a PhD student who worked on a performant version of the Smalltalk VM, and some of that work went to a spiritual successor named Self, which heavily influenced the design of the Java VM. I remember Java feeling slow in the mid-1990s, but that might be due to bad memories of Java applets rather than a fundamental problem with Java VMs.
Tektronix sold Smalltalk workstations [1], you could run Lisp on them as well. You may have been able to run Smalltalk-80 on a Xerox Daybreak which was a fair bit faster than an Alto.
The first JIT was written by L Peter Deutsch for Smalltalk targeting the 68020.
Your original Smalltalk port described in "Bits of History, Words of Advice" wasn't on top of an operating system but the 4404 does have one. What was the reason for this, was it to be able to run the other languages on the 4404?
When I was in college, Brad Cox came and gave a talk about Objective-C (and more generally his 'software IC' ideas). He was pretty clear how Smalltalk was a key influence. His book on ObjC discusses it as well. Very interesting stuff, even now.
I had the pleasure of learning OOP with Smalltalk at university back in 2002. They used it as the second language (Lisp was the first) to teach the principles. I really loved it. What I admired most was that you “lived” in your program. Later on, Java (1.4) was taught, but coming from Smalltalk, everything felt cumbersome, especially working with collections.
Of all the languages I’ve used in my professional career so far, only Ruby has sparked the same joy.
For me, it was Hamburg, Germany. They later replaced Smalltalk with Java and BlueJ, IIRC. It had a similar visual feel (you could click on a class and create an instance of it that then floated around), but it was far from pure OOP.
I've OCR'ed and corrected Yoot Saito's 1992 interview with Alan Kay, and also restored the missing appendix sections with illustrations that are not included in Bret's version of Alan Kay's Early History of Smalltalk, and compiled and linked together indexes of people, institutions, technologies and a timeline:
In 1993, game designer Yutaka "Yoot" Saito interviewed Alan Kay for MACWORLD Japan, for the special issue marking the Macintosh's tenth anniversary (January 1994). The conversation was recorded on cassette and later transcribed. It had only been published in Japan.
Kay covers his own path through computing history: the Flex Machine, Xerox PARC, the graphical user interface, the Dynabook concept, and the creation of Smalltalk and object-oriented programming. He and Saito also discuss networking, education, simulation, and where personal computing might go next. Saito connects these ideas to game design.
During the interview both men appear to be working from Kay's HOPL paper, The Early History of Smalltalk, and its appendices as a shared reference. When Kay says "in that," "in there," or "in the appendix," the links in the transcript point to the relevant section where it can be identified.
The interview also documents Saito's role as a bridge between Japanese game and media culture and the US computing research that produced the personal computer.
Alan Kay's Early History of Smalltalk: Complete Local Edition
This is the local reading guide for Alan Kay's HOPL paper, The Early History Of Smalltalk, together with the restored appendix material, figures, presentation transcript, discussant remarks, Q&A, and related documentation preserved in this repository.
Credit and thanks to Bret Victor for publishing the cleaned-up HTML edition of the paper body and accompanying image set at worrydream/EarlyHistoryOfSmalltalk. The local paper body and EarlyHistoryOfSmalltalk-* PNG files are derived from Bret's public edition. The appendix Markdown files here are local readable renderings from the OCR/plain-text appendix sources and local scans.
Somewhat related, I’ve been digesting this long but fascinating talk about the even earlier history of OOP, going all the way back to the 1950s. It’s from the perspective of someone who questions some early decisions about what OOP would become. Implementation inheritance, of course, which iirc is something Kay calls out as more accidental than principled language design decision in this paper. But also things like the physical arrangement of data in memory, and how all of this affects what kinds of problems will be easier or harder to solve.
https://www.youtube.com/watch?v=wo84LFzx5nI Casey #Muratori’s keynote about, largely, #disjoint-unions and how it is sad that #C++ doesn’t have them. “I’m not saying OOP was a mistake. I’m saying this [a compile-time hierarchy of encapsulation that matches the domain model] was a mistake.” Also traces the #history of records in #programming-languages through Simula and Hoare’s record-handling paper and the “plex” of Douglass Ross of the MIT Servomechanisms Laboratory in AED, Algol Extended for Design, and also #Sketchpad, which had in-memory records (“chickens”) linked together in circular linked lists, which apparently was an idea he got from Ross (“n-component elements”). Both Ross’s plexes and Sketchpad had function pointers in the records. (But the constraint solver was “the most unencapsulated thing that you could possibly imagine”.) Also documents how Looking Glass in 01998 introduced the #Entity-Component-System pattern in Ultima II Underworld, but really introduced it with Tom Leonard’s Thief: The Dark Project. At 82'40” he points out that he independently invented a worse version of ECS at definitionSIX for Negaman in 01997. “It’s just, I sucked at it, and Looking Glass was good.” Basically his “35-year mistake” thesis is that we almost had ECS in 01963 with Sketchpad, but it took until 01998. He likens 01990s OOP dogma to playing Magic: The Gathering, which I think is insightful. At 136'45” he tells his devotee Ryan Fleury that he has snatched the stone from his hand and may now leave. Nice quote: “You should focus on the hardest stuff. You should say, ‘what solves the hardest problems?’ because we can always then take that and scale it down, and remove things from it or dumb it down, for people to use in cases that aren't as hard. But it’s almost impossible to take something that only solves simple problems and scale it up to something that solves hard ones.”
Alan Kay and Bjarne Stroustrup both talked about their Simula lineage at Kristen Nygaard's 100-year birthday celebration at Aarhus University (Aug 27 2026), and had some spicy back-and-forth discussion afterwards!
> Kay came to Simula as a reader, turned it into Smalltalk, and later knew Nygaard and Dahl as colleagues. Stroustrup was taught by Nygaard in person, as a student at Aarhus, and then used Simula for his PhD.
> Roughly: Stroustrup said he never took much from Smalltalk. What he took from Simula was the static part, compile-time guarantees and a direct map to hardware with zero-overhead abstraction, and C++ was never meant to be just an object-oriented language, since not everything is a class hierarchy or a virtual function. Kay argued that late binding pays for itself because the human is the slow part of an interactive system, and that static typing is a good idea applied prematurely.
Before his talk, Alan performed an accidental improvisational avant garde layered audio feedback loop about Claude Shannon, when somebody had the live stream playing out loud near an open Zoom mic:
Alan Kay: Shannon Gave Us a Way of Dealing with Noisy Channels:
Alan Kay> Shannon gave us a way of dealing with noisy channels. I think about that almost every day.
And here's a history of object-oriented programming as a series of subtractions, from Simula to Smalltalk to Self to Korz, that I wrote for Nygaard's centenary:
> Nygaard and Ole-Johan Dahl built Simula at the Norwegian Computing Center to simulate things like ships moving through harbors and customers waiting in queues. [...] He never thought of programming as separate from the people it was for.
Alan Kay> An interesting historical note is that the two inventors of Simula had completely different views of what they were doing and how it should be used for programming. Dahl was brilliant and conservative, and later wrote papers about using class definitions to make Abstract Data Types (and that is how a lot of so-called OOP programming is done today). Nygaard on the other hand was quite a wonderful wild man and visionary -- beyond brilliant -- and was into the abstract "simulate the meaningful structures"...
worrydream is Bret Victor's site. He gave some electrifying talks in the past like The Future of Programming (https://www.youtube.com/watch?v=8pTEmbeENF4). I really miss those!
There really should be a term for people that somehow got exposure to a tool (like Smalltalk) that despite being technically superior (or even just more interesting) but didn't succeed in popularity. They tend to be forever destined to long for a past when they had the freedom to use such a tool, and constantly bemoaning the state of current tools and listing the reasons why current tools are inferior.
The disorder suffered by a particularly egregious variety of bigot, those who believe that the marginality of their preferred machine is the result of some kind of industry-wide conspiracy (for without a conspiracy of some kind, the eminent superiority of their beloved shining jewel of a platform would obviously win over all, market pressures be damned!) Those afflicted are prone to engaging in flame wars and calling for boycotts and mailbombings. Amiga Persecution Complex is by no means limited to Amiga users; NeXT, NeWS, OS/2, Macintosh, LISP, and GNU users are also common victims. Linux users used to display symptoms very frequently before Linux started winning; some still do. See also newbie, troll, holy wars, weenie, Get a life!.
Bah, there he goes again! ESR has a terrible reputation and track record of misappropriating, misquoting, and ideologically redefining hacker culture in his corrupted version of the MIT AI Lab Jargon file (not to mention his vile and unrepentent racism).
"Amiga Persecution Attitude(TM)" is a term I fictionally trademarked in the X-Windows Disaster chapter of the Unix-Haters Handbook in 1994, which ESR ripped off without attribution and misquoted as "Amiga Persecution Complex" in version 4.1.0 of his Jargon File in 1999. He even used my examples, NeWS and NeXT.
ESR suffers from Attribution Deficit Disorder, which, to borrow his own definition, is "the disorder suffered by a particularly egregious variety of bigot", and I won't argue with him about that.
>Unfortunately, NeWS and NeXTSTEP were political failures because they suffer from the same two problems: oBNoXiOuS capitalization, and Amiga Persecution Attitude(TM).
He even admits we discussed this stuff in the late 80's before the Unix Haters Handbook was published. Although he's wrong I wasn't explicitly credited with the chapter I wrote, which is a weird thing to say, then not credit me himself when he rips off a term I'd been using for years.
ESR> Though it’s not explicitly credited, I’m fairly sure most of this chapter was written by Don Hopkins. Don is a wizard hacker and a good man who got caught on the wrong side of history, investing a lot of effort in Sun’s NeWS just before it got steamrollered by X, and this chapter is best read as the same bitter lament for NeWS I heard from him face to face in the late 1980s.
You're right! I'd forgotten about that. Except for the 01980s conversation, which I hadn't heard of.
I don't agree with all of your criticisms of ESR (who, amusingly, is uncredited on the page I linked) but certainly the term was published in the UNIX-HATERS handbook long before.
Speaking of which, are there UNIX-HATERS archives?
And one from my own archive, about how to apply by submitting a flame to prove your Unix Hatred:
From: "Pandora B. Berman" <CENT@AI>
Subject: request
Date: 17 December 1989 at 12:06:15 GMT+1
To: till@____
Date: Tue, 12 Dec 89 14:52:39 PST
From: Don Tillman <till@____>
To: Postmaster@AI
Subject: request
Hiya. Would it be possible for me to get added to the Unix-haters
mailing list? Thanks muchly.
many things are possible. Moon might turn blue, for instance (if we lock
him outside without his jacket for too long, say). it is certain, though,
that as official a body as Postmaster@AI would not touch such a request
with a 10" light pen; that might be construed as giving official sanction
to discussion of such a subversive topic, and besides the unix-haters are
anarchists and would never stand for it. However, if you can provide us
with sufficient good cause -- a short flame, say, on your pet piece of unix
braindeath, or references from recognized authorities that you are a unix
hater in good standing -- then we will be glad to give your request all due
consideration..
Funny, but it was originally intended for the average person to develop their own software for the upcoming PC revolution. So the language was meant to be small and easy to learn. Something a child could learn to use.
Burroughs Large System (aka B5000-B8500) still (virtually) exist as Unisys Clearpath MCP. You could download a VM if you wanted to try it (I assume you still can).
BiiN and i960 are sorta the same thing to the extent that Intel took the BiiN work after that project died and commercialized it as the i960. Unfortunately, except for the early i960MC, XA & XM versions, Intel was busy stripping feature out of it to make an embedded processor instead of making use of the really cool parts. What might have been...
Alongside updated manuals for NEWP, one of the very first (almost) memory safe systems programming languages, and probably the one that introduced the concept of unsafe code blocks (JOVIAL doesn't seem to have had them).
I was never a Smalltalk programmer ((although I did once debug a fairly simple Smalltalk module by looking at the printout of the code). But I did work for awhile in an OOPL built on top of Smalltalk. That project died because it was too slow, but also because the Smalltalk vendor the project used went out of business, leaving an incompatible and expensive Smalltalk as the only one left standing. (At least that's what I was told.)
Today the project is written in C++, which had the advantages of being free and fast (and as far as I can tell, incomprehensible and prone to crashing).
81 comments
[ 0.27 ms ] story [ 14.0 ms ] thread[1] https://www.instantiations.com/
>Call or Email for Pricing
and the upgrade pricing is four figures (per set per year I'm guessing?).
Ages ago, I actually bought a Smalltalk for Windows compiler, but never got around to doing anything with it (which I regret) --- I suppose I should try Dolphin SmallTalk....
The term 'footgun' unfortunately matches all too well: something so great, so powerful yet most of the time, even in the hands of well-intended folks, proceeds to shoot oneself in the foot. I was for more than a decade a professional Smalltalk developer (Telecommunications, Financial/Derivatives) but we were replaced by technically inferior systems, mostly Java, JavaScript and even VisualBasic. The HR person at the Financial company explained (after my exit interview!) that for the cost of a single Smalltalk developer, they could hire 4 or 5 lesser experienced programmers (less cognizant of how systems actually worked!). The HR folks preferred these hires: more selection, cheaper . etc. Sigh!
Am I a horrible person to enjoy so much (schadenfreude!) the upcoming AI/LLM footgun massacre?
If the big labs wouldn't have the incentive of hiding the code and making you rely solely on the models, you'd probably also see more inspection tools and contextual changes when the model does them.
They were the ones that almost on day one pivoted their Smalltalk offerings into Java.
Eclipse still has the Visual Age Smalltalk object browser.
If you look into OS/2 documentation, and SOM (OS/2 version of COM), you will find out Smalltalk on OS/2 had a role similar to .NET on Windows.
I think AI is the revenge of Lisp, dealing with Python without JIT, and the whole 4 GLs, CASE tooling that tried to automate programming in the 1990's, this time around it goes.
Perhaps it’s because I haven’t had a coffee yet, but I’m not following/parsing this last paragraph - can you expand?
Lisp was the AI language, alongside Prolog (see Japan's 5th generation computing project).
Instead of having nice Interlisp-D and Symbolics machines with their graphical tooling, hot code reloading and machine code generation, we got Jupiter notebooks and C/C++/Fortran libraries on a pure interpreted language [0].
Additionally in the 1990's there were several efforts to move into the next level of programming, with more human like languages, CASE tooling, RUP method (with UML), most of them failed, SQL is one of the survivors, think its declarative nature.
https://en.wikipedia.org/wiki/Programming_language_generatio...
https://en.wikipedia.org/wiki/Computer-aided_software_engine...
https://en.wikipedia.org/wiki/Rational_unified_process
So while not all of those ideas caught on as expected, now we get to program in natural language, use Markdown waterfall plans for agents, integrate them with Web services, seat reading email and Internet surfing until their activities are ready for review.
In low code/no code cloud platforms like Workato, Boomi and co, classical programming is already past tense.
[0] - Granted now JIT is being part of CPython roadmap, and there are some nice IDEs for Python actually.
Were you using IBM Visual Age Smalltalk?
This is a good history:
https://computerhistory.org/blog/the-deep-history-of-your-ap...
Mesa and Cedar influenced Niklaus Wirth to come up with Modula-2/Lillith and Oberon.
Which had an influence on Rob Pike, on how he developed ACME for Plan 9.
Meanwhile StrongTalk, and Objective-C ended up influencing how Java came to be, and its approach to JIT compilation.
On another track Smalltalk ends up influencing Self design, which ends up having an effect on how V8 JIT was designed.
Then there is Ruby as well.
Pity that with all of this, many still never tried what actually means to use Smalltalk.
Note that Interface Builder started as a Lisp prototype, before being acquired by NeXT.
https://paulhammant.com/2013/03/28/interface-builders-altern...
There is a bit more of a timeline in a talk [1] he gave at INRIA a couple of years before he died.
[1] https://www.inria.fr/en/jean-marie-hullot-perforated-cards-i...
In what respect? What sources for this claim do you have?
I will hunt down the papers.
You should be, because I spent hours telling you about it, in detail, with citations from the designers of the Alto and Bravo, less than two weeks ago. At the time you conceded the point and said it was not what you intended to dispute: https://news.ycombinator.com/item?id=49857855
I hope not.
And please note that this is again a different topic.
Last time I was talking about Wirth's OO vs. Simula OO, and the similarity of Wirth's implementation with Kay's vision. You then first extended this discussion to whether Kay directly influenced Wirth, which I responded. Then you extended the topic even more to the question whether and to what degree Cedar was influenced by Smalltalk. That was far off my interest and irrelevant for the discussion given that Wirth just took the tiling window manager, which none of the Smalltalk versions had.
Now I'm talking about the development of the Alto computer which included an OS with a GUI and two groundbreaking applications, Bravo and Gypsy (implemented on top of Bravo), all in BCPL, implementing their own interaction and presentation concepts.
If you want to do historical research, you have to go to the primary sources (e.g. https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/xe..., the Alto source code archive of the CHM, or e.g. https://archive.org/details/Xerox_PARC_Gypsy_Demonstration_T...), not to stories written down from memory twenty years later.
I do not believe that Wirth's "OO" is a different topic. To the best of my understanding, the reason he added procedure-typed record fields in Modula-2 and retained them in Oberon was specifically in order to implement that tiling window manager, which in later versions of Mesa (and Cedar) replaced the overlapping-window GUI in earlier versions of Mesa, which came from Alan Kay's 01969 doctoral dissertation, by way of Smalltalk.
> Kay's 1969 thesis has no overlapping windows; its "windows" are Sutherland–Sproull clipping viewports into a vector-display virtual screen ("the terminology follows [A Clipping Divider, 1968]", p. 40); nothing occludes or moves. Overlapping bitmap windows first appear in Smalltalk-72 on the Alto (1973–74), implemented by Ingalls. Tiling did neither come from Mesa nor from Kay; multiple tiled windows were on screen in Engelbart's NLS in 1968 (Engelbart & English, FJCC 1968, and the demo), carried into PARC by his former team (English, Irby), and are the stated model for the Mesa debugger. Procedure types in Modula-2 (1977–80, for Lilith) were taken from Mesa after Wirth's 1976–77 PARC stay, years before Cedar's tiled Viewers (1982), which Wirth saw in 1984–85.
Unfortunately, and horrifyingly, this response is [dead].
I agree with some things in it, but not others, and I will have to write a longer response later.
That's strange. I didn't do anything and it still appears on the site in my browser. Did they add "shadow bans" to HN? That was one reason for me to turn my back on Facebook (and the fact that interesting discussions suddenly disappeared later on).
https://www.lri.fr/~mbl/ENS/FundHCI/2013/papers/XeroxStar-Co...
A few quotes from it,
> SunView is an example of a window system that is based upon the Tools metaphor rather than the Desktop metaphor. Its users see a collection of application program windows, each of which is used to edit certain files. Smalltalk-80, Cedar, and various Lisp environments also use the Tools metaphor rather than the Desktop metaphor
> The Reactive Engine -- While Engelbart et al were developing ideas, some of which eventually found their way into Star, Alan Kay, then a graduate student, was doing likewise. His dissertation, The Reactive Engine, contained seeds of many ideas that he and others later brought to fruition in the Smalltalk language and programming environment, which, in turn, influenced Star.
> Most importantly for Star, they demonstrated the power of graphical, bitmapped displays, mouse-driven input, windows, and simultaneous applications. This is the most visible link between Smalltalk and Star, and is perhaps why many people wrongly believe that Star was written in Smalltalk.
> Even though the machine was designed to run Star, it also ran other software. In addition to selling it as the 8010 "Star" workstation, Xerox sold it as a server machine and as an Interlisp and a Smalltalk workstation.
From this other one, some quotes as well,
"The Mesa Programming Environment"
https://dl.acm.org/doi/pdf/10.1145/17919.806843
> Client programs can attach additional information to windows by means of named contexts, similar to property lists of LISP. Tools can be written to have multiple instances, obtaining their data from the context associated with the particular window that Tajo is notifying (passed as a parameter to the notify procedure).
> The debugger had multiple windows patterned after those of Smalltalk [Kay76]. One, a typescript window, was used for interaction with the debugger executive for setting breakpoints, examining data, etc., and another was used to show the source context at breakpoints.
There are a few others with similar one off sentences like these, telling how designers from one system got influenced by the other, while at Xerox PARC.
The Alto OS, Bravo (1974) and Gypsy (1975) were written in BCPL by CSL/POLOS people (Lampson, Sproull, Simonyi, Tesler, Mott); the June 1975 Alto OS manual and Alto Packages contain nothing from Smalltalk, and they had no overlapping windows or pop-up menus.
Mesa the language (MPS 1971, named 1974, self-hosting 1976) owes nothing to Smalltalk either. Sweet's "patterned after those of Smalltalk [Kay76]" refers to the Dec 1976 Mesa 1.0 debugger's optional, "experimental" window manager. It never touched compiler, binder or OS and was dropped in Mesa 4.0.
Smalltalk influence is documented for Star and for Cedar's environment goals, both 1980s. For the Alto software of 1973–75 there is none; for Mesa 1976–77 it is BitBlt plus an experimental debugger add-on. BitBlt and overlapping windows were specifically Ingalls' work, which he internally demonstrated in 1975.
Paul McJones has a nice Mesa History Collection with a lot of primary sources from the time: https://softwarepreservation.computerhistory.org/mesa
I should made myself clear it wasn't the programming languages grammar or semantics by themselves.
I had no idea about the Interface Builder Lisp history!
ref: https://www.abebooks.com/9780201834543/Object-Model-Lippman-...
The interface/@protocol, JAR files/Bundles, services/plugins, proxy objects/categories,....
I wonder, though, what a pure Smalltalk workstation would’ve looked like, and what hardware would’ve been necessary to make it fast. After all, the late 80s were the era of Lisp machines, though Lisp machines were much more expensive than NeXT cubes ever were. If I recall correctly, Smalltalk on the Xerox Alto was slow, but David Patterson (of RISC fame) had a PhD student who worked on a performant version of the Smalltalk VM, and some of that work went to a spiritual successor named Self, which heavily influenced the design of the Java VM. I remember Java feeling slow in the mid-1990s, but that might be due to bad memories of Java applets rather than a fundamental problem with Java VMs.
The first JIT was written by L Peter Deutsch for Smalltalk targeting the 68020.
[1] https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/te... [2] https://en.wikipedia.org/wiki/Xerox_Daybreak
https://www.inria.fr/en/jean-marie-hullot-visionary-computer...
Yoot Saito Alan Kay Interview: Introduction:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
In 1993, game designer Yutaka "Yoot" Saito interviewed Alan Kay for MACWORLD Japan, for the special issue marking the Macintosh's tenth anniversary (January 1994). The conversation was recorded on cassette and later transcribed. It had only been published in Japan.
Kay covers his own path through computing history: the Flex Machine, Xerox PARC, the graphical user interface, the Dynabook concept, and the creation of Smalltalk and object-oriented programming. He and Saito also discuss networking, education, simulation, and where personal computing might go next. Saito connects these ideas to game design.
During the interview both men appear to be working from Kay's HOPL paper, The Early History of Smalltalk, and its appendices as a shared reference. When Kay says "in that," "in there," or "in the appendix," the links in the transcript point to the relevant section where it can be identified.
The interview also documents Saito's role as a bridge between Japanese game and media culture and the US computing research that produced the personal computer.
Yoot Saito Alan Kay Interview:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
A Journey Through Computing History with Yoot Saito and Alan Kay
And here are missing secions from Bret's version of Alan Kay's Early History of Smalltalk:Early History of Smalltalk, Complete:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
Alan Kay's Early History of Smalltalk: Complete Local Edition
This is the local reading guide for Alan Kay's HOPL paper, The Early History Of Smalltalk, together with the restored appendix material, figures, presentation transcript, discussant remarks, Q&A, and related documentation preserved in this repository.
Credit and thanks to Bret Victor for publishing the cleaned-up HTML edition of the paper body and accompanying image set at worrydream/EarlyHistoryOfSmalltalk. The local paper body and EarlyHistoryOfSmalltalk-* PNG files are derived from Bret's public edition. The appendix Markdown files here are local readable renderings from the OCR/plain-text appendix sources and local scans.
The Early History Of Smalltalk:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
Detailed paper body index:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...<...
https://worrydream.com/EarlyHistoryOfSmalltalk/#smalltalkAnd...
In this way, it was the older brother of Logo, but with a core object scaffold that was far more influential.
https://youtu.be/wo84LFzx5nI
https://www.youtube.com/watch?v=wo84LFzx5nI Casey #Muratori’s keynote about, largely, #disjoint-unions and how it is sad that #C++ doesn’t have them. “I’m not saying OOP was a mistake. I’m saying this [a compile-time hierarchy of encapsulation that matches the domain model] was a mistake.” Also traces the #history of records in #programming-languages through Simula and Hoare’s record-handling paper and the “plex” of Douglass Ross of the MIT Servomechanisms Laboratory in AED, Algol Extended for Design, and also #Sketchpad, which had in-memory records (“chickens”) linked together in circular linked lists, which apparently was an idea he got from Ross (“n-component elements”). Both Ross’s plexes and Sketchpad had function pointers in the records. (But the constraint solver was “the most unencapsulated thing that you could possibly imagine”.) Also documents how Looking Glass in 01998 introduced the #Entity-Component-System pattern in Ultima II Underworld, but really introduced it with Tom Leonard’s Thief: The Dark Project. At 82'40” he points out that he independently invented a worse version of ECS at definitionSIX for Negaman in 01997. “It’s just, I sucked at it, and Looking Glass was good.” Basically his “35-year mistake” thesis is that we almost had ECS in 01963 with Sketchpad, but it took until 01998. He likens 01990s OOP dogma to playing Magic: The Gathering, which I think is insightful. At 136'45” he tells his devotee Ryan Fleury that he has snatched the stone from his hand and may now leave. Nice quote: “You should focus on the hardest stuff. You should say, ‘what solves the hardest problems?’ because we can always then take that and scale it down, and remove things from it or dumb it down, for people to use in cases that aren't as hard. But it’s almost impossible to take something that only solves simple problems and scale it up to something that solves hard ones.”
Kristen Nygaard 100 Years, Celebration Symposium:
https://cs.au.dk/nygaard100years/celebration
Entire Nygaard Symposium Recording (Alan Kay's talk begins at 3:27:49):
https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0...
Bjarne Stroustrup's talk:
https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0...
The discussion afterwards:
https://au.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=fe0...
https://news.ycombinator.com/item?id=49850612
> Kay came to Simula as a reader, turned it into Smalltalk, and later knew Nygaard and Dahl as colleagues. Stroustrup was taught by Nygaard in person, as a student at Aarhus, and then used Simula for his PhD.
> Roughly: Stroustrup said he never took much from Smalltalk. What he took from Simula was the static part, compile-time guarantees and a direct map to hardware with zero-overhead abstraction, and C++ was never meant to be just an object-oriented language, since not everything is a class hierarchy or a virtual function. Kay argued that late binding pays for itself because the human is the slow part of an interactive system, and that static typing is a good idea applied prematurely.
Before his talk, Alan performed an accidental improvisational avant garde layered audio feedback loop about Claude Shannon, when somebody had the live stream playing out loud near an open Zoom mic:
Alan Kay: Shannon Gave Us a Way of Dealing with Noisy Channels:
https://www.youtube.com/watch?v=Cjntrqhn8pk
https://news.ycombinator.com/item?id=49848295
Alan Kay> Shannon gave us a way of dealing with noisy channels. I think about that almost every day.
And here's a history of object-oriented programming as a series of subtractions, from Simula to Smalltalk to Self to Korz, that I wrote for Nygaard's centenary:
https://news.ycombinator.com/item?id=49874023
> Nygaard and Ole-Johan Dahl built Simula at the Norwegian Computing Center to simulate things like ships moving through harbors and customers waiting in queues. [...] He never thought of programming as separate from the people it was for.
http://worrydream.com/EarlyHistoryOfSmalltalk/
Alan Kay> An interesting historical note is that the two inventors of Simula had completely different views of what they were doing and how it should be used for programming. Dahl was brilliant and conservative, and later wrote papers about using class definitions to make Abstract Data Types (and that is how a lot of so-called OOP programming is done today). Nygaard on the other hand was quite a wonderful wild man and visionary -- beyond brilliant -- and was into the abstract "simulate the meaningful structures"...
https://freedictionary.org/search/amiga_persecution_complex
The disorder suffered by a particularly egregious variety of bigot, those who believe that the marginality of their preferred machine is the result of some kind of industry-wide conspiracy (for without a conspiracy of some kind, the eminent superiority of their beloved shining jewel of a platform would obviously win over all, market pressures be damned!) Those afflicted are prone to engaging in flame wars and calling for boycotts and mailbombings. Amiga Persecution Complex is by no means limited to Amiga users; NeXT, NeWS, OS/2, Macintosh, LISP, and GNU users are also common victims. Linux users used to display symptoms very frequently before Linux started winning; some still do. See also newbie, troll, holy wars, weenie, Get a life!.
Oddly it doesn't mention Smalltalk!
"Amiga Persecution Attitude(TM)" is a term I fictionally trademarked in the X-Windows Disaster chapter of the Unix-Haters Handbook in 1994, which ESR ripped off without attribution and misquoted as "Amiga Persecution Complex" in version 4.1.0 of his Jargon File in 1999. He even used my examples, NeWS and NeXT.
ESR suffers from Attribution Deficit Disorder, which, to borrow his own definition, is "the disorder suffered by a particularly egregious variety of bigot", and I won't argue with him about that.
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
>Unfortunately, NeWS and NeXTSTEP were political failures because they suffer from the same two problems: oBNoXiOuS capitalization, and Amiga Persecution Attitude(TM).
He even admits we discussed this stuff in the late 80's before the Unix Haters Handbook was published. Although he's wrong I wasn't explicitly credited with the chapter I wrote, which is a weird thing to say, then not credit me himself when he rips off a term I'd been using for years.
https://web.archive.org/web/20250422231516/http://esr.ibibli...
ESR> Though it’s not explicitly credited, I’m fairly sure most of this chapter was written by Don Hopkins. Don is a wizard hacker and a good man who got caught on the wrong side of history, investing a lot of effort in Sun’s NeWS just before it got steamrollered by X, and this chapter is best read as the same bitter lament for NeWS I heard from him face to face in the late 1980s.
I don't agree with all of your criticisms of ESR (who, amusingly, is uncredited on the page I linked) but certainly the term was published in the UNIX-HATERS handbook long before.
Speaking of which, are there UNIX-HATERS archives?
Here are some Unix Haters archives:
https://github.com/anticomputer/unix-haters-archive/
And one from my own archive, about how to apply by submitting a flame to prove your Unix Hatred:
Smalltalk is conceptual-centric in ways that are remarkably deep.
Pity our hardware architectures couldn't give us better hardware support.
Not that they didn't tried:
- Burroughs B5000 (1961)
- Intel iAPX 432 (1981–1986)
- BiiN project (1985–1990)
- Intel i960
- Rekursiv (Linn)
- jHISC ~2005
- MOOSS 2003
- Structural Object Processor (Xilinx)
BiiN and i960 are sorta the same thing to the extent that Intel took the BiiN work after that project died and commercialized it as the i960. Unfortunately, except for the early i960MC, XA & XM versions, Intel was busy stripping feature out of it to make an embedded processor instead of making use of the really cool parts. What might have been...
Today the project is written in C++, which had the advantages of being free and fast (and as far as I can tell, incomprehensible and prone to crashing).