Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Perl in the Enterprise

by Scott7477 (Chaplain)
on May 17, 2006 at 20:44 UTC ( #550080=perlmeditation: print w/replies, xml ) Need Help??

A post showed up today at BSD DevCenter titled Of Oysters and Perls, or Perl in the Enterprise.

The author, Robert J. Pratte, asks “the question of when Perl will make it as an enterprise-class language?.” He says, “Sure, Perl is widely used in large systems, but usually for testing, systems administration, CGI, and “glue.” What about large, critical applications, however? How many architects and managers have considered Perl lately when it came time to look at an alternative to Java or C++?”

Pratte is not necessarily negative in this post. He asks “why are people frothing over Python or Ruby when Perl still has so much to offer?” He admits that “Perl is widely used in large systems, but usually for testing, systems administration, CGI, and “glue.””

But he suggests that improvements need to be made to turn Perl into a “respectable corporate contender” and gives a laundry list of desired improvements: “better error handling, logging, and threading”, and “adding assertions, native compilation, and a snazzy IDE” along with “some nice frameworks for web, CORBA, and SOA.”

In the end Pratte seems to be saying that Perl can be an “enterprise-class” language that could be used in applications that require bulletproof operation. He gives the example of apps that run submarine navigation systems.

I would be interested to read what all you experienced Perl monks think of all this. Is he way off base, and are there examples of Perl being used in “mission-critical” applications?

Update: I appreciate all of the responses; following this thread has been very educational. My thoughts are that with the right people, and with good planning and project management nearly any application could be produced in Perl to meet the standards of Wall Street trading firms, which I think have the most demanding software requirements in non-military applications.

While ruminating on this subject I came across several items on the web that seem relevant and were at least interesting reads. One is a story titled Botched stock trade costs Japan firm $225M which discusses a human error where IMHO poorly designed software was as much to blame as the actual typo by the person involved.

Another is a document Avionics Software Challenges and Initiatives, which is a Boeing analysis of the title topic. A document that made me chuckle is this case study which describes how the US Navy built a prototype "Smart Ship" which was run using Pentium Pro PC's and Windows NT 4.0. The money quote: "In September of 1997 ... the Yorktown's propulsion system failed. The ship had to be towed to a Naval base at Norfork, and the ship was not restored to operational status for two days. The culprit? The software running on PCs designed to control the ship crashed, taking the rest of the ship down with it."

Replies are listed 'Best First'.
Re: Perl in the Enterprise
by renodino (Curate) on May 17, 2006 at 23:03 UTC
    I eschew the use of the 'E' word, due to the repeated and blatant abuse of the term as marketing hype from empty suits, I'll assume the original author intended the term to be interpretted as "mission critical, scalable, networked, secure, fault-tolerant (or at least fault recoverable), possibly web-based, possibly transactional". Think "J2EE/WebSphere/WebLogic/et al".

    I recently implemented/delivered a pure-Perl application (framework, actually) that meets many of those requirements. While it took some convincing, after I delivered the first working prototype in a few days, the debate quieted some. Then a few days later I delivered the updated prototype with some add'l features the customer tacked on, and they consented to let me proceed with Perl (they had a pretty serious jones for C++, but were smart enough to understand that the complexity and platform migration requirements would probably doom such an effort).

    So here's my experience:

    So I'm convinced that Perl is capable of meeting the 'E' class requirements I outlined above. But I do have some reservations - and a few frustrations.

    To summarize:

    One non-obvious issue may be the lack of a single "bible" of writing 'E' class Perl. Many Perl tomes exist, but they all tend to focus on a specific application set or API, or on the language itself. I'm unaware of any book or website that has attempted a complete and lucid discussion of building 'E' class apps using Perl, ala the shelfloads of J2EE books. (IMHO, P5EE doesn't count, its not much more than a laundry list).

      I basically agree with everything you've said (at least, everything with which I've enough familiarity to be able to come to a reasonable conclusion), with one exception: I'm convinced of another benefit to "native compilation" (meaning persistent binary executable compilation, of course).

      This is really a social benefit, rather than a technical benefit, though it is a technical side-effect that creates this benefit. In particular, I refer to portability. I don't mean portability across platforms, but across implementations of a single platform, via end-users. End-users like having an "installer" that creates an executable program without attendant dependencies. That's often largely irrelevant for Perl on Linux, but highly relevant on Windows systems, where Perl parsers are a rare beast indeed (amongst poplations of people who aren't Perl programmers, at any rate). The ability to simply and easily produce a persistent binary executable that requires no installed parser (or modules/libraries specific to it, for that matter) has I think been a significant advantage for the universalization of C/C++, and the marketing drive to get JVMs of various descriptions installed on every workstation, server, laptop, toaster, and dead badger on the planet by Sun has mitigated this social shortfall for Java enough to overcome that barrier to widespread use of applications developed in that language. Until something written in Perl can be downloaded, one-click "installed", and run on an otherwise "bare bones" MS Windows install (or until MS Windows isn't the default end user OS), we aren't going to see Perl enjoying the same popularity as certain other languages.

      The easiest way to achieve that, I think, is to suddenly sprout a compiler of persistent binary executables for Perl.

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

        While Perl doesn't offer compilation to bytecode (before execution), it is possible to create stand-alone applications by packing all resources in a self-contained, executable archive.
        Of course, I am talking about the PAR module here (Homepage, CPAN).

        Now, it is a little rough around the edges here and there, but it's actively maintained and I have personally used it with large applications in enterprise environments.

Re: Perl in the Enterprise
by wazoox (Prior) on May 17, 2006 at 21:11 UTC
    I've written several storage management applications (99% Perl). One is managing 120TB of video for the INA (french National Audio and Video Archive, see, another one migrate several TB of geographic data at IGN (french National Geographic Institute,
    Is it "enterprise ready" and "corporate class" enough ? :)
Re: Perl in the Enterprise
by GrandFather (Sage) on May 17, 2006 at 20:59 UTC

    What world does Pratte live in? We use Perl as part of our mision critical build system. Part of our mission is to write and deliver software. Our build system is a key part of that process. Perl is used in important places in the build system. (In fact the next version of the build management software will be written in Perl.) So, we at least use Perl in a mission critical role.

    There are already "snazzy" IDEs around for Perl: Komodo and Eclipse/EPIC for a start. Those are not part of the language, but they are important to some people to make it a viable language.

    Anyway, at the end of the day, why does Perl need to be an "Enterprise" language? Why can't it just be a damn good problem solver and a bundle of fun to use with a really good support community?

    DWIM is Perl's answer to Gödel

      You actually proved exactly what the orginal author tried to say - the opposite of what you thought you were proving, perl is not mission critical, but only as a tool - in your case, a building tool.

      Is building a serious step of the process? yes, but is it a serious part of the actual application system that delivers the functionality? you didn't indicate, but most likely no, otherwise you would have emphasized.

      Perl is not enterprise class, that even lots of Perl guys, like me see it crystal clear.

      Go back to one of the point in the original post, which he added after reading some of the replies - that with proper project management, any language can deliver enterprise class system. Look at this from a different point of view: if the management of the project choose Perl for enterprise class system (not as a tool, but as the core), then the management failed right there. No need to go further, I tell you, they failed miserably.

      Perl was sexy, as it was and is free, but free is no longer the point any more, java is free, ruby is free, the list goes on and on. Even .Net IDE is now free.

      How many people will start a new project with CGI? maybe a handful. Perl was the only sexy girl in the class during the CGI era, but now, even I agree that Perl is not ugly, there are also many other pretty girls, why has to be Perl?

      Agree or not, Perl has a bad reputation for being not enterprise. What perl can deliver is unique, and none other languages can deliver? nothing, okay if that's the case, why should I not choose something that has a good reputation? is it not true that one key point of project management is to control the risk? Put in this way, Perl might be a vigin, however quite a few people saying that Perl is a prostitute, do you still want to marry Perl. Remeber there is a chance that she is really a vigin, but the key point is why take the risk? is she the last girl on earth?

        Virgin? Prostitute? What?

        Ultimately, the point is that Perl is one of the truly excellent high-level procedural languages, and while its object model feels tacked-on, it's quite capable. I'm thoroughly enamored with its closures. It excels at producing succinct, stable code very quickly, and while PHP is more accessible to the web development dilettante, and more ubiquitous on bargain-basement webhosts and in low-end general purpose web application software, there are areas where PHP simply does not measure up. Other languages that can fill the same needs Perl does that PHP does not include Ruby, Python, and some Lisp dialects, but the parsers for these languages don't tend to be as fast as Perl's, they don't tend to process text as easily as Perl, and there simply isn't the same supporting codebase out there.

        I could continue. There are quite a few desirable characteristics that other languages cannot deliver (as well). Each language has its purpose, or it wouldn't have been created in the first place, and Perl is not a language that has been obsolesced or superseded (yet) by another extant language.

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

        Actually I'm working somewhere we we have mission critical perl applications, and they were not written by experienced programmers, particularly experienced programmers. The system provides important information for the aviation industry.

        I've come on board as an experienced perl developer to move from an evolved system (with some OO and some basic good practice) to a measurably robust and garunteed 24/7 system with 0 downtime and the ability to scale up to more projects.

        Perl works very well in this job, the hard bit is the development process and defining the requirements. This applies to all languages, and I doubt very much a Java project would be an iota easier to refactor or maintain if developed in the same way.

        Also - this is 90% non-web, a mix of PHP and Perl are on the web, but the data feeds and heavy lifting are all perl, so the CGI era crap won't stick.

        I've been integrating systems using perl for about 6 years and can count the 'cgi scripts' I've written on one hand.

        Formatting added by GrandFather

Re: Perl in the Enterprise
by perrin (Chancellor) on May 18, 2006 at 01:15 UTC
    Someone should clue this guy in that major finance companies (e.g. Morgan Stanley) run mission critical software on Perl, not to mention Yahoo, Amazon, TicketMaster, etc.
      Someone should clue this guy in that major finance companies (e.g. Morgan Stanley) run mission critical software on Perl, not to mention Yahoo, Amazon, TicketMaster, etc.
      Add to that list: a portion of Citigroup's realtime credit card application approval system.

      It's glue, but if the glue fails major $$$ is lost.

      Nothing is too wonderful to be true
      -- Michael Faraday

Re: Perl in the Enterprise
by roboticus (Chancellor) on May 18, 2006 at 04:48 UTC

    Good question. A couple of years ago, I had to create a set of data feed translators between a mainframe and an application on a Windows 2000 box. Since I had only a couple of days to do it in, I whipped it up in Perl. When we attempted to roll it out into production, management delayed the rollout and forced us to rewrite the app in one of the "approved" languages.

    Then we were bought out by a larger corporation, and while exploring the corporate website, I found that Perl is on the Proscribed technologies list, along with the reason it's prohibited. I don't remember the exact reason, but the gist of it was that Perl is thought of as a Web application language, and that it's insecure.

    The funny thing: It's only prohibited on certain platforms. For the Solaris, HP-UX, and AIX platforms it's OK. (I wish my project was deployed on one of those, instead of W2K.)


      While Java and .NET certainly have their uses, and I wouldn't recommend a company making a list of "proscribed technologies" that included Java and .NET, I rather suspect that a company that included Java and .NET in such a list would end up with better software on average than a company that listed Perl and Lisp, or Perl and Python, or something like that, as "proscribed technologies".

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

        I totally agree. I'm pretty much a "what language is going to do the job best for me" type of guy. That's why the latest project is a mixture of C++, C# and VB. I needed to do some process control, so I used VB (a previous employee had a nice set of subroutines to steal, so I needed to add only a little code). For the I/O screens, I used C#. Then I had some *massive* data manipulation and reformatting. I used C++ for that.

        (I originally wrote 'em in Perl. It took very little time to write, and they ran pretty fast. Then when I had to code 'em up again, I tried C#, but quit when I found that C# sucks mightily for the types of data manipulation I was doing--too much typing to do simple byte manipulations, and I like pointers for some things. I finally finished in C++. It took longer to code than Perl (far longer, as I had no handy subroutine libraries). But I console myself in that it runs like a rocket! (2GB of data files in seven formats parsed, sorted, filtered and rewritten into 12 output feeds .... 90 seconds!)

        But if I could've used my original Perl version, I'd've had another 2.5 weeks to work on other tasks.... For the data manipulation I was doing, Perl was clearly better for 90% of it. (Maybe all ... but I'm not so sure about that. On my desktop it starts to suck when my data structures get up to 2GB of data. But that's likely due to my limited Perl skills.)


Re: Perl in the Enterprise
by samtregar (Abbot) on May 17, 2006 at 22:29 UTC
    For context on the real meaning of the term "enterprise", please see The Daily WTF. Hint: it's not a compliment!


    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Perl in the Enterprise
by mvandenb (Beadle) on May 18, 2006 at 14:33 UTC
    I work for one of the largest software companies in the world. For the last couple of years, I architected, developed and maintain a pure Perl application that is considered mission-critical by the company I work for.

    That is: if it stops working, thousands of users across the globe have to stop working also. The application has to be available 24x7.

    So far, I have never had a problem that was related to the choice of language, and I never regretted choosing Perl.

Re: Perl in the Enterprise
by Aristotle (Chancellor) on May 20, 2006 at 06:50 UTC
Re: Perl in the Enterprise
by bigmacbear (Monk) on May 18, 2006 at 23:18 UTC

    I'm making this a comment mostly because it touches on several previous posts and I'm not sure which it "belongs" with.

    First off, whoever is making the point that it's insane for Perl to be used in military control systems (especially the example of submarine navigation) is absolutely right. No software is error-free, no matter what language it is written in or what platform it is running on, and indeed every commercial operating system expressly disclaims in its licensing agreement that it is not suitable for use in direct life-support systems, weapons systems, or any other application where an error could result in loss of life or catastrophic damage to property and equipment.

    A professor of one of my computer science classes once gave us a real-world example of a control system he was asked to build, which was to run a chemical process which produced as byproducts metallic sodium and water, and in which pressures in a given vessel had to be controlled with great precision lest the sodium drop into the water and obliterate the plant. He declined the project, believing it to be too dangerous to ever implement, and opined that there are some processes that cannot be automated with computers and software.

    But that's not what is meant by "enterprise-class" software (unless you're talking about a ship named the Enterprise. ;-) It's a horribly overloaded term, but what they are talking about, surely, is software that must operate continuously to meet a business need, and a failure of which would cost some $BIGNUM of money, but would not be implicated in loss of life, gross injury to persons, or destruction of plant and equipment.

      If I understood the logic of your sodium system example, I think the point was that it would have been inappropriate to fully automate the control process and eliminate human oversight. There would always need to be a person overseeing the process and responding to information supplied by the control system. I completely agree with that concept. In spite of claims made by some regarding the state of artificial intelligence, software development has not reached the point where programs can be substituted completely for human oversight in systems where failure results in the serious consequences that you describe.

        I think he did mention something about having a human operator "in the loop" in this case (it's been a long time ago).

        Now if it had been a chemical engineering class, there might have been some discussion of how such a potentially catastrophic process came about in the first place and how to design the process itself to be safer, but that wasn't such a class.

      Conveniently, the Navy has Enterprise-class aircraft carriers.

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

Re: Perl in the Enterprise
by exussum0 (Vicar) on May 18, 2006 at 17:01 UTC
    perl is not enterprise 'cause people with money say it isn't. sun, ibm, ms and a bunch of other places say java and .net are enterprise.

    anyone who says perl isn't enterprise 'cause it's insecure, it's a web language and other subjective silliness doesn't have the whole picture.

    to say Perl isn't easy to write a language that is easily parseable like java, .net and a few other languages. they're right.

    to say that perl doesnt' have a huge api by default, well, yeah, they're right. dbi/dbm is not typically bundled w/ it. it is in CPAN. so go get it. duh.

    perl isn't enterprise because that's not where the money is pushed. period. it's a horrible stupid, short sighted reason too.

Re: Perl in the Enterprise
by exussum0 (Vicar) on May 18, 2006 at 17:18 UTC
    Perl stay ahead of the curve into Web 2.0 and 3.0 applications?
    perl has as much to do w/ ajax, as assembly, c and ruby. AJAX apps just make HTTP calls. It's the browser (stupid).
    Moreover, if they aren’t considering Perl, what are the reasons - what are the areas that need to be addressed in order to turn Perl into a respectable corporate contender?
    Money. Java came up that way. :P
    This isn’t the first time the question has come up, but why are people frothing over Python or Ruby when Perl still has so much to offer?
    'cause they push features not normally seen in script language, where perl pushes flexibilty and has been around forever.
    Perhaps, like Java, Perl could have its own ‘enterprise’ version. This isn’t a new thought, others have brought it up in the past, including P5EE and Enterprise Perl. Personally, I think that it should be called Perl In the Enterprise (PIE), but that is mostly because I think that, like sex, food is a good selling point.
    Lemme correct this sentence. "Perhaps perl could have it's own Enterprise. There were two attemps which I'll bring up. I won't explain why they failed. I won't attempt to give a word of guidance. I'll just make a bland joke here."
    Adding assertions, native compilation, and a snazzy IDE would sweeten the pot even further. Finally, some nice frameworks for web, CORBA, and SOA would be nice.
    All native compilation means is oyu have a semi-portable binary. We have a snazzy IDE, catalyst, and SOAP for RPC. Binary protocols suck when being used between two companies. "Did your package exceed size? Let's break out netcat and a hex editor to find out."
    That said, I think it goes without saying that features such as error handling and excellent logging facilities are equally attractive to companies spanning the range from startup to blue chip.
    Logging facilities are easy to write. Every language has a log4something. Here's a tip for you btw, few people use java's internal logging system. They use log4j. As for error handling, yes, perl's error handling isn't ideal. Coding patterns easily solve this.
    Well, that is really it for this first installment. Not a lot of meat here, but just some ideas to get everyone thinking. Stay tuned as I start looking at projects and modules out there in-depth. Finally, if your organization uses Perl for Enterprise class applications, and don’t mind discussing how Perl has or hasn’t met needs and expectations, drop me a line.
    Witch! Witch! Burn her at the stake! Or with a steak. Next please.
Re: Perl in the Enterprise
by jdrago_999 (Hermit) on May 19, 2006 at 16:08 UTC
    The strategy my team has used so far has been "use the right tool for the job".

    We have a mail-blaster tool that can send millions of emails each day (Perl + Postfix on Linux).

    We have a media-manager server that serves images and documents for 80+ moderate-traffic websites (mod_perl on Linux).

    For the GUI stuff we use ASP (IIS/VBScript). Not my first choice, but the other developers only know VBScript and are unwilling to learn Perl. Rather than beating them over the head with Perl, we make sure that the Really Important Stuff is written on a stable, efficient platform (Perl + whatever on Linux) and let them happily hack away on whatever garbage they want.

    Part of "Enterprise" software involves the ability for more than one developer in your "Enterprise" having the skill to hack on the code. Granted, VBScript is not the most efficient, elegant or powerful language, but I would rather see these guys make simple mistakes with a simple language than deal with the horrific mess they would make with Perl.

    In the absence of testing, documentation, comments or even consistent indentation, I will opt for a *simple*, uncomplicated language that prevents the "developer" from doing anything too clever.

    On the other hand, if I worked with folks who could comprehend the importance of commenting, testing, documentation and constistent coding style, I would opt for a more rich, robust language (like Perl).
Re: Perl in the Enterprise
by Anonymous Monk on May 17, 2006 at 22:51 UTC
    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.

      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.

        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".

        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.

      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.

        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.

        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.

        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

      ...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.

        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.

          A reply falls below the community's threshold of quality. You may see it by logging in.
      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
        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.

Re: Perl in the Enterprise
by DrHyde (Prior) on May 18, 2006 at 09:07 UTC
    Pratte is clearly a prat.
Re: Perl in the Enterprise
by talexb (Canon) on May 22, 2006 at 18:21 UTC
      .. and a snazzy IDE

    Well, I'll pick up on one thing mentioned here .. the snazzy IDE is very handy when you're still learning the language and are writing programs one line at a time. I consider myself more advanced than that, and write programs several paragraphs at a time. If I have a syntax error, it's because I mis-typed something, and not because I don't know how map works, for example.

    I'm quite happy (and not the least bit ashamed) to use the Perl debugger to step through some of my programs (an installer that's over 2000 lines comes to mind) to make absolutely sure the variables contain what I think they should contain, and that the program flow is what I thought it should be.

    It's the same approach I used to write rock solid C code for many years -- compile and lint to get absolutely all of the warnings out, then step through the code in the debugger to make 100% sure the code's doing what I expect.

    For run-time debugging, I use Log::Log4perl -- this tool will also confirm that my code is doing what I expect it is doing, once the typos have been dealt with.

    What is 'mission critical' anyway? Can something be earning the company money, yet not be categorized as 'mission critical'? I've got lots of Perl in my family of a dozen or so servers; if they stop working, my employer's infrastructure stops. People's lives don't depend on it, but certainly the company's financial life depends on it.

    I think Perl plays a larger part in running critical servers than people realize, but because it doesn't come with an endless supply of well-coiffed salespeople with lovely shiny briefcases, beautiful suits, an avalanche of product literature and soothing MarketSpeak, Perl lives under the radar for a lot of people.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      the snazzy IDE is very handy when you're still learning the language and are writing programs one line at a time.

      I'm sorry but I'm forced to respectfully disagree with this statement. IDE's are not a good idea for people who are still learning a language. I've said it before & I'll say it again - you never learn how to code faster than by doing hand to hand combat with the command line: be it with an REPL, interpreter, or compiler.

      An IDE can become a crutch for someone still learning syntax - especially with code completion tools. For someone who knows what they're doing - they're power tools.

      I know there are plenty of people who still say things like: "real men use vi" I too love vi. I use it all the time - at the command line, to do fast corrections or configurations. To do heads-down development I use IDE's. (I'm a big fan of Eclipse & I too use EPIC) Why? I have found that they can help me be more productive. If you don't find any benefit from using them - by all means don't. But neither should anyone begrudge someone else for finding their own benefit in practicing different ways. (Not that I'm accusing you of that. I'm speaking generally.)

      Further, of late there has been more work done in the merging of Modelling applications with IDE's. In OOP circles these days you find more and more UML functionality actually being tied to code generators & parsers, rather than simply drawing tools. This is also something that could easily become a misleading distraction to a beginner, but represents a powerful toolset to senior developers and architects.

      Wait! This isn't a Parachute, this is a Backpack!
      Well, I'll pick up on one thing mentioned here .. the snazzy IDE is very handy when you're still learning the language and are writing programs one line at a time. I consider myself more advanced than that, and write programs several paragraphs at a time. If I have a syntax error, it's because I mis-typed something, and not because I don't know how map works, for example.

      Of course there's a lot more to a modern IDE than syntax checking. Decent refactoring support for example. Something I sorely miss in the Perl world. Fortunately nice people are working at making that better ;-)

        There's Devel::Refactor which does quite a nice job refactoring you code. I think it's integrated to EPIC, and I personnaly use it with NEdit and a quick macro.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://550080]
Approved by coreolyn
Front-paged by virtualsue
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (4)
As of 2020-10-31 10:49 GMT
Find Nodes?
    Voting Booth?
    My favourite web site is:

    Results (287 votes). Check out past polls.