3 ms·

Here are some reasons for you: http://www.indeed.com/jobtrends?q=perl%2C+python%2C+ruby&l= http://www.indeed.com/jobtrends?q=perl%2C+python%2C+ruby&#38... Pyt

by 321abc 17y ago

Here are some reasons for you: http://www.indeed.com/jobtrends?q=perl%2C+python%2C+ruby&l= http://www.indeed.com/jobtrends?q=perl%2C+python%2C+ruby&#38... Python and Ruby aren't nearly as popular as Perl. CPAN, Perl's repository of libraries, is gigantic, having most everything you can think of already in it; which makes writing new programs much, much easier. As much as Ruby and Python fanboys love to beat up on Perl, their favorite languages have their uglyness and their own faults (which you'll rarely hear them mention). However, their propaganda really has worked on a lot of people that really don't know any better. So my impression is that a lot of the newer stuff is being written for Ruby and Python. So it would probably pay to learn them for that, if nothing else. But I would definitely think twice before choosing them instead of Perl.

ubernostrum 17y ago
On the topic of propaganda and people who don't know better... Once upon a time (five years ago or so) I did Perl professionally. At first I bought into the CPAN hype -- everything's there! Any library you'll ever need has already been written and is in the CPAN! -- but after actually using it for a while, I learned that Sturgeon's Law has no exceptions. There were so many packages which were broken, uninstallable, non-functional or nearly undocumented that trying to use stuff from CPAN could end up involving more time than just writing from scratch. When, one day, I encountered documentation for one project which listed all its dependencies, and then gave a long list of things it needed which were in CPAN but in such broken states that CPAN couldn't actually be used to install them (and an even longer list of instructions for how to manually install and work through the bugs), I started looking for something else.
- 321abc 17y ago
  So you're saying other languages have somehow magically managed to keep their third party packages and libraries from ever breaking? Or that they don't have dependencies? Look, when you've got a large enough library of third-party contributions, some portion of them will be broken. And the more libraries people use to build their own libraries, the more dependencies there'll be. Let me know when some other languages manage to solve these problems, or when the upstart languages actually get enough third party libraries for them to have to start facing this problem themselves.
  - ubernostrum 17y ago
    I'm saying that an awful lot of Perl advocacy is predicated on CPAN, and that -- since Sturgeon's Law doesn't have an exception for the CPAN -- this is basically the same sort of overhyped propaganda the parent comment was lamenting from other languages. That in no way implies any of the statements you're attempting to shove into my mouth, however, so perhaps you should step back a bit and reconsider what you're saying?
    - berntb 17y ago
      The disadvantage with CPAN is that you need to know what you're doing (or check Perladvent and ask on Perlmonks.org). How many DateTime modules are there? Which one is really used by everyone the last few years -- and when should you use the previous one? CPAN is, afaik, better than anything else out there.

by 321abc 17y ago

ubernostrum 17y ago

On the topic of propaganda and people who don't know better... Once upon a time (five years ago or so) I did Perl professionally. At first I bought into the CPAN hype -- everything's there! Any library you'll ever need has already been written and is in the CPAN! -- but after actually using it for a while, I learned that Sturgeon's Law has no exceptions. There were so many packages which were broken, uninstallable, non-functional or nearly undocumented that trying to use stuff from CPAN could end up involving more time than just writing from scratch. When, one day, I encountered documentation for one project which listed all its dependencies, and then gave a long list of things it needed which were in CPAN but in such broken states that CPAN couldn't actually be used to install them (and an even longer list of instructions for how to manually install and work through the bugs), I started looking for something else.

321abc 17y ago
So you're saying other languages have somehow magically managed to keep their third party packages and libraries from ever breaking? Or that they don't have dependencies? Look, when you've got a large enough library of third-party contributions, some portion of them will be broken. And the more libraries people use to build their own libraries, the more dependencies there'll be. Let me know when some other languages manage to solve these problems, or when the upstart languages actually get enough third party libraries for them to have to start facing this problem themselves.
- ubernostrum 17y ago
  I'm saying that an awful lot of Perl advocacy is predicated on CPAN, and that -- since Sturgeon's Law doesn't have an exception for the CPAN -- this is basically the same sort of overhyped propaganda the parent comment was lamenting from other languages. That in no way implies any of the statements you're attempting to shove into my mouth, however, so perhaps you should step back a bit and reconsider what you're saying?
  - berntb 17y ago
    The disadvantage with CPAN is that you need to know what you're doing (or check Perladvent and ask on Perlmonks.org). How many DateTime modules are there? Which one is really used by everyone the last few years -- and when should you use the previous one? CPAN is, afaik, better than anything else out there.