Attending Recurse Center «

Life: ,

I have been accepted to the Recurse Center to spend three months on collaborative, self-directed study of programming. I’m planning to continue studying Haskell and dependent types, proof assistants, and category theory. Maybe Coq, Idris, or TLA+ if I can find someone else interested.

Recurse encourages experienced devs to start or work on open source projects. For a couple years I’ve been taking notes on git’s command-line interface and joking about becoming the first CLI UX specialist, so I think I’m going to start that project as part of my Haskell practice. I don’t plan to re-implement git, I plan to wrap it with more cohesive mental models and useful features for day-to-day development work. If you have thoughts or resources in this area, I’d love to hear about them.

I’ll be attending the Fall 2 session in New York City from September 25 to December 15. If you’re in the NYC area those dates and would like to meet up, reach out, I’d love to meet up. And if you’re in Chicago, well, you won’t see me at Code and Coffee for a few months.


  1. What don’t you like about the git CLI? Not that I think it’s an amazing piece of work, but I don’t really ever find myself fumbling with it in my current workflow.

  2. A brief example: The ‘checkout’ command is terribly overloaded by being used for changing branches, reverting to arbitrary commits, throwing away work, and applying patches from other commits. That practice of reverting is known as being in a “detached HEAD state”, which is a totally uninformative name that doesn’t help the user form a mental model for what’s allowed and disallowed.

    I understand git’s data model very well so I can see the common thread in ‘checkout’ and understand the names, but nothing in git helps the user build a mental model oriented around the operations they’re actually performing. It’s like a variable named “number” instead of “age”, but on a bigger scale because it’s every command and every term.

    And then on top of that there’s features that should be automatic instead of manual. To give a single brief example, git knows whether I’ve pushed a commit or not. If I haven’t, rewriting history should be cheap and easy. If I have, it should warn me I’m going to make life hard for my collaborators and add metadata to the commit so life isn’t actually hard for my collaborators.

  3. Are you familiar with gitless and GUM? They’re earlier attempts to do a new command line interface around the core git concepts. I have no idea how far they’ve gotten (neither seems to have much traction), but at least they should be worth studying.

    Looking forward to meeting you when you arrive at RC!

Leave a Reply

Your email address will not be published.