It also has people who know that their code will need to be maintained, advocating not writing their code as 'cleverly' as they can, to ease maintenance, which was the reason I added a quote in an earlier post to this thread.

Yes. As I tried to indicate earlier, there is nothing at all wrong with the quote. The controversy (from my perspective) is on its applicability to particular situations. For example in that other thread, it centres around the use of one of Perl's "features", namely implicit arguments. These are pervasive in Perl, and have, at points in time, been heralded as one of the features that makes Perl so productive and useful. At other times, certain schools of thought seek to deem this feature, in whole or in part, a mis-feature.

Many of those same people would trounce all over anyone who wrote:

I went to my doctor the other day because I had a problem with my leg. The doctor inspected my leg and the doctor told me that the problem with my leg was a strained muscle within my leg through incorrectly exercising my leg.

Instead of

I went to my doctor the other day because I had a problem with my leg. He told me that the problem was a strained muscle due to incorrectly exercising it.

It's always dangerous for someone who can't write English to save their life, to use English as an analogy, but what the hey.

No one would deem the use of implication within the second example as 'clever'. It is simply 'normal'. 5 years olds and younger learn to do this without effort or strain, or even special instruction.

There are two implicit targets of shift. They exist in clearly defined and very obviously different contexts. One could argue that having two different defaults is 'dangerous' or 'confusing'. One could argue that it might have been better for @ARGV to have simply been @_ at the root level of package main;. Ie. equivalent to argv[] in a C program, @_ would simply be seen as the arguments to the main 'function' in the program, just as it is the arguments to all the other functions in the program. Pah! History.

But given that history, and that it isn't going to change now, then there are 3 (+1) possible responses to the ambiguity:

1. Do nothing. An unadorned shift does what ever it does according to its context.

   For many people this is an non-issue and this is their chosen response.

2. Eschew the defaults feature (at least for this particular usage) and always explicitly state the target.

   In my view, overkill. It makes me wonder what's next.

3. Decide that one default is enough and explicitly state the target in the other context.

   Two possibles:

   • Always state @_.
   • Always state @ARGV.

   If any response is necessary, and as someone who never recalls having found the two defaults confusing I don't, but if it is, then as @ARGV is the least used, elect that one to be explicitly stated.

   Actually, I think I have always done this anyway, without ever consciously making a decision to do so.

Perl, by design, uses defaults and implicit parameters. You can argue whether that is a good design decision or not, but it is an integral part of the language philosophy. Deeming their use 'clever' does not seem appropriate to me. It's just using the language as it was designed.

As features go, I find this feature far less confusing than some features of many other languages.

Take Haskell's type diagrams as an example.

The use of single character identifiers as placeholders for types, combined with reusing that same identifier to represent all different arguments and returns of the same type, in the type diagram for a given function (or chain of curried functions?). I did, and do, find this confusing in the extreme.

Haskellers will say: you'll get used to them as your understanding of the language grows with use; and maybe it will.

And so it is with Perl's implicit arguments. You just get used to them. And very quickly. Far more quickly in my experience than Haskell's type notations.

And that leads to Haskell's almost universal use of single character variable names--albeit that 'variable' is probably the semantically the wrong term:). Yes, they are always locally scoped and it takes extreme effort to define a Haskell function that extends much beyond a handful of lines, but if I presented code here that used that many single character identifiers; and reused the same ones over and over; and used the same character for both actual and formal parameters; (not forgetting their reuse in the type notations!), then I would be hounded mercilessly.

Then there is that 'the whole meaning of a function can be altered--silently--due to the incorrect usage of an invisible character' feature. That caught me out no end of times until I tweaked my editor to prevent it. Talk about a mis-feature. But take that argument to a Haskell forum and you'll be laughed out of court (mixed metaphor).

Basically, judging parts of a languages design philosophy as 'clever', because they differ from those of your preferred language (an assumption), is ... long pause for thought ... let's just leave it as 'unproductive'.

It is more debatable when the argument is made by those seriously well versed in the language. But it is still debatable.