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.
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.
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.
And most people don't, does one really need to be that advanced to appreciate Perl? I hope not
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.
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
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).
Dancer being my current fave :-)
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.
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.