I have lots more feedback than I can digest right now. But I will
point out Robert Solovay's interesting reference to two flavors of
second-order arithmetic. One is the "pure" Z_2 axiomatization with
naturals, predicates over naturals (or functions from naturals to
bool, if you prefer), and quantifiers over both. The other, with
equivalent strength, has functions from naturals to naturals. The
latter is probably a lot more directly useful for what I'm trying to
do, because new functions can be defined as plain old lambda terms,
and application is primitive, i.e. requires no hoops to be jumped
through.

I'm more than a bit intrigued, though. Since these systems are indeed
equivalent in logical strength, but differ widely in the convenience
of their definitional systems, it's clear that choice of definitional
framework is very important. How carefully has this space been mapped
out, though? Is it possible that there are other definitional tricks
that could make the systems even more usable, or is macro expansion
plus function definition and application somehow complete in that all
other definitional frameworks can be reduced to it tightly?

I'm not sure what such things might look like, but I see glimmerings.
For one, I'd imagine that statements of the form "abstract tree S is a
parse of string S by grammar G" might be easier to express and prove
than in the usual logics. In any case, these statements are exactly
the kind of thing I'd expect to be primitive in a human-friendly
"source language", and then compiled automatically to a proof "object
code", so maybe in the end it doesn't much matter.

Paul Snively has been blogging about proofs as well. I've skimmed his references, but so far am not sure how relevant they are.

I was hoping to get subpixel text antialiasing in this release, but
didn't quite manage. Hopefully next time.

Proofs

I got some very nice email from Robert Solovay, answering many of my
questions
about second-order arithmetic.

I'm starting to get a handle on definitions. All proof systems have a
mechanism for them, but mathematically they tend to be not very
interesting, so mathematicians don't talk about them much. Even so,
they're clearly important.

In general, definitions create a mapping from a source language to a
target language, mostly by expanding out rewrites of the form
<symbol> = <expansion>. The target language has just the
axioms of the underlying system, like ZFC set theory or Z_2
arithmetic. So the concept of truth or provability is basically the
same between the two languages: a statement in the source language is
provable iff its expansion is provable in the target language.

So now the important thing is to make sure that there are usable
inference rules in the source language. Ideally, all the inference
rules that work in the target language are also sound in the
source. But this doesn't necessarily have to be the case. For
example, if you define the expansion of, say, y = 1/x to be x * y = 1,
then you have 1/0 not equal to anything. This is cool in a way, but
you have to use somewhat different axioms for equality.

Partiality is of course a big issue here. Joe Hurd recommended this paper on how
to get partial effects in a total logic such as HOL. A different
approach is Jan Kuper's quite readable thesis,
which gave me the courage to consider tweaking the equality axioms in
the source language so that you can write terms that don't exist.
Also see Freek Wiedijk's First order logic
with domain conditions.

There is one way in which definitions may be interesting: as a means
of making proofs portable to different axiomatizations. The idea is
that a module of definitions has an interface that exports proved
theorems, but might keep certain details private. A good example is
pairing. Your theorems basically say that you get out what you put in,
and are the same in Z_2, HOL, and ZFC, but the actual construction
(hidden) is quite different. When you plug in a different definition
module with the same interface, you still expect your proofs to go
through.

I'm not sure about the mathematical consequences of this approach.
I get a feeling that it won't work in all cases, but if it works in
all non-contrived ones, that's good enough. It's also entirely
possible I'm reinventing category theory, in which case I better break
down and get a book on it. I got a nice email from Sarah Mount
recommending a few, as well as this paper updating Reynolds' result that polymorphism is not set-theoretic.

The feedback and intellectual excitement I'm getting from my exploration into proof systems is turning out to be quite addictive!

AaronSw has written a fine first-person account of the Eldred
vs. Ashcroft case seeking to overturn the the latest 20 year extension
to copyrights. Also see Aaron's excellent visualization of the
evolution of copyright lifetime since 1790.

I have an idea for a poster or t-shirt: Mickey Mouse is crushing
diamonds underfoot. The caption reads, "Diamonds last a pretty long
time, but Copyright is Forever(R)".

More words on proofs

There's a lot of material, through email and my own thinking. I'll
try to get through it. This entry might be long.

Second-order arithmetic

chalst recommends second-order arithmetic as a nice "small"
system. I poked around a bit and am definitely intrigued. It's been
well-studied for a long time, which of course means that the main
results are in dusty books rather than Web pages. Here's what I did
find, though: a book (with a first
chapter and content-rich reviews online), a concise definition
(with axioms). There are also some drafts of a book by Paul
Voda on computability theory. These are interesting, but it will take
some slogging to figure out how to make it practical.

None of the "fifteen provers" in Freek's list use second-order
arithmetic. Why not? Voda's CL seems to be,
but I don't see other people talking about it. Why is it not on
Freek's list?

Can you use HOL to prove the consistency of second-order arithmetic
(as ZFC can do with HOL, but see below)? If so, HOL would seem to be a
strictly "larger" system. What other important things are in HOL but
not second-order arithmetic? My intuition tells me that integration is
one of them, but of course it could be wrong (I'm not an
intuitionist).

Conversely, can second-order arithmetic prove the consistency of
primitive recursive functions? If so, I have a pretty good idea of
examples you can do in second-order arithmetic but not primitive
recursion: Ackermann's
function is the most famous.

Definition schemes

If you look at the axioms for second order arithmetic, it's clear that
they'd be painful to work with directly. You can't even write a tuple
of integers (but see below). Instead, you have to construct all these
basics from the primitives.

It's clear that any usable formal system must have a system for
introducing definitions for things like tupling. At minimum, such a
scheme must be safe, in that you can't introduce inconsistency
through definitions. Metamath's mechanism for definitions lacks
enforcement of this property, but almost all the definitions
introduced in set.mm are of a restricted form for which safety is
obvious (there's lots more discussion in the Metamath
book). Fortunately, ZFC is powerful enough that these restrictions
are not too painful. In particular, you can express concepts of
extraordinary richness and complexity as functions, then apply and
compose them quite straightforwardly.

HOL's definition scheme is a lot more complex. Basically, you provide
a proof that implies that the new definition won't let in any
inconsistency, then the system lets you define your new constant or
type. For types, you do this by giving a construction in terms of
already existing types. However, once you sneak the definition past
the prover, it doesn't tie you to that specific construction. In fact,
you could replace the construction with another, and all proofs would
still go through. I consider this an important feature, well worth the
extra complexity it entails.

Metamath's set.mm doesn't have this feature; rather, it nails down
specific set-theoretical constructions of all the basics (fortunately,
these are for the most part the standard ones used by mathematicians).
In practice, all the proofs in set.mm are carefully designed so that
the construction can be replaced, but again there's nothing to check
this short of plugging in different constructions and trying it. It
would be possible to rework set.mm so that reals are a tuple of
0, 1, +, -, *, /, etc., and all theorems about reals are explicitly
quantified over this tuple. It sounds pretty painful and tedious,
though. (Incidentally, Norm Megill sent me a nice email sketching how
to do it).

I get the feeling that for second-order arithmetic, the situation is
even more urgent. My intuition is that you can't just add
another layer of quantification as you can in ZFC (and probably
HOL-like type systems), because that would "use up" one order.

Bertrand Russell famously said
that definitions had many advantages, namely those of "theft over
honest toil". It looks to me like a search for a system of "honest
theft" will be rewarding.

A good definition scheme can help with some other concerns, as well.
Primarily, it should be possible to construct the basics compatibly in
a number of logical systems. Sequences of integers, for example, are
straightforward in second-order arithmetic, HOL, and ZFC, although in
each of these cases the most natural construction is quite different.

I'm also intrigued by the possibility of instantiating an axiom
set with a concrete type, perhaps multiple times within the same
universe. The example that comes most readily to mind is integer
arithmetic as a subset of the reals. If you look at set.mm, naturals
appear (at least) twice; once in the usual set-theoretic construction,
and a second time as a subset of reals (which, in turn, are a subset
of complex numbers). The Peano axioms are provable in both. Thus, a
proof expressed in terms of Peano axioms only should prove things in
both constructions. It could be a powerful technique to stitch
together otherwise incompatible modules, although of course it's
equally probably I'm missing something here.

A little puzzle

One of the things I did not find was a library of useful
constructions in second-order arithmetic, so I thought about them
myself. One of the most basic constructions, pairs of naturals,
makes a nice puzzle. This should be doable for most readers.

I came across one such construction in the datatype package for HOL.
It is: pair(x, y) = (2 * x + 1) * 2^y (where ^ is exponentiation).
This is most easily understandable as a bit sequence representation:
the bit sequence of x, followed by a 1 bit, followed by y 0 bits.

But second-order arithmetic doesn't have exponentiation as a primitive
(although you can do it). Can you write a closed form expression as
above using only + * > and an if-then-else operator ("pred ? a : b" in
C)? Obviously, such an expression has to meet a uniqueness property:
no two pairs of naturals can map to the same result.

I've got a pretty nice, simple construction, but I have the feeling an
even simpler one (perhaps without the if-then-else) is possible. In
any case, I'll keep posting hints if nobody comes up with an answer.

The Web as a home for proofs

In any case, the choice of logical systems and the conversions between
them, while interesting and important, is but one aspect of the evil
plan. The other is to make the proof system live comfortably on the
Web.

I think "hypertext" is a good analogy here. We've had plain vanilla
text for a very long time. Closed-world hypertexts resident on a
single computer system (such as HyperCard), also
predated the Web by many years. A lot of people dreamed about a global hypertext for
quite some time, but it took about thirty years for the Web in its
present form to happen.

Likewise, proof systems have come a long way. In the early days, even
proofs of trivial theorems were quite painful. Over the years,
technology has improved so that truly impressive proofs are now
practical. Even so, I can't just download my math from the web, do
some proofs, and upload the results. I'm convinced that this is
exactly what's needed in order to build a library of correct programs
and their associated proofs.

How did the Web succeed where so many bright people failed before?
It's certainly not through doing anything interesting with the text
part of the hypertext problem. In fact, HTML as a document format is,
at best, a reasonable compromise between conflicting approaches, and,
at worst, a steaming pile of turds. What won the day was a combination
of simplicity and attention to the real barriers to successful use
of hypertext.

In particular, the Web made it easy for people to read documents
published to the system, and it made it easy for people to write
documents and get them published. In the early days of the web,
touches like choice between ftp:// and http:// protocols (it was
sometimes easier to get write access to an FTP repository than to set
up a new server), port :8080 (for the relatively common case of being
able to run user processes on a machine but not having root access),
and of course the use of DNS rather than some more centrally managed
namespace significantly lowered the barriers to publish.

The analogous situation with proofs is clear to me. It should be easy
to use a proof once it's already been published, and it should
be easy to publish a proof once you've made one. A great deal of
the story of theorem provers is about the cost of proving a theorem.
This cost is effectively reduced dramatically when it is amortized
over a great many users.

I'll talk a bit about ways to achieve these goals, but first let's
look at how present systems fail to meet them. Keep in mind, they
weren't designed as Web-based systems, so it's not fair
criticism. It would be like complaining that ASCII doesn't have all
the features you need in a hypertext format.

Metamath

In many ways, Metamath is a nice starting point for a Web-based proof
system. In particular, there's a clean conceptual separation between
prover and verifier, enforced by the simple .mm file format. The fact
that set.mm has been nicely exported to the Web for browsing is
also a good sign.

A big problem with Metamath is the management of the namespaces
for definitions and for theorems. There are two issues. First, the
names of existing objects might change. Second, there's nothing to
prevent two people from trying to use the same name. The namespace
issue is of course analogous to programming, and there's lots of
experience with good solutions there (including Modula's module
system, which serves as the basis for Python's).

Another big problem is the lack of a safe mechanism for definitions,
as discussed above. Of course, on the Web, you have to assume
malicious input, while in the local case you only have to worry about
incompetence.

HOL

HOL solves the definition problem. In fact, the definition scheme is
one of the best things about HOL.

However, the distinction between prover and verifier is pretty muddy.
HOL proofs are expressed as ML code. This isn't a good exchange format
over the Web, for a variety of reasons.

Fortunately, people have started exploring solutions to this problem,
specifically file formats for proofs. See Wong and Necula and
Lee. I haven't seen much in the way of published proof databases in
these formats, but I also wouldn't be surprised to see it start to
happen. Interestingly, Ewen Denney uses these results (motivated by
proof-carrying code) as the basis of his HOL to Coq
translator prototype.

I'm unaware of any attempt to manage namespaces in HOL (or any other
proof framework), but again this could just be my igorance.

How to fix namespaces

Whew, this entry is long enough without me having to go into lots of
detail, but the namespace problem seems relatively straightforward to
solve. In short, you use cryptographic hashes to make the top-level
namespace immutable and collision-resistant. Then, you have namespaces
under that so that almost all names other than a few "import"
statements are nicely human-readable.

There's more detail to the idea, of course, but I think it follows
fairly straightforwardly. Ask, though, if you want to see it.

Category theory

Yes, I've come across category theory in my travels. I have an idea
what it's about, but so far I don't think I need it. My suspicion is
that it might be helpful for proving metatheorems about the system
once it's designed, but right now I'm mostly exploring. Ideally, the
system will be simple enough that it's obviously sound, but of course
it's always nice to have a rigorous proof.

Even so, if I get a strong enough recommendation for an accessible
intro to the subject, I'll probably break down and read it.

Translating HOL to ZFC

chalst
also warns that the translation from HOL to ZFC is not trivial, and
cites a classic paper by
Reynolds. Of course, being Web-bound I can't quickly put my hands on a
copy, but I think I understand the issue. Here's a quick summary:

In untyped lambda calculus, representing the identity function (id =
\x.x) in ZFC set theory is problematic. In particular, applying id
to itself is perfectly reasonable in the lambda calculus, but a
function in ZFC theory can't take itself as an argument, because that
would create a "membership loop", the moral equivalent of a set
containing itself.

For any given type, the (monomorphic) identity function over that type
is straightforward. In Metamath notation, given type T it's Irestricted to
T.

So the trick is to represent the polymorphic identity function
(\forall A. \x:A. x) as a function from a type to the identity
function over that type. Before you apply a function, you have to
instantiate its type. You never apply a polymorphic function directly,
and you never have polymorphic functions as arguments or results of
other functions (or as elements of types). So no membership loops, and
no problems in ZFC.

Is this what you meant, or am I missing something?

Well, that's probably enough for today. And I didn't even get into
Joe Hurd's email :)

I've been getting some really good feedback from my series of diary entries on formal proof systems. The latest batch are from Norm Megill (of Metamath fame) and Joe Hurd, who's done quite a bit of work with HOL.

I've used up almost all of my diary time responding to these threads (privately), but the juicy bits will find their way back here.

As Aaron Swartz suggests, I downloaded
Red Hat 8.0 using BitTorrent.
From casper, the performance was amazingly good: around 800-1000 kB/s.
I've long felt that free software ISO's were a killer app for this
code. Unfortunately, it seems not to be in anybody's business interest
to push this angle, because the relative convenience factor of getting
a boxed CD is pretty much gone if you can get full-bandwidth
downloads.

Incidentally, the GUI version crashed randomly on me, but the command
line version behaved fine.

Red Hat 8.0

I like it. I like it a lot.

I installed it on a spare partition on spectre, just to give it
a whirl. This time, I kept a log of
usability issues and bugs. I ran into quite a few, but I think overall
the system hangs togther pretty well. Obviously, people put a lot of
work into making the desktop a good experience as a whole. This is
rare and highly welcome in the oft-fragmented world of free software.

I was pleased that it detected (almost) all my hardware correctly,
including the Audigy soundcard and the dual CPU's. I'll have to add
the (serial) Wacom pad by hand, but that's not bad at all.

There's a good chance I'll put this on my laptop too.

GnomeMeeting

One of the perks of RH 8.0 is that installing GnomeMeeting 0.93.1 was
near-trivial. As I understand, this is pretty difficult software to
get running from scratch. I wasn't looking forward to herding a Gnome
2 development environment onto my machine. To have it Just Work is a
nice treat.

I'm not sure the rest of our team will be able to use GnomeMeeting
effectively just yet. Among other things, the H.323 nonsense prevents
it from working behind a vanilla firewall. That's a problem TeamSpeak
seems to have solved by using a nonstandard protocol.

I went to #gnomemeeting on irc.gnome.org and got personal help from
Damian Sandras, principal author of the program. He was very nice, and
of course this level of community involvement is exactly the reason
why free software is so good. I want GnomeMeeting (or at least some
free VoIP solution) to win.

ZFC vs HOL

I got a very nice email from Robert Solovay in response to my last
entry. He patiently explained to me that you can prove the consistency
of HOL using ZFC theory, which means that ZFC is strictly more
powerful. Gödel's second completeness theorem means that no
system can prove its own consistency. Thanks.

A lot of this stuff still seems fairly murky to me, but I feel the
waters clearing. I had some minor epiphanies over the past few days.
For one, I now see a clean separation between two parts of making a
Web-friendly mathematical system. One part is the translation between
various proof systems, so as not to limit people too much. The other
part is to arrange the inputs, outputs, and immediate files to make it
maximally easy to share over the Web. These are quite separate: it's
not hard to imagine proof format translators still stuck in the
teletype interaction mode characteristic to HOL, or a Web-friendly
system based on any one of the major logical systems. The latter seems
easier to me, actually. I'm still a novice at the heavy mathematics
behind logic and proofs, but I feel I know a lot about the Web and
about how people can collaborate over the Internet.

The other insight has to do with the issue of making "conservative"
proofs designed for portability. I think I can now answer the
question: what are the natural numbers?

Well, what are the natural numbers?

This may be a bit sketchy, because the ideas still feel a bit raw.

At heart, the natural numbers are the Peano axioms. But just stating
the axioms isn't quite enough to make them useful in a proof system.
Among other things, it's dangerous to just add axioms lest they
introduce inconsistency.

So, you build a construction of the naturals using native primitives
of your proof system. For each axiom, you prove a theorem. In the
Metamath approach, you then do everything in terms of this
construction.

But what HOL does for type definitions is better. Essentially, by
making a construction, you're proving that the axioms are
consistent with the primitive logic. It doesn't really matter which
construction you use, as long as you end up with the same axioms.

In fact, what I just said is a key meta-result. The usual
interpretation of proofs in these formal systems is that they prove a
single statement. But here, an abstract proof using only the Peano
axioms can easily be transformed into a concrete proof, just by
substituting in the actual construction.

Meta-logic in general makes me uncomfortable, but in this case I think
it's what's needed to address deep problems of portability. In
particular, I think it solves the problem of multiple different
axiomatizations of the same basic concept. Your "construction" can go
between two equivalent axiom sets just as easily as to a construction
in your primitives. You keep your proofs abstract, but at the end you
check them in some specific formal framework: ZFC if all you care
about is the truth of the proposition, and "smaller" systems such as
HOL if you want to check portability.

I don't think I've communicated the idea well. It's also a bit
half-baked. I've only talked about naturals, but there are other
things, especially functions, that are harder to treat this way. But I
do think I'm on to something here.

The quest for a good VoIP solution continues. One step which may be
considered either encouraging or discouraging is TeamSpeak. Most importantly, it's
not free software, but it does seem to work well enough to use. It
comes from the gamer community rather than any existing VoIP
constituency, which leads to some funky terminology. When someone
joins a channel, a sci-fi female voice announces, "new player." On the
plus side, there's an emphasis on performance and usability
(especially with NAT's, which basically Just Work).

I do want to try GnomeMeeting again, but so far
it hasn't worked for me. One of the most encouraging things about GM
is that the next version will support the new Speex codec, which basically
does for voice what Vorbis does for recorded audio. I took the
standalone coder for a spin and was very pleased.

Proof-carrying code and code-carrying proofs

Michael Norrish sent me a nice email on my recent entry
on proofs and code. The question of whether the proof checker should
include a virtual machine, so that proofs can include programs is in
some ways the dual of proof
carrying code (and bib
from 2000), in which programs come in "fat binaries" with proofs
attached. A runtime can then check the proof, and execute the code
with some assurances, primarily safety. PCC obviously needs a good,
clean, efficient proof format, and equally obviously motivates a sharp
separation between proof generation and proof checking. It's worth
following.

Code-carrying proofs are by no means a new idea. In fact, Coq already implements them. It's not
clear to me how deeply they're actually used. Among other things,
you'd think they'd be useful for avoiding size blowup when importing
theorems from other systems, but at least Freek didn't seem to use
this in his HOL
to Coq translator (Encoding the HOL
Light Logic in Coq).

Translations between proof frameworks

When you look for it, there's been quite a bit of work done on
translating from one proof framework to another. HOL has been
translated into both Coq (and see another prototype)
and NuPrl.
These are not unique, although as it happens such translations can be
quite tricky. For one, logical systems really do differ in expressive
power. This is a bit unintuitive for those of us who grew up on the
Church-Turing thesis, which effectively states that all programming
languages have the same expressive power, because you can always write
a translator from one to another. But logical systems differ in, for
example, the number of ordinals. A proof that so-and-so-many ordinals
exist can be ported to a "larger" system, but not to a "smaller" one.
I can easily imagine a network of such formal systems, but I do not
know how to draw the arrows. For example, I'm pretty sure that you
can represent HOL in ZFC set theory, but my hunch is that the reverse
is not possible.

However, I think a lower-tech solution may well be practical. Not all
proofs make use of the full power of the logical framework. If a
specific proof only uses the subset common to both frameworks, it
should probably be portable.

I think this issue is related to the way Metamath nails down
constructions. Since other systems naturally choose different
constructions, you clearly can't just port proofs over. In Metamath,
you can add sets and integers and get meaningful results. Obviously,
porting any such proof to a different system will fail. However, if a
specific proof uses only the integer axioms, and doesn't refer to the
construction directly, it should be portable.

The way forward seems to be a significant portable library of the
basic constructions: integers, reals, pairs, sequences, trees, etc.
These basic constructions should be done in the most natural way in
the framework. Then, when importing proofs, you hook up these
constructions. There are some subtle details, mostly around
partiality. What exactly is 1/0?

Proof efficiency

Another concern Michael raised is the relative inefficiency of a
translated proof. Especially in the HOL framework, small proofs in the
"source language" (which is really ML with a nice library) expand out
to a large number of primitive inference steps. In the usual HOL
scenario, the inference steps go very fast. If you're writing them out
to a file, then sending it over the net to a different system, you
might start caring about how many steps there are.

I'm not very concerned about this, for a number of reasons. For one, I
believe it should be possible to greatly optimize the resulting
proofs. For two, storage and bandwidth is relatively cheap and is
getting cheaper. For three, a special-case data compressor is likely
to be very effective, if one is needed.

But it's not clear one is needed. Both Automath and Metamath have
significant libraries of theorems, and both can be checked on modern
hardware in about a second. To me, this suggests a huge amount of
safety margin between the optimal and the acceptible.

The Ghostscript codefest is over now. It went well, I think. We fixed
a bunch of bugs, came to understand issues in such areas as embedded
controllers for color laser printers a lot better, had a lively
discussion about Fitz, and spent a little time hanging out and getting
to know each other. I'm convinced that this is quite important,
especially when the developers are geographically dispersed.

Billy

I got a number of responses on the Billy bookcases, generally
expressing disbelief that they really were sold with such a basic
defect as the holes drilled in the wrong place. No, they really were.
rillian and jack both looked at them, and found
pretty direct evidence - for the bolts that hold the thing together,
there are two holes; one thinner and drilled all the way through, and
one shallow but with greater diameter for insetting the head of the
bolt. On correct pieces, the centers align exactly. On the two
defective ones, they're misaligned by about a half inch.

I seem to have a knack for getting defective products. Perhaps it's
just because it bothers me more than most other people.

Microkernels

I didn't mean to imply that microkernels are bad. In fact, there are
definitely some good kernels based on the microkernel idea out there
(QNX comes to mind), and a number of even more exciting research
projects either based directly on microkernels or inspired by them (User-mode Linux, exokernel and eros come to mind).

What I was criticizing is the belief that, other things being more or
less equal, a microkernel will turn out better than a comparable
monolithic kernel. Experience now indicates otherwise. In particular,
it seems you have to work quite a bit harder to get top-flight
performance from a microkernel design. And, the really good ideas from
microkernels (modules) have been ported to the monolithic style.

Beliefs of the form "X is a good way to build a system of type Y" are
not easy to prove or disprove, because there are so many other
variables that affect the quality of the result. If the question is
important, the way to settle it is to build many systems using both X
and non-X, and see if you can pick out a quality trend. If possible,
though, it's better to focus on more crisply testable beliefs.

I'll give an example of one of those: a dynamic specializer is an effective way to get good performance out of highly dynamic interpreted
languages. In particular, I was skeptical about Psyco, but at the rate it
appears to be going, it looks like it will prove this belief. I hope
this demonstrates that "show me the code" is useful for overcoming
unwarranted skepticism as well as filtering out junk ideas.

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.

Aeron

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.

Ikea

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.