30 Jan 2018

I’ve been keeping my eye on the Eve project and company, both lead by Chris Granger, for a while now, and so I was a little sad to see the announcement that it was shutting the doors.

The aim of Eve was “make programming accessible to everyone”. This is an aim that is close to my own heart, and was the area in which I did my PhD. It revolves around the idea that programming can be a useful tool for a wide variety of people, instead of being the specialist domain of a select priesthood. However, as I wrote a while ago, the vast majority of current approaches throw up needless barriers to casual use, and the systems that are suitable for such use are limited in their scope.

Eve was an ambitious attempt to address this by reconceiving programming from the ground up, rather than modifying or extending an existing environment. The component pieces — logic programming, interactive computation, integrating code and data — weren’t new, but they were combined in a considered and consistent way that showed great promise.

Ultimately, though, the people behind Eve “couldn’t find a home” for the project. They have open sourced the runtime, but I suspect that the project’s more lasting contribution will be the ideas on which it was based. More than the specifics, it acted as a challenge to our assumptions about what programming environments are, and how we approach them. Eve may be winding down, but the questions it raises remain, and we should carry on asking them.

Ringing in the Changes

31 Dec 2017

I’m writing this on New Year’s Eve, a time when it’s traditional to reflect on the year gone by. For me, there’s been one big change that has kept me so busy that I’m only getting round to writing about it six months later. At the start of July, I took on the role of CTO at Cydar.

There’s been a lot to get to grips with; not just the usual strategic and management responsibilities common to the CTO of any growing startup, but also the processes and regulations required when developing a medical device. Fortunately, we have an excellent team, and John, my predecessor, provided invaluable support while I found my feet.

Now I’ve had a while to get the hang of things, and I’m really liking the change. This is not only true where I expected it to be, in the technical areas were I now have responsibility, but also in the areas where I’ve not had previous experience. I was expecting the more organisational aspects of the role to be a price I paid to get my teeth into the fun stuff, but I was surprised to find myself enjoying them. I’ve always enjoyed learning new things, and there’s a lot for me to learn.

The flip side of this is the things that I’m not doing. Given the other things now on my plate, I’ve largely stepped back from programming day-to-day.The last time I moved into a largely non-programming role, I missed writing code. This time around I’m not finding the same thing. It could be because I have more than enough to keep me busy elsewhere. However, I think that it’s rather because I’m still very much working in development in the wider sense. Even though I’m not generally committing changes into Git, I’m still involved in the design, planning and review. The main difference is that I now spend more time looking at the big picture, though I’m hoping the years of focussing on the details will stand me in good stead as I do so.


28 Dec 2017

Parsing arguments in Python isn’t hard. There are already many libraries for command line argument parsing in Python, not least argparse in the standard library. However, just because it’s not hard doesn’t mean it’s entirely without effort, and when you’re working on specific problem it’s probably not top of your mind. Creating a proper command line syntax for your quick script or runnable module requires making declarations or tagging things, so you just end up writing something like this and moving on:

if __name__ == '__main__':
    infile, outfile = sys.argv[1:]
    do_stuff(infile, outfile)

It’s rough, but it gets the job done. However, throw away scripts have a tendency not to get thrown away, and this kind of overly spartan, undocumented CLI can end up hanging around for longer than first thought. Adding features is a pain, and a rewrite using a more structured framework is a lot of effort and has to maintain compatibility with the ad hoc version.

Quarg was written to address this problem directly, allowing a proper command line interface to be built up incrementally, starting from nothing. The first and most important design goal was that it worked on unmodified Python code, and produced sensible results. This is done by taking the information that’s already there — top level functions, parameters names, and docstrings — and building an interface based on some broad assumptions and conventions.

The purely automatic interface (which you can get by running your script with quarg as the interpreter, or adding a call to quarg.main() at the end) is useful, and often sufficient, but you can refine it by adding annotations in the form of function decorators and specially formatted docstrings. This is what allows and interface to be built incrementally, rather than requiring a fixed amount of effort up front.

Under the hood, the actual argument parsing is done with argparse, and much of the functionality of that library is available via the arg decorator. While there are fancier libraries out there, I’ve always found the parsing of argparse to be good enough, and it avoids adding an external dependency. Quarg only depends on the standard library, and works in Python 2 and 3, so it should be easy to integrate into most contexts. It’s available on PyPI (pip install quarg).

(On a personal note, I’ve been using Python for 18 years, and while that’s mostly been ad hoc and proprietary stuff, I’ve shared numerous projects on GitHub (and, earlier, SourceForge). However, this is the first package I’ve uploaded to PyPI. The process was pretty straightforward and painless thanks to the Python Packaging User Guide, and I’ll definitely be doing it again. The spread of unified package indices such as PyPI, NPM and CPAN are one of the biggest practical improvements to the programming experience that I’ve seen over the last two decades, and it’s taken me too long to pitch in.)

There are numerous ways in which Quarg could be improved — for example, by making use of type annotations if they’re present. There are also no doubt numerous bugs still to be fixed. Nevertheless, we’ve been using it internally at Cydar for a while now, and found it pretty useful. Hopefully you will too.

While I’m the main author and maintainer of the library, Quarg began life at Cydar, and the company retains the copyright. Thanks to my colleagues at Cydar, particularly Ian Glover, for useful feedback and code contributions. Unfortunately the latter are not attributed in the Git history, as I had to excise it from a larger private repository.


26 May 2017


Python popularised the term “duck typing”; if it looks like a duck, and quacks like a duck, it’s a duck.

C++ is similar, with the caveat that it had damn well better actually be a duck or everything will explode and you’ll get an error message that won’t fit in your terminal’s scrollback.

C works on the assumption that you probably have your reasons for asking a fire hydrant to quack, and doesn’t want to say anything in case it looks stupid.

In Tcl, it’s a duck. Everything is a duck. If you want something other than a duck, make it yourself by taping a bunch of ducks together.

In Java, you spend three days poring over the documentation to try and figure out how to get hold of an instance of something that implements AbstractWaterfowlFactoryManager, then give up and reimplement the whole avian kingdom from scratch based on a version of dinosaurs that you hacked together in college.

JavaScript has no built in concept of “duck”, but there are dozens of ducks to choose from in NPM. All have several hundred dependencies, aren’t documented, and don’t appear to be actively maintained.

Haskell does have ducks, but they’re so 2011. You should totally rewrite everything using Mallard, which is basically the same thing, but better for some reason.

That’s my lot for now, but feel free to send me any more that fit the bill.

The Thrilling Adventures of Lovelace & Babbage

23 Jan 2017

Tori got me The Thrilling Adventures of Lovelace & Babbage by Sydney Padua for Christmas; I’d seen a few scattered excerpts, but didn’t really know anything about the thing as a whole. Turns out it’s rather good. The comics are entertaining, imaginative and well executed, but the real treat are the notes. Padua goes into detail about the characters, history and technology in an informal and engaging way, often exploring surprising tangents. Definitely recommended.

This site is maintained by me, Rob Hague. The opinions here are my own, and not those of my employer or anyone else. You can mail me at rob@rho.org.uk, and I'm robhague on Twitter. The site has a full-text RSS feed if you're so inclined.

Body text is set in Georgia or the nearest equivalent. Headings and other non-body text is set in Cooper Hewitt Light. The latter is © 2014 Cooper Hewitt Smithsonian Design Museum, and used under the SIL Open Font License.

All content © Rob Hague 2002-2015, except where otherwise noted.