Re: Being helpful to a fault?

[hanenkamp]

I too gave an answer in to this particular post. I thought about the fact that it was likely a bad idea, but I thought of the plugin system that Aristotle pointed out and so didn't consider putting in a warning--I think that perhaps I should have, but nothing as severe as saying, "I'm sorry, but something about this train of thought makes little or no sense."

My opinion is that we can have it both ways. I think it's pretty unwise to assume that we have the answer for someone else's situation when we only have their one question. I also think that part of Perl's mystique is that it's alright to sometimes solve a problem the "wrong way" for various reasons. At the same time, I think we should be careful to point out when a certain action might not be a good idea.

There's no reason to be presumptuous and state, "Don't do that!" All we have to say is, "In general, that's probably not a good idea because of X." Then, they can make the judgement call, "Is my situation such that I'm willing to face X in return for some benefit Y."

It bothers me a little when Perl hackers persecute each other for doing things the wrong way (TMTOWTDI) when much of the rest of the information technology world persecutes us for using the wrong language. Thus, make your recommendation to help someone who might not have thought of a given problem, but remember that there are no hard-fast rules in Perl, so any guideline may be wrong for their situation.

[Aristotle]

I also think that part of Perl's mystique is that it's alright to sometimes solve a problem the "wrong way" for various reasons.

That's not specific to Perl - it applies everywhere. It's called Worse is Better and means that there's no one single metric by which to measure the quality of a work. There are many, and what's better by one or several of them is not necessarily better by one or more others. There's usually one commonly accepted way that will get you a decent or good result in the majority of cases, but that isn't necessarily appropriate for all case. Weighing choices well here requires an observative and experienced programmer. To quote The Tao of Programming:

There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticised him for writing unstructured programs, saying: "What is appropriate for the master is not appropriate for the novice. You must understand Tao before transcending structure."

In other words, you have to understand the spirit and the reasoning of rules in order to be able to appropriately judge when to break them.