13 reasons why you should not use Perl
Tags: perl, nlp, regex
Published: 2021-10-21 20:15:33

Currently, I am conducting a natural language processing course. As part of the curriculum, I need to learn and code in Perl. I was exited! I was enthusiastic! However, the verb is "WAS". I am neither exited nor enthusiastic any more. I already have experience in C, CPP, C#, Java, Golang, Python, JavaScript, TypeScript and Bash. Among this versatile experience, Perl is now my second most hated language after Bash. *Let me tell you why*.

1. **Weird variable access**: I have worked with typed language where I need to tell the type. I have worked with weakly typed language where the language knows which is which. Then comes Perl. It is weakly typed. But, I need to prefix a variable by either `$` or `@` or `%` to tell Perl about the type of variable. And I need to do it every time I access the variable. Even more - the prefix changes time to time based on the usage.

1. **Too much implicit code**: Remember, explicit is always better than implicit. But, Perl works the opposite way. Consider the following snippet.
    ```perl
    while (<>) {
        print;
    }
    ```
    What this does is reads from the input stream in `<>` this command, stores it in a variable named `$_`, then prints that variable. Of course you can assign and use your own variable but Perl developers seem to prefer this. Well, I don't.

1. **Lacking readability**: Continuing from the previous example, when someone sees that snippet, it is literally hard to get what it is doing. At least, it was hard for me. 

1. **No clear parameter list**: While declaring a function (called subroutine in Perl), it does not specify the parameter list. You will always pass a list of arguments and the function need to extract them from an array. The end product is too much boiler-plating with too less readability.
This is what you will do, if you need to retrieve 3 parameters.
    ```perl
    sub func1 {
        my $x = shift;
        my $y = shift;
        my $z = shift;
        // do something with the variables
    }

    func1(1, 2, 3);
    ```

1. **Weirdly passing arrays to function**: When you pass an array to a perl function, it flattens everything. Consider the following code.
    ```perl
    sub func1 { print scalar(@_); }

    @a = (1, 2, 3);
    @b = (4, 5, 6);
    func1(@a, @b);
    ```
    The `scalar` function returns the length of an array and the `@_` variable holds the arguments as an array. So, `scalar(@_)` will give us the number of arguments. What do you think the output is? `2`? It should be. But, it's perl and the output is `6`.
    If you want to pass an array as an array, you need to make a reference of the array, pass the reference and de-reference it inside the function. Hell of a job for such a simple task!

1. **Weirder passing hash/map to function**: Okay. When we pass something to a perl function, it flattens everything and makes a single array. What happens to hashes/maps? Well! It makes that an array too. And that array contains all the keys and values; in a single place. Consider the following code.
    ```perl
    sub func1 { print join ', ', @_; }

    %f = (one => 1, two => 2);
    func %f;
    ```
    What do you think the former code prints? My guess was it will print the keys of the map. At the worst case, it will print the values instead. Alas! The actual worst case worse than what I anticipated. It prints both keys and values. So, the output is `one, 1, two, 2`. And it becomes a mess when you want to reconstruct the map.
    The mess gets messier if you call the function like `func1 %f, three, 3`. How will you know what came from where?

    <!-- 7 -->

1. **Cryptic RegEx handling**: When you do a regular expression match, it automatically assigns some variables like `$&`, ``$` ``, `$'` etc. They are useful when you know them to be honest. But, when you just read the code, specially when you are from another background, it looks like a mess.

1. **Less Searchability**: Consider the previous point. You are reading a perl program. You suddenly found use of undeclared variables like `$&` or `$'`. So, you googled about it - _"what does $' means in perl"_. Alas! while you search something on the search engines, they generally stripes out spaces and punctuation. You will still have relevant results. But, they won't be as great as if you search - _"what does dir mean in python"_.

1. **Pathetic debugging support**: The debugging support for perl is in a word pathetic. It only supports some basic commands and the error messages are cryptic. Once you are stuck in somewhere, you are DONE!

1. **Too much implicit error handling**: While the shown error messages are cryptic, there are a lot of errors that are not shown at all. Say, we have an array `@a` and we want to print it. Now, mistakenly we have typed `print $a`. It will just print nothing just like if the array was empty. In my opinion it either should through an error or print the memory address of `@a`. It does nothing. And you will never know that you have an error there.

1. **Inconsistent behavior**: Say, we have a function like this
    ```perl
    sub one {
        return 'two';
    }
    ```
    Now we define two maps like the following
    ```perl
    %m1 = (one => 1);
    %m2 = (1 => one);
    print %m1;
    print %m2;
    ```
    It will print `one1` and `1two`. Can you make any sense of it? Well, I could not for a while. Turns out if your map's value coincides with one of the functions, it will call that function and use the function's return value as the map's value. But, it will not do such if your map's key coincides with a function.

1. **Poor IDE support**: So far I have not seen any perl IDE that satisfies me. You can add plugin to VS Code or JetBrains IDEs to support perl. But, they are buggy and are not feature-rich.

1. **I just hate it**: This is the full and final reason. And, I guess, this is sufficient reason to hate a language that I just hate it.

> John Lennon dreamed of a world without religion. I dream of a world without perl.