Squeak 6.1

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.

I've been tempted to learn this so I could port my Pips solver to it, solely because PipSqueak would be a good name.

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.

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.

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.

How does this compare to Glamorous Toolkit[1]?

[1] https://gtoolkit.com/

Smalltalk's been enormously influential and successful... There is however a better way of understanding objects. Namely, "objects" are [defined to be] processes, "messages" are asynchronous, and Smalltalk's message invocations are indirect function calls. I know what you're thinking: "But no OO PL works like that. You won't understand anything that way." That's true: this suggested reframing won't help you understand any popular OO language, because they use indirect function calls instead of asynchronous message passing.

The indirect function calls of Smalltalk don't transform the semantics of programming. It's still data structures and algorithms. You can, if you adopt Kay's ideas wholesale, write programs where individual letters in a text typeset themselves (as Kay describes). I'm arguing that that model of programming is more accurately articulated in an async message passing frame.

Smalltalk's function calls do have an important benefit, which is polysemy. I'm stealing that word and not using it quite right. The benefit is you can define ideas that are not algorithmic. You can for instance define many methods for LOOKUP(key,table) that works for many data structures, and now you've defined not a recipe, but an idea that transcends recipes. Any recipe R that uses LOOKUP automatically works with all the data structures that LOOKUP works with, even though R itself may be a specific recipe for a specific data structure of its own.

That's a tremendous benefit, and it's worth using OO features to take advantage. But even so you're still living in an algorithms and data structures world. Polysemy is a linguistic feature and does not cause a mechanical or paradigmatic change.

Asynchronous messaging however does change how algorithms are designed, in much the way that Alan Kay anticipated, and also in a way that models real world entities in direct fashion. But everyone understands this part already.

So how is this a "better" way of thinking about objects? 1) It emphasizes the advantage of polysemy, which in my experience OO pedagogy tends to overlook, even though most everyone utilizes OO partly for that purpose; 2) It explains why OO programs remain organized as algorithms and data structures; and 3) it welcomes combining "object" techniques with A & DS techniques in the same program or function or even the same line of code. They are completely compatible, in the sense that the language or library or database is not "OO" or "non-OO".

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!

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.

I remember enjoying Smalltalk.

I've been tempted to learn this so I could port my Pips solver to it, solely because PipSqueak would be a good name.

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.

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.

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.

> 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?

> Btw, almost all of Javascript's good parts come from Smalltalk.

That's E and Self erasure.

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.

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".

As a Ruby developer this video about Pharo smalltalk made me a smalltalk believer — not surprising because Ruby was heavily inspired by smalltalk.

https://youtu.be/HOuZyOKa91o

I also had Squeak in my curriculum! From what I remember it had a unique object hierarchy or something like

If you think of it as message oriented it makes so much more sense.

More stories please! :)

Also, try taking apart the standard system browser (4 panes + editor), rearrange everything as per your tastes (by drag & drop), and ... everything still works

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.

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.

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".

As a Ruby developer this video about Pharo smalltalk made me a smalltalk believer — not surprising because Ruby was heavily inspired by smalltalk.

https://youtu.be/HOuZyOKa91o

Morphic started on Self actually, maybe start there?

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/

If you think of it as message oriented it makes so much more sense.

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

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.

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.

@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.

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.

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.

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.

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

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

Glamorous Toolkit is built on Pharo, which I think is a fork of Squeak or shares lineage with it.

[1]https://github.com/codefrau/SqueakJS

Cuis Smalltalk has full high-DPI support as its GUI is based on vector graphics: https://cuis.st/

yeah, after all these years, they are waiting for your contribution. you really should go at it with Fable.

Use the Glamorous Toolkit.

Huh, I actually think it's the opposite. Classic Linux distros like debian are much more like Lisp, everything is the same big mutable pile of state and you query and edit it from within the system itself. The REPL is just your shell. It's very live and interactive and a bit scary at times.

NixOS by contrast takes the entire Linux userland and makes it an immutable, dead compiler artifact. So it is to debian like C or Rust are to Lisp.

I never made that connection, it makes sense though!

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.

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.

Imagine inheriting not your colleague’s code, but his entire machine. Then you discover this machine also is the production environment.

Hehe, this was kind of my thesis back 2015; non public unfortunately, but I think the following is save to share: So basically they had the need to persist huge collections of objects that would not fit into a single servers RAM. As for persistence, a key value NoSQL db was chosen (which is a natural fit for a world where everything has a unique identity - I also have some dislike for ORMs because of that, because I saw how beautiful it could synergize, and how ugly some mechanism are that hibernate, EC Framework etc. have to implement in order to brigde the gap between objects and relational dbs).

The core pattern was that the Proxy, which was under Nil and above all other Objects regarding inheritance I think.

It re-implemented `doesNotUnterstand:` by: 1) First loading the actual object from the persistent storage and 2) sending the not understood message to the actual loaded object (which might be able to answer the message instead of calling `doesNotUnderstand:` for every message, like Proxy did.

There where if course optimisations and so on, but that was the gist of it.

What I really like about this system was that it was completely transparent to the sender of the message whether they were talking to a proxy, or the already-loaded object, all while being robust, easy to maintain and so ob. Dealing with collections was tricky though (how much to load at once? what about searching for a particular object?...), and would have been aswell for deeply nested object (which they successfully avoided though because as a SaaS-company, they could model the data exactly to their needs).

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.

Sounds a somewhat like GemStone/S

I think also IBM has or had somewhat similar concepts.

https://en.wikipedia.org/wiki/GemStone/S

How so? Never heard this perspective. Is it substantially more than reflection?

You could argue that a Claude code session also works like a lisp/smalltalk image.

Is APL no longer mainstream-ish?

Additionally, although not the same, this kind of relates to JIT caches as well.

Which Lisps were those? I'm kinda interested in this space.

  > Any recipe R that uses LOOKUP automatically works with all the data structures that LOOKUP works with, even though R itself may be a specific recipe for a specific data structure of its own.

this seems similar to protocol extensions + associated types as used in swift maybe?

https://docs.swift.org/swift-book/documentation/the-swift-pr...

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.

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.

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.

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

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.

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.

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

Thanks for sharing. This piqued my interest.

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

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 :)

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.

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.

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...

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. :)

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.

And Prolog and Assembly!

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.

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!

@DonHopkins your comment is flagged dead.

Is it because of its length giving false signals ?

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

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.

https://github.com/LivelyKernel/LivelyKernel

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

http://youtu.be/QTJRwKOFddc

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)

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.

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.

I never made that connection, it makes sense though!

The core pattern was that the Proxy, which was under Nil and above all other Objects regarding inheritance I think.

There where if course optimisations and so on, but that was the gist of it.

NixOS by contrast takes the entire Linux userland and makes it an immutable, dead compiler artifact. So it is to debian like C or Rust are to Lisp.

Imagine inheriting not your colleague’s code, but his entire machine. Then you discover this machine also is the production environment.

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.

I blame the unknown unknowns. I don’t haven’t learned Prolog yet. Alas, enlightenment still eludes me.

(Agreed that TCL is pretty cool)

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.

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.

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.

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.

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.

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.

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

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.

https://github.com/LivelyKernel/LivelyKernel

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

http://youtu.be/QTJRwKOFddc

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)

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.

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...

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

Is APL no longer mainstream-ish?

Additionally, although not the same, this kind of relates to JIT caches as well.

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.

All of this is very hand-wavy, but it's my impression.

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.

I opened the Squeak image on my Mac, and everything looks good that I checked.

i mean look at the site linked. It's beating you over the head with AI immediately

So this is a little different than what you are talking about, but I'd say it's possible.

Sounds a somewhat like GemStone/S

I think also IBM has or had somewhat similar concepts.

https://en.wikipedia.org/wiki/GemStone/S

How so? Never heard this perspective. Is it substantially more than reflection?

You could argue that a Claude code session also works like a lisp/smalltalk image.

Which Lisps were those? I'm kinda interested in this space.

I blame the unknown unknowns. I don’t haven’t learned Prolog yet. Alas, enlightenment still eludes me.

(Agreed that TCL is pretty cool)

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.

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.

Last time I touched Erlang, "Learn you some Erlang for great good!" was fresh out of the printers.

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. :)

i mean look at the site linked. It's beating you over the head with AI immediately

I opened the Squeak image on my Mac, and everything looks good that I checked.

Sounds like you would find NixOS and/or Unison interesting!

Gemstone/S was first an object database, per above article. Vaguely reminds me of:

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.

I fail to see it. But that could really be me. Could you explain how?

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.

All Common Lisps can do that, though it is not a part of the standard. See e.g. (sb-ext:save-lisp-and-die)

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.

CL and Janet both come to mind as supporting image-based deployment.

If I have to describe the feeling is that you'll realize that computation is symbolic manipulation (yes, it is obvious, but quite difficult to be fluent in it). With C and the likes you're too close to the machinery to easily grasp symbolic manipulation. But with other paradigms like lisp, prolog, oop with smalltalk,... you start learning how to design solutions in terms of symbols and their manipulations instead of values and concrete actions.

Once you start doing that, you move a ladder up in problem solving, where you solve class of problems instead of specific instances.

It does though. It teaches you that closed source is still open source in many many ways. Especially when you have something like Ghidra or IDA Pro. Nowadays this is even more true because LLMs can speed up retrieval of missing knowledge way more quickly. Back in the day I had to search for stuff but I bet now that LLMs give a decent guess at decompilation of something. Also it's the systems programming language and requires you to dive into the computer architecture of things. Try that with Python or JavaScript.

Bootstrapping a Forth in assembly is probably a better option, two birds with one stone.

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.

http://paste.tclers.tk/6165

> If you're an unc with a background in Ruby or that era of webdev

Millennials catching strays I see.

> If you're an unc with a background in Ruby or that era of webdev

"claude, run 'npm install' for me"

The similarity of Ruby and Elixir is only extremely superficial and betrays your lack of familiarity with the language.

Phoenix is a big part of the appeal of Elixir, independently of the differences between Elixir and Erlang.

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

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.

https://github.com/LivelyKernel/LivelyKernel

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

http://youtu.be/QTJRwKOFddc

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)

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.

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.

> If you're an unc with a background in Ruby or that era of webdev

Millennials catching strays I see.

Bootstrapping a Forth in assembly is probably a better option, two birds with one stone.

Gemstone/S was first an object database, per above article. Vaguely reminds me of:

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.

All Common Lisps can do that, though it is not a part of the standard. See e.g. (sb-ext:save-lisp-and-die)

Hacker Times

Hacker Times

Squeak 6.1

Discussion

Discussion