Why I Use Perl: Reliability

Any language would be improved if it had Perl's testing and library culture. Two things it's absolute unsurpassed at so far.

For any value of $LANGUAGE, imagine this situation: your boss comes to you and say "Hey, they just released a new major version of $LANGUAGE today. Can you go upgrade it on all our production servers?" What is your emotional response to that request? For many values of $LANGUAGE, there would probably at least some element of terror (for many languages, probably much more than just "some"). But Perl is one where, depending on the circumstances, the response could plausibly be as article says: boredom. "Yeah, sure, whatever. I'll go upgrade them." (Certainly there are others, but Perl is definitely one of the best in this regard.)

7-10 years ago, Perl was my daily bread and butter. It was the language I used the most, and not only did it supplant a lot of C code, but was the optimal scripting solution.<p>Now, for me, Ruby has supplanted Perl in nearly every conceivable way -- OO Perl was always painful, and I do not miss ever having to bless a refrent again…

I was about to note that the OP clearly hasn't used Clojure if he uses it as a negative example in terms of reliability, but then I remembered — I promised myself not to get too deeply into these kinds of silly discussions.<p>So, dear OP, good luck writing your large-scale multithreaded high-performance distributed applications using Perl.<p>And BTW, I do use Perl quite a bit and I really like it, for certain tasks. But I'd never make these kinds of comparisons.

Perl is like C++ for the Web. Bulletproof. Unless you intentionally remove the kevlar plates. But then it's on you ;)

Yes Perl is a great language -- stability, maturity, etc. But does anybody realize just how hard it is to find decent Perl programmers? It's not a large community to begin with and the pool of decent programmers is even smaller.

The readability arguments need to include such modules as Method::Signatures::Simple, which replaces the old manual method (no pun intended) with:<p><pre><code> method foo ($a, $b) { $self-&#62;blargh($a + $b); }</code></pre>

Good article with some good points. But it did get me thinking, is Perl getting ready to be in a prime position to become the next Cobol? Probability will go up considerably if Perl 6 never comes out to shake up the ecosystem, but even if it does come, what's to say that there won't be Perl 5 applications running into the next century?<p>Combine its shorthand and with the fact that it's already getting hard to find Perl people, and we could see some dedicated Perl warriors doing very, very well in the coming years.

The article makes a good point. But, the title (and comments here) infer that there are a mountain of reasons why people don't use it. Is there a compelling argument against that mountain, or is this just a reminder that Ruby/Python/Closure/Scala communities would be well-served to try and improve in this area?

Reliability, community, and CPAN are some of the main reasons we use Perl at Crowdtilt! Good article.

A quick note on sigils: recently I have been thinking that the dollar sign sigil could be used to denote place forms such that $_ is the top place form. Any place form could be cast into a function to be used on any object, for example you could use the place form $first on a collection like &#38;$first(coll) and you could always set the value of a place with something like setf($first, 1).<p>Inside any function $_ will refer to the argument of the function, so you could program without ever using named parameters like in Perl 5. A parameters list like ($x,$y,$z) will just create new place forms rather then variables. I think this would make for a pretty interesting programming language semantics. On the other hand, I don't see much use for the @ and % sigils because I just consider lists to be structures with numeric places and maps to be structures with general places, so I actually prefer PHP style sigils.

I remain unconvinced. Should the amount of effort that it costs to update the interpreter really be the main consideration?

Unleash the smug Lisp weenies! After all, Perl's stability is minimal compared with Common Lisp's.

Language keywords:<p>Ruby ~40 Python ~40 Java ~50 Perl ~1800<p>Perl can have all the community support, packages, and testing that it wants, but I dislike programming in it and find it difficult to code in. This is not because I have only ever done Ruby or Javascript, I would consider my strongest languages to be Objective-C and Java, I have used C quite a lot, I know what I am doing with programming languages. I just dislike Perl.<p>Did you know there is a Perl package that will catch references to undefined symbols and fuzzy match them to the closest it can find in the current scope. To me, that seems to be the marker for the general quality of the code.

I've used Ruby, Java, and Perl professionally and my favorite by FAR is Perl.

Reliability? Sure. Readability? Not so much.

Speaking of Moose, dependencies and reliability: I love Perl but today having to download the whole CPAN to use a MongoDB driver (based on Moose) forced me to switch to pure javascript with mongo js interpreter.