in reply to Re: Perl in the Enterprise
in thread Perl in the Enterprise

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?

Replies are listed 'Best First'.
Re^3: Perl in the Enterprise
by apotheon (Deacon) on May 20, 2006 at 06:45 UTC

    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

[reply]
Re^3: Perl in the Enterprise
by Anonymous Monk on May 20, 2006 at 16:15 UTC

    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

[reply]

In Section Meditations