I posted the following article on Slashdot:
Subject: F-22 Avionics Require Inflight Reboot
Why do you need the inflight reboot?
Because that is the nature of complex algorithmic systems. An algorithmic system is temporally inconsistent and unstable by nature. Using the algorithm as the basis of software construction is an ancient practice pioneered by Lady Ada Lovelace and Charles Babbage. It is the fundamental reason why dependable software systems are so hard to produce.
There is something rotten at the core of software engineering. Software functionality should not be fundamentally different from hardware functionality. Software should emulate hardware and serve as an extension to it. It should only provide the two things that are lacking in hardware: flexibility and ease of modification. The only way to solve the reliability crisis is to abandon the bad practice of using algorithms as the basis of software construction and to adopt a pure signal-based paradigm. More details can be found at the links below:
Black Parrot posted the following response which was immediately moderated up by the Slashdot geeks:
> Software functionality should not be fundamentally different from hardware functionality.
Am I to understand that you are saying that software, like hardware, should only fail when it fails?
Granted, we have a software reliability crisis on our hands. But hardware isn't generally fault-free either. I've had a lot more Zip drives die on me than I've had kernel panics. And arguably a kernel is much more complex than the design of a removable disk drive.
> An algorithmic system is temporally inconsistent and unstable by nature.
That's an absurd claim. It's possible to prove correct behavior for algorithmic systems. Time is explicitly accounted for in most such proofs.
The biggest engineering difference between software and hardware is that people find software errors acceptable, or even normal, whereas they have never reconciled themselves to, say, collapsing bridges or wings falling off of airplanes. When that attitude changes we'll start seeing software that rivals hardware in reliability, not before. Most of the engineering concepts required for producing good software have been around for quite a while.
I choose to respond to Black Parrot below rather than on Slashdot because the Slashdot pack mentality is not conducive to productive discussions:
Am I to understand that you are saying that software, like hardware, should only fail when it fails?
This is one of the stupidest straw man questions I have ever read. Does this question even make sense?
Granted, we have a software reliability crisis on our hands. But hardware isn't generally fault-free either. I've had a lot more Zip drives die on me than I've had kernel panics. And arguably a kernel is much more complex than the design of a removable disk drive.
It must have taken some really deep thinking on the part of Black Parrot for him (her) to infer that, by hardware, I was alluding to things like Zip drives. But why stop at Zip drives? Why not add toasters, diesel engines and toenail clippers into the mix for good measure? I still don't understand why such a lame post was moderated up to 5 by the clueless Slashdot moderators. Parrot obviously did not read a single line at the linked pages that I provided.
> An algorithmic system is temporally inconsistent and unstable by nature.
That's an absurd claim. It's possible to prove correct behavior for algorithmic systems. Time is explicitly accounted for in most such proofs.
Who said anything about proving the correct behavior of chosen algorithms? I specifically wrote "temporally inconsistent and unstable." The truth is that, unless we are talking about a stand-alone program with no external inputs other than a simple run command, it is practically impossible to predict the behavior of a sufficiently complex algorithm. Why? because, as I wrote on the Silver Bullet page, conditional branches--a necessary decision mechanism in an algorithmic program--make it impossible to predict the exact duration of most subroutines that depend on external events. They often terminate unpredictably, which can throw off the timing of every statement in the calling program. Since a signal-based system does not have subroutines, only an object that is directly affected by a sensory-based decision will behave in a temporally non-deterministic fashion. There is no point in throwing an entire program temporally off-track just because of a single, locally isolated decision.
Here are a few questions that need answers. Does anybody know who Black Parrot is? Is Slashdot really that lame? Do those guys actually think it's always going to be Linux and Windows forever battling it out?
I've got news for them. Both Linux and Windows are destined to be obsolete operating systems sooner than they think. The reason is that they are both based on the same hopelessly flawed software model that was introduced to computing by Lovelace and Babbage one hundred and sixty years ago. This was at a time when the best performance they could hope for that speed demon of theirs--the analytical engine, too bad they never got it to work-- was maybe fifty cycles per second at the most. Times have changed somewhat since then.