4 ms·

#!/usr/bin/env perl python, ruby, perl5 ... agile and fun to work with. perl5 is the fastest. Being around for so long means there are a lot of libraries at h

#!/usr/bin/env perl python, ruby, perl5 ... agile and fun to work with. perl5 is the fastest. Being around for so long means there are a lot of libraries at http://metacpan.org/ http://metacpan.org/ . If interested, search for... "twitter", "google", "oauth", or any other technology/api to find out there are a lot of new and maintened libraries. perl5 libraries have great documentation, ie: - https://metacpan.org/pod/AnyEvent::Memcached https://metacpan.org/pod/AnyEvent::Memcached - https://metacpan.org/pod/distribution/Net-Twitter/lib/Net/Twitter.pod https://metacpan.org/pod/distribution/Net-Twitter/lib/Net/Tw... A lot of perl communication happens directly with developers over IRC. Yes, perl community runs irc.perl .. if IRC is not your thing, you can email the developer shown at metacpan (example in links above) Also not less important is the fact every library uploaded to metacpan gets tested in multiple platforms: https://cpantesters.org/distro/U/uri.html https://cpantesters.org/distro/U/uri.html And, what this means is the library author uploads the library and 2 days later its possible to check if library is broken in any platform. And of course a lot of top notch sites use perl. Many dont promote it, but check metacpan.org home for example of some sponsors. Too bad some people that never learned perl spread the wrong message. It is a great language. And perl6 is another language that just happens to be named "perl" and was developed in conjunction with top perl5/other lang. developers. exit;

nopacience 9y ago
Some other sponsors: http://www.perlfoundation.org/sponsors http://www.perlfoundation.org/sponsors https://metacpan.org/about/sponsors https://metacpan.org/about/sponsors http://www.yapcna.org/yn2016/sponsors.html http://www.yapcna.org/yn2016/sponsors.html http://www.yapcna.org/yn2015/sponsors.html http://www.yapcna.org/yn2015/sponsors.html https://www.perl.org/siteinfo.html https://www.perl.org/siteinfo.html
chomp 9y ago
You chose exceptional libraries to provide as examples. It's my experience that a huge chunk of modules on CPAN are not well maintained, suffer from poor implementation decisions, have decade old bugs, or just have plain bad documentation. Perl5 despite its warts is a decent "just get moving" language, but it's easy to get frustrated with some of the community modules.
- nopacience 9y ago
  Like every other language.. there are bad code and good code. Some developers went so creative they use that (ascii draw) to test if next releases of perl are backwards compatible: - https://metacpan.org/pod/Acme::EyeDrops https://metacpan.org/pod/Acme::EyeDrops Yes, thats another positive about perl5, the code that ran 10 years ago will run the same way today
  - natch 9y ago
    Like every language yes but Perl has an especially pernicious aspect: with Perl TIMTOWTDI is an encouraged and nurtured pathology that got way out of hand. Perl encourages many petri dishes and cross fertilization (or pollination or contamination or pick your word) of everything that springs up. Sounds fun at first, but it becomes a mess. Other languages have cultures (no pun intended) that are more actively encouraging of sticking to best practices.
    - kbenson 9y ago
      > Other languages have cultures (no pun intended) that are more actively encouraging of sticking to best practices. I'm actually not so sure about that. Besides Python, which espouses a "one true way", Perl culture emphasizes idiomatic code quite heavily (because that emphasis is helpful with all the options), and that usually lends itself to just a few obvious ways to approach a problem (at least at the level where this is event different between most languages. That is, well below the architecture level, which has largely language agnostic common problems). TIMTOWDI doesn't mean use all the different ways all the time[1], but is an acknowledgement that in some circumstances some ways are more intuitive and obvious that others, and this may change depending on circumstance. Esoteric and unnecessarily complex syntax is highly frowned upon In Perl 5, if I want to perform an action on all items in an array, such as incrementing them (or concatenating, or passing to a function, etc), the following is obvious and succinct: $_++ for @my_array; The alternative, which is easily extended for multiple actions on each item, and is the obvious solution in those cases, but overkill for the simple case: for ( @my_array ) { $_++; } The important thing is not to look at the second example and say "that looks more obvious to me", because the implicit ride to that statement is almost always "because my prior experience with other languages lends familiarity". That's a poor way to evaluate a language, because it prevents unbiased assessment. It's generally easy for languages such as Lisp to avoid this, as they look so different that people aren't generally tempted to apply their prior C experiences so directly. Perl looks close enough and allows C-like syntax enough (to ease transition) that I think it caused many people that wrote C-like Perl and didn't attempt to fully learn the language trouble when viewing idiomatic Perl. Edit: Since you likely have enough experience with Perl to have your own strong opinion on this topic, please take this less as a reply to you, and more as my take on the idea in general.

nopacience 9y ago

Some other sponsors: http://www.perlfoundation.org/sponsors http://www.perlfoundation.org/sponsors https://metacpan.org/about/sponsors https://metacpan.org/about/sponsors http://www.yapcna.org/yn2016/sponsors.html http://www.yapcna.org/yn2016/sponsors.html http://www.yapcna.org/yn2015/sponsors.html http://www.yapcna.org/yn2015/sponsors.html https://www.perl.org/siteinfo.html https://www.perl.org/siteinfo.html

chomp 9y ago

You chose exceptional libraries to provide as examples. It's my experience that a huge chunk of modules on CPAN are not well maintained, suffer from poor implementation decisions, have decade old bugs, or just have plain bad documentation. Perl5 despite its warts is a decent "just get moving" language, but it's easy to get frustrated with some of the community modules.

nopacience 9y ago
Like every other language.. there are bad code and good code. Some developers went so creative they use that (ascii draw) to test if next releases of perl are backwards compatible: - https://metacpan.org/pod/Acme::EyeDrops https://metacpan.org/pod/Acme::EyeDrops Yes, thats another positive about perl5, the code that ran 10 years ago will run the same way today
- natch 9y ago
  Like every language yes but Perl has an especially pernicious aspect: with Perl TIMTOWTDI is an encouraged and nurtured pathology that got way out of hand. Perl encourages many petri dishes and cross fertilization (or pollination or contamination or pick your word) of everything that springs up. Sounds fun at first, but it becomes a mess. Other languages have cultures (no pun intended) that are more actively encouraging of sticking to best practices.
  - kbenson 9y ago
    > Other languages have cultures (no pun intended) that are more actively encouraging of sticking to best practices. I'm actually not so sure about that. Besides Python, which espouses a "one true way", Perl culture emphasizes idiomatic code quite heavily (because that emphasis is helpful with all the options), and that usually lends itself to just a few obvious ways to approach a problem (at least at the level where this is event different between most languages. That is, well below the architecture level, which has largely language agnostic common problems). TIMTOWDI doesn't mean use all the different ways all the time[1], but is an acknowledgement that in some circumstances some ways are more intuitive and obvious that others, and this may change depending on circumstance. Esoteric and unnecessarily complex syntax is highly frowned upon In Perl 5, if I want to perform an action on all items in an array, such as incrementing them (or concatenating, or passing to a function, etc), the following is obvious and succinct: $_++ for @my_array; The alternative, which is easily extended for multiple actions on each item, and is the obvious solution in those cases, but overkill for the simple case: for ( @my_array ) { $_++; } The important thing is not to look at the second example and say "that looks more obvious to me", because the implicit ride to that statement is almost always "because my prior experience with other languages lends familiarity". That's a poor way to evaluate a language, because it prevents unbiased assessment. It's generally easy for languages such as Lisp to avoid this, as they look so different that people aren't generally tempted to apply their prior C experiences so directly. Perl looks close enough and allows C-like syntax enough (to ease transition) that I think it caused many people that wrote C-like Perl and didn't attempt to fully learn the language trouble when viewing idiomatic Perl. Edit: Since you likely have enough experience with Perl to have your own strong opinion on this topic, please take this less as a reply to you, and more as my take on the idea in general.