[rjurney]

I took a six month break from Perl. I know it better than any other language.

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.

[jrockway]

My experience is the opposite. I've used Perl for one-page web apps. I've used Perl for one-hundred-page web apps. I've used Perl for HTTP load testing. I've used Perl for high performance messaging. I've used Perl for writing desktop apps.

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.

[gaius]

The code is easy to read. The code is easy to extend. The code is easy to test. The code is easy to deploy

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.

[jrockway]

I agree with you up until "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...)

[adrianhoward]

By and large the legacy problem isn't because Perl is a bad language per se - but because it's and old language (in popular usage).

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.

[rjurney]

"I've used Perl for one-page web apps. I've used Perl for one-hundred-page web apps. I've used Perl for HTTP load testing. I've used Perl for high performance messaging. I've used Perl for writing desktop apps."

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.

[jbjohns]

You listed a lot of things you need to get to get Perl to work for you. In big orgs that would mean a lot of battling. For me it's just not worth the fight when e.g. Python just comes with half those things.

[chollida1]

How is this different from Python?

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.

[jbjohns]

You didn't read my comment. The point is that in a big org I don't have CPAN. Not without a big fight. And the perl language comes with do-it-yourself OO (they're not packaging Moose with the distro now are they?) and a bunch of other problems that you have to have CPAN to fix.

[jrockway]

I work at a company with 300,000 employees, and I had no trouble getting CPAN.

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

[jbjohns]

This would be a problem at every big company I've worked for that didn't already have something. Obviously it isn't a problem everywhere but knowing what I do about big companies I would say it's more likely than not.

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

[chollida1]

I thought I did read your comment. However even if you can't access CPAN this doesn't change anything.

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.

[berntb]

I think you are arguing angels and needle heads. :-)

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

[another_ali]

Greetings jrock, I think you are underestimating your own complexity, you seem to know a lot about lot.

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

[mahmud]

Not to appreciate Perl, but to be a competent programmer.

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

[chromatic]

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.

[adrianhoward]

I too have the opposite experience :-)

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.

[sigzero]

These folks seemed to have no problem creating a big system in Perl:

http://www.lacunaexpanse.com/

[elblanco]

The entire backend of www.thinkgeek.com is written in Perl and that's a relatively high volume, big e-commerce site.