Yesterday I had the pleasure of releasing version 5.17.8 of Perl. Perl has had regular, time-boxed monthly development releases for about three years now. This great improvement on the previous situation has been accomplished partly by making the release process into something that can be done even by people who, like me, are far from being experts in Perl’s internals.

One of Perl’s long-standing traditions is that release announcements are accompanied by an epigraph, chosen by the release victim volunteer. Here are some notes about the epigraph I picked for 5.17.8.

I must here declare myself as someone who does not for a moment subscribe to the general view that a willingness to perform oneself is detrimental to the dignity of experimental philosophy. There is, after all, a clear distinction between labour carried out for financial reward, and that done for the improvement of mankind: to put it another way, Lower as a philosopher was fully my equal even if he fell away when he became the practising physician. I think ridiculous of certain professors of anatomy, who find it beneath them to pick up the knife themselves, but merely comment while hired hands do the cutting. Sylvius would never have dreamt of sitting on a dais reading from an authority while others cut — when he taught, the knife was in his hand and the blood spattered his coat. Boyle also did not scruple to perform his own experiments and, on one occasion in my presence, even showed himself willing to anatomise a rat with his very own hands. Nor was he less a gentleman when he had finished. Indeed, in my opinion, his stature was all the greater, for in Boyle wealth, humility and curiosity mingled, and the world is richer for it.

As an aside: describing the monarchy as “English and Scottish” rather than “British” may sound odd, but is pedantically correct: the crowns were unified in 1603, following the accession of James VI of Scotland to the English throne, as James I of England. The united Kingdom of Great Britain, on the other hand, was created by the separate English and Scottish Acts of Union in 1707.

This has long been among my favourite books. It’s a philosophical take on the historical mystery novel, set in and around Oxford in 1663, shortly after the restoration of the English and Scottish monarchy. Many of the characters are fictionalised versions of individuals who formed part of what was later characterised as the Age of Enlightenment, including not only Boyle and Lower mentioned in the passage above, but Wallis, Locke, and Wren. The work explores the contrast between the doctrines of ancient and medieval philosophy on the one hand, and the methods of the then-new “experimental” or “natural” philosophy (or science, as we tend to call it now).

The events of the novel are related by a succession of four unreliable narrators, each of whose experiences and expectations colour their explanations for what they observe. Indeed, the final section purports to be the work of a narrator who knows not only what the others have claimed, and where the gaps in their knowledge have led to faulty conclusions, but some crucial facts that shed light on what is at first glance the central issue of the plot: the suspicious death of a Fellow of New College. Yet even here, the reader is to some extent discouraged from taking the whole of this account at face value (in a way which I sadly can’t share without providing plot spoilers).

Why then did I choose this particular passage? I’m not alone in seeing strong connections between science and programming. I find that ensuring a piece of software has the desired behaviour, while simultaneously leaving it readable and maintainable, has much in common with constructing scientific models that match and predict real-world observations, with as few extraneous assumptions as possible. This passage refers to the experimental process, while alluding to another issue that struck me as directly relevant to releasing a piece of open-source software: sometimes, you have to get your hands dirty and actually do the work.

One option would be to monkey-patch new code into the class you're using — just add extra subroutines to the original namespace. But unconstrained monkey-patching has consequences that make it extremely hard to use in practice. So the usual alternative recommendation is to subclass the upstream code, add the new methods in the subclass, and then ensure that the rest of your program always uses the subclass in place of the original. But that approach has two flaws. First, it can be awkward to make sure your subclass is always used in the right places. Second, it doesn't actually fix the problem: you can still experience all the same issues as with monkey-patching!

I gave a talk on this topic at this year's YAPC::EU in Rīga, and it's getting a repeat (and extended!) outing at the inaugural Dynamic Languages Conference today. But if you'd like to read the full details, the corresponding paper is now on my website.

Enjoy!