When software doesn’t fully meet the needs of its user, what are the user’s options? For commercial software, the user can lobby the manufacturer for the feature they need—but the manufacturer may not respond. For open-source software, the user can fork the repo and add the feature themselves—but this requires becoming a developer on the platform the app is written in.
But there have been better options in the past history of computing: software platforms that allow users to inspect the code of their software and modify it in the same environment the software runs in. With these software platforms, anyone using the application already has all the tooling they need to see how the application works and modify it. Platforms like this have played a significant role in the advancement of personal computing; can they do so again? This talk presents two such user-modifiable software systems: Smalltalk and HyperCard. Based on research into these systems’ origins, properties, and impact, it offers seven insights from them that can be applied to current and future user-modifiable systems.
5. Smalltalk
“Dynamic” means:
• Inspect the state of running objects and send messages to them
• Source for every class is available for inspection
• Modify or extend a class from within the system and it affects the live instances
7. HyperCard
• Send messages to the current card
• UI and scripts are available for inspection
• Modify a UI element or script from within the system for immediate effect
8. Questions To Answer:
• How did these two different user-modifiable systems emerge?
• Motivation
• Properties
• Challenges
• What insights can we gain from them to apply to new user-modifiable systems?
19. Dan Ingalls, "Design Principles Behind Smalltalk"
“The purpose of the Smalltalk project is to provide computer support
for the creative spirit in everyone.
If a system is to serve the creative spirit, it must be entirely
comprehensible to a single individual… Any barrier that exists
between the user and some part of the system will eventually be a
barrier to creative expression.”
20. Ted Kaehler, email interview
“We were devoted to letting users ‘see’ their code better
and more simply…
We avoided putting code in files so the user would not
have to think about or manage files.”
21. 2. Focus on a vision.
Following a simple vision can yield better results
than following a detailed plan.
22. 3. Eat your own dogfood.
These systems grew in featuresets as
their creators used them for their own work.
23. Smalltalk Development Tools
• “Larry Tesler created the ‘Code Browser’ to let users see the classes and methods
of the entire system.
• Dan Ingalls implemented the first opaque overlapping windows to let users see
more code and other objects on the screen.
• Dan invented pop-up menus to put editing commands where the user was working
at that moment.
Ted Kaehler, email interview
25. Ted Kaehler, email interview
“Development [of HyperCard] was partly driven by the requirements of
the HyperCard Help Stack, which my wife Carol Kaehler was making.
She needed an unchanging background for a group of cards. She
needed multiple backgrounds in a stack. She needed scripting to make
buttons navigate between cards. She needed scripts to show what each
paint tool could do.”
26. 3. Eat your own dogfood.
Make your system practically useful for you.
27. 4. Open-source it.
One reason Smalltalk evolved and HyperCard died
is the availability of the source code.
28. 4. Open-source it.
• HyperCard was commercial software.
• It was discontinued by its manufacturer.
• Because the source is not available, making a successor requires a rewrite.
29. 4. Open-source it.
• “the Smalltalk compilers, tools and libraries were provided in source form; only the
VMs were closed source.” — Gilad Bracha, “Bits of History, Words of Advice”
• “the Blue Book contains a Smalltalk description of the virtual machine” which was
translated to C — Dan Ingalls, “Back to the Future: The History of Squeak, a
Practical Smalltalk Written in Itself”
Squeak Smalltalk came from open source:
30. 4. Open-source it.
One way to ensure user-modifiable software stays available to
users is to open-source it.
31. 5. Put it out into the world.
The reason we know about these systems is because they
took steps to get into business’ and consumers’ hands.
32. Bill Atkinson, "Legacy of HyperCard"
“It was an exchange medium… You want
people to be sharing stuff. They all have to have
the software that it takes at least to play it, but
hopefully to be able to author it also. So I
worked out an arrangement with Apple that it
would be bundled free, be in the box with every
Mac…”
33. Adele Goldberg, "Oral History of Adele Goldberg"
“I knew we had something important that met the
goal of empowering people. But we didn’t
understand enough about what this did to empower
people, and we really needed to learn. And the only
way was to just get out there commercially.”
37. Bettencourt, "The xTalk Interviews"
“What made HyperCard the ubiquitous product it was in the
early 90’s… was the fact that it was included free with every
Macintosh sold. So anybody could use it to create something,
then share their creation with somebody else with the
confidence that the other person would be able to run it.”
44. Ted Kaehler, interview
“HyperCard evolved a lot during its development and
Alan Kay was advising Bill Atkinson. Bill had very clear
goals for HyperCard, but Alan and I did try to push it in
certain directions… Alan and I argued for generalized
objects and classes, but Bill wanted to keep it very
concrete. He was right.”
47. Bill Atkinson, "The Legacy of HyperCard"
“There was a little difference [from the web] that
HyperCard was always an authoring environment, never
just a browser. I didn’t separate the guys who consume
the information from the guys who create it.”
51. Principles from Smalltalk and HyperCard
1. Think outside the box.
2. Focus on a vision.
3. Eat your own dogfood.
4. Open-source it.
5. Put it out into the world.
6. Get it in the box.
7. Appreciate spin-offs.
52. Thank you! Questions?
1. Think outside the box.
2. Focus on a vision.
3. Eat your own dogfood.
4. Open-source it.
5. Put it out into the world.
6. Get it in the box.
7. Appreciate spin-offs.
User-Modifiable Software: Smalltalk and HyperCard | Josh Justice | LIVE 2021 | Oct 19
Editor's Notes
I’m not actually in academia; I work at a consultancy named Big Nerd Ranch. But thankfully it’s a consultancy that places a high value on learning, so they supported me learning about user-modifiable software.
This seemed familiar. Reminded me of a system I had used as a kid…
Now I had a pattern: user-modifiable systems. That I wanted to investigate
Patterns in what happened with Smalltalk and HyperCard that I think we can apply to future systems
So, they have significant differences
Your system may be different again
Don't be constrained by what's come before
When you read what Goldberg, Ingalls, Kay, and Kaehler say about Smalltalk, they usually talk like this.
They don't describe a great labor to break out of the constraints of conventional thinking about software.
They talk as though the innovative properties of Smalltalk fell out automatically.
This is not to minimize any of their innovation, but just to say, that innovation is applied in clear thinking.
In other words, commitment to the vision, not to an implementation.
There's a reason many of Smalltalk's greatest innovations were in software development tooling.
The Help Stack required more features to work, and those features in turn needed to be documented in the Help stack as well.
Dogfooding is a reality check.
It reminds us that although our systems are theoretically interesting, they may not yet have reached the point of being practically useful.
User-modifiable systems are not generally seen as big money-makers.
Referring to founding ParcPlace Systems
The goal was to learn. The means to that end was commercial release
If you say both of these things, I would propose that it's a contradiction. Here's why.
The reason we know about Smalltalk and HyperCard is because they had a broad impact.
Don’t leave this as an exercise for the reader.
It doesn't have to be you who puts it out into the world.
If someone else does it, support them.
Here's what I mean
Let me say it another way
Not quite the same in terms of discoverability.
Don’t overlook the web when it comes to accessibility to users.
Check out that humility: this person who did something different did it better
Two early web browsers
Viola, the creator says he copied the UI from HyperCard
Mosaic acknowledged the influence of HyperCard
But some projects are taking this farther
Replit, CodeSandbox, Glitch.com
Preconfigured development environment
Accessible in a web browser with no installation
Allows forking and modifying others' projects
There is still a build vs run distinction but it reduces the barrier
This is the opposite of a single vision. If your system is impactful, it will inspire other systems that don't have the same vision as yours.
But if those systems advance the state of computing and empower users, consider that a win.
You may not get the credit.
If we apply these things to our user-modifiable systems, they will likely have a bigger impact.
If we apply these things to our user-modifiable systems, they will likely have a bigger impact.