LOL
That does not crash Pharo Smalltalk.
That does not crash Dolphin Smalltalk.
Object class(Object)>>error:
Object class(Object)>>primitiveFailed
Object class(Object)>>become:
UndefinedObject>>{unbound}doItFor 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.
There’s also an Alto mode https://codefrau.github.io/Smalltalk78/?alto which is closer to what folks used to work with back then
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.
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.
[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...
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/
I played with (Pharo) Smalltalk a bit in the past, it'd be nice to try it again in the browser.
For a more modern Smalltalk in the browser you can try SqueakJS https://squeak.js.org/
Object become: nil
Sorry but the Squeak VM has crashed.
…
crash.dmpThat does not crash Pharo Smalltalk.
That does not crash Dolphin Smalltalk.
true := false
Cannot store into ->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.
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.
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.
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.
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.
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 —
!BenchmarksGame class methodsFor: 'initialize-release'!
jll29•1y ago
Goldberg & Robson (1983) Smalltalk-80: The Language and Its Implementataion http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....