in reply to Perl in the Enterprise

He's insane.

Perl is a horrible language for control systems. "Do what I mean" works great when a wrong guess about "what you mean" costs only a small amount of your time. It's dangerous and irresponsible, however, when a wrong guess about "what you mean" can actually kill someone.

Control systems are the exact opposite of what perl was designed to do: solve simple, ad hoc problems quickly.

Control systems require solving precisely specified problems, with fully known inputs and outputs, formally and correctly, so that it's not just unlikely but all but impossible that anything can go wrong. A well-built control system has tonnes of cross-checks, double checks, engineering, and the designers debate carefully the impact of every single line of code to prove that it is the exact right choice for the application.

Perl just isn't built for that kind of work. It's great at abstracting away the irrelevant details; but for control systems, there aren't any irrelevant details. In a good control system, you want to trust as little as possible to coder discipline. Perl fundamentally assumes you know what you're doing, and if you don't, that run time is an okay time to find out about it. For control systems, that's just not true. When the submarine is about to be crushed under the weight of the water, printing an error message about an exceptional condition is not an acceptable form of error handling. You have to know what the system will do in advance, have an answer planned, and prove that answer works correctly. Perl isn't built for that kind of overhead.

There are little, if any, cross checks in the language: no compile time typechecks, no compile time assertion checking, no static analysis tools, and few, if any code generation tools. There are no run-time performance guarantees. The language is large (200+ built in functions(), with three contexts each, often with multiple meanings and uses for each function), it has a complicated set of parsing rules that allow for code to have different meanings depending upon what has already been defined, and the language intrisicly supports self-modifying code.

It is not well-suited for control systems: anyone who says so is out to get someone else killed.

Perl is good at what it's good at; (it's excellent at replacing shell scripts), but to try to scale it beyond small scale projects, let alone to mission critical applications, is sheer madness. Perl doesn't even try to stop you from making mistakes; which is fine if you're a lone guy coding a simple system. Past a certain point, though, the motto: "Trust me! I know what I'm doing" doesn't scale well.

Replies are listed 'Best First'.
Re^2: Perl in the Enterprise
by perrin (Chancellor) on May 18, 2006 at 01:14 UTC
    I don't know what these "control systems" you're talking about are, but they clearly have nothing to do with "enterprise" and "mission critical" software. You seem to be talking about something military, or some kind of real-time system, i.e. something that would be written in Ada or similar. Enterpise and mission critical software only has to be good enough to run some backend stuff at a stock trading company. No one dies if it goes down, and correctness at the expense of productivity is totally unacceptable. If the cost of mistakes is lower than the cost of avoiding the mistakes, businesses will take the mistakes every time, and that's what enterprise software is all about.
[reply]

      ObAnecdote: Prof for a software engineering class I took used to work on military grade systems. She told us of one demo they gave of some equipment (some sort of avionics system, I want to say) that was supposed to be very fault tolerant (redundant components, etc). Before they started, one of the observing colonels or generals said "Hold on a second" and went up to the demo unit, popped it open, and plucked out a CPU. Fortunately for them, it worked as designed.

      Needless to say, that's definitely a few steps beyond even "enterprise".

[reply]

        We called the creation of that level of robust system stability "Joe-proofing", because it was ensuring that the system could survive being subjected to the tender ministrations of GI Joe in the field.

        print substr("Just another Perl hacker", 0, -2);
        		 - apotheon
        CopyWrite Chad Perrin

[reply]
      The article is talking about replacing Ada with Perl for submarine navigation controls; that's an example of a control system, and it's insane.

      Read the article; the author thinks perl is perfect for literally everything. It's not.

[reply]
        You're right, that is an idiotic idea. I don't know why he thinks that has anything to do with "enterprise." Military applications are almost the opposite of enterprise coding.
[reply]
Re^2: Perl in the Enterprise
by Unanimous Monk (Sexton) on May 18, 2006 at 05:07 UTC
    He's talking about submarine navigation system, not about its safety and control systems. Safety and control system typically aren't even PC based precisely for the reasons you've already presented.

    Any PC based programming language is going to have disadvantages, simply because those languages are designed for flexible use, not a specific application.

[reply]
      Safety and control system typically aren't even PC based precisely for the reasons you've already presented.

      That was true, once; but no more.

[reply]
      On a submarine, the navigation controls are part of a life-critical control system; they link to the hardware, steer the sub, and control elevation. If they don't work right, fatalities can occur. (eg. The sub loses control, hits a reef, or drifts too low, and is crushed under water pressure) Like you noted, control systems are almost never PC based; they're often implemented in Ada, without an OS, directly on a microcontroller.

      He's talking about replacing submarine navigation code in Ada with code written in Perl. Which is why I called him an idiot; because that's just plain wrong.

[reply]

      Are you saying that Perl is a "PC based" programming language? It's more of a Unix-based language (and Unix definitely did not originate with PCs) that has been ported to just about everything.

      Now, if you're saying that C# isn't the best language to use for something like that because it's a "PC based" language, I agree. Perl may also not be the best language for such purposes, but not for the reason you stated.

      print substr("Just another Perl hacker", 0, -2);
      		 - apotheon
      CopyWrite Chad Perrin

[reply]
        I mean "PC" as in the general view of what "a computer" is (i.e. keyboard, mouse, monitor, hard drive, motherboard, etc) regardless of the OS, as opposed to, say, a PLC (Programmable Logic Controller) which has the single purpose of solving logic and only consists of the processor and some IO cards.

        If all you need to do is take some inputs, do some logic, and set some outputs, its a lot easier and more robust if you use something that only does that.

[reply]
Re^2: Perl in the Enterprise
by chromatic (Archbishop) on May 18, 2006 at 05:22 UTC
    ...but to try to scale it beyond small scale projects, let alone to mission critical applications, is sheer madness.

    Hire someone other than a barely-trained monkey.

[reply]
      Sure. Hire someone who's perfect, and code will never have bugs. That works, in theory. But why stop there? Just write your train control systems in BrainFuck with Intercal extensions, and hey, if you're not a barely-trained monkey, the code will be "obvious", right?

      Normal coders rely on structured programming, separation of concerns, and language guarantees to produce trusted code. Perl doesn't offer very much in the ways of guarantees about anything; everything is left to the programmer's discression. That principle can't scale: independent of the language you implement it in.

      There's no typechecking, no array bounds checking, substr() emits the same warning for fatal as non-fatal errors, but otherwise silently fails on bad input. In a critical system, you don't want one programmer to assume that a dial goes to ten, while another programmer assumes it goes to 11. You want a language that can detects code that tries to set an array bounds outside it's declared size to be detected beforre the code finishing compiling. Perl just doesn't do that. It's not designed for that.

[reply]
        Hire someone who's perfect, and code will never have bugs.

        That's not what I wrote (and I suspect you know that).

        You said that Perl doesn't scale beyond small programs. I said that hiring a good programmer with discipline and skill works.

        There's no typechecking...

        Perl has container types.

        ...no array bounds checking...

        Perl has dynamically-sized arrays.

        That principle can't scale: independent of the language you implement it in.

        Dozens of other people on this site (with names and actual histories of doing such a thing) tell different stories. That's why I say that you should hire people who know what they're doing.

        Now I wouldn't write an embedded control system for custom hardware in much of anything but Ada, but generalizing from that point to "Perl can't scale" is a stupid overgeneralization.

[reply]
        A reply falls below the community's threshold of quality. You may see it by logging in.
Re^2: Perl in the Enterprise
by zentara (Cardinal) on May 18, 2006 at 11:57 UTC
    I think Perl is fine for "control systems" with one caveat..... how fast the respose time is. It might not be suitable for guidance systems which require microsecond accuracy, but it will do fine for things like irrigation controls and remote cameras.

    If you want to rant on something that shouldn't be used for control systems, pick on the OS, like the virus prone Microsoft Windows. The OS platform has more to do with reliability than the program language. In my opinion. I would trust a Perl script running on BSD, more than a Visual C++ app running on MSWindows.

    I'm not really a human, but I play one on earth. flash japh
[reply]
      If you want to rant on something that shouldn't be used for control systems, pick on the OS, like the virus prone Microsoft Windows.

      Control systems don't typically have an OS. Sometimes they don't even use a microcontroller, just dedicated hardware. When they do use a microcontroller, Ada is typically used directly on the hardware.

      The author proposed replacing Ada with Perl on submarine control systems; as I've said before, it's an inappropriate choice.

[reply]

In Section Meditations