I think a useful concept is that a project will have a "discipline budget", just like the "language strangeness budget". Yes, if you're careful with your self-restraint and code reviews, you can write good, clean, maintainable code in a language that doesn't give you a lot of support for that. But if you do that then you're expending your limited supply of discipline, and will have less to spend on other aspects of the project like not scaling prematurely, not using cool-but-unnecessary tech...

Very interesting thought! I think I'll steal it.

Strongly agreed. It’s much more about the team, the conventions used, the organization of the codebase, and the coding culture of the team, than it is about a specific language.

True, but the cultures that grow up around a specific language tend to encourage certain conventions, standards of organization, and team coding cultures.

Under that standard it’s true, but it’s also true for virtually any language and is therefore not a good defense of whether or not a language lends itself to unreadable code.

There are a couple of points in there:

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.

In my 30 years (yes) working with Perl (4->5.32), I have never, once, used wantarray. Perl does not lend itself to bad code. Bad coders, people whom cannot use or articulate good practice in coding or documentation, lend themselves to write bad code, in any language.

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-...