25th
of
February,
2015
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.
5th
of
November,
2014
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 String
s to a
s
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.
2nd
of
October,
2014
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…
20th
of
September,
2014
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.