We all know that PHP is a bad language, but it is used by much many programmers
than Perl. We also know that C# or the other DotNet languages are bad because
they run in really good conditions only under Windows, however are used more
and more these days. We all know that C/C++ are bad languages because they are
old-style and very low productive, however they are used because of their speed
of execution.
Java also has a low productivity but it is used by very many programmers and
companies because of its portability and strict standards.
It is wrong to compare the bad things in other languages with the bad things in
Perl because Perl will surely have more disadvantages.
Why? Because Perl is not a language, but it is... more languages and each "Perl
language" has its own advantages and disadvantages, and if we get only the list
of disadvantages from all of these "Perl languages" then they will surely be
more.
A programmer that still uses CGI.pm to create programs will see a list of
disadvantages. One that uses the low level interface of mod_perl will se
another list of disadvantages. The programs created with these modules will
surely differ, and the programs created with or without Moose will also differ
very much. Also the programs that use or not use an ORM, or the programs that
use or not use a templating system or the programs that use much the built in
functions or many CPAN modules, because any of them imply using their own
"language" and more or less complex syntax.
The combinations of the modules and frameworks that can be used in a Perl
program are very many and the things that hurt and the incompatibilities that
can appear are also very many. The beginner programmers are always interested
about the "recommended" way, but Perl doesn't have any kind of recommended way
and this is its big problem. The single recommendations are those regarding the
coding style, but even there there are more opinions.
TIMTOWTDI is an advantage only for non-standard projects in which there should
be found strange solutions for strange problems but most projects are not so
unusual these days. It is also an advantage for one-person projects in which
each programmer can follow his/her own preferences without caring to adapt to
rules, but I guess that the most of programmers work in a team however so
TIMTOWTDI is not an advantage for them either and that's a big disadvantage in
most software companies' eyes.
Will Perl 6 be the solution for this problems or it will be just another "Perl
language"?
Anyway, for the moment it is too early to consider it a solution.
At one time I've seen the list of improvements in Ruby on Rails, improvements
that were announced as a big event, but reading them with attention I've seen
that those new and shiny features were offered for a long time by Catalyst and
DBIx::Class and even much more.
Another problem is that the Perl programmers community communicates so well
inside using mailing lists, forums and IRC that it doesn't need to advertise
each new and small feature added in a module as an event, and blog about it, so
the "external" world hears only silence from this community, thinking that Perl
is dead for good reasons.
Another problem of Perl is that it is an old language. Too old, and the newbies
don't like old things. If Perl 6 will be presented as a new language this
problem might be solved.
The newbies don't like old things in which there are very many old experts,
because there are little chances that they as newbies will become so fast
better than those old programmers so that's the reason they like to change
things promoting new things (which are not always better than the old ones as
someone said). In a new appeared language the newbies have more chances to
become as good as the old programmers or even better.
Perl is not promoted by companies like Microsoft, Oracle, IBM or Google but
those companies have reasons promoting the languages they promote so I think we
need to also promote the advantages of Perl and not try to find only what hurts
in Perl.
A question about what hurts in Perl can just start flames without good results.
For example, here is what hurts me in Perl (I hope that I won't irritate
anyone):
- There is no high level module for accessing well known protocols like SSH or
SFTP that works under Windows;
- There are too many Perl modules on CPAN that don't work under Windows and
they will probably never work;
- There is no Perl module that can be used for sending email which is also high
level and doesn't requires specifying the Content-Types or constructing each
part manually, that can send email with all kind of charsets possible and all
kinds of body encodings and which reports the errors nice, and which allows
SSL/TLS and authentication, and which can use any kind of transport possible...
althoug mail is a very old protocol;
- The support of Perl for Windows comparing it with the support offered by
other languages, for example by Python is very low;
- Because we all hope that Perl 6 will make our life easier ("soon", "on the
Christmas" :) there are fewer and fewer Perl 5 books published, and perldoc is
not enough in case of many Perl modules. For example the documentation for
WxPerl is very poor;
- A big problem which hopefully will be solved by Perl 6 is that Perl 5 offers
a very poor support for Windows threads - they consume a lot of resources and
the objects can't be share among threads...;
- It also hurts that there are no many well known projects in Perl anymore.
Even the Perl projects use Mailman which is written in Python, MediaWiki
written in PHP, I also use Mercurial (written in Python) as a source control
system because GIT is not very compatible with Windows command prompt, Bazaar
source control is also written in Python, SVK source control which is written
in Perl was abandoned, there are even 2 screen readers one for Windows and one
for Linux (made by Sun) written in Python, and it would be very hard if not
impossible to write such a thing in Perl. Wordpress written in PHP is also much
well known and used than Movable Type...;
- The POD syntax looks worse than the syntax of the documentation used by other
languages because of its notation and lots of empty lines. If there would be a
good and portable IDE for Perl that could hide the documentation when not
needed, it wouldn't be such a problem;
- There is no good and recommended Perl distribution for Windows yet. I have
tried to install DBD::Oracle under Strawberry Perl (after someone else also
tried) but without success until now and I have also tried to install latest
version of Padre under ActivePerl without success, so I can't really follow the
recommendation of using Strawberry Perl and it is also not very nice to
maintain 2 Perl distributions on the same machine;
- Another thing that hurts in Perl and which is also a reason why many
programmers don't like Perl is that it is not possible to install an
application to a server by just uploading the files there and give some
permissions, especially if that app uses XS, and not everyone has access to a
shell;
- CPAN is also great, but it is the haystack that contains too many needles,
beeing hard to find which of them is the wanted one, and the Perl productivity
decreases with the time of finding the right modules;
Octavian
----- Original Message -----
From: "Chris Dolan" <[email protected]>
To: "Bill Ward" <[email protected]>
Cc: "Gabor Szabo" <[email protected]>; <[email protected]>
Sent: Wednesday, December 01, 2010 3:36 AM
Subject: Re: What hurts you the most in Perl?
> On Nov 29, 2010, at 6:52 PM, Bill Ward wrote:
>
>> What hurts me is that Perl has fallen out of favor so much ... I'm
>> contemplating jumping ship myself, and moving to Ruby or Python, not
>> because of anything intrinsic to the language but just because Perl
>> is going the way of Cobol or Fortran.
>
> In the early stages of my last big Perl project, a sysadmin happened
> to mention to the non-technical project lead that Perl is a dead
> language. While that clearly was (and is) a falsehood, it nearly
> killed the project. To me, the mere *perception* that Perl is a
> troubled platform hurts the most.
>
> The funny thing, though, is that I've never worked in a language that
> hasn't been maligned by my peers or customers at some point. Perl, C,
> C++, csh, Java, Actionscript, Python, Lisp, PHP, VB, Javascript, etc
> -- it always seems like there's someone in a position of authority who
> wants to trash-talk the technology. Why is that?
>
> Chris
>
