I suppose that depends on what you're doing, where you're doing it, who you're doing it for, and *how* you're doing it. Some solutions are certainly more effective in some cases than others while the same solution is completely inadequate in different cases.

For example, you can hand roll your own CGI parameter parsing routines and there are certainly times when that's appropriate--specifically: training exercises and when you know more than Lincoln Stein.

However, lesser mortals (like myself) writing production CGI applications under less than ideal circumstances would be wiser to use CGI.pm for their scripts.

My point being that there maybe more than one way to do it, but certain ways are useful for some situations and not others. If you're not experienced enough to know the difference, then trust the experience of those trying to help you do it the best way for the circumstances you've described.

Part of the beauty of Perl, CPAN, and the community at large is the fact that you can stand on the shoulders of giants, that you can trust their work and their advice.

When people tell you something's not the Right Way to Do Something, it may be wise to at least hear them out. They may have specific knowledge that you can learn through by sharing their experiences, rather than by repeating their mistakes. Imagine, if you will, trying to recover a cracked web server, explain to your senior VP's why your site's service was denied, or to call your customers and tell them they need to get new credit card numbers because some cracker made off with your database and is now holding it hostage--all because you thought you were a better CGI Q than Mr. Stein. I'm exaggerating, of course, but hopefully in a way that outlines the differences I'm speaking of.

Yes, Feel free to experiment in a controlled environment. However, with production data, on-line servers, and public applications...ignore well meant--and experienced--advice at your peril.

It's one thing to be confident in your abilities to figure things out and to appreciate the flexibility of the tools at your disposal. It's quite another to recognize your limitations and to accept the wisdom of others.

--f

So far as I have ever heard, the saying is, "There's more than one way to do it", not "All ways of doing it are right." There are things you should not do in Perl (forget strict and -w, blindly untaint vars, not check return on system calls), they just happen to be stated like suggestions rather than laws. Perl'll let you hang yourself, and cheerfully hand you the rope to do it with. But you have to tie that knot.

----Asim, known to some as Woodrow.

That's the reason why "use strict;" isn't the default behavior. It often smooths your way, but you can certainly get into heaven without it. :-D

Gary Blackburn
Trained Killer

"The Wrong Way" is sufficiently defined for at least a number of topics here -- CGI programming, module usage, using -w or strict, etc... And not only is the wrong way(s) documented, but several "right" ways are along with it.

It's these sorts of places that enable one to learn accepted practice and -become- more able.

--
Me spell chucker work grate. Need grandma chicken.

Simply "getting the job done" isn't enough to qualify for righthood. What if you wrote a CGI to verify credit card transactions, and it worked great, passing every test case flawlessly, but it took three hours per run? Sure, it works, and it gets the job done, but I'd call that a wrong way.

I'd also have issues with code that works well and quickly, but is so obfuscated that even the guy who wrote it six months ago can't make sense of it.

Others have already mentioned security issues, as well.

There are many approaches to most problems, and some are better than others. In most cases, it's true that there is no single solitary correct way to do something. But most solutions can be viewed as (if you dislike the terms "Right" and "Wrong") "Good" or "Bad".

It all comes down to your criteria for goodness. If you're writing a quick half-pager to do some file maintenance chore, and you're just going to be running it yourself, and only once, then sure. Skip taint checks and -w, and if it takes an hour, who cares. That sort of thing might ingrain some bad habits into you that'll affect your next production program, though...

"Getting the job done" depends on what exactly that job is. More often than not, the scope is a lot bigger than you think. That one-off program will turn out to be handy next time you have a similar task, so you'll hack a bit to add a feature, then the guy down the hall mentions something that he could use it for, so you pass it along and he hacks a bit. And so on, until finally that little one-off program turns into a tangled 30-page behemoth that the entire company's web site relies on, and it's still not using taint checks...

Code always lives longer than intended. If you don't believe me, ask the COBOL guys who got called out of retirement for that little Y2K issue.

There's More Than One Way To Do It. But Some Ways Are Better Than Others. And Other Ways Are Just Plain Stupid.
(darn, a bit wide for a t-shirt)

---
I'm too sexy for my .sig.

we say TIMTOWTDI, and if it works for you, it is the "right" way. the only time it is the wrong way is when it doesnt work. also, your variable problem you mentioned is easily fixed with "use strict".

Mr. Zoothornrollo, hit that long lunar note, and let it float.

Maby I didn’t define myself all the way (ironic as it were), but the commit about a CGI taking 3 hours per run started a itch I just have to scratch-You see, even then, its not the wrong way-its just a very inefficient way-and once again, the label of inefficiency as being “The wrong way” is a Human definition-not a Perl one.

Once again-there is no clear definition of what is wrong and what is right-it all depends on You, and what You define as wrong-and if you define taking 3 hours to have a cgi run its course, then it would be wrong-to you. But it as far as Perl is considered, it’s the right way of doing things, because even though it takes 3 hours to do it, it still works-even though its not as fast as you would like.