To quote myself from a recent discussion:
I think some languages do make it easy to write convoluted code, but through judicious use of coding standards (including a helping of common sense [don't be clever where you can at all avoid it, which IME is ~~almost~~ all the time], code linters, and so on) I think how you use a language plays a huge part in code maintainability.
For instance, I've heard PHP get shit on pretty badly all around the web, but I've worked at PHP shops that had nice, clean codebases, and my current Perl codebase is, in many ways, nicely structured. That's not to say there aren't some hairy codepaths that could use refactoring, but I really think that kind of thing, again, can happen in almost any language.
1. You can use virtually any language to write clean code
Not sure if I agree with this, though it may well be true. I just know there are some things like Brainfuck where it's designed to be impossible. I realize that language is created specifically for the purpose of making a coder say "WTF", but perhaps there are other languages that are not designed to be so that are really nearly impossible to write good code in.
2. Perl lends itself to unreadable code
If you stick to Modern Perl you still might end up with things like `wantarray` in your code so I guess this is kind of true. You need to be judicious in your use of code.
Some languages lend themselves more easily to writing clean code, like I feel about Go or if you hate the Go type system, Ruby. Even in Ruby I feel like metaprogramming is ripe for misuse.
It's a tough thing to talk about. I don't feel like I wholeheartedly disagree with your sentiment which seems to be "some languages lend themselves to bad code" and subsequently that Perl lends itself to bad code but there is plenty of ambiguity in these thoughts.
I used it for automation of my calculations in grad school. For data analysis. For monitoring.
In my subsequent day jobs, I used it to develop shipping products. No one really should care what language something is written in, if it does the job well.
Most recently (a few weeks ago), I used it as the driver for creating and submitted 10's of thousands of jobs for COVID19 research the team I am working with[1][2].
For the above project, I had to forward port 12 year old C++ code to make use of modern C++ based boost libraries. Took a bit of time to fix this. But the perl code, ran perfectly, and quickly[3].
Anyone trying to portray things otherwise, likely has a longstanding axe they like to grind. Language advocacy can be done without attempting to tear down other languages. Though those who argue against perl often bring up the same, old, tired, and incorrect points.
I'll keep using perl thank you. And Julia. And C. Each has their domain of applicability. Most people know and understand this.
[1] https://community.hpe.com/t5/advantage-ex/how-my-supercomput...
[2] https://community.hpe.com/t5/advantage-ex/the-story-of-how-i...
[3] https://scalability.org/2020/04/fun-and-topical-hpc-project-...
The system is from like 2013 and still going, but I really wish I could rewrite it in a language I can actually train people on in a reasonable amount of time. It took the one junior I have about 6 months to get to the point where he could read the syntax without tearing his hair out. It's not really built to create maintainable structures.
The libraries and stuff are full of opinionated little "gotchas." As an example, the Test::Simple module will throw errors if you use a number to title a test which is infuriating when you're writing a test which tests all the numbers in the space of acceptable or possible inputs.
Especially for example how variables have symbols for different types ($ for scalars, % for hashes, @ for arrays). And if you want to for example pass an array to a function you have to send it manually referenced with like method(\@myArray) which then inside the method is contained in a $scalar.
Compared to Python for example where you'd literally just pass the array to the method like method(array).
The values in @_ are aliased to the values in the subroutine call.
Most of the time, you want pass by value semantics, so you unpack the array and copy the values into function variables. If you want to modify an argument, it's typically passed in as a reference, and you can mess with it that way.
However, there are times when it would be horribly inefficient to make those copies, or when you need to do some magic (generally best avoided in 99.999% of your code), that this makes possible.
Also, since Perl functions are always variadic, it means that it's easy to work with a variable list of arguments in a function. For example, if you are expecting a list of key value pairs for your function, you can simply write:
my %args = @_
sub method {
my ($self, $a, $b, $c) = @_;
}
How does one tell Python to pass the contents of said array as distinct parameters to the function, instead of as a lone array parameter?
In Perl, that's the difference between foo(@bar) and foo(\@bar) or foo(1, 2, 3) vs foo([1, 2, 3]).