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).
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! Thank you for digging that up!
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.
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.
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 and extensive quotes 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.
> 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). I took me more than half an hour to re-check all sources; I (we) probably shouldn't spend that much time on comments anymore.
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.
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?
> 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/replaced 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.
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?
I've been looking for one of these for years. Dont think ive ever seen one for sale. Sadly my retrocimputing days (especially for such rare and likely expensive machines) is about over. I've met people willing to strike me good deals on lisp machines, but these are just a bit too obscure perhaps.
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 from Smalltalk-72. See the Ingalls 1978 and 2020 papers for more information (https://dl.acm.org/doi/10.1145/512760.512762 and https://dl.acm.org/doi/10.1145/3386335, both more interesting and relevant than the one in the title, written by the person who invented most of the technology we today know as Smalltalk-80).
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,....
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.
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.
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.
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?
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.
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.
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).
Smalltalk didn't start until 1971/2 (Alan Kay started at Xerox in early 1971 as a consultant and then joined as a full time member). It's covered in the HOPL article above
Brian Harvey> I admit that my slogan "Snap! is Scheme disguised as Scratch" would sort of push in the direction of hygienic macros. But historically we built Snap! more with the idea of Logo disguised as Scratch. It was just when we added lambda that we started thinking more in Scheme terms.
Alan Kay> The fact that kids were to be the users, and the simplicity and ease of use of the already existing LOGO, whose own parents were LISP and JOSS (which set a standard for the esthetics for interaction that has not yet been surpassed), provided lots of motivation to have programs and transactions appear as simple as possible-i.e. moving from left to right, procedures gather their own messages, etc. It is no accident that simple SMALLTALK programs look a bit like LOGO!
Don Hopkins> Here is the source code to LLogo in MACLISP, which I stashed from the MIT-AI ITS system. It's a fascinating historical document, 12,480 lines of beautiful practical lisp code, defining where the rubber meets the road, with drivers for hardware like pots, plotters, robotic turtles, TV turtles, graphical displays, XGP laser printers, music devices, and lots of other interesting code and comments.
Lars Brinkhoff suggests that this comp.lang.logo thread with Brian Harvey and Leigh Klotz is required reading:
Brian Harvey> Wally Feurzeig started the whole thing by organizing a group at Bolt, Beranek, and Newman, Inc., to study the educational effects of teaching kids a programming language. The first language they used, like most programming languages, was focused on numeric computation, and it was Wally's idea that kids would find it more natural to work in an area they knew better, namely natural language; therefore, he set up a team to design a language featuring words and sentences. Wally made up the name "Logo."
Brian Harvey> The team Wally put together at BBN included Seymour Papert and Dan Bobrow. The three of them are credited as the designers of the first version of the language; Dan wrote the first implementation.
Leigh Klotz> In the mid 1970's, when the AI Lab Lisp Machine project was just getting underway, Marvin Minsky and Danny Hillis (later to found Terrapin, and still later, Thinking Machines) put together a project to build a Logo machine.
Lars Brinkhoff> Now also BBN PDP-10 Logo, MIT CLOGO, MIT Lisp Logo, and hopefully soon MIT Apple II Logo (direct ancestor of Terrapin Apple II Logo).
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).
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.”
I'm interested to see the results of your digestion too!
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" idea. Dahl was trying to fix the past and Nygaard was trying to invent the future.
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.
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 unrepentant racism).
"Amiga Persecution Attitude(TM)" is a term I'd been using for years before I fictionally trademarked it in the X-Windows Disaster chapter of the Unix-Haters Handbook in 1994, and ESR ripped it off without attribution and misquoted it 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.
Don> Unfortunately, NeWS and NeXTSTEP were political failures because they suffer from the same two problems: oBNoXiOuS capitalization, and Amiga Persecution Attitude(TM).
Anyway, "Amiga Persecution Complex" sounds too much like "Military Industrial Complex", which implicitly gives Amiga users too much credit for power and organization and influence. It's not complex: Amiga, NeWS, NeXT and Lisp users have ATTITUDE.
In his 2008 review of the book, he even admits we'd discussed this stuff face to face in the late 1980s, years before the Unix-Haters Handbook was published. He also complains that I wasn't explicitly credited for the chapter, which I was. It's a weird thing to say from someone who took a term from that very chapter without credit, corrupted the wording, and shaved off the fictional (TM).
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.
And his story doesn't even make chronological sense. In the late 1980s NeWS was alive and kicking, and I was enthusiastically hacking and evangelizing it, not lamenting it. I didn't go to work at Sun on NeWS until the early 1990s. I started porting SimCity to NeWS and HyperLook in 1991 and shipped it in 1992, and Sun didn't cancel X11/NeWS until late 1993. So what he heard from me face to face in the late 1980s wasn't a "bitter lament" for something that hadn't died yet. He's retconning the outcome into the conversation, just as he retconned my term into his Jargon File.
Even on his own blog, his readers connect the dots. In 2008 someone asked what "Amiga Persecution Attitude" on page 140 of the Unix-Haters Handbook meant, and was told it's "defined in the Jargon File as Amiga Persecution Complex." That's how uncredited appropriation works: the original gets explained by pointing at the copy.
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..
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!
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.
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).
This is a good history:
https://computerhistory.org/blog/the-deep-history-of-your-ap...
Which then influenced Mesa, Cedar, Interlisp-D inside Xerox.
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...
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.
The development experience while using the environment, the debugger, edit-compile-continue, REPL with suggestions for typos, dynamic code loading.
I should made myself clear it wasn't the programming languages grammar or semantics by themselves.
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! Thank you for digging that up!
The LeLisp version of Interface Builder that JMH wrote at INRIA predates the timeline in your link.
That link is the official story I am aware of, where can I read about that one?
I have a paper copy of a paper (in French) about SOS Interface. Had scans of this at one point.
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...
Thanks.
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.
> Which then influenced Mesa, Cedar
In what respect? What sources for this claim do you have?
You and I already went through this discussion at great length two weeks ago, and I came up with lots of sources: https://news.ycombinator.com/item?id=49857855
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.
The Xerox papers on digital archive, I can try to hunt them down, see for example the one on XDE Tajo experience for Mesa.
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.
Yes my claim is about the IDE experience shared across all Xerox PARC environments, and how it affected the design of each language individually.
I will hunt down the papers.
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 and extensive quotes 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 spent hours telling you about it
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..., https://xeroxparcarchive.computerhistory.org/Xerox_PARC_sour..., or e.g. https://archive.org/details/Xerox_PARC_Gypsy_Demonstration_T...), not to stories written down from memory twenty years later.
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.
Rochus has posted a response saying:
> 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). I took me more than half an hour to re-check all sources; I (we) probably shouldn't spend that much time on comments anymore.
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.
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?
[dead]
Here is one such paper,
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.
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/replaced 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
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.
[1] https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/te... [2] https://en.wikipedia.org/wiki/Xerox_Daybreak
https://wirfs-brock.com/allen/things/smalltalk-things/tektro...
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?
I've been looking for one of these for years. Dont think ive ever seen one for sale. Sadly my retrocimputing days (especially for such rare and likely expensive machines) is about over. I've met people willing to strike me good deals on lisp machines, but these are just a bit too obscure perhaps.
Yeah...wouldn't we all like to find a Tek 4404 :-)? You might like to live vicariously through this guy: https://medium.com/@adambillyard/restoring-an-ai-workstation...
He seems to have added emulation of the 4404 to Mame.
I had a brief play on a 4404 at an exhibition when they were new but have never seen any for sale since.
Interface Builder was originally a Lisp project
https://www.inria.fr/en/jean-marie-hullot-visionary-computer...
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 from Smalltalk-72. See the Ingalls 1978 and 2020 papers for more information (https://dl.acm.org/doi/10.1145/512760.512762 and https://dl.acm.org/doi/10.1145/3386335, both more interesting and relevant than the one in the title, written by the person who invented most of the technology we today know as Smalltalk-80).
This is correct.
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.
ref: https://www.abebooks.com/9780201834543/Object-Model-Lippman-...
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,....
s/Similar/Simula/
Similar would be the perfect name for a Simula Simlator.
Slimula is to Simula as Minyma is to Macsyma.
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.
Some prior discussions on this:
https://news.ycombinator.com/item?id=31062369 - April 20, 2022 (45 comments)
https://news.ycombinator.com/item?id=25012425 - Nov 7, 2020 (28 comments)
https://news.ycombinator.com/item?id=17913668 - Sept 4, 2018 (69 comments)
https://news.ycombinator.com/item?id=9907556 - July 18, 2015 (5 comments)
https://news.ycombinator.com/item?id=9588316 - May 22, 2015 (5 comments)
https://news.ycombinator.com/item?id=7926141 - June 21, 2014 (10 comments)
https://news.ycombinator.com/item?id=1311282 - May 1, 2010 (17 comments)
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.
[1] https://www.instantiations.com/
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.
There is Pharo (and Squeak) as a free SmallTalk.
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.
Was it at Carleton? Ottawa seems to have a fondness for Smalltalk and seems to have been a… hotspot for it.
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.
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?
Blame IBM and other Smalltalk vendors.
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?
Sure.
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.
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.
Interesting!
Were you using IBM Visual Age Smalltalk?
I for one already have the popcorn at the ready. Can't wait for it.
Most beautiful computer syntax of the world.
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)
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).
What is the Structural Object Processor?
Another hardware project was MUSHROOM [1]
[1] https://www.wolczko.com/mushroom/index.html
What is really surprising to me is that Smalltalk was originally targeted as an educational language for children:
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.
> it was the older brother of Logo
Logo predated Smalltalk, so Smalltalk is more like an evolution on the idea and a younger brother.
EDIT: Looked up the dates. Logo was made in 1967, Smalltalk started development in 1969.
Smalltalk didn't start until 1971/2 (Alan Kay started at Xerox in early 1971 as a consultant and then joined as a full time member). It's covered in the HOPL article above
I should have checked that.
I remember that Logo was available for my TI-99/4a and assumed it was closer to the '80s.
I'd like to see LOGO but with support for 3-D, accelerated with CUDA
Logo is essentially just Lisp without parens. And Brian Harvey argues that it should have dynamic binding, because that's easier to teach to children.
Brian Harvey on dynamic binding, in the Snap! forum thread "Hygienic macros":
https://forum.snap.berkeley.edu/t/hygienic-macros/3258
I've summarized his points in moollm's snap-macros-metaprogramming.yml under dynamic_binding_and_scope:
https://github.com/SimHacker/moollm/blob/main/designs/snap/s...
He wishes Snap! had dynamic binding, at least for learners. This comes from decades of teaching Logo to kids, and he finds it easier to explain.
In Logo without lambda, the dynamic environment includes everything the lexical one would, plus more of the caller's variables.
Logo's MAP with ? wants name capture: the called procedure reads a variable the caller set.
Logo debugging works in the same language at the REPL, with every relevant local visible at the error.
Name capture rarely bites kids, who write one-off helpers for one or two callers.
He proposed hybrid scope and a DYNAMIC VARIABLES block. Neither shipped. Jens argued for lexical scope only, because blocks must be interchangeable.
https://forum.snap.berkeley.edu/t/hygienic-macros/3258/6
Brian Harvey> I admit that my slogan "Snap! is Scheme disguised as Scratch" would sort of push in the direction of hygienic macros. But historically we built Snap! more with the idea of Logo disguised as Scratch. It was just when we added lambda that we started thinking more in Scheme terms.
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
Alan Kay> The fact that kids were to be the users, and the simplicity and ease of use of the already existing LOGO, whose own parents were LISP and JOSS (which set a standard for the esthetics for interaction that has not yet been surpassed), provided lots of motivation to have programs and transactions appear as simple as possible-i.e. moving from left to right, procedures gather their own messages, etc. It is no accident that simple SMALLTALK programs look a bit like LOGO!
https://news.ycombinator.com/item?id=23054174
Don Hopkins> Here is the source code to LLogo in MACLISP, which I stashed from the MIT-AI ITS system. It's a fascinating historical document, 12,480 lines of beautiful practical lisp code, defining where the rubber meets the road, with drivers for hardware like pots, plotters, robotic turtles, TV turtles, graphical displays, XGP laser printers, music devices, and lots of other interesting code and comments.
Lars Brinkhoff suggests that this comp.lang.logo thread with Brian Harvey and Leigh Klotz is required reading:
https://groups.google.com/forum/#!topic/comp.lang.logo/UqOvE...
https://news.ycombinator.com/item?id=23054236
Brian Harvey> Wally Feurzeig started the whole thing by organizing a group at Bolt, Beranek, and Newman, Inc., to study the educational effects of teaching kids a programming language. The first language they used, like most programming languages, was focused on numeric computation, and it was Wally's idea that kids would find it more natural to work in an area they knew better, namely natural language; therefore, he set up a team to design a language featuring words and sentences. Wally made up the name "Logo."
Brian Harvey> The team Wally put together at BBN included Seymour Papert and Dan Bobrow. The three of them are credited as the designers of the first version of the language; Dan wrote the first implementation.
Leigh Klotz> In the mid 1970's, when the AI Lab Lisp Machine project was just getting underway, Marvin Minsky and Danny Hillis (later to found Terrapin, and still later, Thinking Machines) put together a project to build a Logo machine.
Lars Brinkhoff> Now also BBN PDP-10 Logo, MIT CLOGO, MIT Lisp Logo, and hopefully soon MIT Apple II Logo (direct ancestor of Terrapin Apple II Logo).
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).
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://youtu.be/wo84LFzx5nI
My summary from http://canonical.org/~kragen/human-folly/day/02025-07-22.htm...:
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.”
I'm interested to see the results of your digestion too!
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!
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" idea. Dahl was trying to fix the past and Nygaard was trying to invent the future.
I still have my August 1981 BYTE at work. It and the 1980 FORTH (or TIL) greatly influenced my preferences in programming languages.
(Oh, I also have the blue book, green book and red book at work.)
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:
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...
Appendix I: KiddiKomp Memo 45:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
Appendix II: Smalltalk-72 Interpreter Design 47:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
Appendix III: Acknowledgments 50:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
Appendix IV: Event Driven Loop Example 53:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
Appendix V: Smalltalk-76 Internal Structures 54:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
Appendix VI: Smalltalk Documentation, HOPL Talk, and Discussion:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
References:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
Transcript of presentation:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
And I've made some additional cross references including the Yoot Saito Interview:
People:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
Institutions:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
Technologies:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
Timeline:
https://github.com/YootTowerManagement/YootTower/blob/main/Y...
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.
There's been a term for the phenomenon for decades: "Amiga Persecution Complex":
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!
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 unrepentant racism).
"Amiga Persecution Attitude(TM)" is a term I'd been using for years before I fictionally trademarked it in the X-Windows Disaster chapter of the Unix-Haters Handbook in 1994, and ESR ripped it off without attribution and misquoted it 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...
Don> Unfortunately, NeWS and NeXTSTEP were political failures because they suffer from the same two problems: oBNoXiOuS capitalization, and Amiga Persecution Attitude(TM).
Anyway, "Amiga Persecution Complex" sounds too much like "Military Industrial Complex", which implicitly gives Amiga users too much credit for power and organization and influence. It's not complex: Amiga, NeWS, NeXT and Lisp users have ATTITUDE.
In his 2008 review of the book, he even admits we'd discussed this stuff face to face in the late 1980s, years before the Unix-Haters Handbook was published. He also complains that I wasn't explicitly credited for the chapter, which I was. It's a weird thing to say from someone who took a term from that very chapter without credit, corrupted the wording, and shaved off the fictional (TM).
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.
And his story doesn't even make chronological sense. In the late 1980s NeWS was alive and kicking, and I was enthusiastically hacking and evangelizing it, not lamenting it. I didn't go to work at Sun on NeWS until the early 1990s. I started porting SimCity to NeWS and HyperLook in 1991 and shipped it in 1992, and Sun didn't cancel X11/NeWS until late 1993. So what he heard from me face to face in the late 1980s wasn't a "bitter lament" for something that hadn't died yet. He's retconning the outcome into the conversation, just as he retconned my term into his Jargon File.
Even on his own blog, his readers connect the dots. In 2008 someone asked what "Amiga Persecution Attitude" on page 140 of the Unix-Haters Handbook meant, and was told it's "defined in the Jargon File as Amiga Persecution Complex." That's how uncredited appropriation works: the original gets explained by pointing at the copy.
https://web.archive.org/web/20240525182528/http://esr.ibibli...
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?
Leave it to ESR to attempt to pathologize the attitude that things could be better than they currently are.
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:
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!
Why did they name a programming language after a skill most programmers are bad at?
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.