Rendered at 23:42:23 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
avaer 11 hours ago [-]
Just like learning Lisp will make you rethink programming languages, and learning Erlang will make you understand the true power of concurrency: learning Smalltalk will make you understand what "object oriented" actually means.
I haven't used Squeak since college but I'm glad it was part of the cirriculum.
Btw, almost all of Javascript's good parts come from Smalltalk.
kitd 9 hours ago [-]
For me, Smalltalk's "wow" moment was the concept of a persistently running image, with the developer's job being to mould and manipulate it into the shape s/he wants.
morphle 3 minutes ago [-]
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
embedding-shape 31 minutes ago [-]
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.
dev_dan_2 15 minutes ago [-]
I never made that connection, it makes sense though!
whartung 6 hours ago [-]
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.
unignorant 6 hours ago [-]
I'm also interested in this and made decent progress on a git-style content addressed image where everything is identified by hash and residency determines what's in memory. For example, there's a filesystem on the image that works this way and you can page over the "cold" non-resident bytes for very large files that you would not want to hold in memory.
You don't persist the state of the full image continuously to the host disk, but any given state (new programs, new runtime state, filesystem) can be saved via a delta, not a full rewrite, due to this representation.
So this is a little different than what you are talking about, but I'd say it's possible.
3 hours ago [-]
actionfromafar 4 hours ago [-]
Sounds a somewhat like GemStone/S
I think also IBM has or had somewhat similar concepts.
I remember object or object relational databases were popular at one time. maybe they still are to some extent.
packetlost 8 hours ago [-]
There are Lisps with similar semantics. It faded (further) out of popularity for a number of reasons, but it still has its niche.
pjmlp 6 hours ago [-]
Additionally, although not the same, this kind of relates to JIT caches as well.
Quitschquat 8 hours ago [-]
Which Lisps were those? I'm kinda interested in this space.
jlokier 3 hours ago [-]
It's not widely known, but GNU Emacs works like this.
When you launch the Emacs editor, you're loading an Emacs Lisp image that was populated at build time by running Lisp code, with the resident Lisp definitions "dumped" to make an image file.
The image file used to actually be the `emacs` executable you'd run, using a clever but non-portable mechanism called `unexec` to make an executable.
But as of version 27.1 (in 2020), the image file is separate from the executable for portability reasons.
vincent-manis 40 minutes ago [-]
There are a number of image-based Scheme systems. Chibi Scheme and Chez Scheme come to mind. In both, you can save an image and reload it at a later time, though for very good reasons, most people start each session with a fresh copy of the default image.
mike_ivanov 7 hours ago [-]
All Common Lisps can do that, though it is not a part of the standard. See e.g. (sb-ext:save-lisp-and-die)
packetlost 5 hours ago [-]
CL and Janet both come to mind as supporting image-based deployment.
waldrews 6 hours ago [-]
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.
NetMageSCW 2 hours ago [-]
Is APL no longer mainstream-ish?
e12e 4 hours ago [-]
You could argue that a Claude code session also works like a lisp/smalltalk image.
TheTaytay 7 hours ago [-]
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.
fidotron 6 hours ago [-]
I think the gnarlier part is that it reveals how much (and how error prone) initialization code is. When objects start glued together in the right structure a lot becomes magically easier to deal with.
lilbigdoot 7 hours ago [-]
I'm considering this for my language but it's a lot more complex to implement (especially with today's ecosystems) and I keep wondering if it's worth it.
xjdjdkdjn 6 hours ago [-]
Imagine inheriting not your colleague’s code, but his entire machine. Then you discover this machine also is the production environment.
Lisp, Forth, Erlang, Smalltalk, and Rebol, so easily forgotten.
All languages that multiply your insight into the nature of computer programming. A bit sad that many just stop at the first of these, and many more don’t even venture past their Pythons and Javascripts.
iLemming 2 hours ago [-]
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.
ux266478 9 hours ago [-]
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.
Qem 8 hours ago [-]
Also SNOBOL/Icon.
zelphirkalt 6 hours ago [-]
The more of them you explore, the more insight you get. The list does not have to be complete. It just needs to list some languages, that are truly different in how they work and what the ideas behind them are.
uncircle 7 hours ago [-]
I blame the unknown unknowns. I don’t haven’t learned Prolog yet. Alas, enlightenment still eludes me.
(Agreed that TCL is pretty cool)
konart 9 hours ago [-]
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.
tvink 9 hours ago [-]
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.
sbuttgereit 8 hours ago [-]
From what I've seen... I think if I were writing business applications, I'd reach for Elixir... if I were writing something lower level like communication software, I'd reach for Erlang.
I have written a fair amount of Elixir (and targeting business applications) and I think Elixir's expressiveness lends itself well to making more abstract models of the business processes and data seen in solving business problems. However, writing Elixir I find you end up reading a lot of Erlang and in certain problem spaces I could imagine the appeal over Elixir. I could absolutely see where if I were writing more technically oriented programs.... programs closer to the hardware in some ways or programs designed to communicate with other programs (protocols, etc.) I could see Erlang as being a more clear and direct language in these circumstances.
All of this is very hand-wavy, but it's my impression.
ux266478 8 hours ago [-]
For me, Elixir misses the mark. If you're an unc with a background in Ruby or that era of webdev, I can see the appeal. It's a familiar set dressing. I don't have that background, I much prefer the syntactic structure of Erlang's psuedo-horn clauses. Both for similar familiarity reasons (I knew Prolog before I touched Erlang), as well as a general preference for the simplicity.
vanderZwan 3 hours ago [-]
> If you're an unc with a background in Ruby or that era of webdev
Millennials catching strays I see.
uncircle 7 hours ago [-]
The similarity of Ruby and Elixir is only extremely superficial and betrays your lack of familiarity with the language.
ux266478 7 hours ago [-]
I didn't imply otherwise, nor is the story different on the Erlang-Prolog axis (actually it's even more pronounced there.) I literally called it "set dressing". Where I think you go off the rails is that you're conflating surface-level things with irrelevance. Which isn't really true, especially in matters of taste.
I find this to be a very strange thing to get defensive about. It's not exactly a subtle part of Elixir's history. It was pretty well documented to be born out of the creator's dissatisfaction with concurrency in Ruby, and simultaneously, for a more Ruby-like language on the BEAM. That doesn't mean it's literally Ruby-on-the-BEAM (which was originally attempted, and didn't work out), however mistaking that as cause to dismiss the link between the two and the carry-over appeal for developers is an unsound overcorrection.
7 hours ago [-]
foldr 6 hours ago [-]
Phoenix is a big part of the appeal of Elixir, independently of the differences between Elixir and Erlang.
pjmlp 5 hours ago [-]
While I appreciate guest languages for bringing new ideas to specific language platforms, at the end of the day I rather use those that are developed alonside the platform, hence Erlang instead of Elixir, at least if I would be ever doing something with it again.
Last time I touched Erlang, "Learn you some Erlang for great good!" was fresh out of the printers.
doublerabbit 5 hours ago [-]
I loved Erlang. I want to use it, those who can master mnesia natively are a powerful wizard/ess. I've only touched the surface and seen it's raw power.
I've just not had time to learn further. As swapping between languages when trying to complete my original Tcl project is tricky. I'm now poking around with Crystal.
A rookie example of erlang and converting strings to base16. I posted in haste a while ago on Tcl's IRC but fun. Never did implement the teddy bear colour.
Elixir brings mostly a new syntax, and little more. I rather use Gleam IF i really need to use the BEAM.
Other than that, vanilla Erlang is THE way to go.
2 hours ago [-]
NetMageSCW 2 hours ago [-]
No love for APL?
andsoitis 8 hours ago [-]
And Prolog and Assembly!
uncircle 7 hours ago [-]
Assembly is very useful to learn, but does not bring as strong a paradigm shift, as it is similar to most other imperative, procedural languages.
vanderZwan 3 hours ago [-]
Bootstrapping a Forth in assembly is probably a better option, two birds with one stone.
addaon 11 hours ago [-]
> almost all of Javascript's good parts come from Smalltalk
Is this underselling the role of Self in JS’s prototype-based object system, or saying that a prototype-based object system is not one of the good parts?
sscaryterry 10 hours ago [-]
Prototypical inheritance has caused so many, many vulnerabilities...
sebastianconcpt 7 hours ago [-]
And some months ago I was flirting with the idea of "Smalltalk and Erlang had a baby" and have Smalltalk syntax to an actor environment ran by a Erlang VM style. Plus some insanely cool ideas about a causal debugger for distributed bugs.
The problem is that as beautiful as programing in that sound, we're not even coding anymore, AIs will take the fun of it.
Although, thinking long term and for understendabilitymaxxin and reliabilitymaxxin it might still be worth having something like that.
Since Smalltalk can be so close to english and Erlang VM so reliable, humans and LLMs should thrive on it.
jonjacky 6 hours ago [-]
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!
moomoo11 5 hours ago [-]
i think it’s a good thing.
experts will emerge from this convenience focused paradigm we are entering so the output quality will certainly improve imo.
mncharity 4 hours ago [-]
> 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.
gliall_err 7 hours ago [-]
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.
WillAdams 9 hours ago [-]
I would give a lot for a version of Squeak which could instantiate standard GUI controls and easily compile to a stand-alone binary or HTML page w/ included JavaScript.
I didn't understand programming at all until I read about (not even tried) Smalltalk. And it's because of Smalltalk I write Ruby today.
My favourite thing about it is the lack of "reserved words" - just a handful of punctuation marks. It's incredibly pure - almost all of the syntax is "send this message to this object".
gosukiwi 2 hours ago [-]
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 :)
vanderZwan 7 hours ago [-]
> Btw, almost all of Javascript's good parts come from Smalltalk.
That's E and Self erasure.
throwatdem12311 8 hours ago [-]
As a Ruby developer this video about Pharo smalltalk made me a smalltalk believer — not surprising because Ruby was heavily inspired by smalltalk.
I also had Squeak in my curriculum! From what I remember it had a unique object hierarchy or something like
kar1181 7 hours ago [-]
If you think of it as message oriented it makes so much more sense.
CobrastanJorji 4 hours ago [-]
Georgia Tech in the Mark Guzdial days?
Jtsummers 4 hours ago [-]
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.
lilbigdoot 7 hours ago [-]
I thought JS had a lot of Scheme inspiration?
Jtsummers 7 hours ago [-]
Scheme and Self were both major influences, along with Java's syntax (by fiat).
>Btw, almost all of Javascript's good parts come from Smalltalk.
Like what, exactly? I'm genuinely curious. There is no root object or message passing in JS, and the OO aspects are only incidentally bolted on (classes don't actually exist, prototypal inheritance was an afterthought), named params are newer sugar, and polymorphism is a struggle due to all of the above. I've always thought of JS as what Crockford himself said: "a Lisp in C's clothing".
tl 9 hours ago [-]
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.
6 hours ago [-]
Smalltalker-80 8 hours ago [-]
I agree, but JS has evolved so far, that when using TypeScript, you can mostly ignore the underlying mismatch.
tvink 9 hours ago [-]
A big influence for modern js is chained enumeration, like forEach
bowsamic 8 hours ago [-]
The main thing you’ll learn is that actually the static and inflexible abstractions of an operating system do a lot to protect the system integrity and prevent everything from blowing up. Many smalltalk VMs rely on recovery features for a reason
codesnik 8 hours ago [-]
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.
Congrats to the Squeak 6.1 team! I was an early contributor to Squeak from when Alan Kay's group was at Apple (I see that SameGame, the first game implemented in Morphic is still in the image), and still enjoy following the progress of Squeak and all of its spinoffs.
mannycalavera42 4 hours ago [-]
More stories please! :)
Decabytes 8 hours ago [-]
one thing I love about Smalltalk is being able to inspect the code as it's running. Especially from the GUI. You can just be like Oh I wonder where the code for this button is from, inspect it, and it takes you right to the code. It's a shame we can't have this level of introspection without negative performance implications.
eitland 7 hours ago [-]
We could in Java Swing (and Visual basic, but lets not talk about that) as well. Well, not runtime, but we could design applications and just right click on the objects in the IDE and go directly to the click (or double click or right click) handlers.
Then again, not having to disable this for runtime is a feature if you ask me.
Yes, current web applications are prettier and easier to upgrade but we lost a lot on the way wrt developer experience and ux.
davexunit 10 hours ago [-]
What are the best books/papers/blog posts to learn about Morphic's architecture? I'm not a user of any Smalltalk implementation but I'd like to learn more as the Smalltalk approach to UI is very interesting.
pjmlp 9 hours ago [-]
Morphic started on Self actually, maybe start there?
I am unaware how it evolved since then, especially given the differences between Self and Smalltalk.
Is it because of its length giving false signals ?
DonHopkins 6 hours ago [-]
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:
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.
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:
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:
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:
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.
srean 6 hours ago [-]
I had vouched for your comment but it did not have any effect. Please email Dang, it seems to be a false positive of some sort.
Love your long comments.
> Oh I've posted much longer than that (see the one I linked) without getting flagged
Those were simpler times
Jtsummers 6 hours ago [-]
I vouched as well, but it's [flagged][dead] not just [dead] which is usually the result of user moderation, not the mods or auto moderation (which typically will just render as [dead] in either case). Which was odd because it was [flagged][dead] by the time it was 4 minutes old (maybe earlier, that's just when I saw it).
DonHopkins 6 hours ago [-]
I am just hoping and praying somebody will post something about Bakelite. Hold my beer!
Oh shit, I just missed a Bakelite discussion 17 days ago!
But there's a comment from 9 days ago that's still replyable. ;)
DonHopkins 7 hours ago [-]
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:
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.
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:
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:
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:
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.
isr 1 hours ago [-]
Can I suggest you take a look at Cuis Smalltalk (a simplified fork from squeak), and any of the talks given by Juan Vuletich (main author of cuis). In Cuis, Juan took morphic back to basics and updated it heavily. Now submorphs use relative geometry (not absolute), and everything is hardware accelerated vector graphics - EVEN THE FONTS.
Seriously, reading Unicode enhanced code in a 45 degree tilted editor window, while zooming in and out just for kicks (all of this can be done by manipulating the morph with its halo's menu) just to see how crisp everything is - thats FUN!
Also, try taking apart the standard system browser (4 panes + editor), rearrange everything as per your tastes (by drag & drop), and ... everything still works
Glamorous Toolkit is built on Pharo, which I think is a fork of Squeak or shares lineage with it.
ioasuncvinvaer 9 hours ago [-]
It's not about AI
brabel 9 hours ago [-]
Are you joking? GTK is not about AI either (though yeah they put LLMs in it if you want), it's another Smalltalk environment.
flowardnut 2 hours ago [-]
i mean look at the site linked. It's beating you over the head with AI immediately
broswell 7 hours ago [-]
I just downloaded on Windows 11. My antivirus (Symantec Endpoint Protection) did not like it and erased the executable. I reinstalled and got it working.
Question? Does this work with Etoys? If so, how? I tried following various directions online without success. Thanks!
goodthink 7 hours ago [-]
Help/Useful Expressions has some EToys instructions.
The Squeakland images stopped getting upograded when Squeeak went 64-bit (I think).
You can get a "halo" on any object, click the Inspector icon (the eye) and create an etoys script from there.
Also, under Extras/Themes and Colors there is a Set Etoys Mode option. You can try that but, it didn't work last night.
Lastly, files.squeak.org/etoys has a 6.0beta image you can download. Drop the image/changes into SqueakJS [1] (that is the only way to run a 32bit image).
And after all these years, still no fixes for high-DPI displays. The UI is still pixely and slow. Perhaps I should take Fable and try myself, this was the only bug I cared about and it is not solved after 10 years at least.
sswezey 10 hours ago [-]
Same, I've been tracking this and Pharo for high-DPI fixes. Pharo is working on a new graphics stack that is intended to address this as well, but until then no high-DPI support.
sczi 7 hours ago [-]
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.
mparrett 10 hours ago [-]
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.
I opened the Squeak image on my Mac, and everything looks good that I checked.
AdmiralAsshat 9 hours ago [-]
The UI has been a huge impediment in my getting into Squeak development. Every couple years I decide I will try it again, and then see that very little has changed.
It's a shame. Smalltalk/Squeak/Pharo was supposed to be the future, but it feels like an IDE stuck in the 90's.
morphle 1 hours ago [-]
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 haven't used Squeak since college but I'm glad it was part of the cirriculum.
Btw, almost all of Javascript's good parts come from Smalltalk.
(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.
You don't persist the state of the full image continuously to the host disk, but any given state (new programs, new runtime state, filesystem) can be saved via a delta, not a full rewrite, due to this representation.
So this is a little different than what you are talking about, but I'd say it's possible.
I think also IBM has or had somewhat similar concepts.
https://en.wikipedia.org/wiki/GemStone/S
https://en.wikipedia.org/wiki/InterSystems_Cach%C3%A9
Which I heard about from a friend who was using it at work.
https://en.wikipedia.org/wiki/Comparison_of_object_database_...
Caché is first one in the table.
I remember object or object relational databases were popular at one time. maybe they still are to some extent.
When you launch the Emacs editor, you're loading an Emacs Lisp image that was populated at build time by running Lisp code, with the resident Lisp definitions "dumped" to make an image file.
The image file used to actually be the `emacs` executable you'd run, using a clever but non-portable mechanism called `unexec` to make an executable.
But as of version 27.1 (in 2020), the image file is separate from the executable for portability reasons.
or my language https://github.com/timbran-project/mica
All languages that multiply your insight into the nature of computer programming. A bit sad that many just stop at the first of these, and many more don’t even venture past their Pythons and Javascripts.
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.
(Agreed that TCL is pretty cool)
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 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.
I have written a fair amount of Elixir (and targeting business applications) and I think Elixir's expressiveness lends itself well to making more abstract models of the business processes and data seen in solving business problems. However, writing Elixir I find you end up reading a lot of Erlang and in certain problem spaces I could imagine the appeal over Elixir. I could absolutely see where if I were writing more technically oriented programs.... programs closer to the hardware in some ways or programs designed to communicate with other programs (protocols, etc.) I could see Erlang as being a more clear and direct language in these circumstances.
All of this is very hand-wavy, but it's my impression.
Millennials catching strays I see.
I find this to be a very strange thing to get defensive about. It's not exactly a subtle part of Elixir's history. It was pretty well documented to be born out of the creator's dissatisfaction with concurrency in Ruby, and simultaneously, for a more Ruby-like language on the BEAM. That doesn't mean it's literally Ruby-on-the-BEAM (which was originally attempted, and didn't work out), however mistaking that as cause to dismiss the link between the two and the carry-over appeal for developers is an unsound overcorrection.
Last time I touched Erlang, "Learn you some Erlang for great good!" was fresh out of the printers.
I've just not had time to learn further. As swapping between languages when trying to complete my original Tcl project is tricky. I'm now poking around with Crystal.
A rookie example of erlang and converting strings to base16. I posted in haste a while ago on Tcl's IRC but fun. Never did implement the teddy bear colour.
http://paste.tclers.tk/6165
Other than that, vanilla Erlang is THE way to go.
Is this underselling the role of Self in JS’s prototype-based object system, or saying that a prototype-based object system is not one of the good parts?
The problem is that as beautiful as programing in that sound, we're not even coding anymore, AIs will take the fun of it.
Although, thinking long term and for understendabilitymaxxin and reliabilitymaxxin it might still be worth having something like that.
Since Smalltalk can be so close to english and Erlang VM so reliable, humans and LLMs should thrive on 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!
experts will emerge from this convenience focused paradigm we are entering so the output quality will certainly improve imo.
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.
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.
It ain't a version of Squeak, though.
My favourite thing about it is the lack of "reserved words" - just a handful of punctuation marks. It's incredibly pure - almost all of the syntax is "send this message to this object".
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 :)
That's E and Self erasure.
https://youtu.be/HOuZyOKa91o
https://dl.acm.org/doi/10.1145/3386327
Like what, exactly? I'm genuinely curious. There is no root object or message passing in JS, and the OO aspects are only incidentally bolted on (classes don't actually exist, prototypal inheritance was an afterthought), named params are newer sugar, and polymorphism is a struggle due to all of the above. I've always thought of JS as what Crockford himself said: "a Lisp in C's clothing".
https://drcuis.github.io/TheCuisBook/The-Change-Log.html
Then again, not having to disable this for runtime is a feature if you ask me.
Yes, current web applications are prettier and easier to upgrade but we lost a lot on the way wrt developer experience and ux.
I am unaware how it evolved since then, especially given the differences between Self and Smalltalk.
https://handbook.selflanguage.org/2017.1/morphic.html
https://sin-ack.github.io/posts/morphic-intro/
Is it because of its length giving false signals ?
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.
Love your long comments.
> Oh I've posted much longer than that (see the one I linked) without getting flagged
Those were simpler times
Oh shit, I just missed a Bakelite discussion 17 days ago!
https://news.ycombinator.com/item?id=49026992
But there's a comment from 9 days ago that's still replyable. ;)
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.
Seriously, reading Unicode enhanced code in a 45 degree tilted editor window, while zooming in and out just for kicks (all of this can be done by manipulating the morph with its halo's menu) just to see how crisp everything is - thats FUN!
Also, try taking apart the standard system browser (4 panes + editor), rearrange everything as per your tastes (by drag & drop), and ... everything still works
[1] https://gtoolkit.com/
Question? Does this work with Etoys? If so, how? I tried following various directions online without success. Thanks!
[1]https://github.com/codefrau/SqueakJS
> 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...
It's a shame. Smalltalk/Squeak/Pharo was supposed to be the future, but it feels like an IDE stuck in the 90'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. 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