I recently started using it again for one offs. I love Perl. It is so much fun to be totally fluent in a language.

Then I wrote a one page app in it. Oh my god, I can't believe anyone still uses Perl.

Its strange. I love it. I hate it. Its great. Its a piece of shit. I am familiar with Modern Perl practices... I just can't understand why anyone without a massive legacy codebase bothers.

With modern Perl 5, some CPAN modules, and a little bit of discipline, I can write a thousand line application to the delight of my client without the language, the libraries, or the tools ever getting in my way. I can't say that of any other language.

With something like Dancer the simple stuff is just as neat as playing with Sinatra/Ruby - with CPAN to pull upon for large chunks of functionality and a wonderful testing environment.

Much as I love ruby - I can just get stuff done so much faster because of CPAN. Less code to write.

Every time I do it, I finish and say, "this is great". The code is easy to read. The code is easy to extend. The code is easy to test. The code is easy to deploy. And I had fun making it. And it's fast. For stitching together complex apps that need to interact with the outside world and not randomly die, Perl is the best tool there is.

Incidentally, people tend to think the opposite -- Perl is for text munging oneoffs, not for complex apps. This isn't my experience, though. Perl is great for gluing things together, but it's not the best tool for performing compute-heavy work on data.

Situations where Perl has served me well: "Produce a CSV file from this data derived from a web page and this database and this C-based analytics library." "Open up as many HTTP connections to this server as possible." "Accept connections from 30,000 clients, and send them a JSON message when a certain event occurs." "Allow someone to interactively edit a complex data structure on the web." "Send a message to server a, poll server b until the message comes back, and report the latency to a monitoring tool over XMLRPC, and write the result to a database." etc.

These worked well because of the great tools I have available in Perl. Moose, with MooseX and roles, to keep my code organized. Bread::Board for making it easy to wire components together, without sacrificing modularity. 100s of Test:: modules to make it easy to exercise all my code ("unit" and "integration" are both really easy with Perl). EV for high-performance IO. Coro for making the async-IO code look "normal". AnyEvent for writing modules that do async IO, without requiring the author to make a decision about which event loop to use. Plack for making all my web apps look the same to the server. Tatsumaki for making streaming easy. Catalyst for making big apps easy. DBIx::Class for making complicated database queries easy. KiokuDB for making my in-memory data persistent.

Situations where Perl has not served me well: "Write a language independent API that adds a tiny bit of business logic over a network protocol." "Load data via a proprietary and buggy C-based library, do complex transformation and normalization, and write the fixed data to a new file."

Why did Perl fail? In the first case, because there is a mental hangup of linking Python or Java with -lperl, even though it's easy to write the C to expose Perl modules to *. It's easier to write your simple "value-add" in C, because then everyone can use it and they feel like they are not making any political decision. And it turns out that C is not that difficult if you are willing to think like a defensive programmer when programming in it!

In the second case, Perl was slow. Writing an XS binding is straightforward, but not trivial. Creating objects, something you need to have at least somewhat-organized code, billions of times is... pricey. Doing a lot of work on a lot of data just isn't very fast. So I use Haskell for this type of work instead. It's trivial to write a binding to a C library (you can do it interactively with ghci and :load, no compilation necessary!), and you can write an expressive, maintainable, abstract program to operate on your data without sacrificing any runtime speed.

In conclusion, you might be doing it wrong. Or you might have picked a bunch of tasks that Perl is bad at and not stopped to notice how good it is at everything else.

I don't doubt that it is, for its author - but that's what all Perl programmers believe.

Why did Perl fail?

For no purely technical reason. It failed because too many people got burned on inheriting horrifying tangles of spaghetti legacy code and vowed, never again. There's just not a critical mass (left) in the Perl community who believe that the target audience of their code is the next programmer who works on it.

I think those people left and moved to PHP. All that's left in the Perl community are a bunch of people who think tests and readable modular code are good. (Not everyone implements this really well, but at least it's in mind.)

And by community, I mean "people that write CPAN modules and hang out on IRC", not "people that submitted their resume to the open 'PERL' position". Those people are more than happy to write spaghetti, but it's because the market allows it. Start firing people for writing crap code, and start paying the people that write great code a lot of money, and you'll see a lot of great code -- Perl or otherwise. As it stands now, code quality and pay are not linked, so there is a lot of bad code being written for a lot of money.

(Ask me about 10,000 lines of C++ to encrypt a password and send it over a socket...)

Old code in _any_ language tends to be bad. Popular languages especially since popular languages attract more bad developers (there is a reason there isn't a "Clojure for Dummies" book :-)

I've seen horrible Ruby & Python. I've seen horrible PHP. I've seen horrible Lisp and Smalltalk. I've seen horrible C and C++. Pretty much any language that's been around more than a couple of years and has become popular has really ghastly legacy code.

(And yes - lots of horrible Perl)

<p><em> There's just not a critical mass (left) in the Perl community who believe that the target audience of their code is the next programmer who works on it</em></p>

Ironically I think that's the exact opposite of the current problem. The vast majority of the Perl developers I encounter now care very deeply about exactly those topics.

That's because the people who don't care are off playing with the new and shiny toys :-) I absolutely guarantee that in five years we'll have folk complaining about this horrible legacy Rails code - and this is why everybody is now using Clojure (or whatever).

I can pick out problems in the Perl community - but lack of a focus on quality is not one of them.

People see horrible code and think that it's because of a horrible language.

Horrible code is because of horrible (or novice) developers. Or good developers working under horrible management.

Bad legacy code isn't primarily a problem of language. It's a problem of time.

Me too. And I hung out in the same IRC channels as you, and I used the same style and followed the same trends. And you know what? My informed opinion remains ;)

Once you write a web app in Ruby, writing one in Perl seems very silly. There is too much syntax. There are too many special characters. There is nobody to collaborate with outside of IRC. Library support in my area is quite poor.

I've done a lot of data/matrix math stuff in Python lately, but I'm actually switching back to Perl for that - I am just not productive in Python.

I've never had Perl 'fail me.' It can always do most anything I need to do. Its just a question of whether it is the best tool for the job, and whether it is the most enjoyable tool for the job.

I install Python and most of the libraries I want are included,(batteries included).

I install Perl and most of the libraries I want are included, (batteries also included).

With Perl I've got CPAN available to install any libraries that I may be missing.

Python may have some advantages over Perl, but "alot of things needed to get the language to work for you" isn't one of them. In this respect I think Perl is heads and shoulders above Python.

Perhaps it's just your company that's dysfunctional, not all big companies.

And I wouldn't call it dysfunctional to not make it easy for people to be downloading all kinds of software for production systems.

If only we felt the same way about letting people write their own software for production systems...

I find the default install of Perl to have just as many libraries built in as Python does. So even if you can't access CPAN then neither Perl or Python has a library advantage out of the box.

The best part with Perl is the CPAN. If you know what you do, for quite a few areas you are crazily productive. It makes good economic sense.

My point is -- the size of the default install is irrelevant, the win is when you install stuff from CPAN. It is arguably better if the default install is thin, because then people/organizations will have routines to install stuff from CPAN...

(Other good points with Perl is that the language is fun and that the social culture of nerds is wonderful. The main negative ones for Perl are the trolling ("PERL is dead") and the learning curve.)

And most people don't, does one really need to be that advanced to appreciate Perl? I hope not

I would worry if most programmers couldn't do those things in their $LANGUAGE.

http://www.lacunaexpanse.com/

I just spent about 30 minutes skimming through it. It's only 260 pages in clear and articulate English. Should this be THE new Perl book? Could be...I think this coupled with Effective Perl Programming that came out a few months ago are great for getting onboard or returning to the world of Perl. Hats off to you Chromatic for your work on this.

There may not be any reasons to learn Perl if you already know Ruby/Python/Tcl/Lua but you certainly won't be worse for it if you do. At the end of the day, it's just another tool and I love having access to so many great ones these days.

The core of the language still has some warts - but there's still some interesting stuff to play with.

Three reasons to have a look at the language if you haven't before (or take another look if you've been away from perl for a few years):

* Moose - http://moose.perl.org - is becoming the de facto OO layer on top of Perl's basic OO system. It has some interesting features that you don't see in most other OO languages (Roles for example.)

* CPAN - http://search.cpan.org - the library of perl modules. Interesting for a couple of reasons. First it's scope is amazing. When I need to talk to some weird API there's usually something there to help. Cuts development time enormously. Second - the infrastructure of CPAN itself is fascinating. The way that things like http://cpantesters.org, http://search.cpan.org, the standard methods for building libaries and modules, etc. all work together is an interesting software ecology. Worthy of study. Lessons to be learned there for gems et al.

* Testing. The testing infrastructure in perl is _amazing_. It's the best I've used in any language. That's because it's evolved around a language/framework agnostic testing protocol TAP (http://en.wikipedia.org/wiki/Test_Anything_Protocol) that allows many different styles of testing to co-exist in the same test running framework. Really nice stuff.

Well, it has to be, because it's too difficult to second-guess when Perl will DWIM and when it won't. So you have to move a whole lot of complexity out of where it should be, the compiler, and into your own head and your own code. Check out Haskell's QuickCheck for this done right.

I've used Haskell's QuickCheck. Declarative testing is lovely. But it's one particular approach to testing - suitable for finding a class of problems and bugs.

TDD via an xUnit framework is another approach - suitable for finding another class of problems and bugs (after, of course, driving the design - which is it's main purpose).

Style/lint testing is another approach to finding a different class of problems and bugs.

Load testing is another approach to finding a different class of problems and bugs.

The most languages it's an annoying pain to get different kinds of testing framework. TAP and Perl's testing framework makes that really easy.

In Haskell if I want to combine doing TDD with HUnit and declarative testing with QuickCheck - I have to do work to get both frameworks running and integrated at the same time.

In Perl if I want to combine doing TDD with Test::Class and declarative testing with Test::Lectrotest (the QuickCheck style testing library for Perl - http://search.cpan.org/dist/Test-LectroTest) it comes out of the box - because they both output TAP.

I can even interleave declarative styles test inside my xUnit tests - because the both output TAP.

If I discover I need to write some custom test library to poke at some specific corners of my app - I can just output TAP and it's instantly integrated with the rest of my test framework.

Stupidly useful.

I've personally never seen this issue when testing perl code.

So you have to move a whole lot of complexity out of where it should be, the compiler, and into your own head and your own code

Actually the perl compiler with use strict; use warnings catches a lot more at compile time compared to most other dynamic languages.

You don't need to guess, never. I can recommend a book which explains how Perl 5 works (and which features to avoid because they're too difficult for novices--and sometimes experts--to use correctly).

There's an element of practicality. Perl doesn't force the use of any specific paradigm, but as it's not a pure functional language, the dominant paradigm for maintainable, large applications tends to be OO.

http://mojolicious.org

Dancer being my current fave :-)

Should I be interested in Perl? Is there any reason to learn it if I know these other languages? I am genuinely curious

Nowadays Phusion Passenger makes Rack-based Web apps snake-simple, and using JRuby gives me all of the Java libs out there (including Swing for insanely-easy cross-platform GUI apps when teamed with Monkeybars), as well the option to deploy Web apps as war files to Java app servers.

At this point the interest in Perl would have to be due to some intrinsic language feature that might help broaden your ideas about programming in general (the way that, say, Haskell or Io might).

Still, I'd say try it out for a few small things; you might find that Perl better fits the way you think, and if not, at least you can say you know a bit of Perl if anyone ever asks.

I know Perl better than most other languages in my toolbox, and it's my default prototyping and one-off utility language. I don't find a lot of niches (for my typical uses, of course) that are served better by Ruby, so it's been really difficult to switch away from Perl.

Maybe look around CPAN a bit, see if you find any libraries that you think might be useful, and are not available on PHP or Ruby.

The reason I say that is because a programming language is just like a religion. You will like it or you will not (even with its quirks).

[1] You can probably learn things in Perl that you couldn't in PHP but if you pick a more pure language the lessons will stick out more. Perl also has a lot of extremely bad practices by default.

This is also good: http://www.perl.com/pub/2007/12/06/soto-11.html

However, Perl is still an excellent language for building scalable web systems in no time.

With 'Modern Perl' you get 'Ruby on Rails' style of programming in Perl, and with Perl you get the tons of libraries in CPAN.

I wouldn't recommend learning Perl if you already know Ruby. For the same reason I wouldn't learn Python or Ruby because I know Perl. I'd learn something different like Erlang.

    With 'Modern Perl' you get 'Ruby on Rails' style of programming in Perl

Considerable use of convention over configuration? Not sure what you mean here.

Built-in object mapping to database schemas? Yes.

I'm also referring to the clean MVC/OO style project architecture.

Here's how I described it in another thread:

With modern Perl, code is usually clean and free of crazy syntax. With a OO architecture where the base classes do most of the work (such as auto authentication, auto encoding/decoding, auto DB joins, etc.) and you do business/game logic in the upper modules.

Ah, OK. That just sounds like Ruby, though, nothing special to Rails about that.

But perhaps I got Rails confused with Ruby with my brief experience with it. I thought Rails provided the tools to auto-create your project structure in an MVC style.

If you use something like Catalyst of CGI::Application you get built in things like MVC project structure, auto populate a 'class' from a table entry, etc.

Basically, you get all those built-in functionality for building web apps that you would in Rails. But, I very briefly played with Rails, so I may have its definition confused.