The lawyers are coming

It seems strange to me that some of the most important software is written in some of the easiest-to-mess-up languages. When we are writing a web application to share 140 character messages with our friends, everything is high-level. There are no blocks of memory, or bits to twiddle that change the hardware configuration, etc., etc. You have to go pretty far out of your way for your application to not work correctly, and then you have extensive unit tests to make sure you don't do that. The possibility of a bug in your application affecting other applications, or the OS, or the hardware is pretty much exactly zero. You aren't even allowed to write code that could be incorrect, like casting pointers or indexing into memory you didn't allocate.

Then there are embedded systems that control missile batteries or commercial aircraft, and to save money on processors, everything is implemented in the lowest-level language possible. You have some registers and a block of memory. The programmer has to manage the hardware configuration, manage memory, make sure he never writes outside of an array, make sure he never treat one pointer as a pointer of another type, etc. If you accidentally forget to do any of those things exactly right, even once in a million lines of code, the device can kill 500 people. And that's not even including bugs in the actual control algorithm... which you don't have much time to get right, since making the computer work at all is the hard part.

Anyway, it would be nice to see the embedded industry as a whole start using a programming language that can ensure some minimal amount of correctness at compile-time. Add a bit of expressiveness to the language so that describing complex algorithms is only a few lines of code, and I think we won't be hearing much about embedded software failing.

My guess, though, is that this will never happen; for the same reason that soft drinks are sweetened with high fructose corn syrup instead of sugar. Saving 0.01 cents times a hundred million units means massive profits. Saving a few cents by using a low-level but dangerous programming languages, and then paying out a few wrongful death settlements is probably cheaper than spec-ing better hardware. Externalities, gotta love 'em.

Edit: I see things like Atom (http://hackage.haskell.org/package/atom) as hope for the future. Machines can write C just fine. Just don't let the humans do it.

As long as the software model is, "if it crashes my desktop computer (or my handheld device, etc.), there is no legal liability for the consequences of my bug," the lawyers do not have an entry point.

Put it in as software embedded in a device where the crash may lead to physical crashes, injuries, and deaths, and the liability stakes increase immeasurably as lawyers and lawsuits enter the picture.

This is a tough area, as almost all complex coding will have bugs in it. In such cases, the manufacturer of the device will have the primary liability to the injured party but almost certainly would have indemnification/contribution rights against the software developer as well. Whether such rights would ever be exercised against a company employee is doubtful but they would undoubtedly be used against a contractor to whom the work had been subbed out.

Important words of caution for software developers dealing with such systems.

I program residential automation systems and this is a real concern of ours. On some projects we must show proof of proper insurance coverage.

I am surprised that most programming projects don't require a similar assurance.