8 ms·

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

by rjurney 16y ago

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.

chromatic 16y ago
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.
jrockway 16y ago
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.
- another_ali 16y ago
  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 16y ago
    Not to appreciate Perl, but to be a competent programmer. I would worry if most programmers couldn't do those things in their $LANGUAGE.
- gaius 16y ago
  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 16y ago
    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 16y ago
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 16y ago
These folks seemed to have no problem creating a big system in Perl: http://www.lacunaexpanse.com/ http://www.lacunaexpanse.com/
- elblanco 16y ago
  The entire backend of www.thinkgeek.com is written in Perl and that's a relatively high volume, big e-commerce site.

by rjurney 16y ago

chromatic 16y ago

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.

jrockway 16y ago

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.

another_ali 16y ago
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 16y ago
  Not to appreciate Perl, but to be a competent programmer. I would worry if most programmers couldn't do those things in their $LANGUAGE.
gaius 16y ago
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 16y ago
  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 16y ago

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 16y ago

These folks seemed to have no problem creating a big system in Perl: http://www.lacunaexpanse.com/ http://www.lacunaexpanse.com/

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