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.
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.
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.
> 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.
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.
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."
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.
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.
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?
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.
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.
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.
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).
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.
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.
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.
[1] https://cuis.st/
You might be interested in this paper: "Unix, Plan 9 and the Lurking Smalltalk" (https://www.humprog.org/~stephen/research/papers/kell19unix-...)
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.
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.
https://hackaday.com/2020/07/12/making-smalltalk-on-a-raspbe...
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.
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.
> 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 —
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...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.
With Python or Java or Rust don't we have to know what we want and where to find it?
Goldberg (1984) Smalltalk-80: The Interactive Programming Environment http://stephane.ducasse.free.fr/FreeBooks/TheInteractiveProg...
Goldberg & Robson (1983) Smalltalk-80: The Language and Its Implementataion http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....
A demonstration of on-the-fly modification of GUI internals in Smalltalk-78: https://www.youtube.com/watch?v=eEz08IlcNMg
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.
You confused me with "ST" here. I thought you meant the computer called the ST, that could run an Apple OS image.
https://en.wikipedia.org/wiki/Atari_ST
I once crashed Squeak by telling it that true:=false
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."
The "couldn't possibly work" things seem different — they don't crash the VM and exit.
Seems like Cuis Smalltalk also has that crash & exit behavior.
That does not crash Pharo Smalltalk.
That does not crash Dolphin Smalltalk.
At that time it didn’t exit - it just hung there forever. Even the mouse wouldn’t move.
Today after re-install on MSWin10
Cuis is perfectly OKObject become: nil -- pretty findamental rug pull
Which could be handled without crash & exit behavior.
That does not crash Pharo Smalltalk.
That does not crash Dolphin Smalltalk.
Every time a young hacker finds one of these, it gets patched.
Today after re-install on MSWin10
Cuis does crash & exit, or hangs, or …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.
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.
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?
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.
> the Unity game IDE took up the throne of Smalltalk
No, that would be OpenCroquet, I think.
https://www.theregister.com/2023/03/23/croquet_for_unity/
> not all Smalltalk vendors switched to Java
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.
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.
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.
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).
> Lots of things went wrong.
https://wirfs-brock.com/allen/posts/914
> non-native widgets
Digitalk’s Visual Smalltalk and IBM’s VisualAge provided native widgets.
Suitable only for content consumption - only if you define content narrowly as software/apps.
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.
A faster booting version (without Lively Kernel IDE): https://codefrau.github.io/Smalltalk78/
The whole Smalltalk zoo is interesting:
https://smalltalkzoo.thechm.org
I expected the Note Taker to have a much smaller screen. This is pretty unbelievable for a portable back then.
It had a 7 inch CRT with 640x480 resolution.
The emulator has a much higher resolution. Did it use a follow-the-mouse window?
You can run the emulator with a different screen size: https://codefrau.github.io/Smalltalk78/?width=640&height=480
There’s also an Alto mode https://codefrau.github.io/Smalltalk78/?alto which is closer to what folks used to work with back then
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.
Very unexpected typeface for 1979 year. Thanks for sharing.
It’s definitely very unique and proves that the Macintosh wasn’t the first computer with nice typography ;)
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.
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.
Perhaps Lively Kernel?
https://www.lively-kernel.org/presentations/
This is using my Smalltalk-78 Virtual Machine https://github.com/codefrau/Smalltalk78
For a more modern Smalltalk in the browser you can try SqueakJS https://squeak.js.org/
Is it possible to download this for offline use? Or to view the source code for it?
You can run Smalltalk78 locally by cloning (or downloading) https://github.com/codefrau/Smalltalk78
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/
"If you change the JavaScript code of the VM, it will immediately affect other users of this webpage. Please use responsibly."
LOL
[flagged]
[flagged]