Reply to post: Perl fan here

Official: Perl the most hated programming language, say devs

JulieM Silver badge

Perl fan here

I don't hate Perl. I've come to understand it.

Perl requires you to think in a certain way and if you don't get that, then you probably won"t get Perl. The first key concept is Regular Expressions. In Perl, regular expessions are literally just a comparison operator. If you don't get Regular Expressions, then you probably won't get Perl. The second key concept is redundancy. There is more than one way to do most things, and Perl never tries to force your hand. This means you have to think about which might be the more appropriate one to use under any given circumstance.

For instance. The code sample on the front shew the operator "eq" being used to test strings for equality, but it also would have been equally valid to use a regular expression test;

if ($origin_LANG =~ /^n/) { # nl

# ...

} elsif ($origin_LANG =~ /^e/) { # en

# ...

} elsif ($origin_LANG =~ /^i/) { # it

# ...

};

And it would not be wrong. It would not run noticeably slower (the business logic inside the executing branch being the limiting factor) nor would it break any worse under unexpected conditions (i.e., a language besides "nl", "en" or "it"; it would give false positive matches with languages such as Norwegian being mistaken for Dutch, Spanish or Greek for English or Icelandic for Italian, but at least that failure mode is predictable). Nor would it be harder to extend (though careful ordering of tests may be required e.g. to distinguish English from Spanish:

elsif ($origin_LANG =~ /^e/) { # en

# ...

} elsif ($origin_LANG =~ /^es/) { # es

# ...

} elsif ($origin_LANG =~ /^i/) { # it

This will always treat Spanish as English. It could instead be written as:

elsif ($origin_LANG =~ /^es/) { # es

# ...

} elsif ($origin_LANG =~ /^e/) { # en

# ...

} elsif ($origin_LANG =~ /^i/) { # it:

(moving the test for /^es/ for Spanish before the test for /^e/) or:

elsif ($origin_LANG =~ /^en/) { # en

# ...

} elsif ($origin_LANG =~ /^es/) { # es

# ...

} elsif ($origin_LANG =~ /^i/) { # it

(rewriting the old test for English to require two letters to match).

If you are already thinking Regular Expressions, though, this should not surprise you; think of /^e/ as a fairly rough test such as

if ($h >= 1.8) { #...

whereas /^en/ is a more precise test such as

if ($h >= 1.8 && $h < 1.9) { #...

But having such ready access to regular expressions can be a double-edged sword. If you have data in a known format such as HTML, XML, CSV or JSON, and you want to extract just a small portion of it, you might reasonably write a simple regular expression match to pull out the item of interest as opposed to using a library. Why walk all the way to the tool shed, in the pouring rain, just to fetch a chisel, when you already have a screwdriver to hand? Sometimes the improvised tool is perfectly adequate for the simplified case of a more general task.

However, if and when your requirements grow more ambitious (and as a rule, every IT project tends to grow until it includes a Church-Turing Complete Interpreter), then your homebrew parser becomes the weak link. How easy it is for you then to modofy your code so aa to replace your original out-of-control ad-hockery with a proper Perl module (or executing an external program; ) will depend on how well you wrote your code in the first place.

TL;DR Perl is a mindset-dependent language, and code written coming from the wrong mindset is liable to be bad in mindset-dependent ways.

What i do hate in a programming language is the use of + as a string concatenation operator. Wherever this is found, another major design brokenness is never very far away.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019