Times to avoid using the otherwise standardized language:

• When the runtime performance is critical, but the language in question can't support it.
• When the memory constraints are critical, but the language in question can't support it.
• When the security considerations are critical, but the language in question can't support it.
• When the use or re-use of an already-written library or application is critical, but the language in question can't support it.
• When sticking to the current workforce is critical, but the available workforce can't support it.

That said, it's usually high-capacity number crunching with no hardware assistance (raytracing, fluid dynamics, etc.) which fails the performance test for Perl (though see PDL). Everything else technical in nature is pretty well handled.

Any workforce issues is a matter of mindset: if you feel you need more discipline in your language, or less complexity in your language, I won't fault you, but I think you can get over it and leverage Perl's strengths.

--
[ e d @ h a l l e y . c c ]

The problem here is that you've identified two areas (code quality, ease of use) where Perl tends to look rather good to me. You certainly won't find it easier to write automated tests in, say, Java.

Now if you said something about needing top speed, or a cutting-edge GUI, or less memory, I'd be with you. But quality? I feel like Perl does pretty well there.

I do see situations where it's easier to write "high quality applications" in another language. Let's say for instance I need to write applications that do a great deal of testing and measurement of a laboratory environment... well, could I write the application in Perl? Sure. But I'd probably use LabVIEW. Or lets say that I'm writing applications that require symbolic mathematics... I'd probably write it in Mathematica or Maple or Matlab. Or lets say I'm writing applications which have to do a ridiculous ammount of statistican analysis... could I do it in Perl? Of course, but I'd probably chose R... or let's say that I'm writing some kind of application that is, at it's core, a system for doing real-time analytics or timeseries analysis... well, I'd probably use K. Or let's say that I need to write an application for the telecommunications industry, say switching or converting protocols, could I use perl? Sure! But I might chose erlang. Let's say I've been asked to write a small windows application to interface with a MS-SQL server and an Excell spreadsheet... let's say, a simple decision support system... could I write it in perl? Sure, the Win32::* namespace rules... but realistically it would probably be easier (and a lot more deployable) in Visual Basic. Or let's say that I'm writing a banking application that has to support millions of transactions in a completely fault tolerant manner spread accross a geographically disparate cluster of E10k's, provide an understood environment in which I can hire commercial trainers to get my developers up to speed, as well as a pre-existing code library, accepted best practice design patterns, in order to minimize risk of an aborted development cycle (which would be massively detrimental to the bottom line.) Well, I may not like it, but I'd most likely chose a combination of Java, and J2EE. Let's say that I'm writing the worlds most advanced system for global airfare pricing and airfare shopping... I'd probably be these guys and implement the thing in Lisp.

Perl rules. I usually write code in Perl. Sometimes to my detriment, because other languages would have fit the problem domain better, but I'm human, and I'm confortable in my environment, and I'm loud and intimidating enough that if I want something, the other developers will let me get my way. But there is a nearly infinite number of domains in which chosing a language/platform/implementation strategy other than Perl is the right choice.

So, given 9 or 10 major projects, if you're a big shop and have the money you can hire 10 separate developers, skilled in 10 languages to do the coding; but if you're a little short on resources, you could just hire One Good Perl Hacker who could do it all.

I've haven't got much to add, except to say that Matlab and Labview are going to take over the world some day (if Perl6 doesn't do it first). (-:

(P.S.: An insider at NI told me that they are pretty close to being able to write LabView with LabView - now thats an excitingly scary thought!)

You seem to be saying that given a set of very unusual requirements which Perl is obviously ill-suited for, you would use a specialized tool instead. I don't see how anyone could disagree with that. But the original poster didn't have these specialized requirements. He was concerned about using Perl to build a high-quality system. There is no problem with using Perl to do that.

I also believe that the Java project you refer to stands a good chance of spending millions, taking years, and producing something unsatisfying, regardless of the language chosen. I don't think Perl is going to make it any harder to write than Java. (Java in a totally fault-tolerant system? That's madness.)

At my own peril, I'll respond in the affirmative.

Perl is a great tool. So is Java... Python... COBOL... Each tool has its strength and weakness. One can write application X in language Y, just like one can use a hammer to drive screws.

I worked with one guy who was the resident expert on Lotus Notes. He kept on and on about how great Notes was. He would get irate if it was even suggested that Notes wasn't the greatest tool ever made.

Over the course of discussing an issue he was having, this guy said that he had been working on this particular application... for the same client... for over four years. Yes, this was his primary client.

I found out later that he was a former FoxPro guy who used FoxPro for everything, whether it called for it or not... Until Notes became his new hammer.

The caveat is... if your salary depends upon sculpting with a screwdriver, pick up a set or find someplace that knows how the tool is supposed to be used.

Cē

Perl is a great tool. So is Java... Python... COBOL... Each tool has its strength and weakness.

COBOL has no advantages. COBOL needs no advantages.

The politically correct trend towards "the right tool for the job mentality" is getting a bit out of hand. Sure it prevents a few flamefests (and quality discussions about language design), but really, what can Perl/Python/Ruby/Java/ that Java/Ruby/Python/Perl can't? They're so similar it comes down to what your developers already know well, speed/efficiency, and platform support. The four languages I list are in the same category for speed, efficiency, and portability concerns, so it isn't really an issue either. They're all the same slot screwdriver, just different brand names in different colors. Pick the one you find most pretty and are most familiar with.

Although I wouldn't catagorize "right tool for the job" as "politically correct", you do bring up a valid point. With a caveat.

Pick the one you find most pretty and are most familiar with.

I concur that when the developer has the latitude to choose how the work is done, then pick the tool that you are most comfortable with.

Unless you are your own customer, this doesn't occur often as your customer will have (for good or evil) a standard development platform. Apparently, the OP's boss found that rare customer, and chose perl.

The OP has a choice: use perl, beat feet, or suggest that another tool may be in order. Needless to say, the last two are very closely related.

On my current assignment, my customer chose WebLogic, Java, and SQL Server. While I am within my rights to use perl to automate some of the more tedious aspects of development, I would be entirely out of line to put any of this into production.

If I felt strongly about implementing a solution in some other tool, it is my responsibility to recommend this to my customer. It is equally my responsibility to abide by their decision, or move on.

COBOL has no advantages. COBOL needs no advantages.

I disagree. While my personal preference is never to look at COBOL again, if my job depends on me dusting off my Stern & Stern, guess what I'll be doing.

Bottom line: "Him that pays, says."

Cē

COBOL has no advantages. COBOL needs no advantages.

When a company has several million lines of working COBOL code that the organisation relies on for daily operations then COBOL has an advantage :-)

The fact that there is no type checking, the sometimes cryptic syntax, and the unusual object oriented features seems to be hindering our development.

What does "our development" refer to here? Your personal development as capable and flexible programmers? The actual development cycle of applications? Something else? What are some particular symptoms, events, or hassles that make it seem like perl is a hindrence?

If you haven't coded in other languages (or if you've been doing perl so long that you've forgotten what it's like), then I would ask you to consider whether things that seem to be a hindrence could just be misconceptions. For example:

How big a problem is it that there is no type checking? When I look at C and C++ (where there are no sigils), I find people having a lot more trouble with designing, writing and maintaining code (and I have more trouble reading their code) just because of the way variables are bound instrinsically to specific arrangements of memory storage (and a variable name gives no explicit clue as to the nature of its storage, unless the programmer is using a compulsive coding style that flags types in the variable names, but often this makes the code even harder to read). Last time I checked, it is still possible to compile and run C or C++ code that will crash nastily, because programmers can (and do) still coerce pointer types, or they just don't anticipate the variety of data people will throw at it. Meanwhile, in Perl you need to know the difference between a hash, an array, and a scalar, and for scalars, you need to recognize when it's a reference. That's all, and it's easy.

How bad is it that Perl's OO features are optional, and require some extra syntax to set up, involving a few strange bits of syntax? (I'll confess, the first time I saw "bless" in a perl script, I felt is was a joke of questionable taste.) Frankly, I don't believe that every piece of code needs to be An Instance of A Class or Object. Lot's of software requirements just don't lend themselves easily to that sort of abstraction, or at least can function quite well without it, thank you. My impression is that the mandatory OO framework of C++ and Java doesn't mean that less code is required to implement OO, or that the code is sure to be a better implementation -- rather, it just means that the extra baggage required for OO has to be part of every program. (Python suffers somewhat less from this problem, because it has managed to boil down the OO syntax to a bare minimum -- but then, some people have other complaints about how Python code is supposed to be written.)

halley's initial reply presents the most important truths about language selection -- the things that Really Matter. If those issues don't apply to the applications you're working on, and you still think Perl isn't the best choice, why not go ahead and try some other choice, just on your own, and see if that's a better way, all things considered?

Now -- 'unusual' object oriented features? Que? What do you speak of?
-----------------------
You are what you think.

Furthermore, in 95% cases Perl has possibility to interconnect with your favourite language X (including Java. C/C++ also guaranteed as Perl is written in C).

Personally, I use Perl in my everyday programming -- it's great to have a possibility to perform complicated transformations in just a seconds after I needed them.

Courage, the Cowardly Dog

So, what I ask of the monks is this, does anyone else think that there are times to use perl, and times to forgo its use?

There is always a set of circumstances where one language is a better choice than another.

If all the code currently written in your company is C++, everybody on the development team codes C++ and you need to create a real-time application to run on a device with limited RAM and CPU then Perl would be a foolish choice.

If everybody in the organisation knows Perl, your existing codebase is all Perl and you need to create an application that provides a SOAP API to a dozen different databases then C++ would be a foolish choice.

Without more detail about the applications being developed, your development environment, your development team's skills, your existing codebase, etc. it's hard to say whether Perl would be the right choice or not.

There is no reason (IMHO) that developing quality applications should be more difficult in Perl than another language. I do most of my development work in Perl not because I'm forced to, but because I think it is the best language for developing the applications I'm paid to develop (and I like to think that they are of a vaguely decent quality :-)

Can you give us more detail on where/why the lack of type checking and OO features are causing you problems? We may be able to offer some pointers.

The syntax, cryptic or otherwise, shouldn't really be an issue since that's a matter of learning the language. You can make the (possibly valid :-) argument that Perl is a harder language to learn than some others, but I think that's a separate issue from its suitability for building quality applications.