What does a cookbook do for people who don't cook? Perl is a programming language. CPAN is a bunch of Perl libraries. Perl and CPAN don't do anything for non-developers.
[Edit: I see now that the author is saying that there are no significant applications for end-users written in Perl, which is certainly true. I attribute that in part to the difficulty of distributing a reasonably small installer package for a GUI application written in Perl.]
Vast amounts of code is written by people who don't primarily self-identify as a programmer/developer/whatever. Python is huge within the science/engineering community who want to use NumPy for example, Perl has virtually no presence there.
Erm, it does depend on which part of the scientific community you are talking about - we're not all a monolithic Borgian block you know. There are a bunch of non-programmers using the Perl Data Language for example (pdl.perl.org).
The real problem in my opinion is that perl has no buzz so is not picking as many new users - we can speculate about the reasons, I personally blame how perl6 has gone for a lot of it though.
- it can be very hard to figure out what arguments are being passed, or what arguments a subroutine or method expects.
- it's common to pass around a hashref (a.k.a. magic blob of data) as an argument. Finding out what the proper internal structure of this is can involve jumping around a lot of code
- there can be spooky 'action at a distance' effects. For example, the URI module calls 'require' deep within a private internal class. This can crash your program if, for example, you've forgotten to properly implement the STORE method for a tied hash in a completely unrelated part of your program. For another example, using unicode in a regex somewhere can cause files to be pulled from disk, suddenly slowing your app by three orders of magnitude.
- not everyone has read the best practices book, including the authors of very widely used CPAN modules
- Chasing up and down inheritance chains can be very unpleasant. See MovableType.
Again, nothing wrong with Perl, it just has certain features that make it a bear to work with when the project size exceeds a certain threshold, or when there are multiple programmers.
>- there can be spooky 'action at a distance' effects.
Yeah, those are unique to Perl... :-)
>- not everyone has read the best practices book
True, it is unique that Perl has programmers which doesn't follow the coding standards of the group... :-)
>- Chasing up and down inheritance chains can be very unpleasant.
True, it is only Perl which have over complex OO libs. :-)
>> For another example, using unicode in a regex somewhere can cause files to be pulled from disk, suddenly slowing your app by three orders of magnitude.
I don't know much about Unicode. You mean that using Unicode characters would require loading a library? Can you give a reference to that "three orders of magnitude"?! If you count the startup time of the lib as run time, I am disappointed.
>- there is poor IDE support for perl
Huh? Afaik that IDE from Activestate gets good reviews, but Perl programmers use Emacs (or Vim) anyway. Than we have Padre on the way.
>- sigils make it difficult to scan code
>- it can be very hard to figure out what arguments are being passed, or what arguments a subroutine or method expects.
(More or less the same point.)
At least partly correct, I guess. I generally check the synopsis, first. Their existence probably comes from this.
>- it's common to pass around a hashref (a.k.a. magic blob of data) ...
[Edit: I see now that the author is saying that there are no significant applications for end-users written in Perl, which is certainly true. I attribute that in part to the difficulty of distributing a reasonably small installer package for a GUI application written in Perl.]