On 24/11/10 12:01, Gabor Szabo wrote: > The other day I was at a client that uses Perl in part of their system and we > talked a bit about the language and how we try to promote it at various > events. > > Their "Perl person" then told me he would not use Perl now for a large > application because: > > 1) Threads do not work well - they are better in Python and in Java.
I don't use threads, if there is a need to run parallel operations I use fork. > 2) Using signals and signal handlers regularly crashes perl. I've not seen this. There are some issues I've seen with signals when a Perl module depends on non-Perl library and that defines signal handlers e.g. DBD::Oracle and Oracle's instant client - there is even a recent thread on dbi-dev about this. > 3) He also mentioned that he thinks the OO system of Perl is a hack - > that the objects are hash refs and there is no privacy. As David said, I don't really see a good technical argument here, more a personal one. > So I wonder what hurts *you* the most in Perl? 1. Interfaces from Perl to C libraries via XS. Memory leaks, signal issues (above), seg faults, changes in PERL_POLLUTE which has knock-on effects to every XS module. Many are coding errors but these seem more common in XS and harder to find/fix. 2. huge dependency trees which are often moving targets e.g., module A needs modules B..Z, module B needs module BB which needs BC..BZ and then module BZ is changed to need Perl 5.10.1 and suddenly anyone using module B, BB or A needs 5.10.1. I have seen this one (although I cannot remember where right now) but it is not that uncommon to see more minor dependency changes that have large knock-on effects. 3. modules dying with insufficient details to see what went wrong without resorting to a debugger. 4. modules which fail tests and are at the bottom of a long module list chain. 5. modules with little or no documentation for a minimum of the most common usage cases. 6. HTTP/FTP modules (or modules using them) which don't handle env_proxy - particularly annoying as I am behind a firewall most of the time. 7. modules which prompt during install but don't use prompt so they don't work in non-interactive sessions (I've even come across some which loop forever in non interactive sessions). Saw a lot of this when I was smoking. Do I report any of this to the authors? mostly, but sometimes I do just move on and find something else. In particular, when I was running a smoker I used to report 6 and 7 a lot but hit them so often my patience waned and I started adding them to the ignore list (IIRC Apache::* had a lot of 7's.) Perhaps this is sounding a little grouchy and it is not intended to - you did ask. There are a lot of very good modules (and I greatly appreciate them and the work their authors do) but I'm not sure everyone adding a dependency to their module thinks so carefully about it and the implications if that module is changed a lot or tends to fail tests. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
