Skip to main content

Perl is a terrible language

Every time I go to use Perl, I end up having to re-learn it entirely from the ground up. That is how bad the language is. Most languages I can come back and look at some code and say, "Oh, I remember what that does." Not Perl. Perl is the only language I've ever used that I come back to the code and say, "Huh? What in the world did I do there?" And then as I read yet another Perl tutorial (how many do we really need?) to re-learn Perl for the zillionth time (okay, more like 25 times), I say, "Good grief. This language is terrible."

Plus Perl has these weirdly named modules and sticks everything, and I mean everything in the global namespace. Including variables you define inside a function. Perl is the only language I know of where, if you forget to use the word 'my' before using a variable for the first time, it royally messes up the entire script execution and takes hours to diagnose.

Additionally, every last Perl module reeks to high heaven of bad design. An example of a poorly designed Perl module is LWP. Whoever named it that should be soundly beaten. Not that I'm advocating violence. Microsoft would have named it Internet. Or Web. But, no, it has to be an acronym for "libwww-perl". Totally obvious. Plus the module itself is poorly written for the average programmer. What, precisely, does the average programmer want to do with a web module? Well, probably access the web and, almost always, a webpage sitting on a web server. So, someone created LWP::Simple. That is great if all you want to do is run GET requests all day, but if you want to do a simple POST request? Not allowed - you have to go use the full-blown LWP library for that.

Here's a wonderful little function that does a POST request LWP::Simple style:

sub LWP_Simple_Post
{
my ($URL, $Content) = @_;
my $Request = HTTP::Request->new(POST => $URL);

$Request->content_type('application/x-www-form-urlencoded');
$Request->content($Content);
my $UserAgent = LWP::UserAgent->new();
my $Response = $UserAgent->request($Request);
if ($Response->is_success())
{
return $Response->content;
}

return undef;
}

Now, really, how hard would that be to have quickly thrown together in LWP::Simple? Probably not even five minutes. Perl programmers are clearly lazy. If you write a module for CPAN, please make it versatile enough to not be so incredibly painful to use. Thank you.

I swear that only bad programmers actually use Perl and swear by it. That statement includes you Larry Wall, Mr. high-and-mighty creator of the second worst but popular language on the planet. Only COBOL holds the dishonor of being worse than Perl.

PHP 5 is an infinitely better scripting language. I've settled on PHP for major web development projects and C++ for client-side projects. It is a pain to have to know more than that.

And now a word from our sponsors...

Oh. Wait. I don't have sponsors. Never mind.

I feel dirty after having to learn Perl again. I'll just go wash my brain or something.

Comments

  1. Out of frustration with Perl I typed the phrase "Perl is a terrible language" into google and you were the first result.

    Ugh I agree in two years it hasn't gotten better, I mitigate things by trying to use named parameter hashes and going with a more OOP design of modules. The error reporting is cryptic/misleading and I don't even get column numbers just "near blah blah blah ..." which in many cases could mean multiple positions within the line. I haven't used python but I hear its loads better as a general purpose scripting language and PHP most certainly takes the title of the most versatile server side web scripting language.

    ReplyDelete
  2. I got here the the same way as Jim (hi Jim).

    Perl takes all of the fun out of programming. I don't get it at all. You don't spend any of your time fixing the problem you set out to fix, you spend it jousting with the language's idiosyncrasies.

    And the worst thing about perl? There are intelligent people out there that continue to put up with it. It's like a new team entered into F1, go the best drivers and engineers, and then expected him to win with a space hopper.

    Or going to war armed with airguns.

    Or opening up a restaurant, and not allowing your chef any ingredients other than pot noodle.

    Or writing a book containing no words other than "ook" and "PERL IS BOLLOCKS". Actually, that might be quite good.

    Urgh. Back to work :(

    ReplyDelete
  3. Almost 8.5 years after this article, and I got here the same way Jim & Patrick did. Perl is awful, and I would rather cut my eyes out with a dull spoon then continue debugging this Perl script.

    ReplyDelete
    Replies
    1. Yup. Still a terrible language. Oddly, I'm still focused primarily on PHP and C++ code after all these years. Obviously, both PHP and C++ have withstood the test of time. I also don't jump on whatever the hottest new bandwagon is either (e.g. Go) that has a pretty good chance of shooting itself in the foot. On the other hand, I have only rarely seen a Perl script here or there.

      Delete
  4. Almost 10.5 years after this article, and I got here the same way Jim, Patrick and Unknown did.

    ReplyDelete
  5. God damn it, Perl is awful. I have been trying to parse a 3 dimensional array inside a web app that was built with Perl and HTML::Mason. For 2 straight days. This language can do each and every trivial thing in about 20 different ways using cryptic syntax that was clearly designed for robots. Trying to find out how to iterate an array? Get Google results with 10 different approaches.

    If you give people too much freedom and leeway to use syntax shortcuts, you get exactly this experience. You BREED bad code. Why can't there be one standardized syntax?

    ReplyDelete
    Replies
    1. Oh but you get choices! Lots of choices must be good! /sarcasm

      Well, it's not like my languages of choice are faring well either these days. PHP is starting to look like symbol soup and getting progressively worse with every release. I'm not sure the PHP core devs even know who their audience is anymore. C++, starting around C++14, became symbol soup and C++17 made the situation even worse. If I wanted to write code in APL, I'd use APL. No one should write anything in APL.

      The usual argument is that symbol soup simplifies the code because code is getting more complex. That's simply wrong. Readable code makes even the most complex code maintainable. Symbols make code harder to read. There is a balance to be struck between words and symbols. COBOL leaned too far in the former direction, APL in the latter. Code should be understandable and graceful and elegant. Someone coming in from language A should be able to understand code written in language B at a glance. In that regard, .NET, as misguided as it was and still is, had some logic to it. However, all languages that abstract and remove the user from the hardware represents a major threat to the understanding of what technology is and how to correctly use it. I see an entire generation these days who throw code at a wall in whatever language is the hottest new thing but don't know the first thing about the hardware itself or how OSes are constructed. I've even occasionally succumbed to that mentality at times just to "get a project out the door." Case in point is anyone who chooses to use Composer for PHP, npm for Node/JS, pip for Python, Gems for Ruby, modules for Go, Maven for Java, Cargo for Rust, NuGet for .NET, etc. instead of building it themselves! Anyone who uses package managers for programming languages most likely does not know the first thing about writing real software and are easily sucked into the myth that symbol soup will somehow save their code. Clock cycles, memory allocation strategies, data structures, and algorithms are what matter but a lot of programmers have forgotten those things - or worse, never learned them in the first place and then go out of their way to excuse others who haven't learned them either. And later those same people think that, "If my language had a way to simplify doing XYZ using magic symbol sequence !$$, I could save typing two lines of code and my code will be better and I can pat myself on the back for making the world a better place!" They don't understand that all computing problems were solved in the 1960's at the dawn of computing. Not just some computing problems. ALL computing problems. Everything else adds a layer, which slows down code and abstracts the hardware on which everything runs. Not that abstractions are always bad, I'm saying the tendency is that devs use abstractions without understanding the fundamentals once the abstraction exists. And that leads to abstractions being built on top of multiple layers of abstractions. Symbol soup then creeps into the language and adds keyword abstractions that ultimately ruin clean code. Some languages like Perl and Bash/shell scripting actively encourage symbol soup at the outset but all languages are in danger these days.

      Delete

Post a Comment