Dec 30, 2020
The Mu Computer in 2020
“There are two ways of constructing
software. One way is to make it so simple that there are obviously no deficiencies,
and the other way is to make it so complicated that there are no obvious
deficiencies. The first method requires a willingness to accept limitations,
and to compromise when conflicting objectives cannot be met.”
A. R. Hoare
It seems to me that modern computers trap people in a vicious cycle. Compatibility
guarantees breed complexity over time as the world changes. Complexity is
managed by introducing layers of abstraction. Abstractions introduce new
compatibility guarantees. Over the decades this vicious cycle leads to even
professional programmers understanding only a tiny fraction of the software
infrastructure that runs their computers. As a result, our world is increasingly
captured by software that is unaccountable to people.
For several years now I've had a vision for a computer
that allows anyone to audit its inner workings, where any operation can be
decomposed strictly into a parsimonious combination of simpler operations,
terminating without cyclic dependencies or circular reasoning at some ground
level. Ideally it would do this in a way that rewards curiosity, leading to a
virtuous cycle where an order of magnitude more people grow to understand how
their computer works as they use it.
Nowhere in this picture are compatibility guarantees, version numbers or
forced upgrades. At any point your computer should be internally consistent
and free of known historical accidents. Even if this means upgrades are more
work and so more infrequent, and that our computers must be slower. Or do
less. That seems like a worthwhile trade for a
more sustainable world.
At the start of 2020 the state of the
Mu computer looked like this:
Read more →
Mar 15, 2020
Mu: The first 6 years
Over the last few months I've written up in one place the entire argument
for—and comprehensive description of—what I've been working on
since 2014. It will be published in the proceedings of the Convivial
Computing Salon. From the
call for submissions:
In Tools for Conviviality , Ivan Illich said, “I choose
the term ‘conviviality’ to designate the opposite of industrial
productivity… Tools foster conviviality to the extent to which they can
be easily used, by anybody, as often or as seldom as desired, for the accomplishment
of a purpose chosen by the user… People need new tools to work with
rather than tools that work ‘for’ them.”
We were promised bicycles for the mind, but we got aircraft carriers instead.
We believe Illich’s critique of the damage to society from technology
escalation offers a fresh perspective from which to discuss the pathologies of
modern software development, and to seek better alternatives.
An inspiring theme. My response: “Bicycles
for the mind have to be see-through.” Get it? When I look over at my
bicycle I can see right through its frame. I can take in at a glance how the
mechanism works, how the pedals connect up with the wheels, and how the wheels
connect up with the brakes. And yet, when we try to build bicycles for the
mind, we resort to “hiding” and “abstraction”. I think
this analogy has a lot more power than we credit, a lot more wisdom to impart
if we only let it in. I think conviviality requires tools with exposed
mechanisms that reward curiosity.
I've been trying to falsify this hypothesis for 6 years. There are still large
gaps to investigate, but so far it's holding up. Read
on → [pdf; 25 pages]
Oct 15, 2019
Mu: Sketching out a minimal system programming language
In the previous post, I described what my
new hobbyist computing stack looks like today, and how the design decisions
seemed to accumulate inevitably from a small set of axiomatic goals. In this
post I describe some (far more speculative) future plans for Mu and try to
articulate how the design process continues to seem pre-ordained.
(Many of the sections below outline constraints before describing a design
that mostly fits them. This flow is inspired by
Christopher Alexander's “Notes on the synthesis of form”.)
Read more →
Oct 14, 2019
Mu: A minimal hobbyist computing stack
“It is far better to have an
under-featured product that is rock solid, fast, and small than one that
covers what an expert would consider the complete requirements.”
(pg 219) of his essay, “Worse
Over the past year I've been working on a minimal-dependency hobbyist computing
stack (everything above the processor) called Mu.
The goal is to:
- build up infrastructure people can enjoy programming on,
- using as little code as possible, so that people can also hack on the
underpinnings, modifying them to suit diverse desires.
Read more →
Mar 16, 2019
Four Example Projects
“Most kinds of power require a
substantial sacrifice… By the time someone has acquired it, he has also
matured to the point where he won't use it unwisely.
— Ian Malcolm, “Jurassic Park”
“It is impossible to form
anything which has the character of nature by adding pre-formed parts.
— Christopher Alexander, “A Timeless Way of Building”
Lately I tend to program in a certain unconventional manner. A series of design
choices, each seemingly reasonable in isolation, take me pretty far from
Read more →
Feb 25, 2018
Nobody's just reading your code
A guest post by Stephen
Malina, my partner in crime on Mu.
Most programmers agree that we don't read enough code. The
interviews in Peter Seibel's book, “Coders at work”
highlight a comical contradiction: almost all the programmers interviewed by
Seibel recommend that others read code for fun, but none of them routinely do
so themselves. Seibel even asked
Hal Abelson (of SICP
fame) directly about this phenomenon:
“I want to dig a little deeper on
this. You, like many other people, say programmers should read code. Yet when
I ask what code have you read for fun or edification, you—also like many other
people—answer that you read students’ code, which is your job, and review code
at Google, which is also your job. But it doesn’t sound like you sit down of
an evening with a nice printout and read it.
Read more →
Nov 27, 2017
Delimited continuations in a statement-oriented language
I've been periodically wrestling with the concept of continuations
for several years now, and have somehow never gotten comfortable with them.
Looking back, I think this was for two reasons:
Read more →
- Continuations are usually explained in the context of high-level languages
with higher-order functions and lots of nested function calls. But continuations
fundamentally subvert the notion of “function”. Operators like
‘reset’ looked like functions, but had “spooky
action at a distance” effects that were hard to reason about.
- I had trouble finding real-world programs where continuations are more
expressive than regular recursive function calls with well-designed data
structures. For example, classic back-tracking problems like the
N-queens problem have elegant solutions that don't require continuations.
Were continuations just a low-level primitive for building more high-level
tools like generators (‘yield’) and exceptions? Building
fluency with a concept requires developing an instinct for when it's applicable.
Nov 10, 2017
The cargo cult of versioning
[Update Nov 27: This post had issues, and I retract some of my more
provocative claims. See the errata at the end.]
All software comes with a version, some sequence of digits, periods and
characters that seems to march ever upward. Rarely are the optimistically
increasing versions accompanied by a commensurate increase in robustness.
Instead, upgrading to new versions often causes regressions, and the stream of
versions ends up spawning an extensive grapevine to disseminate information
about the best version to use. Unsatisfying as this state of affairs is to
everyone, I didn't think that the problem lay with these version numbers
themselves. They're just names, right? However, over the past year I've
finally had my attention focused on them, thanks to two people:
Read more →
Sep 13, 2016
How the right syntax can help teach recursion
(Or why goto is worth keeping around in modern
“It seems to me that there have
been two really clean, consistent models of programming so far: the C model
and the Lisp model. These two seem points of high ground, with swampy lowlands
— Paul Graham
A cool thing happened during a lesson today, and I wanted to try to capture
the magic before it slipped through my fingers. It happened while I was trying
to teach recursion (without ever using that word) using my side project, Mu.
The experience got me thinking about the quote above, and wondering if there
was a way to bridge the summits of C and Lisp without having to go through the
“swampy lowlands” between them.
Read more →
Mar 18, 2016
An alternative worldview to 'modularity'
It's a common trope among programmers that a single computer contains enough
bits that the number of states it can be in far exceeds the number of atoms in
the universe. See, for example, this
3-minute segment from a very entertaining talk by Joe Armstrong,
the creator of the Erlang programming language. Even if you focus on a single
tiny program, say one that compiles down to a 1KB binary, it's one of 21024
possible programs of the same length. And 1KB is nothing these days; larger
programs get exponentially larger spaces of possibility.
The conventional response to this explosion of possibilities is to observe
that the possibilities stem from a lack of structure. 10 bits encode 210
possibilities, but if you divide them up into two sub-systems with 5 bits each
and test each independently, you then only have to deal with twice 25
possibilities — a far smaller number. From here stem our conventional
dictums to manage complexity by dividing systems up into modules, encapsulating
internal details so modules can't poke inside each other, designing their
interfaces to minimize the number of interactions between modules, avoiding
state within modules, etc. Unfortunately, it's devilishly difficult to
entirely hide state within an encapsulated module so that other modules can be
truly oblivious to it. There seems the very definite possibility that the
sorts of programs we humans need to help with our lives on this planet
intrinsically require state.
So much for the conventional worldview. I'd like to jump off in a different
direction from the phenomenon of state-space explosion in my first paragraph.
Read more →