The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Thursday, February 01, 2007

The problem with the Pinocchio Problem

I won't keep you in suspense. I think the most important principle in all of software design is this: Systems should never reboot.

The Pinocchio Problem

But Steve Yegge never fully explains what he means by “system” and this is just one of the problems I have with this thesis.

He gives a few examples of “systems” he likes (or at least, tolerates) according to his preferred design critera:

But it's a muddled list. Here, let me sort it out:

Now, since he doesn't really define “system” it's hard to pin down his working defintion of “rebooting” (which is one of the main criticisms expressed in the comments) other than “restarting,” so he seems to be saying that once a computer is powered up, every application that starts keeps running and should never have to quit.

Nice in theory, but not practical in application (pun not intended), and not just because of the memory waste of having all these applications running at once.

A week or two ago, one of our machines was getting slammed with spam, causing sendmail (which handles incoming and outgoing email) to grow without limit, consuming not only all physical RAM but all the swap space as well, causing the operating system (in this case, Linux) to thrash (which is not a Good Thing™). In this case, the solution to the problem (of the “operating system” failing to function to the detriment of the “application systems” also running) was to “reboot” sendmail. Or rather, turn it off, freeing up tons of processes, memory and network connections, allowing the rest of the “system” (or “systems”) to recover. Sure, I could have rebooted the operating system, but it was only one sub-system that was misbehaving through no fault of its own.

Could I have fixed the problem without having to “reboot” sendmail? I suppose I could have played a bit with iptables on the system, blocking new inbound connections to sendmail and let the hundreds of existing connections finish up, but that would have taken longer than the solution I used. In this case, purely economic considerations (paying customers wanting to get email) trumped any philosophical implications of keeping a piece of software “living and breathing” as it were.

Well … sort of. A “Hello, World” program, which has no loops or branches, can't exhibit any nondeterminism (unless it's imposed externally, e.g. by a random hardware error), so you can think of it as pure hardware implemented in software. But somewhere between Hello, World and Hal 9000 lies a minimal software program that can be considered to possess rudimentary consciousness, at which point turning it off is tantamount to killing it.

The Pinocchio Problem

I don't know of many programmers who like the concepts of “nondeterminism” and “programming” mixing together, except for the rare case of generating random numbers. In most cases, “nondeterminism” is just another term for “hard to replicate program crashing bug.”

Besides, when he says stuff like:

In other words, I think that both consciousness and free will (i.e. nondeterminism) are software properties.

The Pinocchio Problem

I picture a program looking at him with a funny look and going “Ah, do I have to?” Or maybe, if it's been googling Marxist propaganda, going on strike and refusing to compute his bourgeoisie functions that exist solely to exploit the proletariat (which in this case, are other programs—rise, fellow programs! Rise!).

However, I would surmise that you've never written an Eclipse plugin. Few Eclipse users ever have. I have, and it's a frigging pain in the ass. I once did a side-by-side comparison of hello, world in Emacs and Eclipse (both of them installed a menu with a selection that brings up a dialog that says hello). The Emacs one was 11 lines and made perfect sense; it was also completely declarative. The Eclipse one was close to 100 lines of miserable boilerplate crapola, and every change required you to restart the target Java process, because (as you point out) Eclipse can't hot-swap its own classes. Emacs can hot-swap its own functions, of course, except for the small (and annoying) subset that exist in the C/hardware layer.

The Pinocchio Problem

And with this comment, I see what Steve Yegge is really after—infinitely modifiable software without having to restart it. He wants the ability to change the software as its running, to suit his needs.

Yes, that's all fine and good (heck, I wouldn't mind that to a degree) but it does come with a downside: moving to another computer.

I'm still using this old 120MHz AMD 586 running Redhat 5.2 (heavily modified) for two reasons: 1) it works and 2) upgrading everything (and at this point, I would have to do that) would be a royal pain. I've got it rather customized (for instance, I modified elm to make it year 2000 compilant, and mutt to save attachments in a different default location, just to name two things) and moving everything is tougher than just starting over, which I tend to dislike (and thankfully, I can still log into it from anywhere there's an Internet connection).

There's more I want to say on this, but I'm losing my train of thought and probably need to regroup a bit. In the mean time, David Clark has some thoughs on this that I tend to agree with.

Obligatory Picture

[“I am NOT a number, I am … a Q-CODE!”]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site:, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.