3 ms·
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 implem
by 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 agoLike 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 agoLike 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.
- smonff 9y ago"Plain bad documentation" on CPAN? It is unfair...