
Perl: No Applications for Normal Users - fogus
http://www.modernperlbooks.com/mt/2009/09/applications-for-normal-users.html
======
bumbledraven
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.]

~~~
gaius
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.

~~~
frossie
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.

------
idlewords
I think there are two reasons for the paucity of Perl applications for non-
technical users:

1\. It is horribly painful to try to write non-Web GUIs in Perl

2\. It is horribly painful to maintain large codebases in Perl

(speaking as a longtime Perl developer and big fan of the language)

~~~
berntb
Why is it harder to maintain codebases in Perl if you follow the "Best
Practices" book?

~~~
idlewords
Several reasons:

\- sigils make it difficult to scan code

\- there is poor IDE support for perl

\- 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.

~~~
berntb
>\- 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) ...

Create an object, if it is complex.

Edit: Moved answers to strange claims to top.

