Hacker News

For me, that was my "I'm getting out of here before I break it irreversibly" moment while working through some introductory tutorial ~20 years ago; I've never touched Smalltalk again. I can't understand why being bespoke and unreproducible would be a desirable thing for software.

(Yes, clearly I don't "get it". Happy to hear explanations.)

Ive always "dreamed" of having something like the ST image but backed by persistent virtual memory, not simply RAM.

(Crudely) mmap the ST image to a 100GB file and just change pages. Let the OS flush the pages back and forth.

Maybe full boat, heap sweeping GCs would be Bad as it pages the entirety of the heap in and out. But we have (had) lots of RAM these days. We have generational GCs that leave idle stuff alone. Its no doubt impractical, but I think it would be neat to have the entirety of my historical email in the global "mailbox" array, and I can build indexes off it as I wished. But the mail isn't "on disk", it's all marshalled up as first class objects.

I don't know enough about it, no doubt it "won't work", but the idea of simply mapping the entire, large, ST VM heap to a persistent backing store, just be interesting I would think.

Dangerous too, as there is a demarcation between "running image" and "saved image". But, still think it could be interesting.

NixOS is kind of like that, the image being the environment you end up with running the system. Difference being you tend to edit the source code of small programs passing/transforming data, package manifests and definitions in NixOS, instead of using the "Inspector" to find and browse live Objects of the image/system and figuring out what comes from where, then running things in the REPL to edit them into the right shape with imperative commands, or use the little widgets to enter/edit data.

I have an image with an uptime 2007-2020 and a still working image 50 years old. Images run bit-identical on all platforms because they are byte coded virtual machines

There are Lisps with similar semantics. It faded (further) out of popularity for a number of reasons, but it still has its niche.

The only mainstream-ish language where that still happens? R. Too bad, there's a lot more use cases for this sort of thing now - versioning, anything non-persistent agents touch, collaboration, auditable enterprise LOB. It's 2026, why are we (or our agents) still writing serialization code? Even if the AI's write the boilerplate, the state management fragility is often a tax/risk.

I wish this didn’t go out of fashion as much as it did. An environment that you perturb makes more sense in a lot of ways than a “tear it down and restart” model.

Like LambdaMOO (or my variant of it https://github.com/timbran-project/moor)

or my language https://github.com/timbran-project/mica

Lisp is not "forgotten". It's quite alive, kicking and running [big] circles.

Nubank (the largest digital bank in the world) using Clojure as their primary driver grew from ~12M customers in 2019 to 131M in 2025 - almost 1000% growth in less than a decade. JPMorgan that has about 80M customers took around 150 years and dozens of acquisitions.

Apple, Walmart, Netflix, Cisco, Amazon - they all use Clojure. Google and Grammarly use Common Lisp.

Check the GitHub language stats and be surprised to see Emacs Lisp among the visible top. There's so much Elisp on GitHub alone - it's just effing crazy. That fact alone at least should be surprising. Remember? This is a not a general-purpose language - it's made for one and only thing, tis a damn configuration language for a text editor. And no, it isn't "some old stuff", check r/emacs - new packages get announced daily! I'm not even exaggerating - new stuff for Emacs comes every single day. Who the heck are all these psychos? Have they not realized how "forgotten" and "dead" Lisp was?

Seriously though, Lisp dialects are enormously practical, it is inconceivable today to find a runtime where you just can't run stuff built with a Lisp. And Lispers keep adding more - Janet, Jank, Jolt, Fennel, Clojure-Dart, Cljbang, Squint - all are pretty young, yet already not some "useless toys" - they're used to build real stuff.

And that's completely natural. Compare it with woodworking.

Yes, some people would dive deep into the craft and create works of art, exquisite furniture and tools they need to make it even better.

But those are the few. For the most of woodworkers this is just something they somehow learned to do on a level needed to be able to get a job and make living.

I find that lamentation a bit funny, because the list in practice is never really complete. For instance, you forgot the mighty Prolog. Surely, tcl belongs on there too.

Wouldn't you just do elixir now? It's like erlang but even wilder.

I think smalltalk and erlang are so interesting because they model the idea of small computers so differently.

Lisp just feels like the purest way to understand what the units of a programming language really is.

Favorited and commenting on this so I can get back to this :)

My version of that list, in no particular order: Smalltalk, Haskell, C, Lisp, Prolog, Forth.

And Prolog and Assembly!

No love for APL?

Prototypical inheritance has caused so many, many vulnerabilities...

I was flirting with the idea ... Plus some insanely cool ideas ... The problem is that as beautiful as programing in that sound, we're not even coding anymore, AIs will take the fun of it.

We've come to this. The mere existence of AI is discouraging people from pursuing creative ideas. This is a catastrophe! It's not just taking the fun out of life, it's destroying alternative futures we might have built.

There is this advice for dealing with tyrants and would-be tyrants: "Do not obey in advance." In your case that means pursuing and implementing your exciting ideas.

... it might still be worth having something like that.

Yes! Good luck with it!

> we're not even coding anymore, AIs will take the fun of it.

Or... Writing a compiler from a large language test suite is already an LLM sweet spot. Writing code which is atypically pretty and readable isn't... but there's at least a possibility of that changing someday.

Imagine a future Lisp-ish culture of "write code to communicate with humans - prioritize readability - machine execution is incidental" and "don't merely solve a problem - write a language for the problem space (and keep it cleanly updated)"... but moving at LLM-catalyzed speed. So much fun.

Metalworking, lathes, precision tooling, are all way more valuable skills and tools today than they ever were before the industrial revolution.

I suspect that over time a good grasp of fundamentals and great tooling will only get more valuable in software as well as automation expands, in whichever form.

Automation expands the demand for skills. It can never diminish it. Required variety indicates that complexity doesn't go away with automation, and at some level someone will have to understand and make decisions about complex issues. You can't automate all the way down. Or, put another way, everything is already automated all the way down. The expansion of automation as we perceive it is merely the growth of complexity over new dimensions.

Or put a third way: automation means two different things: constraint and liberty. The confusion arising from not discerning which one is in force makes it seems like one can grow unbounded. Liberty requires constraint and vice versa.

This looks like Gilad Bracha's Newspeak: https://en.wikipedia.org/wiki/Newspeak_(programming_language...

Objective-Smalltalk with Interscript. https://objective.st

It ain't a version of Squeak, though.

SmallJS (https://small-js.org) does what you want mostly. In the sense that a standalone desktop app can be made with NW.js.

For the HTML/JS side see https://amber-lang.net but not updated for a few years

I learned about Smalltalk from Ruby, because DHH recommended a book about Smalltalk back in the day. I really enjoy Smalltalk-style OOP, but at the same time it can be so different to Java enterprise OOP with all its patterns.

Nowadays I write a lot of TypeScript and prefer having a type system (especially for agentic coding), but Ruby is one of my favorite languages to write myself :)

Thanks for sharing. This piqued my interest.

I was about to make the same comment. Squeak and Scheme were mind expanding points of curriculum for me.

I still remember writing a Ga Tech themed version of The Sims in Squeak. I felt omnipotent being able to inspect or modify any object while debugging the game mechanics engine I’d written; that was a fun project.

That was going to be my guess, too. Looking through some syllabi over the years it looks like they used Scala for it for a while and Python, more recently.

Scheme and Self were both major influences, along with Java's syntax (by fiat).

https://dl.acm.org/doi/10.1145/3386327

Ignore the syntax for a moment. Minus Javascript, HTML + CSS is a green screen terminal with better fonts and image support. Message passing (fetch, XMLHttpRequest, polling, streaming, etc...) is how you build something that feels like a real tool out a system where the sandbox gets in the way of everything you want to hold locally.

I agree, but JS has evolved so far, that when using TypeScript, you can mostly ignore the underlying mismatch.

A big influence for modern js is chained enumeration, like forEach

recovery features? how do they work? and what smalltalk runtime do you have in mind? I still have a very vague understanding on how changes could be applied to a production running images, or if there is one and preferable way to do that.

@DonHopkins your comment is flagged dead.

Is it because of its length giving false signals ?

After Self, the short lineage is Self (~1992, Smith & Maloney) -> Squeak port (Maloney & Ingalls, Etoys/Scratch 1) -> two independent JavaScript reimplementations, plus Squeak-in-the-browser via SqueakJS. I dug into this same question a decade ago and posted a longer treatment -- my email exchange with Alan Kay on MVC vs Morphic vs watchers, plus replies on Self's "soup of objects" UI. Good philosophical complement to the architectural links below:

https://news.ycombinator.com/item?id=8841428

Self Morphic is not a classical class hierarchy. The handbook describes parallel traits objects (shared behavior) and prototypes (structure), with instances delegating via parent* slots and "copy-down" differential prototypes. Bottom-up: morph copy, tweak, factor shared behavior into a traits object. Worth reading section 7.3 alongside pjmlp's links.

https://handbook.selflanguage.org/2017.1/morphic.html

The Squeak port is single-inheritance Smalltalk classes -- closer to what most people mean by "OOP UI toolkit." Etoys is Morphic. Full Squeak Morphic in a browser, no install:

https://try.squeak.org/

Squeak 6.1 release notes (Objectland, tree morph overhaul):

https://squeak.org/release_notes/6.1/

In JavaScript there are two Morphic implementations people often conflate. Same family, not the same code.

Dan Ingalls's Lively Kernel / Lively Web (~2008, Sun) is the full live system: modular core/lively/morphic/ (Halos, Serialization, Scrubbing, Connectors, constraints), plus IDE, parts bin, world persistence. JSConf 2012 demo:

https://github.com/LivelyKernel/LivelyKernel

https://github.com/LivelyKernel/LivelyKernel/tree/master/cor...

http://youtu.be/QTJRwKOFddc

Jens Monig's morphic.js (~2010, BYOB4/Snap!) is a separate codebase: single-file Canvas kernel (~13k lines), World/Hand/stepping/dirty rects, template peel-off, ScrollFrame inertial pan. Jens names Ingalls's LK as the gold standard but says it is not a direct port -- though fullCopy() was ported almost literally from Squeak, comments included. Snap bundled it from day one (2013-03-16). Standalone extract:

https://github.com/jmoenig/Snap/blob/master/src/morphic.js

https://github.com/jmoenig/Snap/blob/master/docs/morphic.txt

https://github.com/jmoenig/morphic.js

https://wiki.squeak.org/squeak/6550

https://en.wikipedia.org/wiki/Morphic_(software)

On multiple inheritance: neither JS port uses it, and Self Morphic didn't really either. LK cheats with an explicit Trait composition layer (Object.subclass plus Trait(...) mixins). Snap cheats with Squeak-style copying (fullCopy, isTemplate peel-off). The live feel comes from copyable morph trees and shared behavior, not MI.

If you want one more readable architecture tour beyond sin-ack's intro, the Self handbook chapter 7 is still the root document; everything else is commentary on it.

https://cuis.st/

Are you joking? GTK is not about AI either (though yeah they put LLMs in it if you want), it's another Smalltalk environment.

Yes. I don't know Swift, but it appears that Swift's protocol and class are similar to Java's interface and implementation (class), and defining a protocol would be required in Swift in order to define a generic table.LOOKUP(key) operator.

Does Glamorous Toolkit work for you? It's pharo with a different rust based GUI stack, and some batteries included for making custom inspector views and such. I don't have a high DPI display so I'm not completely confident, but my understanding is that their rust based GUI works fine with high DPI.

I see some movement on high-DPI in the latest release. What are the current gaps? I'm not familiar with the project, just curious.

> Improves high-DPI support for buttons, scroll panes, sliders, menus, multi-selection lists, trees, drop-shadows, the scratch pad, the keyboard exerciser, and others.

https://squeak.org/release_notes/6.1/#:~:text=and%20dialog%2...

Wow, never heard of it! Thank you!

I have at least eight different GUIs implemented in Squeak and also native Xwindows, macOS, iPhone and Windows. Plus several through the FFI interface. And three/seven Web GUI interfaces. We used to run (around 2009) Squeak on more platforms than Linux, they all still work in the 32 versions. I'll make the old bitrotted GUI's work again in the latest Squeak 6.1 if you pay me a few thousand euro's.

I count many more native GUI support in all Smalltalk versions https://github.com/jeceljr/SmalltalkSurvey

Squeak goes back all the way to 1972, we ran on most GUIs in existence. Smalltalk was the invention of the first GUI. https://smalltalkzoo.computerhistory.org

See many of my old comments on my 18 years on HN https://news.ycombinator.com/threads?id=morphle

I even have the most scalable (massively parallel) GUI written in a few thosand lines of code: https://youtu.be/f1605Zmwek8?t=3100

And several 3D GUIs https://www.youtube.com/watch?v=1s9ldlqhVkM&t=4s and the highly scalable https://www.youtube.com/watch?v=uQTeWJNkylI

It should not be a problem, given how many love to use CLI and TUI workflows stuck in the 1960-80's. :)