A little light on technical content today, largely because I've been preparing to host a weekend codefest for Ghostscript developers. I want to study Bram's recent thoughts on trust metrics, and respond to an email from Michael Norrish on "code-carrying proofs" vs "proof-carrying code". Ah well, later.
Show me the code
rlevin wonders whether "show me the code" is perhaps too arrogant a stance. I don't find arrogance particularly appealing, but I think there is a good reason why this tenet is central to the free software ethic.
The problem is that the world of computing is filled with many, many opinions about things. Hard sciences are driven more by data and falsifiable experiment, but in the sciences with the word "science" in the name, it's still mostly opinion. However, there are good and bad opinions. Many years from now, when we look back, some will look sensible, but most won't. But now, I believe, critical thinkers among us can start to separate the wheat from the chaff.
The hard sciences, of course, evolved from proto-sciences dominated by opinion. Over many years, they developed a culture organized around propagating the good ideas more efficiently than the bad ones. Central to this culture is the idea of experiment. In particular, if a particular opinion can be tested by doing an experiment, it's a lot more interesting. Philosophers used to spend a fair amount of time debating how many angels can fit on the head of a pin. It's clear to us now that this is a matter of opinion. You cannot do the experiment.
As an example of an opinion of an entirely different sort, many chemists in the early 18th century were of the opinion that the relationship between a calx (such as rust) and its corresponding metal (iron) was the addition of a substance, some kind of "inflammable earth". Others believed that it was rather the subtraction of a substance that formed a metal from its calx. What decided the matter was a series of quantitative experiments carefully designed to settle the matter. Today, of course, we know the answer.
In computing, many opinions are of the form "method X is a better way to build systems of type Y than its competitors". I can choose from hundreds of examples, but I'll choose one fairly well known, not too controversial, but with some bite left in it. Microkernels, so believe some people, are a vastly superior way to build operating systems than monolithic kernels. Ten years ago in academic circles, such an opinion would have been considered entirely mainstream. Indeed, the arguments were quite persuasive: elegance, modularity, robustness. Who but a reactionary would disagree that they are the wave of the future?
Well, you can see where I'm going with this. The way to settle the question is to "show me the code". Today, the best kernels for general-purpose use are BSD (still) and Linux. Comparing, say, Darwin and Linux head-to-head is virtually no contest. Not only does Linux eat Darwin for lunch performance-wise, but it's also quite a bit more stable in actual use. Ordinary users see OSX kernel panics commonly, whereas in Linux-land, unless you're a kernel developer they're a pretty reliable sign your hardware has died.
There are still a few crazy holdouts who hold the opinion that microkernels are better. Perhaps they're right, and the superior track record of monolithic kernels is due to accidental factors, such as Linus's superhuman code chops. If so, I'll be convinced when they show me the code. After all, the early experiments to try to settle the phlogiston vs oxygen debate had many flaws, and trying to draw a conclusion from them may have been misleading.
But opinions are damn cheap. Any idiot can have them, and many do. Even smart people are tempted by pretty ideas. We're surrounded by a flood of wrongheaded opinions. The best way to convince me that your idea is one of the few good ones is to show me the code.
Yes, this attitude makes life harder for those with good opinions, but lack time or resources to write code themselves. Lord knows, I've felt the sting of that lash myself with my ideas on trust metrics. If I can't spare the time to code up at least a prototype myself, how can I expect other people to invest their time into my ideas? Since all my ideas are brilliant, it would of course be a lot more efficient if others would just take them up without me having to waste my time on coding, but in the off chance that one of my ideas isn't quite as good as I believed, for other people to take the attitude of "show me the code" might, I admit, save quite a bit of trouble.
I bought a couple of Aeron chairs for the codefest, and so far I love mine. It's still not easy to come to grips with spending the money, but dammit, I earned the money from my own work, and if I should choose to spend it on something I'll enjoy, I shouldn't have to justify it in terms of higher productivity because of better ergonomics or whatnot. But, of course, it's easier if I do.
I got a bunch of Billy bookcases from Ikea a few months ago, and tried to put the last four together yesterday, in preparation for the codefest. But two of them had the holes drilled in the wrong place, and I can't put them together properly.
I suppose I should try to fix the problem, either by getting a replacement from Ikea (not particularly easy), or by hacking (drilling new holes, filling with epoxy). I don't really want to invest my time and energy either way, though, particularly because the material is cheap. Particle board is in many ways the worst construction material very heavy, and no strength. What I'll probably end up doing is slapping some nails into them and ending up with improperly built bookcases, really more suitable for storage of old papers than showcasing my collection of books, almost all of which are meaningful to me and some of which are valuable. I won't be happy with them in my studio, but they'll do.