Re^2: [beginner is learning] How comes before I ask a question here, it is answered

[shmem]

Conway argues that leaving off the parens from user-defined subroutines makes them harder to distinguish from built-ins

and that way trades decoration for understanding. Looks silly to me, to say the least. The language doesn't distinguish builtins from overriden builtin functions via parens, so the riddle remains for the beholder.

Besides, at the place where I work, they cruft perl in a C fashion, and the coding guidelines require parens even for builtins, so "people with less expertise in perl feel familiar and know what's happening" - which statement makes me cringe. A two hour talk would give them FMTTEWTK about parens, functions and context to get perl basics right and feel at ease with parens just as needed.

Oh, and parens around arguments for builtins even don't work always. Take print. Much has been argued against the current implementation of print. I am glad that it is as it is. At least it gives me an argument against folly.

[eyepopslikeamosquito]

Curiously, I also work with "people with less expertise in Perl" and our coding standards similarly mandate always using parens (and no leading &) when calling non built-in subroutines. We had this standard in place long before PBP in response to a specific incident here when an inexperienced Perl programmer simply changed "use" to "require" so as to load his (procedural) module at runtime rather than compile time. Unfortunately, this broke his code that was calling the module's functions without parens, and, due to his inexperience with Perl, he struggled for hours to figure out what was going wrong. If I understand correctly, the OP in this node had a similar problem and similarly spent quite a bit of time figuring it out, time that might have been saved by following this coding standard.

[BrowserUk]

in response to a specific incident here when an inexperienced Perl programmer simply changed "use" to "require" so as to load his (procedural) module at runtime rather than compile time. Unfortunately, this broke his code that was calling the module's functions without parens, and, due to his inexperience with Perl, he struggled for hours to figure out what was going wrong.

Firstly, that reasoning is considerably different, and far more persuasive, than the justifiction you cited from PBP.

But, and this goes to the core of the argument, the side-effects of arbitrarily switching from use to require go far beyond those that manifest themselves as a result of not using parens at the call sites. For example, the failure to call the import subroutine would likely manifest itself first, loudly and fatally with the classic

Undefined subroutine &main::xxxx called at ...

But even more important than that, it is surely an extremely important part of any programmers education to learn that when things suddenly go wrong, the first thing to do is back out recent changes to determine what change made them go wrong. And part of that is recognising that when you make changes that you do not fully understand the implications of, you should make them in isolation of other changes and immediately check what effects they have had. Ie. Small steps and frequent tests.

the OP in this node had a similar problem and similarly spent quite a bit of time figuring it out, time that might have been saved by following this coding standard.

And that goes to prove my major argument against PBP and similar "always do this, that and the other and everything will always work" education policies. They do not prevent programmers from making mistakes. They simply defer the fundamental, trial & error, learn by your mistakes, stages of their educations from the first few months of their careers--when they are expected and (should be) tolerated--to later, when they are expected to:

1. work without supervision;
2. work at a much faster rate;

   ie. Without the time to experiment and so learn by doing;

3. work on technically challenging code;

   That necessitates moving beyond the textbook examples and standard working practices in order to achieve timely, effective and efficient solutions.

Newbie programmers, whether to programming as a whole, or just a significantly different programming paradigm, should not just be tolerated, but encouraged to make mistakes. Because those mistakes are a fundamental and important part of their education. It's not just learning what they did wrong; but learning how to discover what is was they did wrong; and in the process, learning why it was wrong.

All the recent moves to short-cut the learning process for new Perl programmers--for the sake of short terms gains by their current employers--not only does long term damage to those employers; or their subsequent employers; and Perl itself--"he came here with 5 years of documented "experience", but turned out not to have a clue about algorithmic efficiency or maintainability". It can also totally ruin a programmer's potential.

And that is bad for everyone. What comes around, goes around. If you churn out, use up and discard programmers by attempting to derive short term financial gains at their expense, by short-circuiting their education; the pool is small and it will come back and bite you.

Please do not take this as an attempt by me to start a flame war. It isn't. This is a subject that I feel very strongly about, and you are one of those monks I have acquired a deep respect for over time. My hope is that this will persuade you that you should not be promoting PBP. If you feel the the need to counter this, go ahead, I will not respond unless you explicitly ask me to do so. Clearly!