Weird Bobby Tables

11 Feb 2019

Jarred Sumner asks why isn’t the internet more fun and weird? He laments the creativity lost when modern social platforms cut off the Wild West your-code-here flexibility of earlier platforms such as MySpace.

We — the programmers, designers, product people — collectively decided that users don’t deserve the right to code in everyday products. Users are too stupid. They’d break stuff. Coding is too complicated for ordinary people. Besides, we can just do the coding…so why does it matter?

He then goes on to cite this well-known XKCD:

XKCD — Exploits of a Mom

While I agree with the general premise of the post, namely that users are more than capable of creating with code and that there’s value in a platform that lets them do so, I think the reasoning is backwards. The problem with Bobby Tables isn’t that users are too stupid. The problem is that they are too smart.

In the early decades of computing, and even the early years of the web, everyone was on the same side. Nobody was going to go out of their way to break or abuse the systems you put online, and any chaos that happened to be caused was purely by accident. Needless to say, times have changed. Even if the majority of people in your corner of the internet are community-minded saints, there are enough bad actors that it’s only a matter of time (perhaps milliseconds) before one finds you.

We can’t turn the clock back to those halcyon days, and give the benefits of the modern web few would want to. However, all is not lost. A recurring theme in recent years is isolation — technologies such as virtualisation, containers and sandboxing. These allow untrusted code to be run while mitigating the risks if that code is in fact malicious.

Modern, mature (although still evolving) isolation technologies have enabled a flourishing of platforms such as Glitch, Binder and Sumner’s CodeBlog. Following an over-correction in the direction of safety, this is a welcome move back towards flexible, creative platforms, made with eyes open to the technological risks. These platforms allow users to code the web both easily and safely, without the whole thing crashing down when it meets little Bobby Tables.

A Great Year for Blogging

22 Jan 2019

Just before New Year, I happened to look at the archive and realised that I’d only written a single post in the entirety of 2018, making it the joint-leanest year since I started this site in 2002. This was certainly not intentional, but rather due to a parade of other things big and small eating up my time. Nevertheless, it’s something I resolved to improve upon in 2019.

My resolve was cemented when I came across Manton Reece’s post, which ends on the following positive note:

I think 2019 is going to be a great year for blogging.

This may well turn out to a sentiment akin to the Year of Linux On The Desktop, more hope than reality, but I there are reasons to think that there may be something in it. Barely a week goes by without a revelation of a remorseless Facebook doing something terrible, and Twitter is increasingly polarised and toxic. The shine definitely seems to be coming off centralised, bite-sized social networks.

Whether or not this is the case generally, I’m going to aim to write more here this year. We’ll see how that goes…


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.

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, 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.