* * * * *
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 [1]”
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:
* Unix
* Windows XP
* Mac OS/X
* Emacs
* Microsoft Excel
* Firefox
* Ruby on Rails
* Python
* Ruby
* Scheme
* Common Lisp
* LP Muds
* The Java Virtual Machine
* Microsoft Word
* OmniGraffle Pro
* JavaScript
* Perforce
* The GIMP
* Mathematica
* VIM
* Lua
* Internet Explorer
But it's a muddled list. Here, let me sort it out:
* Operating systems
* * Unix
* * Windows XP
* * Mac OS/X
* Applications that want to be operating systems
* * Emacs
* * Microsoft Word
* Applications that are parasitic to the Operating System they inhabit
* * Internet Explorer
* Interpeted Computer Languages
* * Python
* * Ruby
* * Scheme
* * Common Lisp
* * Lua
* * JavaScript
* Interpreted Computer Langauges that are also frameworks
* * The Java Virtual Machine
* * Ruby on Rails
* Applications
* * Microsoft Excel
* * Firefox
* Long lived or continuously running applications
* * LP Muds
* Applications
* * OmniGraffle Pro
* * Perforce
* * The GIMP
* * Mathematica
* * VIM
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 [2] 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 [3]”
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 [4]”
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 [5] propaganda, going on strike
and refusing to compute his bourgeoisie [6] functions that exist solely to
exploit the proletariat [7] (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 [8]”
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 (Megahertz) AMD 586 running Redhat [9] 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 [10] 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 [11] has some
thoughs on this [12] that I tend to agree with.
[1]
http://steve-/
[2]
gopher://gopher.conman.org/0Phlog:2007/01/31.2
[3]
http://steve-/
[4]
http://steve-/
[5]
http://en.wikipedia.org/wiki/Marxism
[6]
http://en.wikipedia.org/wiki/Bourgeoisie
[7]
http://en.wikipedia.org/wiki/Proletariat
[8]
http://steve-/
[9]
http://www.redhat.com/
[10]
gopher://gopher.conman.org/0Phlog:2007/01/23.2
[11]
http://prophipsi.blogspot.com/
[12]
http://prophipsi.blogspot.com/2007/01/pinocchio-became-little-
Email author at
[email protected]