in reply to Projects where people can die

Suppose you're given a project in which a failure can mean the loss of human lives.

Suppose you want Perl to be the language in that project.

What would be your cautions regarding the choice of Perl?

How would you go about using CPAN modules?

You don't use Perl. Perl isn't designed for life-critical applications; it's designed to make life easy for the coder. That's great when the coder is the guy you care about; in this case, it isn't. The guy who's life is on the line is the guy you care about; and you're going to formally prove that he will never die, no matter what your system does.

That takes a hell of a lot of engineering and formal design work, and a relativly small amount of coding.

In any highly serious (life-critical) app, you need formal design, you need formal analysis of the entire state of the system, you need a rock hard, iron-clad spec of the entire thing, and you need QA built in from the ground up.

Coding time and effort for these sorts of projects is simply irrelevant. The effort it will take to prove every possible logical outcome of the code, and to test every possible branch path is going to dwarf the code itself, no matter what language you use to write it in. The tests will take ages to run; but they will be comprehensive. The certification will take forever to get; but it will formally prove safety (to the degree that you've deemed an acceptable risk). For every line of code you write, there will be hundreds of hours of proof to ensure that that particular line won't kill anyone.

You'll use a language that compiles directly onto the hardware you're running, like C, or Ada; you won't use any language that requires an operating system, or you'll have to certify every single line of the OS, too. You don't want to do that. Just certifying the correctness of the compiler is going to take years and cost hundreds of thousands, if not more.

My friends work on subway controls for automatic train systems. They literally spend days debating the impacts of the changes to a single function; they have to prove to all members of the team that what is proposed is correct, and they do so multiple times, at multiple levels of review, so that no one person's mistake will cause a fault in the end product. Coding is the very least of their worries; not that it's easy, but it's at least all the code has to do is match the spec. The spec itself has to be provably correct; and that's the hard part.

If you're serious about hard-real time control systems, you don't use anything resembling Perl. If you really think you should use Perl, go talk to some professional engineers who build these sorts of systems, and let them change your mind.

Perl is good for many things. Life critical apps are not one of them. CPAN doesn't enter into it.

Replies are listed 'Best First'.
Re^2: Projects where people can die
by merlyn (Sage) on Sep 07, 2006 at 21:21 UTC
    I'm sure I agree with you in the ideal.

    But in the realm of the practical, the US Navy chose Windows(tm) for a critical battleship controls system, which crashed, leaving the battleship stranded for a short time during a wargame.

    So, there's what we should do, and what we actually do. Readers of RISKS digest are well familiar with this principle.

    In that regard, I don't consider Perl and the CPAN to be any riskier than Windows. {grin}

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

    Update: Yeah, for me anything at sea that is used in battle is a "battleship". Well, either that or an aircraft carrier. Shows what I know!
[reply]
[reply]
      It's not the same. Military enterprises are vastly different from civillian ones.

      A corporation that knowingly fails to employ proper engineering tactics could end up with it's entire staff, from the CEO down to the poor schmuck who coded the thing, up on a huge string of both civil and criminal charges. It's simply not acceptable to knowingly let civillians die. That's not something corporations are allowed to do.

      It's the right of the military to get their own soldiers killed however they see fit: as decoys, as cannon fodder, to distract or confuse the enemy, or in a whole host of other ways. It's not great for morale, but it's certainly something a military is allowed to do.

      In the case you cite, the military decided that the risk to it's soldiers was acceptable. That same risk would not be acceptable in a civilian context; but the military is free to sell the lives of it's soldiers as richly or as cheaply as it chooses.

[reply]
        A corporation that knowingly fails to employ proper engineering tactics could end up with it's entire staff, from the CEO down to the poor schmuck who coded the thing, up on a huge string of both civil and criminal charges. It's simply not acceptable to knowingly let civillians die. That's not something corporations are allowed to do.

        Thats bullshit. Everyday, designs are made, in which the designers "KNOW" that so many people will die due to it. It's called cost-benefit analysis, and "externalizing corporate costs". Some examples:

        "highway design" where it is decided that saving 30,000 lives is not worth the price of concrete lane barriers.

        "chemical industry" where it is known that x number of random cancers will be caused by the widespread use of the new whizbang product.

        "auto industry" where it is known that in reality, the streets are being flooded with carcinogenic compunds from tailpipes, resulting in untold cases of disease and death.

        In all these cases, a price is put on human life by the corporations, and the government agency that oversees it.

        Even in "high-profile areas" like airplane crashes, they limit liability and let the designers get away with (murder) negligent man-slaughter , in order to maintain profits. The most obvious example I recall, is the case of the faulty insulation in the cockpits, which caused that plane to go down off Nova Scotia a few years ago. Once the fault was determined, they DID NOT order the planes grounded, nor repairs made. They decided to risk the lives of the passengers, until the planes went out of service due to age. (Another example is the "nitrogen-fueltank-flushing" which would prevent Flight800 type disasters. They decided it isn't worth the price, yet they know it will happen again.)

        I'm not really a human, but I play one on earth. Cogito ergo sum a bum
[reply]
Re^2: Projects where people can die
by chromatic (Archbishop) on Sep 08, 2006 at 06:30 UTC
    You'll use a language that compiles directly onto the hardware you're running, like C...

    You really ought to mark the sardonic parts of your post. I almost fell out of my chair.

    Yes, in one sense C compiles down to hardware (or at least the hardware instructions the VM inside the CPU provides), but I'm not sure "safety" is a word that should apply to a language that allows pointer arithmetic.

[reply]
      Well, control systems have been written in *Assembly Language*; the development process, correctness by construction, and exhaustive testing are what are expected to produce correct results, not intrinsic features of the language. And if a given language feature, such as pointer arithmetic, is deemed too unsafe (or even just too unpredictable), it is simply not used.

      That said, you're totally right: Ada is much safer than C for the types of errors you mention, and thus more widely, (but not exclusively) used for such applications.

[reply]

In Section Meditations