▲ 290 points
back
145 comments
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.
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.
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.
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.)
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.
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?
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.
> Btw, almost all of Javascript's good parts come from Smalltalk.
That's E and Self erasure.
As a Ruby developer this video about Pharo smalltalk made me a smalltalk believer — not surprising because Ruby was heavily inspired by smalltalk.
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.
>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".
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".
If you think of it as message oriented it makes so much more sense.
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
I also had Squeak in my curriculum! From what I remember it had a unique object hierarchy or something like
Georgia Tech in the Mark Guzdial days?
I thought JS had a lot of Scheme inspiration?
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.
More stories please! :)
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.
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.
Cuis Smalltalk has full high-DPI support as its GUI is based on vector graphics: https://cuis.st/
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.
Use the Glamorous Toolkit.
yeah, after all these years, they are waiting for your contribution. you really should go at it with Fable.
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.
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.
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.
Morphic started on Self actually, maybe start there?
I am unaware how it evolved since then, especially given the differences between Self and Smalltalk.
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
I've been tempted to learn this so I could port my Pips solver to it, solely because PipSqueak would be a good name.
How does this compare to Glamorous Toolkit[1]?
Glamorous Toolkit is built on Pharo, which I think is a fork of Squeak or shares lineage with it.
It's not about AI
What do you use it for?
Can someone give me some advice on what to use as a beginner? Pharo? Squeak? Common Lisp?
I just want to understand how this whole thing works and see how I can use it.
Probably start with Pharo MOOC: https://www.youtube.com/playlist?list=PL2okA_2qDJ-kCHVcNXdO5...
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".
> 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.
https://docs.swift.org/swift-book/documentation/the-swift-pr...
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!
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).
I used to love using Squeak but moved to Pharo to get better high resolution display support. I should try the Squeak 6.1 release.
I remember enjoying Smalltalk.