develooper Front page | perl.perl6.language.strict | Postings from February 2001

Re: Warnings, strict, and CPAN

Thread Previous | Thread Next
From:
Peter Scott
Date:
February 16, 2001 19:06
Subject:
Re: Warnings, strict, and CPAN
Message ID:
4.3.2.7.2.20010216184043.00b29bd0@psdt.com
At 09:36 PM 2/16/01 -0500, schwern@pobox.com wrote:
>On Fri, Feb 16, 2001 at 06:08:20PM -0800, Peter Scott wrote:
> > But if you want P6 to be so backwards
> > compatible that the largest issues are smaller than "@", an awful lot of
> > good stuff ain't gonna make it in, it seems to me.  'Sides, we already got
> > some clues that P6 won't have to be that backwards compatible with P5.
>
>Perl 6 is going to break things, fine.  But break them for a better
>reason than saving a few keystrokes, please.

S'not about saving keystrokes, as many times as I do type the same things 
in every file; it's about giving newbies the right introduction to the 
language and providing appropriate feedback at the appropriate level of 
individual development.

> > I repeatedly tell people, "If you're handed a program that doesn't have
> > -w/use strict in it, hand it back and say, Please insert -w/use strict, 
> and
> > give it back to  me when you've eliminated all the resulting messages," 
> and
> > many of those people have thanked me for that instruction.  So far,
> > no-one's said it was a bad idea.
>
>That's fine if people know why.  Some people don't.  Some people know
>why and decide otherwise.  Complicate it by the fact that its no
>longer a human rejecting your perfectly valid code, but a computer.
>People will resent it.

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.

>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.

> > I don't get this.  If someone's developing code right now with "use
> > warnings", and they want to ship with warnings disabled, they gotta edit
> > the code anyway.
>
>They're not using the warnings pragma, they're mostly using -w when
>its run and tested.  Alternatively, you can set PERL5OPT='-w' on your
>development machines (though I haven't heard of this in wide
>practice).

Eh?  I still don't get it.  You're saying that instead of typing 'foo', 
these people are typing 'perl -w foo' every time, to save themselves from 
putting -w on the #! line?  That's insane.

>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 :-)

>Just look at how much discussion this topic has generated all over the
>lists!  What's the net gain?  Some vague ideas about making people
>more aware of warnings and saving a few keystrokes.

I don't find the ideas vague... and they could save clpm from descending 
into a cesspool of iniquity.  Oops, too late...

>Instead, let's concentrate on some more tangible areas of need.  Perl
>is almost completely lacking in code metric tools.  We have no
>statistical analysis tools, our coverage library is barely there and
>our two profiling tools are anemic and underdocumented.  Our lint
>checker is an early alpha.  CPAN has no security checks, no author
>signatures, little auditing.  Vast sections of perl's core libraries
>and source code are not covered by tests, etc...

All agreed, and orthogonal.  So you concede the point, eh? :-)
--
Peter Scott
Pacific Systems Design Technologies


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About