I developed a (personal) Squeak application a few decades ago and to this day it stands out as a novel software development experience that I'm very glad I did. I highly recommend everyone even remotely interested in Smalltalk read the classic "Design Principles Behind Smalltalk" [0]
Perhaps the most immediately shocking feature of Squeak is the "world" which relates to the principle:
> Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one.
This means all Squeak programs live in their own, entirely Squeak based, virtual machine. This was, understandably, off putting to many devs since you can't bring any of your local tooling with you, but it had some interesting consequences. For starters, way back in the early 2000s, you could keep your Squeak image on a thumb drive and bring your entire dev environment with you to not only different computers, but different OSes! Then, in the Squeak window system, you could view the source of any arbitrary window or part of the gui.
Squeak, despite the small community, had some really novel software at the time. Monticello was a dvcs that predated git! There were also a proper object graph database, GemStone, that could be used for object persistence that, at least from an interface level, still beats any ORM we have today. There was also a feature that allowed method lookup by putting in the inputs and expected outputs (I still haven't seen anything like this).
In general learning about the history of Smalltalk interactively really drove home how incredibly novel of a system is was, and still remains in some ways today.
> > Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one.
Squeak/Pharo and Smalltalk in general never took off (and it’s unlikely they ever will) because of this mindset.
I dabbled a bit with pharo and this mindset became evident pretty much immediately.
The thing is: for many things pharo/squeak are really shitty runtimes (think smp/threading, high-throughput or low-latency i/o, network protocols support etc). But the OS is generally great in that sense.
Smalltalk is nice but it will never get past the “toy language” phase with that attitude.
Also: in terms of object database Versant OODBMS is much better :P
This very much depends on your definition of ‘best’. While your criticisms of the environment are valid, smalltalk is flexible in tangible ways that Java couldn’t match. Java took the OO model of smalltalk and make a bunch compromises that had big negative impacts on the language that are still there today.
Smalltalk was (and still is in some places) successful because of its portability, flexibility, etc. while it hasn’t enjoyed the degree of success as Java, ruby, perl, python, C++, and friends it would be a mistake to call it just a you.
Best is often a tradeoff among many things, including (but not limited to): usability/ergonomics, productivity, effectiveness, licensing costs and many other things.
When you factor in all these things, no wonder that Java won.
Not quibbling at all, but I recall some discussion somewhere saying that the history of the Squeak impl itself (not the name) traces back via saved base images to the original Smalltalk implementations, including via customs at-rest transformation tools when backwards incompatible changed where made in the primordial days. Base images, at least back when I was toying with Squeak, where never rebuilt from scratch, just modified, transformed etc. In some sense, at least for the image, they were decades old.
Back in the early '90s, an envelope was delivered to me containing a physical 3.5 inch diskette. The contents was a Smalltalk/V 286 image file. A bug had been found in a program I'd written a couple of years earlier.
The client had saved the program state (including the full dev environment) at the bug (and exported their current data to CSV files, just in case). I stepped into the debugger, fixed the problem, saved the new image file to a 3.5 inch diskette, went to the post office and sent it back to them.
Of course they had continued working but I don't recall which approach they took to merging their new data with the corrected program.
Too bad 99% of real world (c)(tm) workloads don't look kindly on hauling not only a debugger but "the full dev environment" in every product shipped out there...
I am very interested in the combination of Smalltalk and local-first (offline-first) designs, and the ability to share code and data on ad-hoc networks.
I know the One Laptop Per Child project started with Squeak (Scratch) with this in mind, but Scratch has since moved to an always-on Internet and Python for the environment.
I know there is a preoccupation on LLMs and vibe coding … but just as there is a smallweb movement keeping that torch lit in a sea of enshittification, there is something to be said about a development environment that can be customized by end users. For example, a website/blog authoring tool or RSS feed reader written in Smalltalk would be interesting, if not directly monetizable.
Perhaps the most immediately shocking feature of Squeak is the "world" which relates to the principle:
> Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one.
This means all Squeak programs live in their own, entirely Squeak based, virtual machine. This was, understandably, off putting to many devs since you can't bring any of your local tooling with you, but it had some interesting consequences. For starters, way back in the early 2000s, you could keep your Squeak image on a thumb drive and bring your entire dev environment with you to not only different computers, but different OSes! Then, in the Squeak window system, you could view the source of any arbitrary window or part of the gui.
Squeak, despite the small community, had some really novel software at the time. Monticello was a dvcs that predated git! There were also a proper object graph database, GemStone, that could be used for object persistence that, at least from an interface level, still beats any ORM we have today. There was also a feature that allowed method lookup by putting in the inputs and expected outputs (I still haven't seen anything like this).
In general learning about the history of Smalltalk interactively really drove home how incredibly novel of a system is was, and still remains in some ways today.
0. https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....