At 11:00 PM 2/16/01 -0500, [EMAIL PROTECTED] 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
