My apologies for taking so long to get back to you.

No problem. I never saw a debate worthy of the name that wasn't improved by the time to think. I would have had considerably less strife in my life had I had an (erasable) output buffer on my mouth :).

First of all you suggest that your response is partly because you feel that I am criticizing a kind of person that you feel you are.

Think no more of it. If I felt 'slighted' in anyway by your words, it was only because I chose to. If your words incite sufficient passion in me to respond, it is just an indication that I have some level of interest in the subject matter. Parhaps the greatest of life's lessons and one of the hardest to grasp is that the opposite of love is not hatred, but disinterest. I promise not to be offended by anything you say on the basis that you'll do the same :).

That doesn't mean I won't argue with what you say, only that I won't take it as directed at me personally, but rather at whatever "group hat" my screen personna is choosing to wear today :). That I will often use "I" rather than "they" or "we", is simply indicative that I am rarely comfortable speaking on behalf of others and trying to write without using pronouns results in turgid, incipient prose.

* Note that I don't always say that the first programmer needs to use fewer tricks, that is as wrong as saying that every programmer should learn every possible technique before they do anything. Hopefully this answers your question about whether causing confusion in others makes something a candidate for the "proscribed list". Well, you should think about it. But it is just as likely that you will instead decide that "people around here should understand that", and think about what you can do to make sure that people are at the desired competence level.

Rather than respond to the rest of your post blow-by-blow, I'll use the above as a placeholder.

Had you used the word 'techniques' everwhere that you used the word 'tricks', in this or your original post, I doubt that we would be having this discussion, but where would be the fun in that:). The line I was looking to see you draw is what distinquishes a 'technique' or 'idiom' from a 'trick'.

I've promised myself that I would try and avoid using analogy on-line as it usually leads to more confusion than clarification, but since you've mentioned lawyers:). The phrase currently resounding in my head is 'In loco parentis'.

In the specific cases you cite, whilst there are undoubtably gotchas involved in using the while each form over the foreach keys form, the reverse is also true.

I have two problems with not using the while form the loop.

1. foreach does not scale well once the number of keys grows beyond certain limits.
2. A much more incidious problem is that what you are doing by using the foreach method to avoid the 'one iterator' problem inherent in the while form, is diguising the real problem.

There was a recent node (that I can't find right now but may do before posting), where the OP was confused by the weirdness he was experiencing when using splice on an array whilst iterating over it within a foreach loop. To my way of thinking, the problem here lay with lack of awarness of the nature of the foreach mechanism (ie. aliasing, list expansion).

So, by using the foreach instead of while, you are protecting the OP from the gotchas of the 'one iterator' but leaving them vulnerable to the non-scalability of foreach as their project grows. The former will usually fail quite quickly once a change is made in the body of the loop that alters or resets the iterator of that loop. Whilst the latter will tend to 'creep in' as the scales grow over time and code that has been working correctly for a long time and that hasn't been modified, starts first slowing down and then failing intermittantly because the size of the list in the foreach loop has grown to the point it where it starts bumping its head.

You are also avoiding the need to mention that any form of manipulation of the source of a list whilst iterating over that list (using either mechanism) has to be done with serious consideration to the side-effects such manipulation might have. This latter caveat is one that is inherent in every language and is a fundemental tenent of programming.

Don't mess with contents of a data structure whilst in the process of iterating it, without giving serious consideration to the effects of doing so.

The question I have here is, are you doing them any favours? Isn't it better to either mention the limitations of the code up front, perhaps mentioning the alternative and its inherent limitations, and so cause them to think about both solutions and associated caveats? That way, when their code starts to fail as the scale grows or the code in the loop is modified beyond its original use, they may remember and have a notion as to what to look for.

In the end it translates to there being no substitute for being aware of the ins and outs of each technique (trick) and applying that knowledge in the context of the problem at hand. No amount of rules-of-thumb, selective deprecation, or "thou shalts" and "shalt nots" will ever substitute for understanding of the underlying mechanisms. There is also a lot to be said for learning from your own mistakes. There are industries and professions where this is an absolute no-no. Airline pilots, doctors, judges etc. and in these cases, there are mechanism for preventing catastrophic errors by these types of people. That's why it takes 7 years to qualify as a doctor and 15 or more as a judge (a guess and legal system varient).

There are skills that can be rote learnt, or picked up from a " ... for Dummies" or "Teach yourself ... in 30/21/14/7/3 days/hours/minutes" book:), but coding does not fall into this category. If someone learning to code is only doing so to "get the job done", then they would be better advised to employ the skills of someone with the requisite experience. However, if they have an immediate need to solve a specific problem, but are ready to take on-board learning for the longer term, then I think giving them an immediate solution to that problem whilst (breifly) mentioning any inherent caveats is ok.

Likewise, if the problem is that a specific snippet of their code is 'taking too long', or 'consuming too much memory', and there is an advanced, even obscure technique (trick) that will (even if temporarially) alleviate that specific problem, then I have no problem with suggesting that technique whilst mentioning that the long term solution to their problem may be a better algorithm or even bigger hardware.

With respect to the links you gave, I had already read most if not all of that, and most of your previous posts too, though not necessarially in context, and it is all interesting. Personally, I'm hoping that with your return, that some of the open debate that took place back then will also return, it has been sadly missing around these parts recently.

Relating this all back to where this thread started. My reasoning for suggesting the question "When would you consider not using strict?" rather than the original "What are the advantages of use strict?", are that I beleive that it would elucidate more insightfully about the responder than the latter.

I would be as wary of the responder that said they never would consider not doing so, as I would the responder that said they never did use it. It doesn't take much effort to discover that use strict is generally thought of as a "Good thing!". If the person saying that they never used it, does so through ignorance--either because they hadn't done enough actual coding or at least enough research to know that saying this is quite likely to raise serious questions--then the chances are that I am going to "discover" this ignorance through one or more of their other answers.

If however, they do so with a full knowledge of the implications, then I am quite likely to take them seriously as a candidate for the post. Their action in being bold enough to state this position, inspite of knowing how it might be received, indicates (to me at least) someone who bases their judgements upon their own thought processes and decisions rather than upon the collective conciousness. This is a person that I would want to work with. Here I go with one of those "In my experience statements", but in this case it happens to be so; This type of person can often contribute more to a project than those that consistantly toe the party line. (Mr. Segars, where are you now?)

All of that said, I don't think that in most specific cases, yours and my positions are so very far apart. The difference is in how we would go about handling them. I find myself having grave doubts about making this final statement, as I would hate for it to be widened into the general debate which would become totally unrewarding in this environment and I've already ranged over a far wider area than the inputs merit, but as a generic statement:

I don't believe prohibition to be the solution to any problem.

There will always be idiots like me who never got over their teenage angst against "Don't do as I do, do as I say" and will want to understand "Why not!"*

* Note: That isn't a question:)

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

Comment on Re: Re: Re: Re: Re: Re: Re: Re: Re: A Perl aptitude test