Author Topic: Why I Dislike Perl  (Read 7615 times)

precisonline

  • President
  • Administrator
  • Rock Star
  • *****
  • Posts: 1612
    • Precision Solutions
Why I Dislike Perl
« on: April 05, 2008, 11:05:58 PM »
While presenting an introductory course on PHP at the recent Spectrum conference, I let my true feelings towards the Perl language show.  As luck would have it, at the end of the conference I learned that one of my customers is putting a lot of money and energy into a Perl initiative, and therefore it's something I will have to use - irrespective of my past opinions and preferences.

That being said, understanding this new necessity of a mutual understanding between myself and this language, tonight I figured I'd give Perl a clean slate.  No more bias.  No more prejudice.  I've had to learn BASIC, Fortran, COBOL, Pascal, Java, C, C++, RPG, PHP, and a half dozen different scripting languages over the years (and I feel like I'm missing about a half dozen more in this list), so certainly I can put aside bias long enough to give it a real go, right?

I did.  For several hours, I did.  Having done that, now I REALLY dislike Perl.  More importantly, I now remember why.  Here's my top 10 list, gathered from today's experience:

1) Perl's syntax supports bad programming habits:

From http://perldoc.perl.org/perlsyn.html:

Quote
Many of Perl's syntactic elements are optional. Rather than requiring you to put parentheses around every function call and declare every variable, you can often leave such explicit elements off and Perl will figure out what you meant. This is known as Do What I Mean, abbreviated DWIM. It allows programmers to be lazy and to code in a style with which they are comfortable.

(emphasis added) Okay, so the Perl guys have invented a new 4 letter word to describe a feature of a language that lets the computer decide what the human means.  Perl "allows programmers to be lazy" and this is a good thing... how?

2) Perl does not support formal arguments to subroutines.

While you can pass parameters to a subroutine, the subroutine has to extract each one separately using the "shift" keyword.  This means that all parameters have to be extracted to get to the next parameter, even if it's not actually used.  More importantly, there's little way to tell what parameters are being passed into a subroutine without comprehending the entire subroutine.  That could definitely impact the time it takes to read, rationalize, and respond to the code.  And as we all know, the more time it takes to understand the code, the less supportable and more expensive that code will be for the customer over time.

3) In many places, Perl uses "or" where other languages use "else".  Linguistically there is an important distinction between these two words.  "Or" implies two options of equal merit where one or the other could be true and the two options could be interpreted in any order without impacting the meaning.   This, however, is not true; Perl constructs using "or" do not have two options of equal merit and they absolutely must be interpreted sequentially.  Therefore, linguistically the word "else" - as used in nearly every other programming language including PHP (which is derived from Perl) - is the better choice.

4) The construct "else if" is abbreviated "elsif".  Why?  Was the extra "e" just too much to type?  I have no statistics to back this up, but I would bet that this minor syntax abbreviation has tripped up a lot of programmers over the years.  Certainly the "else if" construct is a valid one, but why must it be misspelled? 

5) From http://perldoc.perl.org/perlintro.html

Quote
Perl by default is very forgiving. In order to make it more robust it is recommended to start every program with the following lines:
(snip) The two additional lines request from perl to catch various common problems in your code.

We have to tell Perl to "catch various common problems in our code?  Shouldn't the interpreter do that automatically rather than us having to specifically tell it to do so?  I can see enabling some checking for uncommon errors but shouldn't the interpreter automatically catch the "common" ones?

6) Each type of variable has a different prefix.  Scalars use a "$" prefix, arrays use a "@" prefix, and hashes use "%".  I'm sorry, but why?  PHP uses a "$" prefix for all types of variables, including all of the ones named here, and also objects.  Other languages don't use a prefix at all.  I understand the readability gains of having a character that helps to identify the type of variable, but it gives the programmer one more thing to screw up.  In short, it's an abbreviated Hungarian notation, and even Hungarian notation is considered by some to be a suspect naming methodology.  See http://en.wikipedia.org/wiki/Hungarian_notation Section: Disadvantages of Systems Hungarian.

7) From http://perldoc.perl.org/perlintro.html:
Quote
The special variable $#array  tells you the index of the last element of an array:
Quote
As it happens, using @array  where Perl expects to find a scalar value ("in scalar context") will give you the number of elements in the array.

Unless one is reading and writing Perl every day for months, how readable - truly - is a variable named
Code: [Select]
$#array six months later?  Seriously?  Also, using the array name with the array indicator (see #6 above) actually returns a scalar - so it's not REALLY an array in this context.  So you can use a variable of one type to return a value of another type.  Hmm.. I wonder how many Perl programmers have been bitten by that once or twice?

8 ) String comparison and numeric comparison use different operators.

From the same reference above, string comparison uses "eq" whereas numeric comparison uses "==".  I understand the difference for typing purposes, but Perl is otherwise supposedly typeless!  If the language is typeless, why have comparators that respect type?

PHP handles this just fine with just "==".  Yes, there's a "===" (triple equal) in PHP for comparing objects, but for normal scalar variables "==" is all that's needed.  Adding variety like this is just one more way of making the language harder to learn, more lengthy to code, and more error prone.

9) Regular expressions, while uniquely powerful, are very difficult to interpret several months later, especially if the programmer hasn't been writing regular expressions the whole time.  I have yet to see Perl code with documented regular expressions.  And while it may make sense today, if it doesn't make sense six months from now you can bet there's going to be some dollars involved in reacquainting oneself with that heinousness.

10) Perl objects... uh... aren't - at least not in the traditional sense that most every other language implements objects.  Little quirks like "blessing" variables in the object context are just plain weird.  Therefore, learning objects in Perl doesn't help a person understand objects in any other language, and vice versa.  How can that be a good thing?

Okay, so here's the wrap up.  I am all for a language that is forgiving - to a degree but not to a fault.  Any language that gives a new programmer all the rope in the world and then expects the programmer to tell the interpreter to catch his or her mistakes is just asking for trouble.  Making the language typeless and then using different operators for strings vs. numbers is a dichotomy.  And purporting to have object support and then doing it just as different as possible from every other language complicates cross-training to other languages and other environments.

I know Perl has a devoted following, and those that attain a level of mastery are a lot like APL programmers; they can do a lot and very quickly.  But there's a lot of land mines here, and land mines translate to significant expense for someone, somewhere.  My customer will undoubtedly learn this a few million dollars from now.  Until then, I just needed to vent.
« Last Edit: April 06, 2008, 12:18:34 PM by precisonline »
-Kevin
Accidents "happen"; success, however, is planned and executed.

precisonline

  • President
  • Administrator
  • Rock Star
  • *****
  • Posts: 1612
    • Precision Solutions
Re: Why I Dislike Perl
« Reply #1 on: April 06, 2008, 12:16:11 PM »
A couple more reasons:

1) Perl scripts are like shell scripts so they don't integrate directly with HTML; the HTML can be generated from the Perl script, but the script cannot be embedded inside of an HTML document as one can with PHP or JSP.

2) I've been spoiled by the $_REQUEST superglobal in PHP to gather input from the web form.  While there are similar mechanisms in Perl, they all involve writing or including some code rather than making it automatic. But you be the judge - which do you find easier to achieve the exact same result?

The Perl way?  (From http://www.cgi101.com/book/ch2/text.html):
Code: [Select]
use CGI qw(:standard Vars);
my %FORM = Vars();
print %FORM{'id'};

..or the PHP way?
Code: [Select]
echo $_REQUEST['id'];

3) Confusing scope.  In most languages, if you declare a variable in a block, the variable is local to that block.  Variables that are to be defined globally are defined outside of any block.  Not in Perl.  If you declare a variable like:

Code: [Select]
$value = 1;

It doesn't matter if that variable is declared inside or outside of a block, it's a global variable.  To make it local to the block, the programmer has to use the keyword "my", as in:

Code: [Select]
my $value = 1;

Understand, I'm not saying that Perl - or any language - is intrinsically bad, but when given a choice of languages to work with, doesn't it just make sense to choose a language that makes it easier to succeed than to fail?  Perl definitely has thrown out the rulebook in a lot of areas, which is fine if you can afford the cost of anarchy.  And make no mistake about it, there are costs.

Interesting... Now that I think about it, I wonder if this is why there are so many overseas Perl programmers?  Your thoughts?
-Kevin
Accidents "happen"; success, however, is planned and executed.

Tom Pellitieri

  • Rock Star
  • *****
  • Posts: 224
  • Tom Pellitieri - Toledo, Ohio
Re: Why I Dislike Perl
« Reply #2 on: April 07, 2008, 06:55:27 AM »
Hmmm..... reminds me of the old (original) C compilers.  One of the doctoral candidates in my department in college won a contest for confusing C code.  His code matched syntax per the language definitions, but the compiler couldn't handle it - it actually tried to compile his comments!