My programming lately has sort of stagnated; not (entirely) in the traditional sense that I’ve just stopped or lost the inspiration, but that I tend to have been doing lots of smallish or trivial things that maybe don’t actually warrant my time.
The most recent project was writing the Erlang::Parser module for Perl, now distributed on the CPAN. This was a really great way to get to grips with Perl, Moose, and another excuse to write a parser. The resulting module may also prove handy in my line of work, where it might be beneficial to extend Erlang’s syntax with our own additions without having to modify Erlang’s own parser. I also wanted an excuse to have a module on CPAN, and I hope this isn’t the last module I release there.
While it was fun, and a lovely result for the test case–verifying that all of MochiWeb parses correctly–to finally pass on CPAN Testers, the original purpose for which I wanted to parse Erlang code has now gone.
I was toying around with an idea for an OS that implemented Erlang-style light-weight processes with mailboxes (and little else) as the core process type. Rather than inventing a new syntax, or indeed, language, I thought it might also be an idea to parse Erlang (which I thought couldn’t be that hard).
First, I started a prototype in Go, then decided I’d do a quicker and hackier one in Ruby; I cooked my own lexer, and my own not-very-LALR(1) parser generator, but ran out of steam shortly after my home-grown parser started having to deal with precedence issues–or not deal, as it ended up. When my Perl proficiency started to pick up, I started pawing through the Parse:: namespace and realised, in the Perl spirit of things, that I could build on some giants’ shoulders and probably end up with a parser in short order. Thus was born Erlang::Parser.
The first release of E::P such that one of its then 3 modules would end up being module #100,000, at least according to the small count in the lower-left corner of search.cpan.org. From what I could tell, I think I was successful; I uploaded E::P 0.1 to PAUSE when the number read 99,999; it updates quite slowly, but the next update was 100,002, so it was either E::P, or some other 3-module distribution that made #105.
I couldn’t leave the job half finished; even if it did parse enough Erlang at 0.1 to suit my needs, I wanted to do the job properly, now that it was on the CPAN. So I selected MochiWeb as the test case, assuming it would end up using every syntactic quirk of the language at least once. 0.2 ended up being able to fully parse (and verify that it did so to some degree of correctness) MochiWeb.
Now I was parsing code correctly, but the interface of E::P sucked; the AST nodes were just arrays, with the first element being a string describing the type of node, and the remaining elements differing (somewhat arbitrarily) according thereto. If I wanted the module to be really usable (and maintainable), I’d have to make the node types better defined. So I learned to cook a Moose, and then OO-ified the AST nodes. I also spent a lot of time writing POD for every node kind, which I’m glad I did now. That was 0.3. 0.4 was including the Parse::Yapp-generated parser in the distribution, as my Makefile.PL-fu is weak and most CPAN Tester reports were failing due to the generated parser’s absence.
A bit before that, I was enjoying exercising in Golang, and so a few weeks’ spare time were spent writing enwd, a Go DNS server. The name is a pun(?): ‘enw’ is Welsh for ‘name’, and the most popular DNS servers tend to be referred to as ‘named’ (name daemon). Getting things like compression was an exercise in following RFCs.
enwd still seems to disagree with some upstream servers, and doesn’t support recursion, but otherwise it’s a fully functional DNS server. The only thing it lacks is a sufficient administration interface to actually create the zone (!). My plan was for it to support interactive zone editing via HTTP–which it has the beginnings of–but doing that kind of front-end UI work for me is, frankly, pretty boring.
I pushed myself along for a bit, but commits become fewer and further between. The work stopped once I was in the thick of the admin interface.
Other recent-ish projects include golex, a lexical analyser-generator for Go (which makes use of Go’s nifty Go parser and AST manipulation libraries–a must for any language worth its salt!), kotaete, a not too-seriously open-sourced project in PHP which I used to quiz friends on which baby names they preferred.. and somehow not too much else. I suppose HaeSeun also counts–her source isn’t open, however.
The more I look at this paltry(!) list, the more I wonder where my time has been going.. outside of work, family, Loki, etc. I made a few abortive attempts at reviving very old game ideas, and messed around a bit with programming language ideas. Really, though, I’ve been gearing so much thought towards systems programming.
Rob Pike’s “Systems Software Research is Irrelevant” talk from 2000 continues to exact as much of an effect on my thoughts about the subject as it did when I first read the slides (the contention of which, if you hadn’t guessed it, is other to that which the title suggests). See page 6: the software and language stacks we used in 1990 (Unix, X Windows, Emacs, TCP/IP, C, C++) were still used in 2000, with the addition of Netscape, Java, and a little Perl. What’s changed in 2011? Netscape lives on as Firefox, and programming languages fade out of and back into obscurity. The web has probably been the single biggest change in ‘software’ since 2000, which is fitting (with regards to the talk) as it actually largely escapes the realm of the concerns of systems software. I still think systems software research is really important.
In a future post[1], I’ll expand on why I’m thinking that microkernels will probably be a large part of how I choose to spend my free time. I want to stop frittering away my spare time on aimless (though fun) projects, and start trying to actually stretch my creativity, and maybe make something novel while I do it.
