The Xerox Alto, Smalltalk, and rewriting a running GUI (2017)
righto.com116 points by rbanffy a day ago
116 points by rbanffy a day ago
This post was part of a project that happened in 2017, the year that Alan Kay donated a Xerox Alto to YC. That was amazing but also challenging: what do you do with such a treasure? You can't just let it collect dust.
After sweating a bit, we found a perfect answer and I think it's still valid today. What you do with something as precious as an original Xerox Alto, is you find someone as good as kens to entrust it to.
Here's me describing the effort at the time: https://news.ycombinator.com/item?id=11930198.
Ken ended up pulling in a brilliant bunch of volunteers (loosely grouped around the Computer History Museum, IIRC), and they eventually got the Alto working. Not only that but they made an incredible series of videos and posts along the way, so the rest of us could follow along.
Once they'd gotten it working, we had a new challenge: what do you do with a working Alto? Again, the answer didn't take too long to figure out. What you do in such a case is you give it to the people who actually knew (and cared) enough to resuscitate it.
Thank you for your nice comment. Also, thank you to Y Combinator for donating the Alto.
Here are the threads I found from back then—if anyone finds others, let me know!
Fixing the Ethernet Board from a Vintage Xerox Alto - https://news.ycombinator.com/item?id=15636863 - Nov 2017 (29 comments)
The Xerox Alto, Smalltalk, and Rewriting a Running GUI - https://news.ycombinator.com/item?id=15527726 - Oct 2017 (56 comments)
Inside the vintage Xerox Alto's display, a tiny lightbulb keeps it working - https://news.ycombinator.com/item?id=15472747 - Oct 2017 (50 comments)
Bitcoin mining on a vintage Xerox Alto: very slow at 1.5 hashes/second - https://news.ycombinator.com/item?id=14683326 - July 2017 (41 comments)
Improvements to the Xerox Alto Mandelbrot drop runtime from 1 hour to 9 minutes - https://news.ycombinator.com/item?id=14637763 - June 2017 (63 comments)
One-Hour Mandelbrot: Creating a Fractal on the Vintage Xerox Alto - https://news.ycombinator.com/item?id=14587915 - June 2017 (53 comments)
Xerox Alto Restoration – Ethernet pioneers/founders of 3Com visit [video] - https://news.ycombinator.com/item?id=13138977 - Dec 2016 (35 comments)
Restoring YC's Xerox Alto day 10: New boards, running programs, mouse problems - https://news.ycombinator.com/item?id=12714358 - Oct 2016 (13 comments)
Restoring YC's Xerox Alto day 9: tracing a crash through software and hardware - https://news.ycombinator.com/item?id=12685593 - Oct 2016 (27 comments)
Restoring YC's Xerox Alto day 8: it boots - https://news.ycombinator.com/item?id=12583554 - Sept 2016 (95 comments)
Restoring YC's Xerox Alto day 7: experiments with disk and Ethernet emulators - https://news.ycombinator.com/item?id=12557777 - Sept 2016 (14 comments)
YC's Xerox Alto restoration Part 7: disk exerciser trial [video] - https://news.ycombinator.com/item?id=12520795 - Sept 2016 (8 comments)
Restoring YC's Xerox Alto: how our boot disk was trashed with random data - https://news.ycombinator.com/item?id=12507361 - Sept 2016 (50 comments)
Restoring YC's Xerox Alto, Day 6: Fixed a chip, data read from disk - https://news.ycombinator.com/item?id=12482209 - Sept 2016 (31 comments)
Xerox Alto restoration day 5: Smoke and parity errors - https://news.ycombinator.com/item?id=12437018 - Sept 2016 (1 comment)
Xerox Alto Restoration Part 5 [video] - https://news.ycombinator.com/item?id=12427341 - Sept 2016 (13 comments)
Restoring Y Combinator's Xerox Alto, day 4: What's running on the system - https://news.ycombinator.com/item?id=12197591 - July 2016 (35 comments)
Restoring Y Combinator's Xerox Alto, day 3: Inside the disk drive - https://news.ycombinator.com/item?id=12072827 - July 2016 (21 comments)
Xerox Alto Restoration Part 3: drive ok and First boot attempt [video] - https://news.ycombinator.com/item?id=12035108 - July 2016 (20 comments)
Restoring Y Combinator's Xerox Alto, day 2: Repairing the display - https://news.ycombinator.com/item?id=12017354 - July 2016 (38 comments)
“Hello world” in the BCPL language on the Xerox Alto simulator - https://news.ycombinator.com/item?id=11987324 - June 2016 (59 comments)
Xerox Alto Restoration Part 2: Firing up the monitor [video] - https://news.ycombinator.com/item?id=11977215 - June 2016 (24 comments)
Restoring YC's Xerox Alto, day 1: Power supplies and disk interface - https://news.ycombinator.com/item?id=11954920 - June 2016 (23 comments)
Y Combinator's Xerox Alto: restoring the legendary 1970s GUI computer - https://news.ycombinator.com/item?id=11929396 - June 2016 (105 comments)
In person, on the real screen, is the font easier to read? I don’t understand why they didn’t go with something more… “plain”?
This font is called "Cream" and was designed and created by Bob Flegal to look identical on both screens and laser printers.
cf. https://squeak-dev.squeakfoundation.narkive.com/Rs0CrNOk/fon...
It was the late 70s/early 80s, so a certain amount of twee whimsy was obligatory.
I imagine it would look a lot nicer on a CRT vs rendered in high resolution on a LED display.
How similar is Pharo to this whole experience?
Cuis Smalltalk seems to be the keeper of the old Smalltalk experience:
Pharo is like enterprise-grade, bells and whistles galore.
What is the best path for getting into Smalltalk these days? It seems like a good option for personal projects but never found much in the way of resources or even a good run down on Pharoh vs Squeak.
Programming a Space Shooter in Squeak/Smalltalk (Also has links to Squeak By Example) : https://scottgibson.site/ShooterGame/
A gentle introduction to Pharo Smalltalk (From the Glamorous Toolkit) https://book.gtoolkit.com/a-gentle-introduction-to-pharo-sma...
Prof Stef (In Amber ST on JS): https://amber-lang.net/learn.html
Immersive Object Programming course videos from INRIA: https://www.youtube.com/playlist?list=PL2okA_2qDJ-kCHVcNXdO5...
Pharo related books (links to Pharo By Example, etc.): https://books.pharo.org/
Free Smalltalk Books: http://stephane.ducasse.free.fr/FreeBooks.html
https://newspeaklanguage.org Smalltalk like, runs in a web browser, quite different.
I'm generally shocked that people aren't profoundly shocked and saddened by what has been lost with these kind of "modifiable while running" systems like Xerox Alto and the Lisp Machines.
Modern software frameworks are so shockingly bad and uninteractive that we now have to rely another layer of bullshit with LLMs just to get us to be half as productive as these envs. : (
(okay okay REPL-based things are getting better, but still nowhere close to what Lisp even w/ Emacs can do.)
That model stops working as soon as you try to distribute software at scale. You need some kind of standardisation and baseline. Otherwise your customisations conflict with someone else's customisations, with consequences that vary from mildly annoying to catastrophic. And the whole idea of shared software collapses.
It would work if you had strict access control to each feature in a common code base. But Git hadn't been invented yet.
The other issue is performance. Compiled ST isn't particularly slow, but you lose the modifiability. Interpreted ST has a mixed profile - some features are slow, some are fast - but generally it was slow compared to C.
Today that doesn't matter so much, but it was a drawback at the time.
It's a seductive model and I totally get the appeal. But it's not quite as straightforwardly superior as it might appear to be.
> standardisation and baseline
1984 "Smalltalk-80 The Interactive Programming Environment" page 500
"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager."
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
~
https://www.google.com/books/edition/Mastering_ENVY_Develope...
https://archive.esug.org/HistoricalDocuments/TheSmalltalkRep...
As far as performance, the Alto team described the performance of Smalltalk as between "majestic" and "glacial". From my experience with the Alto, Smalltalk seemed unusably slow, and I'm amazed that they could actually accomplish anything with it.
With the ParcPlace flavour teamwork with Envy version control was pretty slick. And in performance it was mostly compiled to bytecode with some cunning tricks in place to make interactive debugging appear to work at the source level. Truly great environment for exploratory development: concrete example, while building a comms server I could inspect why message handling failed, patch code, rerun from failure, much faster cycle time than most other langs/envs.
The Xerox Dorado, an ECL beast evolved from the Alto, was considered the only machine to offer a good Smalltalk experience when Smalltalk-80 was initially released. The Xerox Dolphin, for example, was only about "0.1 Dorados" despite being a serious improvement on the Alto. The Apple Lisa was only about 0.05 Dorados.
That level of performance was only achieved by PCs when we got 50MHz 486 (for purely interpreted Smalltalk-80 virtual machines, with JITs much slower computers could match the Dorado).
not sure about context or timing, but there was work put towards improving performance around the same time: https://archive.org/details/ungar-smalltalk (pub Feb 1986)
With regards to performance, Craig Chambers's thesis on the Just-In-Time compiler for Self proves pretty definitively that a language as (or more) flexible as Smalltalk can be very performant without losing any dynamic properties. It certainly isn't an easy compiler/runtime to recreate for any given language, but it does exist.
It didn't exist at the time you're referring to however, so in that context the point does stand, mostly. I believe there was some form of flexible compiled optimization for Smalltalk (since Chambers's thesis references it as prior work) but I forget when that was and how commonly used it was.
Chamber's thesis was '92 if i'm looking correctly (https://www.cs.tufts.edu/~nr/cs257/archive/craig-chambers/th...), Ungar's thesis from '86 greatly predates it: https://archive.org/details/ungar-smalltalk
The first JIT was for Smalltalk, running on a 68020 system.
That sounds about right. (Just to clarify, what I was referring to with "did not exist at the time" was specifically Self's JIT and its new techniques.)
> But Git hadn't been invented yet.
Git isn't the first or oldest DVCS. Smalltalk actually had multiple DVCSs, including ENVY (VA/Cincom), which dates back to the mid 90s, and Monticello (Squeak/Pharo), which dates to the early 2000s--both of which predating git.
> That model stops working as soon as you try to distribute software at scale.
True, but lots of people do not need to distribute software at scale.
IIRC Pharo has a way of exporting the current image to files for version control. That should solve the problem of multiple developers working on the code. You can modify while running to try things, and then commit the final result to version control.
Does Erlang have these same properties? From what I hear, it works great for distributed systems and modifying-while-running.
Erlang systems don't do so well when multiple people are working on them with different understanding of what production is. (And especially if nobody actually knows).
I don't know that you need 'strict access control' as proposed, but you do need coordination, and a source code repository is a way to manage coordination.
Erlang doesn't have a different mode for fixed vs loadable code, although you may need to write code differently in order to be able to hotload changes, and that could affect performance; some code naturally fits the idioms needed though.
I find it amazingly valuable to be able to change the program without having to lose the program state; but it requires different thinking, and it is easy to mess things up in exciting ways that are different than many other systems. It's amazing to fix a bug and deploy it in seconds into a live system with millions of active connections; it's also amazing when you try to fix a bug and break millions of active connections in seconds, but in a negative way, because now you and your users have to pay the costs of reestablishing all of those connections.
OTOH, the key issue is interchange of state and messages between versions, and that's an issue that comes up in almost all distributed systems that update without downtime, so most people have to deal with that issue anyway, just usually not within the much smaller scope of a single task.
> stops working as soon as you try to distribute software at scale.
I disagree – just make it read-only – but to illustrate my point, let me try to invert your point.
You're saying that the Lisp/Smalltalk software creation model doesn't scale and only mass-produced software can.
Instead of the traditional car analogy, let me use clothing instead. Even more people use clothes than cars.
"The idea of hand-making bespoke clothing stops working as soon as you try to distribute clothes at scale. There are billions of people and they're all slightly different sizes and shapes. You can't customise clothes for them all!
"The only way we can clothe billions of people is if they all wear the same thing. One-offs worked when we only had a small population and only the rich got a choice. There was no other way. But since then, we invented elastic and zips and belts.
This way we can give everyone a simple all-in-one coverall, a sort of jumpsuit, and using a few zips and elasticated bands and some straps to shorten or lengthen the arms and legs, it will fit everyone. At the worst we can make a few sizes and they will scale.
It's all about scale, and we have to make sacrifices if we want something that scales efficiently."
Freedom to modify any part of your environment live in an Image is wonderful when your changes work perfectly, and horrific if you make any low-level mistakes; you can easily destroy the tools necessary to back out changes to your tools. It gets even worse in a world where you might run code from someone else with malicious intent!
I think it's generally better to aim for what the old C2 wiki called "Alternate-Hard-And-Soft-Layers": substrates that are less malleable with dynamic layers floating on top. We can do much better in terms of malleability than mainstream operating systems without descending into the complete insecurity and fragility of a classical Lisp Machine or Smalltalk environment.
> you can easily destroy the tools necessary to back out changes to your tools
Of course, you did make backup copies of the original image file and original sources file and original change log file.
Of course, you can restore your changes from your modified change log file, but not restore the changes that broke your IDE.
The "modifiable image" model to me poses a huge problem of just not knowing what has changed and what is going on. I believe that things like Pharoh integrate into version control, but just on a fundamental level being able to throw away everything and go back to some notion of a clean state is very helpful when working on a mutable system.
Distributed version control and CI makes it way more tractable to work on even a small team IMO.
I would be very curious to see someone stream a "real" workflow using something like Pharoh or other smalltalk-like envs though. There's a bunch of short clips showing "beginner" demos but for such a visual system I would expect there to be more detailed presentations of the actual workflow.
Not just a "modifiable image".
1984 "Smalltalk-80 The Interactive Programming Environment" page 46
"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users."
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
~ workflow> throw away everything and go back to some notion of a clean state
So throw away the modified image and go back to the original image (and sources file and change log file) which you still have "unmodified" ?
Pharo and Squeak had a DVCS called Monticello that integrated with the system much better than git, but they abandoned it in favor of git, primarily so they could use github, expecting it would raise their profile amongst developers (also the VM was already developed there). The end result was the method-level modification history, including timestamps and authorship info, was lost, since it didn't fit into git's model of treating everything as text files or blobs.
Git is also much more confusing than Monticello.
> The end result was the method-level modification history, including timestamps and authorship info, was lost, since it didn't fit into git's model of treating everything as text files or blobs.
That seems odd, they seem easy enough to map to each other?
> Git is also much more confusing than Monticello.
Not my experience. Uni had us use Smalltalk for a bunch of courses, and Monticello was universally hated (and people caused their to-be-expected number of messes with Git too, but still got on with that much better)
> That seems odd, they seem easy enough to map to each other?
Not unless you treat every method-level modification as a separate commit.
Why not? Git should handle this just fine. And you can always make details-in-second-parent merge commits or squash them down later, if you don't like the whole history having that level of detail.
Years ago, someone made a fun proof of concept called Entity that'd allow you to do this with Perl, C, and one more language (I want to say Javascript). The C support involved shelling out to gcc and building an .so file that was then dlopen()'ed... It was quirky, and obviously not production-ready, and then it vanished. But it was an interesting experiment.
I agree with you to a great extent. For my Ruby development I often near live in Pry (a REPL that while nothing like Smalltalk, is at least loosely inspired by it, the same way Ruby in general has elements that are Smalltalk-ish under the hood), and often integrate Pry into the application so I can drop down into a REPL and modify the running system to debug things.
I also often make a point of implementing a "reload" method that will reload the main parts of the codebase into the running image, so I can make bigger changes "outside" and load them without losing current state.
It makes a great deal of difference.
Hot module reloading is very useful and part of why I added it to Node.js, but it has its time and place, and it's not well suited to every problem. For example, when you have a lot of live objects, like a GUI has, it's very difficult to know which objects are stale and need to be replaced. When I use it in Node.js for developing websites, I use HMR as a means to skip some parsing/evaluating, but I still re-build the entire website from scratch so that there's no (okay a little) state left over from the last build.