At 08:14 -0400 6/17/1999, Chris Nandor wrote: >Well, some of us don't code primarily for profit. And if you are using >Perl, I hope you can appreciate that, because Perl exists, and continues to >exist, only because of that fact. Sure, but whether you are talking about Perl or any other language that has a viable commercial application, the object is to meet the project specs within the agreed time. Within that framework, optimizing code that already yields adequate results may be personally satisfying, but it isn't productive. From what I've seen of development in general, the big holes aren't related to efficiency or functionality, they are a direct result of failing to anticipate just how blindingly stupid users of an interactive application can be and trap against their blunders or assuming that environmental states are stable when they aren't. All I am really saying is that the solution that is the quickest to implement is generally the best one whether it's pretty or not and that it begs the point to spend time optimizing something if you don't give at least equal weight to insulating it from user or environmentally induced failures. Richard Gordon -------------------- Gordon Consulting & Design Database Design/Scripting Languages mailto:richard@richardgordon.net http://www.richardgordon.net 770.565.8267 ===== Want to unsubscribe from this list? ===== Send mail with body "unsubscribe" to macperl-request@macperl.org