A cute and up-to-date version of Smalltalk is Cuis [1]. I enjoyed playing around with it and developing small projects, but I will never get used to using a graphical VM and UI to develop ordinary programs. That's too far from the UNIX philosophy, which I respect and follow for good reason. Nevertheless, the curious hacker in me is attracted to the freshness and unconventionalness of Smalltalk as a unique programming experience.
Cuis Smalltalk and related implementations are rather self-contained systems to the point they seemed walled off from the rest of the system, making it difficult to develop Smalltalk programs using external tools.
However, there's something compelling about the idea of a Smalltalk (or Lisp) OS running on bare hardware, where everything runs in a single address space. I've been thinking about this for a few years, but I haven't had time to pursue these ideas. Some ideas from the 1994 paper "Sharing and Protection in a Single-Address-Space Operating System" (https://homes.cs.washington.edu/~levy/opal.pdf) could be applicable to add some security to a Smalltalk OS.
pjmlp · 52d ago
Hence why I am already happy with half filled cup, when considering the existence of platforms like ChromeOS, Android, Meadow, Micro/CircuitPython, or Inferno, that seldom gets love from Plan 9 folks.
It isn't the full thing, but apparently it is very hard to get mainstream interest in such approaches.
Naturally this is not the same as using Smalltalk, or the other three Xerox PARC siblings, only partially.
There were some efforts to run Squeak on the Raspberry PI I think, but eventually they runned out of steam.
Squeak runs just fine on Linux computers (among many OSes) including the Raspberry Pi.
The project you linked to recreated the original Xerox Smalltalk-80 on the Pi. It has a rather limited scope so I don't know if they ran out of steam or simply reached the end.
pjmlp · 52d ago
Yes, but OP's point was about bare metal deployments, not on top of an existing OS, there are plenty of Smalltalks doing that already, all of the surviving ones.
igouy · 52d ago
> but I will never get used to using a graphical VM and UI to develop ordinary programs.
I guess that by "ordinary programs" you mean command-line TUI programs.
Being able to explore and inspect helps whether you are writing GUI or TUI.
When you write Smalltalk code with a Smalltalk IDE, your actions have an implicit context. If you write Smalltalk code with a plain text editor, you must provide that missing context. Something like the fileOut format —
!BenchmarksGame class methodsFor: 'initialize-release'!
Last time I tried that project I got into the object browser and from there got lost, lacking context about what objects I needed and what methods to call on them. The browser will show you everything but you have to know what you want and where to go to find it.
igouy · 51d ago
With Python or Java or Rust don't we have to know what we want and where to find it?
My first encounter with ST was at a Macintosh event at college in ‘85.
And there was a fellow there with a Mac Plus, and he had the Apple ST image running on it.
The Apple ST image was a descendant of the original Xerox image. This is the same image that became Squeak. Quite the heritage.
The first the the guy showed me was how easy it was to change the width of the scroll bar. A simple tweak and, voila, the scroll bar changed. This worked particularly well because in the original UI, the scroll bar was a popup (unlike most are today).
It was a dynamic demo to be sure to get that kind of reactivity to development. Made an impression to be sure.
lproven · 51d ago
You confused me with "ST" here. I thought you meant the computer called the ST, that could run an Apple OS image.
I once crashed Squeak by telling it that true:=false
Jtsummers · 52d ago
I think that or something like it was a rite of passage in our course using Smalltalk in college (number forgotten). "That couldn't possibly work...Oh, shit."
igouy · 50d ago
The "couldn't possibly work" things seem different — they don't crash the VM and exit.
igouy · 50d ago
Seems like Cuis Smalltalk also has that crash & exit behavior.
That does not crash Pharo Smalltalk.
That does not crash Dolphin Smalltalk.
rbanffy · 50d ago
At that time it didn’t exit - it just hung there forever. Even the mouse wouldn’t move.
igouy · 50d ago
Today after re-install on MSWin10
true := false
Cuis is perfectly OK
Cannot store into ->
speedbird · 51d ago
Object become: nil -- pretty findamental rug pull
igouy · 50d ago
Which could be handled without crash & exit behavior.
Every time a young hacker finds one of these, it gets patched.
igouy · 50d ago
Today after re-install on MSWin10
Object become: nil
Cuis does crash & exit, or hangs, or …
Sorry but the Squeak VM has crashed.
…
crash.dmp
sannysanoff · 52d ago
I was always amazed that the smalltalk environment looks like a complete computer control - a paradise for a programmer and a hacker, and a creator. It's surprising that it didn't take off. Probably too much openness reflects the internal openness of the smalltalk creator to the world, but the outside world, unfortunately, did not reciprocate. Especially if we pay attention to Apple's success with completely closed devices, suitable only for content consumption.
pjmlp · 52d ago
Smalltalk as platform did take off, that is why the famous GoF book uses Smalltalk and C++, even though many think Java is somehow on a book that predates it for about three years.
All the IBM's Visual Age line of IDEs were written in Smalltalk, and in a way it was the ".NET" of OS/2.
SOM (OS/2 COM) supported it natively, and one biggest difference to COM is that it supports meta-classes and proper inheritance, language agnostic.
What made Smalltalk lose industry mindshare was exactly Java.
When it came out, some major vendors, like IBM, pivoted all the way into Java, leaving Smalltalk behind.
It is no accident that Eclipse was designed by some of the GoF authors, and it is initially a rewrite of Visual Age underlying platform from Smalltalk to Java.
Eclipse even to this day has a Smalltalk like code browser.
It wasn't only the IDEs, some famous Java libraries, like JUnit, started their life as Smalltalk libraries.
Now as full OS, yes that never really took off.
Note not all Smalltalk vendors switched to Java, that is why Dolphin and Cincom Smalltalk are still around.
djmips · 51d ago
And as you hint at C# later and honestly it sometimes feels like the Unity game IDE took up the throne of Smalltalk with it's Smalltalk derived language and it's interactive IDE. What do you think?
pjmlp · 51d ago
Not sure about Unity in particular, I would say that is already part of .NET given its linage, don't forget J++ was going to be the main language of what became .NET, had it not been for Sun's lawsuit.
Many of the Unity capabilities are built on top of Mono, and the reference implementation alongside Visual Studio has more capabilities still.
If you mean the game editor experience itself, yes the interactive development ideas are there, but so are they in any game engine reasonable modern worth using.
lproven · 51d ago
> the Unity game IDE took up the throne of Smalltalk
Cincom only acquired the VisualWorks Smalltalk software after ParcPlace had unsuccessfully rebranded as ObjectShare in response to the emergence of free as in beer Java.
pjmlp · 51d ago
Thanks for the overview.
Yeah, still it is quite surprising, in a positive way, that a few vendors manage to stay in business, despite all the reasons not to.
speedbird · 51d ago
Lots of things went wrong.
ParcPlace acquired competitor Digitalk and tried to create a Frankenstein hybrid - jigsaw? - that royally screwed things up.
Around the time, the industry was very exercised about a number of features that alledgedly made PP Smalltalk bad:
- non-native widgets (emulated) for windows - who cares now;
- principal deployment as a single process, not natively multi-threaded, using internal virtual threads - which actually scales better;
- must be able to run in the browser like java applets - :-)
- can't get my head round "image" model, must have individual files
This was all FUD. Developing in VisualWorks with Envy (Gemstone) centralised version control was a blissful experience I haven't seen bettered.
But yes, Smalltalk and C++ faced off in industry for a number of years for the crown and then along came Java on the OSS tidal wave that effectively destroyed the business model for VisualWorks that relied on expensive licences.
pjmlp · 51d ago
Ironically the whole way modern IDEs work with virtual filesystems, or the LSP approach, aren't much different than putting an image like layer on top of traditional filesystems.
And still don't have quite a C++ IDE experience that somehow comes close to Visual Age for C++ v4 (from Smalltalk side), or Energize C++ (from Lisp side).
Digitalk’s Visual Smalltalk and IBM’s VisualAge provided native widgets.
badc0ffee · 52d ago
Suitable only for content consumption - only if you define content narrowly as software/apps.
criddell · 52d ago
And when you use that narrow definition you have to remember that all those apps were made on Apple devices.
A broader definition of content would include things you read, listen to, or watch and lots of writers, musicians, and film makers do a lot of their work on Apple hardware.
The suitable only for content consumption claim just doesn’t hold up.
As far as I know the Tektronix Smalltalk computers (4404 and later) were the only ones to try a higher resolution scrolling virtual screen.
For Alan Kay's talk they removed some limits of the original hardware, like screen size, processor speed, memory limits and storage (floppies in the original). They found that without these limits the experience was actually better than more modern Smalltalks in some ways. Sort of like using a 1980s 8 bit microcomputer with a modern SD card.
reconnecting · 52d ago
Very unexpected typeface for 1979 year. Thanks for sharing.
trinix912 · 52d ago
It’s definitely very unique and proves that the Macintosh wasn’t the first computer with nice typography ;)
dominicrose · 51d ago
What I liked about Smalltalk is the IDE and the language so I had two ideas.
Use Ruby instead, which is similar but with a more expressive syntax.
The IDE shouldn't save the code in a DB but as regular Ruby files (1 class per file) but the programmer would still only see one method implementation at a time in the IDE.
znpy · 52d ago
I looked left and right but it doesn't say anywhere what software is it using to run a smalltalk environment in the browser.
I played with (Pharo) Smalltalk a bit in the past, it'd be nice to try it again in the browser.
[1] https://cuis.st/
Cuis Smalltalk and related implementations are rather self-contained systems to the point they seemed walled off from the rest of the system, making it difficult to develop Smalltalk programs using external tools.
However, there's something compelling about the idea of a Smalltalk (or Lisp) OS running on bare hardware, where everything runs in a single address space. I've been thinking about this for a few years, but I haven't had time to pursue these ideas. Some ideas from the 1994 paper "Sharing and Protection in a Single-Address-Space Operating System" (https://homes.cs.washington.edu/~levy/opal.pdf) could be applicable to add some security to a Smalltalk OS.
It isn't the full thing, but apparently it is very hard to get mainstream interest in such approaches.
Naturally this is not the same as using Smalltalk, or the other three Xerox PARC siblings, only partially.
There were some efforts to run Squeak on the Raspberry PI I think, but eventually they runned out of steam.
https://hackaday.com/2020/07/12/making-smalltalk-on-a-raspbe...
The project you linked to recreated the original Xerox Smalltalk-80 on the Pi. It has a rather limited scope so I don't know if they ran out of steam or simply reached the end.
I guess that by "ordinary programs" you mean command-line TUI programs.
Being able to explore and inspect helps whether you are writing GUI or TUI.
When you write Smalltalk code with a Smalltalk IDE, your actions have an implicit context. If you write Smalltalk code with a plain text editor, you must provide that missing context. Something like the fileOut format —
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...Goldberg & Robson (1983) Smalltalk-80: The Language and Its Implementataion http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....
And there was a fellow there with a Mac Plus, and he had the Apple ST image running on it.
The Apple ST image was a descendant of the original Xerox image. This is the same image that became Squeak. Quite the heritage.
The first the the guy showed me was how easy it was to change the width of the scroll bar. A simple tweak and, voila, the scroll bar changed. This worked particularly well because in the original UI, the scroll bar was a popup (unlike most are today).
It was a dynamic demo to be sure to get that kind of reactivity to development. Made an impression to be sure.
https://en.wikipedia.org/wiki/Atari_ST
That does not crash Pharo Smalltalk.
That does not crash Dolphin Smalltalk.
That does not crash Pharo Smalltalk.
That does not crash Dolphin Smalltalk.
All the IBM's Visual Age line of IDEs were written in Smalltalk, and in a way it was the ".NET" of OS/2.
SOM (OS/2 COM) supported it natively, and one biggest difference to COM is that it supports meta-classes and proper inheritance, language agnostic.
What made Smalltalk lose industry mindshare was exactly Java.
When it came out, some major vendors, like IBM, pivoted all the way into Java, leaving Smalltalk behind.
It is no accident that Eclipse was designed by some of the GoF authors, and it is initially a rewrite of Visual Age underlying platform from Smalltalk to Java.
Eclipse even to this day has a Smalltalk like code browser.
It wasn't only the IDEs, some famous Java libraries, like JUnit, started their life as Smalltalk libraries.
Now as full OS, yes that never really took off.
Note not all Smalltalk vendors switched to Java, that is why Dolphin and Cincom Smalltalk are still around.
Many of the Unity capabilities are built on top of Mono, and the reference implementation alongside Visual Studio has more capabilities still.
If you mean the game editor experience itself, yes the interactive development ideas are there, but so are they in any game engine reasonable modern worth using.
No, that would be OpenCroquet, I think.
https://www.theregister.com/2023/03/23/croquet_for_unity/
Cincom only acquired the VisualWorks Smalltalk software after ParcPlace had unsuccessfully rebranded as ObjectShare in response to the emergence of free as in beer Java.
Yeah, still it is quite surprising, in a positive way, that a few vendors manage to stay in business, despite all the reasons not to.
ParcPlace acquired competitor Digitalk and tried to create a Frankenstein hybrid - jigsaw? - that royally screwed things up.
Around the time, the industry was very exercised about a number of features that alledgedly made PP Smalltalk bad:
- non-native widgets (emulated) for windows - who cares now;
- principal deployment as a single process, not natively multi-threaded, using internal virtual threads - which actually scales better;
- must be able to run in the browser like java applets - :-)
- can't get my head round "image" model, must have individual files
This was all FUD. Developing in VisualWorks with Envy (Gemstone) centralised version control was a blissful experience I haven't seen bettered.
But yes, Smalltalk and C++ faced off in industry for a number of years for the crown and then along came Java on the OSS tidal wave that effectively destroyed the business model for VisualWorks that relied on expensive licences.
And still don't have quite a C++ IDE experience that somehow comes close to Visual Age for C++ v4 (from Smalltalk side), or Energize C++ (from Lisp side).
https://wirfs-brock.com/allen/posts/914
> non-native widgets
Digitalk’s Visual Smalltalk and IBM’s VisualAge provided native widgets.
A broader definition of content would include things you read, listen to, or watch and lots of writers, musicians, and film makers do a lot of their work on Apple hardware.
The suitable only for content consumption claim just doesn’t hold up.
https://smalltalkzoo.thechm.org
There’s also an Alto mode https://codefrau.github.io/Smalltalk78/?alto which is closer to what folks used to work with back then
For Alan Kay's talk they removed some limits of the original hardware, like screen size, processor speed, memory limits and storage (floppies in the original). They found that without these limits the experience was actually better than more modern Smalltalks in some ways. Sort of like using a 1980s 8 bit microcomputer with a modern SD card.
I played with (Pharo) Smalltalk a bit in the past, it'd be nice to try it again in the browser.
https://www.lively-kernel.org/presentations/
For a more modern Smalltalk in the browser you can try SqueakJS https://squeak.js.org/
Any web server that serves static files will do (like "python3 -m http.server").
To use the full Lively interface, start here: https://www.lively-kernel.org/development/
LOL