At 11:00 PM 2/16/01 -0500, schwern@pobox.com wrote: > > strict/warnings are not that picky; the odds that the code is more wrong > > than right are very good if they complain. "But it produces the right > > answer" is not a defence. You know that; why else would you develop with > > them? Anyone who resents the feedback is in the wrong business. > >No, they're not in the wrong business, they're just learning. "But it >produces the right answer" may not be a valid defense, but it is a >common one and you and I aren't going to be around to tell them it >isn't. Forcing extra stricness on a new programmer only works if >there's a mentor around to help them through the process and explain >things. Help me out here. You're saying: User: perl -e 'print 1/$x' Perl: Illegal division by zero at -e line 1 User: Okay, run-time error, no problemo, I can handle that. User: perl -we 'print 1/$x' Perl: Name "main::x" used only once: possible typo at -e line 1. Use of uninitialized value in division (/) at -e line 1. User: Okay, that's it, if you're going to whine like that I'm switching to Ruby. > > >You also have to take into account the legions of sysadmins who use > > >Perl as more powerful shell scripting. Do not equate not using strict > > >and warnings with "newbie". > > > > Okay, but these people are not going to be put out by sticking -q on > the #! > > line. > >We're talking about the folks who call things 'ls' instead of 'dir' >because its one less character to type, right? Oh well, then we should call the new executable 'p' instead of 'perl'. I checked... it's not taken... > > >Code style is a very, very emotional and personal issue. Adding any > > >default enforcement is going to piss off lots and lots of people. > > > > Just like the lack of it has already pissed off lots of people :-) > >Yes, but like it or not, they have over 10 years of precedent behind >them. We're used to this situation, the screaming has already been >done, the scabs are healed over. Let's not pick at them. I've always picked at 'em... in any case, the mandate for Perl 6 design was to consider everything fair game, within user-defined reason. We may well eliminate bareword filehandles in Perl 6, just 'cos they no longer make sense; seems we might as well go for everything we want to fix. If we don't create a better language when we have the chance, someone outside of Perl will do it and name it after a snake or something... -- Peter Scott Pacific Systems Design Technologies