Hacker News Reader

Comment by greyman | Hacker News Reader

It's not a joke, it's true. Your code is nice, but the problem is, that Perl doesn't enforce any kind of readability; some other languages also don't but Perl is worst in this aspect, and that makes it unusable for anything bigger. New programmer will not understand the code or his colleague at the first glance, and at least in corporate environment, there are always new and junior programmers.

View on HN

This readability requirement is a bit overrated. It's best to rely on comments and documentation so that you can rewrite something if you have to.

I see lots of Java that's written in a simple and direct manner, but that has no documentation/comments and where it's a pain to find the execution flow in between so many classes and layers (especially when there's dependency injection).

> Especially when there's dependency injection

If it were just dependency injection it would be one thing but when you have all the opaque behavior that comes with a framework like Spring you get a bunch of spooky action at a distance code that can't be followed simply by traversing the call stack.

Couldn't disagree more. Comments should only ever be present to explain why a choice was made. Never what code is doing. If it needs to explain what the code does, the code needs to be rewritten.

Comments don't compile, so the only documentation of what code is doing guaranteed to be correct is the code itself.

Comments go beyond explaining why a choice was made, and this is usually not very useful information for a comment.

Really like comments for providing edge cases and information that can't be found by reading and understanding the code.

With Perl there’s always the temptation to completely eschew any readability by using its incredibly powerful and loose syntax to create programs that are indistinguishable from line noise.

You can write some absurdly powerful, really terse programs that make absolutely no fucking sense to anyone else.

Some people see this as a point of pride - Perl golfing etc.

the issue is Perl made TMTOWTDI a core value. So there's a hundred ways to express something differently. Compactly, verbosely, etc. Until you're familiar with your peers code, it can be a pain. Once you understand the style adopted internally it's not so bad.

Compare that to PHP where theres generally one way to do something right.

It’s even worse because not only is there more than one way, each way gets added and then deprecated, or worse there’s some big caveat like not being compatible with references or with values. This leads to all kinds of insane syntax that won’t make sense without a very careful reading. And because everything changes meaning depending on where it is, what functions were last called, and what it is being applied to there is no way to be sure of the effect of a function or a piece of syntax without having a deep amount of context from careful reading of the code before the call site. Context sensitivity sounds great in principle but leads to a lot of unpredictability in practice.

All this means is that teams have to enforce readability. It's not good or bad, just a different shifting of responsibilities - and this is something that you still need to do for other languages, there's just more tooling (like flake8 and black for Python).

I worked on (and modernized) a distributed ETL system all in Perl some time ago, and applying the long-codified ideals of Modern Perl made it one of the cleanest codebases I've ever worked in.

You can write shit code in any language. That's why teams have code reviews.

So Brainfuck would be an acceptable choice for a language to use?

My point is that there are extremes here that are worth considering: and Perl is on the bad side of any exchange involving the question of readability. The community doesn't help, either: they're as bad as the Rust Evangelism Strike Force, but in different ways.

> they're as bad as the Rust Evangelism Strike Force, but in different ways.

Who do you think RESF learned their ropes from? ;-)

This article has aged pretty well: https://www.perl.com/pub/2000/12/advocacy.html/

What are some examples where languages enforce readabity?

Golang is quite good in this regard: - language itself is quite simple - default coding style was defined at the very beginning - usually there is one standard way to do something - the language do not have so-called "syntactic sugar"

Reply on news.ycombinator.com