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