I have submitted an essay to the Stanford Law Review for publication. I didn’t tick the box for “exclusive”, so I think I can blog it as well. It’s a reply to Andrew Tutt’s essay on Software Speech.
English is a Scandinavian language?
Here’s the most interesting adventure in linguistics I’ve run across in a while. Two professors in Norway assert that English is a Scandinavian language, a North Germanic rather than a West Germanic one. More specifically, they claim that Anglo-Saxon (“Old English”) is not the direct ancestor of modern English; rather, our language is more closely related to the dialect of Old Norse spoken in the Danelaw (the Viking-occupied part of England) after about 865.
The bolster their claim by pointing at major grammatical traits which English shares with Old Norse rather than West Germanic languages – notably, consistent SVO (subject-verb-object) word order rather than the SOV (subject-object-verb) or V2 (verb-second) orders that dominate in languages like German, Dutch and Anglo-Saxon. The practical consequence they point out (correctly – I’ve experienced this myself) is that English and Norwegian or Swedish are quite a bit closer in mutual intelligibility than any of this group is with German or Dutch or Anglo-Saxon. I had actually noticed this before and been puzzled by it.
The professors think the reason for this is that rather than evolving into Modern English, Anglo-Saxon actually died out during the two centuries between the invasion of the Great Army in 865 and the defeat of Harold Godwinsson in 1066. They propose that Anglo-Saxon influenced, but was largely replaced by, the Norse dialect of the Anglo-Danish Empire. Which, SVO North Germanic grammar and all, then collided with Norman French and evolved into English as we know it.
This isn’t crazy. It may be wrong, but it isn’t crazy. Two centuries is plenty of time for an invading language to reduce a native one to a low-status argot and even banish it entirely; we’ve seen it happen much faster than that when the invaders are as culturally and politically dominant as the Anglo-Danes were in England at the time of Cnut (1016-1035).
Even in the conventional account of the evolution of English, modern English is supposed to have derived from the Anglo-Saxon spoken in the East Midlands – which, as the professors point out, was the most densely settled part of the Danelaw!
All of this gave me an idea that may go beyond the professors’ hypothesis and explain a few other things…
The wages of secrecy
One of my regulars, contemplating the increasingly pathetic series of clusterfucks that have passed for exciting new products at Microsoft, wonders why a company with all its advantages – more money than $DEITY to hire the best developers, lots of experience, dominant position in a major technology market – can’t seem to release a decent product any more.
The answer is simple and deep. It’s because evil is inefficient.
A secret of game-fu
Last night I utterly trounced three opponents at the slick new Fantasy Flight reissue of a classic interstellar trade and exploration game, Merchants of Venus. My end score was nearly three times that of the runner-up, and I had acquired so many fame points (which each become 10 victory points at game end) that we ran out of fame tokens.
One of the other players half-humorously protested that I had gotten incredibly lucky. “Nonsense”, I said, “it was planning”. He sputtered that I had frequently had the victory conditions for lucrative missions apparently drop in my lap. Which was true, and he was right to view those individual occurrences as luck. But it was also true that I planned my way to victory.
I made chance work for me. Pay attention, because I am about to reveal why there is a large class of games (notably pick-up-and-carry games like Empire Builder, network-building games like Power Grid, and more generally games with a large variety of paths to the win condition) at which I am extremely difficult to beat. The technique is replicable.
reposurgeon 2.0 announcement – the full-orchestra version
I shipped reposurgeon 2.0 a few days ago with the Subversion support feature-complete, and a 2.1 minor bugfix release this morning. My previous release announcement was somewhat rushed, so here is a more detailed one explaining why anybody contemplating moving up from Subversion should care.
To go with this, there is a new version of my DVCS Migration HOWTO.
Terror of the Reposturgeon!
I’ve just shipped reposurgeon 2.0, a power tool for editing and interconverting version-control repositories. This is a major release, adding the capability to read Subversion dump files directly.
The microzen: a unit of enlightenment
Earlier today one of my commenters caused me to realize that it would be entertaining to try to define a unit for the intensity of “aha!” experiences – moments of sudden insight.
Storm warning
By now you’ve doubtless heard about Hurricane Sandy; the record-breaking superstorm hype has been pretty hard to miss. Well, I just got a look at the latest NOAA track projection, and it looks like the storm center is going to pass directly over my house sometime Tuesday night. The center track on that map couldn’t hit me more accurately if it had been aimed.
Announcing autorevision
autorevision extracts metadata about the head version of your repository. This program is meant to be used by project build systems to extract properties that can be used in software version strings. It can create files containing variable and macro definitions suitable for C, C++, sh, Python, Perl, PHP, lua, Javascript, and header files suitable for use with preprocessing Info.plist files.
This was a sort of spinoff from irker, though I’ve decided it not to use it there because I want to keep irkerd and irkerhook.py in single self-contained files.
No, I don’t know dak180′s real name. He’s a pretty good collaborator, though.
I hate having to be the heavy…
I nearly issued a forking threat a few minutes ago. Only the second time I’ve felt a need to do that and the first was in 1993, so this is not something I do casually. And I drew back from the brink.
But I may have to if the maintainer I’m dealing with doesn’t clean up his act. His library is critical to one of my projects, but his behavior has been increasingly sloppy and erratic lately. He made a serious design mistake which he’s been trying to paper over with kluges; the kluges have made the code unstable and the latest shipped version is actually broken to the point of unusability without a patch.
End-to-end arguments in software design
My title is, of course, a reference to the 1984 paper End-to-End Arguments in System Design by Reed, Saltzer, and Clark. They enunciated what has since become understood as perhaps the single most central and successful principle of the design of the Internet. If you have not read it, do chase the link; it well deserves its status as a classic.
The authors wrote mostly about the design of communications networks. But the title referred not to “network design” but to system design, and some of the early language in the paper hints that the authors thought they had discovered a design rule with implications beyond networking. I shall argue that indeed they had – there is a version of the end-to-end principle that applies productively and forcefully to the design of (non-networked) software. I shall develop that version, illustrating it with a case study from experience.
Adventures in kuntao
My regulars will be aware that, since the Mixed Martial Arts program we were in folded up, my wife Cathy and I have been having an interesting learning adventure checking out various schools in our area as possibilities for our next style. We’ve had some more adventures since.
irker is feature-complete
I’ve just shipped irker 1.8, and I think this brings the wild ride I’ve been on for the last eleven days approximately to a close. I consider this release feature-complete; it achieves all the goals I had in mind when the CIA service died and I decided it was up to me to rescue the situation. I expect the development pace to slow down a lot from the almost daily release I’ve been doing.
The last really major feature was irkerhook support for Mercurial repositories. I’d be mildly interested in a bzr extractor class if anyone wanted to contribute one, and that probably wouldn’t be hard – the git and hg extractors are about 70 lines each. But with git, hg, and Subversion covered it’s good enough.
Uptake of irker continues at a pleasingly rapid pace. There’s now a second symbiote application, a poller daemon that watches the log of a specified Subversion repository and uses irkerd to ship notifications from it. This can be useful if you don’t have write access to the repo hooks and thus cannot install irkerhook.
Time for a pause and some reflection on lessons to be learned.
How not to engage me
Considering the extent to which I’m still a public figure, it is perhaps surprising how seldom I get email that deserves a thorough, up-one-side-and-down-the-other flaming. I got one today which I shall reproduce here as a perfect example of how not to engage me.
irker takes off like a rocket
It was just three days ago that I shipped irker 1.0, but the project is already a huge hit out there in hackerland. It’s clear from traffic on the freenode #commits channel that irker installations are springing up everywhere. There’s already one symbiote, a proxy that takes XML-RPC requests in the CIA format and passes them to an irker instance (you have to supply your own mapping of projects to IRC channels for it to use). And at least one custom hook already written and in production – by the Python development list, as it happens.
I’m a bit boggled, actually. I don’t think I’ve ever had a project go from launch to all over the freakin’ landscape this fast before. Guess that’ll happen when you step up with a clean replacement for a service that lots of people were habituated to and have suddenly lost.
There’s more work to be done, of course. (There’s a public repository, and an #irker IRC channel, for people interested in following development.)
CIA and the perils of overengineering
The CIA commit-notification service abruptly died two days ago, a development that surprised nobody who has been paying attention to the recent history of the codebase and its one public server site. A screwup at the cloud service hosting the CIA virtual machine irretrievably destroyed the instance data; please don’t ask me for details, I don’t know how it happened and don’t care. The CIA codebase is so messed up that even reconstituting a virgin instance would be way too much work – and that I will talk about a bit later in this post.
Fortunately, I saw this coming and had started work on a CIA replacement in late August. I had been holding off releasing it because there was some effort going on to salvage the CIA code, but that possibility effectively vanished when the only instance was erased. I shipped my replacement just a few minutes ago, and expect to spend much of the next week helping forge-site operators install it so we can have our notification service back.
The remainder of this post is a finished version of a design analysis of CIA I started a couple of weeks ago when the death of the service was still only a theoretical possibility. Since that theory has become actuality, the message should be heard loudly and clearly: this was a truly classic case of over-engineering, code bloat, excessive centralization, and bad practice. Read on for the cautionary tale.
irker 1.0 (a functional CIA replacement) is shipped
OK, I’ve been hacking intensely for most of the last 24 hours and here’s the payoff: irker-1.0 is shipped. Code and documentation are at http://www.catb.org/esr/irker/.
Out of the starting box we have a hook script with tested support for git and (rather clumsily) Subversion; hg should be a piece of cake for anyone who wants to step up. Forge-site operators can begin installing the relay daemon and the repo hook immediately, and should do so.
Coming soon: a long essay I’ve been sitting on analyzing the now-dead CIA service as a case study in over-engineering. It’s not really very surprising that it collapsed under its own weight.
Also note that there is an XML-RPC proxy for people who have limited ability to change their hook scripts. I haven’t looked at the code myself but there’s a pointer in the irker README file.
An emergency replacement for the CIA service is coming.
A few hours ago I learned that, due to a virtual-server mishap, the cia.vc notification service is dead. And not coming back.
This was not entirely unexpected. The CIA codebase was a shambles, the service has been flaky and subject to outages, and the server-site operator who inherited it has for some time been muttering darkly that the end was probably nigh.
I’ve been sitting on a lightweight replacement for CIA since late August, holding off shipping until it was clear whether or not a salvage effort on the codebase was going to succeed. That option is off the table now, so I’m going into emergency overdrive to get a release out.
The main thing that still needs to be done is for me to finish and test a hook script for git repos, so that when I ship the admins at places like SourceForge and GitHub will be able to drop in both a server instance and the correct hook code. This script will also be a model for hooks serving other VCSes such as Mercurial, Subversion, and (ugh) CVS.
I’m working on that now and expect to ship within 48 hours. Watch this space.
Practical prophecy
Inspired by Dave Logan’s keynote on tribal leadership at AgileCultureCon, I did a breakout session and then an open-space followup on “Practical Prophecy 101″.
Recall that in Logan’s terms a “prophet” is a person who moves the behavior of his tribe towards greater cooperation and creativity by (his words) “preaching the inevitability of values-based change”.
Venessa Miemis took notes on my talk. Here’s a lightly edited and expanded version of those notes. In each item I have replayed a quote of mine that she recorded; where appropriate I have expanded a little on the thinking behind it.
Who were the prophets of the early hackers?
I learned a new way of thinking about social behavior at Agile CultureCon last week – Dave Logan’s taxonomy of tribal stages and his interestingly specialized notion of what a “prophet” is. For review, see Logan’s TED talk.
Logan explains the distribution of tribal stages as follows: Stage 1, “Life Sucks”, is the violent and profoundly dysfunctional tribalism of gangs and prisons (approximately 2% of tribes); Stage 2, “My life sucks”, is bureaucracy (about 22% of tribes); Stage 3, “I’m great (but you’re not)!” is most of business and academia (about 48% of tribes); Stage 4: “We’re great!” is where you start to see serious creativity, tribal self-awareness, and collective sense of mission (about 22% of tribes); and Stage 5 “Life’s great!” is high-creative behavior totally driven by values rather than ego or struggle against some adversary (about 2% of tribes).
A “prophet”, in Logan’s model, is somebody who expresses the deepest shared values of a tribe and invites people in it to change stage (and fuse with other tribes at the new stage). Because most people, most of the time, live in tribes with a stage 3 culture, the most common upward transition (and the most common kind of prophet) is from stage 3 to stage 4.
I noted in a previous post that hearing this in a talk made the hair on the backs of my arms stand up. Because I have lived through, and was one of the prophets of, the hacker culture’s transition from largely unconscious mixed stage-3/stage-4 to fully conscious mostly Stage 4 behavior (“We’re great!”) in the 1990s.
But. I am by no means sufficiently ignorant or egotistical to think I was our only prophet. Most obviously there was Richard Stallman a decade before me, issuing a stage 4 call to higher values around “free software”. But because I was a historian before I was a prophet, I can’t really stop there. I find myself asking who the earlier prophets were!