Nov 7, 2013
My mission

I'm working on ways to better convey the global structure of programs. The goal: use an open-source tool, get an idea for a simple tweak, fork the repo, orient yourself, and make the change you visualized -- all in a single afternoon. I'd like to live in such a world, wouldn't you?

The benefits of such a world extend far beyond mere convenience. Open source would more fully deliver on its promise; are the sources truly open if they take too long to grok, so nobody makes the effort? More broadly, the fact that software is eating the world makes it imperative we keep it easy for anybody to understand, lest we disempower vast swathes of humanity. Specialization has been great to us for ten millennia, but it has also caused problems. We delegate too much to 'experts' because we want to ignore externalities, but the 'experts' then capture our institutions. I'm hoping software will allow us to break out of this cycle of dysfunction by helping us manage the burden of externalities. But first we must manage the externalities that plague software itself.

Software today is based, like the rest of society, on specialization. We delegate our dependencies to some stranger upstream. If something is broken we wait for someone else to fix it. That's an externality. We require things to continue working the way they always have. That's a second externality. We're at the mercy of changes made upstream. That's capture. I want to explore an alternative way, a virtuous cycle where using a dependency gradually causes one to learn its internals, and learning internals gradually empowers one to change them. In this world, upgrades are never effortless, but they also never turn into arbitrarily deep rabbit holes.

Peter Naur thinks (c. 1985) that programs can never be understood without talking to their author. I'd like to prove him wrong, with some help from Christopher Alexander and others. My best-guess solution lies somewhere in the vicinity of http://akkartik.name/post/wart-layers and http://akkartik.name/post/tracing-tests. I'm now trying to apply these ideas to a relatively hostile domain: a mini OS to build full-stack applications that boot directly into a single application, only providing what it requires. If this resonates, get in touch!

Update Nov 2014: Development is now happening in the open.

Update Mar 2015: I've been increasingly exploring the duality between conveying codebases to programmers and teaching programming to non-programmers. The best way to teach programming might be by getting them gradually making bigger and bigger changes to existing programs. And the biggest reason programming is hard for most people might be that the software stacks we've ended up with actively hinder learning. Even if we forget how bad they are after we cross the chasm to become programmers.

"For me, the first challenge for computing science is to discover how to maintain order in a finite, but very large, discrete universe that is intricately intertwined. And a second, but not less important challenge is how to mould what you have achieved in solving the first problem, into a teachable discipline: it does not suffice to hone your own intellect (that will join you in your grave), you must teach others how to hone theirs. The more you concentrate on these two challenges, the clearer you will see that they are only two sides of the same coin: teaching yourself is discovering what is teachable." -- Edsger Dijkstra, 1979

I think the first program I use to demonstrate Mu might be an environment for teaching programming.

mission
Making the big picture easy to see, in software and in society at large.
about me
Code (contributions)
Prose (shorter; favorites)
favorite insights
Life
Making
Work
Cognition
Economics
History
Startups
Social Software