Why many monks don't like use parenthesis with functions such as split, map, print. is it because concise, readable or other reasons?

For the same reason most people don't type:

my sum = (((($p+$q)+$r)+$s)+t);

when

my $sum = $p + $q + $r + $s + $t;

is cleaner and clearer.

Perhaps more realistically, my $z = sqrt( $x**2 + $y**2 );

in preference to my $z = sqrt (($x**2)+($y**2));.

is it because concise, readable or other reasons?

• Reduces clutter
• Enhances readability
• Lack of parentheses visually distinguishes builtins from subroutine calls

The book is full of well-articluated reasons for its many coding style recommendations.

Lack of parentheses visually distinguishes builtins from subroutine calls

Hm. Apart from the fact I don't need to use the addition or omission of parens to distinguish between built-ins and not; because in common with most (not all; but most), programmers I use a syntax highlighting editor that is capable of doing that for me.

That distinction is wholly artificial.

For starters, there are some places where the parens are not avoidable without jumping through contorted hoops that would completely negate any benefit of their omission. Eg.

print '(' . join( ',', @things ) . ')'; ## (1,2,3,4,5,6,7,8,9,10)

print '(' . join ',', @things . ')';;   ## (10) Whoops!

print '(', join ',', @things, ')';;   ## ( 1,2,3,4,5,6,7,8,9,10,) Doub
+le whoops!
[download]

It also presupposes that everyone will always use, often redundant, parens on every non-built-in.

And then the definition of what is a built-in and what is not gets blurred when you start using (for example),

• Math::Random::MT qw[ rand srand ];
• Time::HiResqw[ time sleep stat ... ];

And at least one of those, behaves quite differently to the built-in in many circumstances, if used without parens.

Also, I realise you're only paraphrasing, so the fault, (if there is one,) may be yours not the books, but aren't those first two "reasons" actually just one? Ie. Enhanced readability by reducing clutter. or By reducing clutter it enhances readability.

I greatly prefer, and practice religiously, the "low clutter style" of Perl coding, and I think that the results are self-demonstrable. I don't see any additional benefit from overselling them with justifictions.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

You chose a good example. I've always found it difficult to come up with any style of concatentation/interpolation that doesn't look cluttered and hard to read. A significant proportion of my bugs are due to this.

As soon as there is any amount of complexity I reach for builtins with parens.

my $str = sprintf(
  qq{(%s)\n},
  join(q{,}, @things),
);
[download]

Clearly, this is borderline complexity but I've had ternaries, function calls, math (generously seasoned with parens) and the kitchen sink in there as well. I find having a trailing paren to pin the ; to helps me keep things in order. In a word: templates++.

I was disappointed with the book and wish I had bought something else. A two page pdf trying to be a book. I've adopted q, qq, qw and qr but I'm not sure if that was due to advice or my code editor.

And while we're here, you can't have the words "readable" and "uncluttered" alongside the phrase "nested ternaries". However hard people try to format them they're unreadble. Too posh to use a humble if/elsif/else block?

Phew, that's better. :-)