Category Archives: programming

Two projects and an absence

My entry for NaNoGenMo 2016 is ANNALES, a procedurally-generated chronology of rulers, courtiers, tribes and intrigue:

Being a faithful narration of the history of the realm from the reign of Fobbial Artesia I to the present day

As transcribed by the algorithm annales-exe using the pseudo-random seed 1835917550 1 during the reign of Armey Engine III

“For God’s sake, let us sit upon the ground / And tell sad stories of the death of kings”

Reign of Fobbial Artesia I the Unbridgeable.

Fobbial Artesia I, surnamed the Unbridgeable, won the throne by divination.

Fobbial Artesia I espoused Sidentilation with wild channession.

Rumours of morees in Wire Star.


Fobbial Artesia I the Unbridgeable gave birth to a son, Lavaloman, under the influence of Kabdhilinan.

Rumours of rederes in Vectary Viroth.

The source code is here and I’ll be blogging a bit about the technical details on when I get around to it.

I also got around to implementing my dumbest Twitter bot idea, @TVisoTropes.

I’ve been away from Twitter proper since the US election: my mental health has been poor this year, so I’ve had a couple of enforced absences, but the way I was reacting late stages of the campaign and Trump’s victory were pretty decisive in showing me that the way I’ve been using social media is really bad for my brain. I miss it a lot but I still don’t know how to return: maybe when my mood improves? Maybe I should start a new account and reset things?


Learning Haskell

Chris Okasaki – Purely Functional Data Structures
Simon Thompson – Haskell: The Craft of Functional Programming
Bryan O’Sullivan, Don Stewart, and John Goerzen – Real World Haskell

My team at UTS, the eResearch Support Group, has just finished off two major projects, for which I wrote a lot of integration code in Perl and hacked around a lot more than I cared to in Velocity, a horribly ugly template library for Java which is now at the top of my least-favourite-technologies list.

Despite the fact that my job involves less coding than it used to, and that this proportion is likely to drop further, I needed to clean all the glue out of my brain, so I’ve returned to teaching myself Haskell. The last time I attempted this was about five or six years ago: since then, an open-source ecosystem seems to have developed around what was once a very academic language. There are web frameworks and package repositories and things which aren’t really possible in other languages, like a search engine by type signature.

The best way to learn a language is to do something useful with it, and I have a work project for the end of next year in mind: whether Haskell is the right choice or not is something I haven’t quite decided yet.

I read the first two of the three books a couple of months ago: The Craft of Functional Programming was a good way to remind myself of the basics, but I didn’t have the time or energy to work through the exercises, so it didn’t stick. I looked up Purely Functional Data Structures because a friend who is much brighter than I  mentioned it; it’s not so much about Haskell per se, as it is a demonstration that the kind of reasoning which makes for efficient data processing in imperative languages can be applied to functional ones. Not having a background in computer science, I think I understood about forty percent of it, but it left me with the feeling that those who deeply understand such things will have taken care of the details and written great libraries for me to use.

I’m currently reading Real World Haskell properly and doing all of the exercises in spare moments and it’s a lot of fun. I think I’ve even started to understand, or remember, what monads are. (In a side-effect-free programming environment, state – or a sequence of imperative instructions, which is really just a particular kind of state – can be modelled as a sequence of nested evaluations.)

Parsing Perl

I’m going to try blogging about technical matters now, but in a way which my non-technical readers might be able to understand. This may well end up pleasing nobody.

Most of my work is done in Perl, a programming language which divides people. To outsiders, Perl is ugly, hairy, inelegant, badly-specified and generally crappy. It lends itself to bodgy jobs, to a slovenly approach to coding, and to messy, unreadable code that’s impossible to maintain.

There are a couple of ways in which a Perl programmer can respond to this. The first is to half-jokingly argue that Perl is indeed bodgy, and that bodgy jobs are its ecological niche. The second is to point to the design goals of the language, which were to make life easy for the programmer, not for the computer which is running the program.

This last argument is, in a sense, an evasion of the criticism about being badly specified. Perl is, in fact, badly specified. In general, a programming language will be defined by a rigorous grammar. This is something like the grammar of a language like English. I’m not a fan of the analogy between what IT people call ‘natural languages’ and programming languages, but I’ll spare you that for now: I’ll just say that programming language grammars defined the language in a way that is formally precise. The grammar allows any statement or set of statements in the language to be separated into words and parsed into a logical structure: this logical structure is then translated into a set of low-level instructions which the computer executes when it runs the program.

Except that Perl doesn’t really have a rigorous grammar. Perl is full of cheats and niggles which allow it to second-guess the programmer’s intentions, usually in ways which make it a very convenient language in which to write code; they also make it formally intractable. It’s an old Perl joke that “the language specification is the interpreter” – meaning that there’s no formal definition of the language apart from what Perl does when you feed it code: but this is no joke. It’s literally, mathematically true, and here is a fairly rigorous proof that Perl 5 can’t be parsed.

The standard Perl hacker’s response to such things is to laugh. In theory, a badly defined computer language could be dangerous, because you can’t predict with 100% certainty what will happen when your code is compiled and executed. In practice, the number of times I’ve created a bug which arose from Perl’s muddle-headedness – that is, a program malfunctioned because of an ambiguous code construct which Perl took the wrong way – is vanishingly small. Almost all of my bugs were the consequence of bad design, muddled thinking on my part, typos, losing my way, and all the various other kinds of human error. One of the best arguments in Perl’s defense is that the extra levels of convenience it gives you enable you to avoid many of these bugs, and that this more than makes up for the danger of the language’s sloppiness.

However, formal language definitions have another use besides writing compilers: they are highly useful for programming tools, which become considerably more powerful if they can be given access to your code’s structure. Perl’s programming tool support is a long way behind that of languages like Java, because writing tools to support Perl in this way is devilishly hard. It was instructive at OSDC last year to hear Adam Kennedy talking about the lag in the Perl toolchain, compared with what Java programmers get to play with. The Perl hacker’s response to this kind of talk is often to act all tough, as if refactoring tools and class browsers are for wusses, and then go back to our text editors where even syntax highlighting can still be kind of broken: this is not really good enough.

Seen in this light, the Perl design tradeoff – loosening formal language design in exchange for programmer comfort – is not really a tradeoff between formalism and pragmatism; it’s a tradeoff between two different kinds of pragmatism.

Perl 6 is expected to have A Grammar, but the grammar will be modifiable from within the language: a very Perl answer to the problem, but one that has its own dangers.

From today’s code review

Elwyn: “All these long function names are too emo.”

Perl turned 20

I would have more to say about this, if I weren’t up to my elbows in it, madly trying to fix bugs before Christmas. Oh, and Perl 5.10 looks cool.