Arc Forumnew | comments | leaders | submitlogin
Bret Victor - Inventing on Principle (2012) (
4 points by shader 19 days ago | 8 comments

4 points by shader 19 days ago | link

I'm sure many of you have already seen this (it's from 2012...), but it seems relevant to the discussion we were having about the future of programming.

He makes the great point that we should be enabling creation, and tightening the feedback loop between thought and product. I've been mostly focusing on better was to represent thoughts and communicate them to the computer, but this draws attention to the purpose of programming itself.


3 points by akkartik 19 days ago | link

I was just thinking about it yesterday, after reading Very inspiring talk.


2 points by shader 13 days ago | link

That's precisely where I found out about it :D


2 points by breck 16 days ago | link

Such a great talk, like his others.

I think it would be great to live in a world where not only could you use your finger to create a sprite animation, but if curious, you could also more easily delve into all the black boxes that make that experience happen (down to the physical level).

I like the NOMODES license plate. If you all had to pick a license plate to describe your work, what would it be? I might go with NOPARENS or NOSYNTAX.


2 points by akkartik 16 days ago | link

Mine would be COPYMORE. Or NODEPS.

I think I share your vision:


2 points by shader 13 days ago | link

Do you have any references for those terms? Or a short explanation for them?


1 point by akkartik 13 days ago | link


I'm what I like to call a 'copyista': I think DRY is overrated, and abstraction is overrated, and people are too quick to create abstractions to compress code rather than for conceptual clarity. Some links:;;;;;; You don't have to read them all, but hopefully this gives you as much flavor as you want :)


This is short for "no dependencies". I think a lot of software's ills stem from people's short-sighted tendency to promiscuously add dependencies. In fact, our fundamental metaphor of libraries is wrong. Adding a library to your program isn't like plugging a new block into your Lego set. It's like hiring a new plumber. You're not just adding a few lines of code to a file somewhere, you're creating a relationship. Everytime I see someone talk about "code smells", I wait to see if they'll bring up having too many dependencies. Usually they don't, and I tune them out. And the solution is easy. When you find a library that does something useful, consider copying it into your project. That insulates you from breaking changes upstream, and frees up upstream to try incompatible changes. As a further salubrious effect, it encourages you to hack on the library and tune it to your purposes. (Without giving up the options of merging further changes from them, or submitting patches upstream.)

As it happens, this worldview of mine was actually catalyzed by conversations here in the Arc Forum, most proximally That thread led to me writing and (a little clearer)

I consider an example of exemplary library use to be how I copied the termbox library into Mu (, periodically merged commits from upstream (, gradually cleaned it up to fit better with my project (, and gradually stripped out code from it that Mu does not require (;; In the process I made some wrong turns, deleting features that I later decided I wanted ( and created bugs for myself (; But when it did things I didn't want, I was now empowered to change them ( One of my patches was useful upstream, so I submitted it: I would be in no position to submit that patch if I hadn't taken the trouble to understand termbox's internals. That's another benefit of copying and privately forking libraries: it makes you a better citizen of the open source world, because open source depends on eyeballs, and using a library blindly helps nobody except your (extremely short-term) self.

More broadly, Mu is suffused with this ethos. My goal is that if you have a supported platform you should be able to run it with three commands:

  $ git clone
  $ cd mu
  $ ./mu
(That highlights another benefit: your software becomes easier for others to try out. Without giving out binaries, because what's the point of being open-source if you do that?)

Mu's also geared to spread this idea. I want to build an entire software stack in which any part is comprehensible to any programmer with an afternoon to spare ( Which requires having as little code as possible, because every new dependency is a source of complexity if you're building for readers rather than users. In chasing this goal I'm very inspired by OpenBSD for this purpose. It's the only OS I know that allows me to recompile the entire kernel and userland in 2 commands ( People should be doing this more often! I think I'm going to give up Mu and build my next project atop OpenBSD. But that's been slow going.


Ah, here's an old HN thread where I managed to combine both these ideas:

I'd have preferred to more directly call out my hatred for compatibility constraints, but I couldn't figure out how to fit it on a license plate :)


1 point by breck 11 hours ago | link

The Pike maxim "A little copying is better than a little dependency" comes to mind. I think the overhead of dependencies is underrated ("it's just a 1 line import statement!"), and often a little repetition is a good thing.