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 →
Sep 6, 2015
“You can know the name of a bird in
all the languages of the world, but when you're finished, you'll know absolutely
nothing whatever about the bird."
I've been teaching programming using my new UI for just
about six weeks now, and it's been miraculous and endlessly fascinating to
watch a young mind up close. I'm still processing many of my observations and
lessons, but I want to describe how one of my students learned something I
never meant to teach: consistent indentation.
The only thing I did to help him learn indentation was this: I never ever
brought it up. Mostly because I just don't
consider it very important, especially at such an early stage. When I
wrote programs to demonstrate features I indented as I normally would, then
I'd hand over the keyboard, and ignore the fact that my student was abutting
each line of code with the left margin.
Read more →
Jul 21, 2015
An experimental UI for teaching programming
Six months ago I fell into a little gig to teach two students programming, and it's been an eye-opening experience. Where I was earlier focused on conveying codebases to programmers, I've lately been thinking a lot harder about conveying programming to non-programmers. I think the two might be special-cases of a grand unifying theory of software representation, but that's another story. For now I don't have a grand unifying theory. What I have is a screenshot:
Let me describe the tool and the problems that it tries to address. When I started out teaching I picked an existing platform that I'd always liked. But quickly I started noticing many limitations. Today's platforms are great for experienced programmers and one can do great things with them, but they are very alien to noobs, who suddenly have to learn many different things at once.
Read more →
Oct 3, 2014
Literate programming: Knuth is doing it wrong
Literate programming advocates this: Order your code for others to read,
not for the compiler. Beautifully typeset your code so one can curl up in bed
to read it like a novel. Keep documentation in sync with code. What's not
to like about this vision? I have two beefs with it: the ends are insufficiently
ambitious by focusing on a passive representation; and the means were insufficiently
polished, by over-emphasizing typesetting at the cost of prose quality.
Elaboration, in reverse order:
Read more →
Sep 9, 2014
Consensual hells: Geopolitics for individuals
My third guest post at ribbonfarm.com.
Apr 9, 2014
Consensual Hells: The legibility tradeoff
My second guest post has just been published over at ribbonfarm.com,
on the subject of building capture-resistant organizations. Tl;dr - constrain
individual discretion at the top, and empower it on the fringes. But the
direct ways to do that won't work. What will? Read on →