The Story of Squeak, a Practical Smalltalk Written in Itself (1997) [pdf]
Key topics
Delving into the 1997 tale of Squeak, a self-written Smalltalk, sparks nostalgia and insightful commentary from those who've built bootstrapped systems and lived through the Smalltalk era. Commenters lament how licensing and costly implementations hindered Smalltalk-80's broader adoption, while others highlight its lasting influence on modern technologies like the JVM and V8. As one veteran notes, "I DID live through that era and I AM the 'old-man-yelling-at-clouds'," underscoring the challenges of working with Smalltalk, from recruiting developers to navigating its complexities. The discussion reveals a shared appreciation for Smalltalk's legacy and its continued resonance in contemporary programming.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
2h
Peak period
20
Day 7
Avg / period
7.6
Based on 38 loaded comments
Key moments
- 01Story posted
Dec 24, 2025 at 4:42 PM EST
11 days ago
Step 01 - 02First comment
Dec 24, 2025 at 6:20 PM EST
2h after posting
Step 02 - 03Peak activity
20 comments in Day 7
Hottest window of the conversation
Step 03 - 04Latest activity
Jan 4, 2026 at 6:14 PM EST
6h ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
I was very excited by Squeak in the late 90s (and even more excited by Self), but it was clear that the time of Smalltalk being able to make any kind of broader splash was done, and Java was where people's attention switched.
Or maybe I'm just entering my "old man yells at cloud" phase of life haha
This lead to some extraordinary per-diem charges that I knew some folks enjoyed for a while, mostly paid for by the Financial industry. Eventually those on the paying side looked for cheaper alternatives .. and yes, the new-kid-on-the-block Java played a big role, but so did Visual Basic!
… to use Smalltalk fluently, a programmer must become familiar with a huge class hierarchy and with the tools of a sophisticated interactive programming environment. New programmers often became lost in the hierarchy or spent considerable time in unfocused exploration of the interactive tools.'
"Making Use: scenario-based design of human-computer interactions", 2000, page 103
https://books.google.com/books?id=CD8EAAAAMBAJ&lpg=PA25&dq=d...
There was a lot of reliance on the Smalltalk books. While the blue book was common, the green (history) and orange (how the GUI works) were not. I don't even recall stumbling across those at OpAmp back in the day (and if anyone would have had those, they would have). I was very excited about ST back in the day.
All of my forays into ST ended up being a struggle and I never got any real momentum to make progress.
> but, it didn't have very good documentation on getting "your first app" up
I thought the "Smalltalk/V 286 Tutorial and Programming Handbook" [0] was good for that. (I hadn't seen the ParcPlace books back then.)
[0] http://stephane.ducasse.free.fr/FreeBooks/SmalltalkVTutorial...
It was the .NET of OS/2 and getting into enterprise, until Java came to be, and IBM one of the big Smalltalk backers, decided to pivot into Java.
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, has some really novel software. 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 someways today.
0. https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....
fwiw GemStone (and other commercial Smalltalk implementations) preceded Squeak.
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.
In other words: Smalltalk was the best in town until Java came to be.
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.
When you factor in all these things, no wonder that Java won.
Do you mean like hoogle [0]? Or does what you're talking about operate on values rather than type signatures?
[0] https://hoogle.haskell.org/?hoogle=a%20-%3E%20a
Neither was carrying around one's dev environment entire or partial.
You're quite an early adopter.
The client had saved the program state 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.
The past is a foreign country …
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...
A blinding setup otherwise ngl.
I started doing that with Turbo Pascal + MS-DOS 3.3 on HD floppies.
OP just jummped in when thumb drives started being available.
Too bad the whole world isn't the MIT Campus/Silicon Valley.
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.
Squeak was bootstrapped from Macintosh Smalltalk-80 and the kernel was in C to make it portable. Related projects to squeak are etoys, scratch and lively (2).
(1) https://vpri.org/ (2) https://computerhistory.org/profile/dan-ingalls-2/