[HN Gopher] The Xerox Alto, Smalltalk, and rewriting a running G...
___________________________________________________________________
The Xerox Alto, Smalltalk, and rewriting a running GUI (2017)
Author : rbanffy
Score : 116 points
Date : 2025-06-09 21:25 UTC (1 days ago)
(HTM) web link (www.righto.com)
(TXT) w3m dump (www.righto.com)
| yakz wrote:
| 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"?
| neilv wrote:
| I don't know, but I've wondered whether they were trying to
| signal or encourage (in demos or usage), that this was
| _different_ , than familiar business computers.
| packetlost wrote:
| I imagine it would look a lot nicer on a CRT vs rendered in
| high resolution on a LED display.
| kens wrote:
| Well, the CRT on our Alto is pretty old, so the text is a lot
| worse in person. (That's why I used screenshots instead of
| photos.) But I think that even with a good monitor, the
| Smalltalk font would be quirky at best.
| sumim wrote:
| 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...
| TheOtherHobbes wrote:
| It was the late 70s/early 80s, so a certain amount of twee
| whimsy was obligatory.
| ChrisArchitect wrote:
| (2017)
|
| Discussion then: https://news.ycombinator.com/item?id=15527726
| tho23i4324324 wrote:
| 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.)
| TheOtherHobbes wrote:
| 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.
| wonger_ wrote:
| Does Erlang have these same properties? From what I hear, it
| works great for distributed systems and modifying-while-
| running.
| toast0 wrote:
| 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.
| kens wrote:
| 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.
| speedbird wrote:
| 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.
| jecel wrote:
| 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).
| uticus wrote:
| 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)
| mkfs wrote:
| > 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.
| graemep wrote:
| > 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.
| johnlorentzson wrote:
| 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.
| rjsw wrote:
| The first JIT was for Smalltalk, running on a 68020 system.
| johnlorentzson wrote:
| 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.)
| uticus wrote:
| 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
| lproven wrote:
| > 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."
| igouy wrote:
| > 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...
| ~
|
| Later "ENVY/Developer"
|
| https://www.google.com/books/edition/Mastering_ENVY_Develope.
| ..
|
| https://archive.esug.org/HistoricalDocuments/TheSmalltalkRep.
| ..
| rtpg wrote:
| 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.
| mkfs wrote:
| 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.
| detaro wrote:
| > _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)
| mkfs wrote:
| > That seems odd, they seem easy enough to map to each
| other?
|
| Not unless you treat every method-level modification as a
| separate commit.
| TOGoS wrote:
| 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.
| igouy wrote:
| 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
|
| https://drcuis.github.io/TheCuisBook/Daily-Workflow.html
| igouy wrote:
| > 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" ?
| RodgerTheGreat wrote:
| 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.
| igouy wrote:
| > 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.
|
| https://drcuis.github.io/TheCuisBook/The-Change-Log.html
| 90s_dev wrote:
| 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.
| vidarh wrote:
| 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.
| ofalkaed wrote:
| 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.
| jdougan wrote:
| 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
| goodthink wrote:
| https://newspeaklanguage.org Smalltalk like, runs in a web
| browser, quite different.
| dang wrote:
| 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.
| dang wrote:
| 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)
| kens wrote:
| Thank you for your nice comment. Also, thank you to Y
| Combinator for donating the Alto.
| pkphilip wrote:
| How similar is Pharo to this whole experience?
| frou_dh wrote:
| Cuis Smalltalk seems to be the keeper of the old Smalltalk
| experience:
|
| https://cuis.st
|
| https://cuis.st/features
|
| Pharo is like enterprise-grade, bells and whistles galore.
___________________________________________________________________
(page generated 2025-06-10 23:02 UTC)