Foreiture of one's Man card

I'll be brief on this:  If your accelerator sticks and you can't get it unstuck, throw the car into neutral.  You may blow the engine or transmission, but what's that next to the value of your life?

Granted, I understand the tension of the moment makes things less clear-cut.  I truly do understand:  When in college, the throttle cable on my car once stuck.  It was an attention-getting experience, but I had the presence of mind to use my clutch and a combination of high gears and slow speeds to keep the car under control.  I limped it the half-mile home.  Had I been driving an automatic, I would've dropped the car into neutral, pulled over, and turned the engine off.

This Prius driver, pardon my French, is a pussy.  Listening to him on the 911 audio, I heard a panicked, effeminate man.  Correction, an effeminate male.  A man would've simply grumbled an obligatory "Crap", thrown the car into neutral, and pulled over.  A real man would've taken it a step further and tried to diagnose and fix the problem on the side of the highway.  A real man would never speak to the press, especially to advertise helplessness against a piece of machinery.

UPDATE, 3/14:

It's now looking like this incident may have been a cry for attention.  Physical evidence from the car doesn't jibe with Mr. Sikes' version of events.  A cloudy past involving allegedly burned business partners is coming to light.  That doesn't affect Mr. Sikes' credibility, but it could indicate intent.

I've spent some time the last couple of days learning about the design of the Toyota Prius, specifically its incorporation of drive-by-wire technology, adapted from a proven technology known as fly-by-wire that's been used for quite some time in aircraft, both commercial and military.  I was unaware that the Prius uses drive-by-wire in place of mechanical linkages.  OK, I'll accept in Mr. Sikes' case that it's possible:  It's possible the Prius' Engine Control Unit (ECU) suddenly accelerated the car.  It's possible that inputs from the brake pedal were ignored in favor of the accelerator.  It's possible that the ECU rejected a transmission shift from Drive into Neutral.  It's possible that the input from the starter button to turn the car off was ignored in favor of the accelerator.  It's possible.  But it's unlikely.  It's a scenario called multiple simultaneous failure.  And armchair engineers are pointing the finger of blame at everybody's favorite whipping boy:  Software.

EDN, a publication I grew up seeing in stacks with my father's work-related stuff, had this gem of elitist snobbery:

The reason all this came to mind this morning was actually not the newspapers, but a panel I attended yesterday at DesignCon. The subject was achieving quality closure. But the issue of software sat like an elephant in the corner of the room, awaiting notice. One of the panelists—I believe it was Design Rivers president Camille Kokozaki—pointed out that perhaps the most serious quality problem in IC designs now is not quality closure on the hardware, but the integrity of the firmware and software that will run on the chip. There simply is no systematic approach to ensuring the quality of an integrated hardware/software system.

And this is a tragedy. Thirty years ago, work was well under way on the problem of formally proving software correctness. One company had designed a completely deterministic microprocessor—no interrupts, no indirect addressing—that made it possible to mathematically prove all of the possible trajectories of a code set. And computer scientists such as Edsger Dijkstra were making strides in methodology to create formally proven software. But along came C, UNIX, and the cult of the bemused hobby programmer, and the entire notion of formal correctness vanished under a smokescreen of hacking.

Excuse me?  What the hell does C, UNIX, and the "cult of the bemused hobby programmer" have to do with software correctness?  I worked at a defense contractor for over 10 years, spanning two DoD contracts.  The software for the projects was developed to run on a real-time OS based on UNIX.  The first project, per DoD requirements at the time, was developed in the software straight-jacket known as Ada.  When the second contract was started, the DoD had dropped the Ada-development requirement.  Ultimately the prime contractor chose C++.  I will concede that C would be a bad choice for an embedded system because of its inherent susceptibility to data corruption through pointers, be they uninitialized, dangling, or null.  But that's not the fault of the language, but the fault of the programmer.  Had the author criticized the abandonment of best software practices, I'd agree with him.