The Change

I am leaving vim, my editor of three years, for a younger tool.

The move to using vim was an interesting experience for me. I had previously been mainly a user of TheCodingMonkeys’ SubEthaEdit, an editor for which I still have a great fondness. A couple of summers ago, though, I took a momentous (lol) decision: productivity was important, and I would learn vim. As with the experience of many people switching to vim, I felt a bit of a dip as I really delved into the features it started to feel very fast indeed. But that, I have slowly come to realise, is possibly the issue. It certainly feels very fast—but is it?

According to TechRepublic, there are 18.5 million programmers in the world. That’s a large number, and every single one of them is using a text editor of some description¹. Tools that can change the productivity of programmers are big business. So why are there no studies? I’ve been looking around for about a year and I’m increasingly troubled by the fact that there is no scientific evidence at all of vim or emacs being faster than a standard editor. Not even the kind of academic educated guess that undergraduates can get away with citing. Nada.

Have we been taken in by snake oil? Not that anybody has been deliberately misleading anybody else, but we may have come to a collective received wisdom which may not reflect reality. vim feels efficient, but the arguments about speed based on numbers of keystroke don’t take any of the cognitive load into account, and gut insticts aren’t always right.

The doubts about speed were for me coupled with some headaches about customisation. I decided to finally get around to learning Rust this week and went to install a Rust plugin for vim to give myself syntax highlighting. It was somewhere around the point of looking at multiple (and variously incompatible) plugin systems for being able to use other plugins which provide syntax highlighting that I realised this wasn’t work that was worthwhile.

When the most complex part of setting up a project is trying to configure the editor for it, one has to reconsider the editor. So, Today, I’m finally kicking the habit. My ESC key can retire to a quiet island somewhere as I experiment with Atom, Zed, and very possibly SubEthaEdit again.

There will be updates anon.

peggy—PEG parsing in Python

This morning, to scratch an itch¹, I wrote a PEG implementation in Python.

I took a bit of an unusual approach to it, which I’ll explain here and I hope you may find interesting.

I am, I confess, a Haskell programmer on the sly. Haskell is quite interesting for giving one a bit of a different perspective on how code should look.

In particular, here, the design process for the imperative mindset is to ask what a parser does. I think what’s an interesting alternative approach is the declarative mindset, where we ask what a parser is.

To a first approximation, a parser is this (if you’ll forgive the Haskell syntax):

type Parser a = String -> Maybe (a, String)

Transliterating this to English: a parser which parses Strings to as is: a function which takes an a and returns either an a and the rest of the unparsed input, or nothing (in case of a parse error).

In Haskell, this takes the shape of a stack of monad transformers. Indeed, if we restate that type with some newtype wrappers:

type Parser = StateT String Maybe

We get most of the functionality we want “for free”. If we throw in the following extra utility function:

dot :: Parser Char
dot = do (x:xs) <- get
         put xs
         return x

That’s enough for the majority of basic parsing².

Sequencing is achieved through <*> and >> which both come with the Applicative instance for StateT String Maybe. Ordered choice and empty come from <|> and empty in the Alternative instance for StateT String Maybe. In fact, the ?, + and * operators also come from the Alternative instance as optional, some and many.

I think this makes rather a nice example for Haskell: a pretty full set of parsing combinators in five lines of code, one of which is just type signature.

Python

I wanted to translate this formulation into Python to produce a relatively small and clean PEG implementation. The basic idea was a Parser wrapper class around these parser functions.

A Python parser function here is one that takes an input string and either:

• Returns a (parsed value, residue) tuple, or
• Throws a ParseError.

The other combinators can all be built up from that basic building block.

The implementation is about 140 lines of Python.

Adventures in Monorail

Nearly a year ago, I took part in Ludum Dare 28 with some of the usual suspects. What we came up with was an off-beat game called Monorail.

After talking to the rest of the team, I decided that the time had come to move Monorail on to new and better things. “New and better things” in this case meaning mobile platforms.

I’ve only had a brief dalliance with iOS before and Android is utterly alien to me so this is lining up to be an interesting challenge.

LibGDX supports those targets which is the first major hurdle. iOS support is provided via the rather clever RoboVM, which cross-compiles from JVM bytecode to native code. This is both a blessing and a curse.

It’s a blessing because it means everything is small and fast and easy to ship. It’s a blessing because it means not having to ship a JVM implementation for iOS. It’s a curse because the compile process is extremely slow.

Java is the lingua franca of Android which makes the Android LibGDX target rather more straightforward. Other than the standard “here be dragons” warnings about Dalvik I’ve heard very good things about LibGDX’s Android support, so other than having to slog through setting up the appropriate dark rituals to get an emulator working I’m looking forward to working with it.

Expect to see Monorail hit some flavour of app store near you, at some point, maybe! _{I’m not a marketer…}

Jekyll

I have a blog now!

It’s been my intention to set up my website for some time, but as you can probably imagine the hunt for work has brought me to finally setting it up.

As those of you with an eye for design will immediately notice, you are much more talented than me. I started out with an idea of just making my front page an analogue of a business card (very minimal!) and everything went from there.

I went for a deep dive into the world of semantic markup. The HTML is actually very minimal and just contains the content, CSS is doing all the heavy lifting: even adding the Twitter bird to the front of my twitter handle.

I wanted to keep the site JavaScript-free since while I’m not a fan of people turning off JavaScript it does seem somewhat excessive to need JavaScript for a site containing just static content. What I did discover from that, however, is that it’s possible (though I didn’t) to do fold-out animations and collapsible sections without any involvement of JavaScript using deep CSS3 transition magic.

Something along the lines of:

.container .detail {
  transition: height 0.4s;
  height: 0;
}

.container:hover .detail {
  height: 10em;
}

will expand elements with the class detail inside container when the container is hovered over.

I’m certain that the design of the website will change as I come to terms with just how awful I’ve made this first cut at it, but for now I’m fairly satisfied.