DEV Community: Parvez M Robin

13 reasons why you should not use Perl

Parvez M Robin — Thu, 21 Oct 2021 20:15:33 +0000

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.

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.
Too much implicit code: Remember, explicit is always better than implicit. But, Perl works the opposite way. Consider the following snippet.
```
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.
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.
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.
```
sub func1 {
    my $x = shift;
    my $y = shift;
    my $z = shift;
    // do something with the variables
}

func1(1, 2, 3);
```
Weirdly passing arrays to function: When you pass an array to a perl function, it flattens everything. Consider the following code.
```
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!
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.
```
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?
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.
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".
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!
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.
Inconsistent behavior: Say, we have a function like this
```
sub one {
    return 'two';
}
```
Now we define two maps like the following
```
%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.
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.
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.

What is .dockerignore and why you need it

Parvez M Robin — Wed, 13 Oct 2021 16:35:12 +0000

Yesterday, I was trying to replicate a tool from a conference paper. Unfortunately, it is using python 2. I wish one day researchers will know python 2 is dead. Anyway, I dockerized it, built it, ran it. It went fine. Today, I came back to my lab. Tried to build it again. LACKADAY! The build took more than 10 minutes. It kept showing the following message.

Preparing build context archive...
[==================================================>]79/79 files

So, I did what a computer scientist should do — Google. And I found a gem — .dockerignore. Before jumping into detail. Let me share what was the actual problem in my case. Before building a docker image, the docker CLI compresses all the files in the current directory and sends them to the docker daemon. These files are called the build context. In your Dockerfile you can only refer to the files/directories from the build context. The scripts I ran yesterday downloaded some files having a size of nearly 10 GB. Hence, when I was building the docker image today, it was taking forever.

There comes .dockerignore for the rescue. All the heavy files were inside two directories — data, and embeddings. So, I created a file in the project named .dockerignore and put the following content there.

data/
embeddings/

Bingo! The build time was reduced from 10 minutes to 10 seconds.

However, how could this be useful for your particular case? If you are a modern-day developer, surely you are familiar with dependencies. Could be npm, yarn, composer, nuget, gradle, gem, pip, conda, cargo, dep, or anything else. But there is definitely one. Now, for example, you are using npm, in most cases, your Dockerfile contains the following line —

RUN npm install

So, you are installing your dependencies inside your image. Now, if you have a node_modules directory outside your image (i.e., in your actual machine), that is not actually needed. However, by default, it will be added to the build context with the weight of a black hole and make the build process slow. However, if you put the node_modules directory in the .dockerignore, it will have no impact on the build process. The same goes for any other dependency management tools.

I Hope, from now on, your docker builds will be a little bit faster, if not gigantic.