HackerTube 中文?
Software boundaries and change →

With old users still here, how far can a new version change?

A required field, an old web page, a Soviet computer: once a version has users, every change must say who migrates and who carries the old behaviour.

Questions in this reading · 8
  1. Is starting the old program enough for compatibility?
  2. Who migrates when a field becomes mandatory?
  3. What obligation can one old web page create?
  4. Who pays for the next update to custom software?
  5. Who must keep up after a compatibility decision?
  6. Should a menu describe its role or command all input?
  7. Can successors still maintain the hidden implementation?
  8. How can others combine modules in ways their authors never planned?

Is starting the old program enough for compatibility?

Rename a field in a message and the producing service may still compile. Hickey points out that names crossing a process boundary have other readers. Goetz distinguishes linking an old binary, recompiling old source and preserving behavior at runtime. Keep an old artifact, old source and an old message, then exercise them separately. Each tests a different promise.

Passages and timestamps · 2
as your names start escaping out of your processes, that they are global names
The Language of the System - Rich Hickey · ▶ 21:29–24:03 · passage interval
existing class files will continue to link
Brian Goetz - Stewardship: the Sobering Parts · ▶ 20:53–20:59

Who migrates when a field becomes mandatory?

In Hickey’s terms, a mandatory field raises the caller’s obligations. Winters’s diamond dependencies explain why two teams may not move together: each reaches a shared component through a different intermediary. Wright supplies a migration order: offer the replacement while retaining the old default, move callers in batches, then end the transition. A version number can identify the two interfaces but cannot supply the missing data for an unmigrated caller.

Passages and timestamps · 3
if you require more than somebody who's giving less now is not going to get what they want
Spec-ulation Keynote - Rich Hickey · ▶ 24:55–25:05
If everyone in your infrastructure doesn't upgrade at the same time, then we have version skew.
CppCon 2017: Titus Winters “C++ as a "Live at Head" Language” · ▶ 15:30–15:36
Usually you add the new thing without making it the default.
CppCon 2018:H. Wright “Large-Scale Changes at Google: Lessons Learned From 5 Yrs of Mass Migrations” · ▶ 13:15–13:19

What obligation can one old web page create?

Eich explains why early JavaScript choices survived: other people had shipped pages that used them. Van Rossum recalls a different route, fitting information for an external checker into existing Python syntax. Lattner presents gradual type adoption as a Mojo design goal. Take an old unannotated function and ask three questions. Must its result stay the same? Which tool reads the new information? Can an unmigrated caller still use it? The compatibility obligations differ across the three projects.

Passages and timestamps · 4
the force of web compatibility meant early mistakes couldn't be fixed
Brendan Eich: JavaScript, Firefox, Mozilla, and Brave | Lex Fridman Podcast #160 · ▶ 18:48–18:55
a compromise syntax
Guido van Rossum: Python and the Future of Programming | Lex Fridman Podcast #341 · ▶ 84:58–85:04
use that existing dummy syntax
Guido van Rossum: Python and the Future of Programming | Lex Fridman Podcast #341 · ▶ 85:50–85:54
progressively adopt types into your program
Chris Lattner: Future of Programming and AI | Lex Fridman Podcast #381 · ▶ 32:43–32:46

Who pays for the next update to custom software?

Customizing a package for one Japanese customer's workflow could win a contract without producing something another customer could immediately adopt. Fragmented platforms also spread update work across implementations. Alongside the initial contract, track who maintains the differences and which tested behavior a second customer can inherit.

Passages and timestamps · 2
modified for customers' existing business practices
Why is Japan So Weak in Software? · ▶ 5:48–5:53
there was no widely accepted platform or operating system
Why is Japan So Weak in Software? · ▶ 11:59–12:08

Who must keep up after a compatibility decision?

In the Soviet planning history, compatibility with existing software, access to programming methods and time to delivery could favor different options. Follow compatibility over one update: can a current program run, which documentation and skills are needed for the next release, and which supplier must act? That turns a checkbox into a maintenance obligation.

Passages and timestamps · 2
compatibility, learn British programming methods
Why the Soviet Computer Failed · ▶ 15:17–15:22
push back the project's delivery date
Why the Soviet Computer Failed · ▶ 15:23–15:28

Should a menu describe its role or command all input?

Stone adds a concrete test to an interface contract. When a menu opens, does the application say “this is a popup triggered by this click,” or demand all input and a fixed window position? In his 2013 account, conflicts involving volume keys and screensavers show how the latter agreement spreads a local need across the desktop. Device enumeration provides a second example of the boundary: using the same event format for current devices and later hotplug notifications lets callers use the same handling logic. For your own interface, list the intent the caller actually knows and the actions that belong with whoever coordinates global state. That reveals more about responsibility than counting parameters.

Passages and timestamps · 2
Wayland is also descriptive, not prescriptive.
The Real Story Behind Wayland and X - Daniel Stone (linux.conf.au 2013) · ▶ 31:35–31:39
these are all the current devices in the same format
The Real Story Behind Wayland and X - Daniel Stone (linux.conf.au 2013) · ▶ 34:38–34:42

Can successors still maintain the hidden implementation?

Blow adds a maintenance question to hiding implementation: can the complexity mastered by one person today also be passed to whoever takes over? His concern need not require every caller to understand all lower-level details. It asks what happens when troubleshooting habits become common knowledge while fewer people understand the mechanism. For a module, record its interface promises, who can explain the implementation, and how to test maintainability after a handover. This is a reading exercise drawn from the talk, not evidence that a particular tool or the entire industry must decline. Carry the answer from the final questions along with it: problems can be inherently difficult, and removing added complications does not guarantee complete understanding by everyone.

Passages and timestamps · 2
the amount of complexity we can sustain over time
Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc) · ▶ 47:56–48:01
whether that's good enough I don't know
Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc) · ▶ 62:30–62:37

How can others combine modules in ways their authors never planned?

Ken Thompson recalls how Unix pipes let people connect programs that had worked independently. To make a sorting tool work as a filter, its output had to shed chatter such as progress messages so the next program could use it directly. Stefan Karpinski describes another way to build on existing code in Julia. A downstream package can define new methods for an existing type while other packages continue to use the same type. The first example makes data passed between programs the point of connection. The second uses a shared type and methods that packages can add. What must stay stable for downstream developers to make the extension in their own code?

Passages and timestamps · 2
interconnections of things that were never meant to be in the same room together
VCF East: Ken Thompson interviewed by Brian Kernighan · ▶ 34:48–34:58
can define methods outside of the type later on
The Unreasonable Effectiveness of Multiple Dispatch | Stefan Karpinski | JuliaCon 2019 · ▶ 24:03–24:09

Try it on your own example

Pick an interface you want to change. List who still relies on the old behaviour, then write down who pays for the migration.