FAQ

Turn 'em on! (was Re: Warnings, strict, and CPAN)

Schwern
Feb 23, 2001 at 1:37 am
Something I think Ed mentioned in passing a few days ago has been
running around in my mind and after some contemplation I think its
changed my mind on all this.

My position has been that warnings are ultimately good, but people who
have not internalized this will easily become annoyed with them and
switch them off. This is based on my particular observations and
speculations. But ultimately, its just an opinion.

Ed says by putting warnings right in a user's face, it'll make them
more aware of their existance and they'll more quickly come to see
their benefits. As with mine, its an opinion.

If this was the Software Engineering Institute, we'd setup a big study
to find out if new programmers learning Perl on their own find default
run-time warnings beneficial. But we're not the SEI.

But we can run an experiment. Warnings can be made default for the
first few releases of Perl 6 and we'll see what happens. If it looks
good, leave them on. If not, shut them off. Unlike most other
features, this one doesn't have any serious backwards compatibility
consequences! -w, -W and -X will still all work the same, C<use
warnings> and C<no warnings> will still be the same. Programs
will still run the same (baring Deep Mucking with $SIG{__WARN__}).

So I say, sure! Let's give it a shot and see what happens. I hope it
turns out that I'm wrong and Ed is right.


--
Michael G Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
reply

Search Discussions

7 responses

  • Nathan Wiger at Feb 23, 2001 at 10:16 pm

    schwern@pobox.com wrote:

    But we can run an experiment. Warnings can be made default for the
    first few releases of Perl 6 and we'll see what happens. If it looks
    good, leave them on. If not, shut them off. Unlike most other
    features, this one doesn't have any serious backwards compatibility
    consequences!
    Ummm, I'm not too sure about this. There are, actually, backwards
    compatibility concerns. Unless I'm mistaken, warnings go to stderr,
    correct? Meaning that a program which may have lots of "unitialized
    variables" and "variable only used once" warnings in them, *and* which
    rely on outputting useful information to stderr (like "real" warnings
    that the user put in the program) will have that polluted with lots of
    Perl gunk.

    This doesn't break code, but it does break the usability and behavior of
    the program. So to do this effectively and transparently p52p6 should
    really stick a "no warnings" in a p5 script to make sure that stderr
    isn't polluted. But then we're back to where we are now....

    Maybe what we really should be talking about is a way to let site users
    customize what flags are on by default? Just like customizing which
    modules are dynamically vs. statically loaded. I know this issue got
    beaten to death in the language RFC process already, but... if there are
    truly 2 groups with opposing viewpoints, why not add to Configure:

    Command-line flags on by default [-T -Mstrict -Mwarnings]:

    ??????

    -Nate
  • Dave Storrs at Feb 23, 2001 at 10:44 pm

    On Fri, 23 Feb 2001, Nathan Wiger wrote:

    schwern@pobox.com wrote:
    But we can run an experiment. Warnings can be made default for the
    first few releases of Perl 6 and we'll see what happens. If it looks
    Ummm, I'm not too sure about this. There are, actually, backwards
    compatibility concerns. Unless I'm mistaken, warnings go to stderr,
    [example snipped]
    the program. So to do this effectively and transparently p52p6 should
    really stick a "no warnings" in a p5 script to make sure that stderr
    isn't polluted. But then we're back to where we are now....
    I would tend to agree that old (i.e., <6) scripts should work
    exactly as they did before (or as closely as we can manage). However, if
    someone runs their old scripts through p526, that shows a commitment to
    the Perl6 track which implies that their new development would be in
    P6. The implication, to me at least, is that if we have p526 insert "no
    warnings" but all scripts written fresh in Perl6 have the warnings on by
    default, then we can get the best of both worlds. And, and M. Schwern
    suggests, we could try it for the first version or two and then solicit
    community feedback to see what people think.

    On a different topic, I for one am not thrilled (FWIW) about the
    idea of having a config file which sets site-wide policy for default
    switches are on by default; it represents another detail to keep track of,
    it could potentially represent a security hole, it's an
    "action-at-a-distance" effect, and there will still need to be some
    builtin "default" switchs (or lack thereof) to cover what happens when the
    config file doesn't exist or can't be read.


    Dave
  • Schwern at Feb 24, 2001 at 11:05 pm

    On Fri, Feb 23, 2001 at 02:16:34PM -0800, Nathan Wiger wrote:
    Ummm, I'm not too sure about this. There are, actually, backwards
    compatibility concerns. Unless I'm mistaken, warnings go to stderr,
    correct? Meaning that a program which may have lots of "unitialized
    variables" and "variable only used once" warnings in them, *and* which
    rely on outputting useful information to stderr (like "real" warnings
    that the user put in the program) will have that polluted with lots of
    Perl gunk.
    Yes, it causes problems between perl 5 and perl 6 if we turn them on
    (which p52p6 can take care of) but once they're on, turning them off
    doesn't cause much of a problem. Users should be encouraged to still
    use -w until we decide if this is a good idea. That decision should
    have to be made fairly earily to cause the least problems when we shut
    it off.

    This doesn't break code, but it does break the usability and behavior of
    the program. So to do this effectively and transparently p52p6 should
    really stick a "no warnings" in a p5 script to make sure that stderr
    isn't polluted. But then we're back to where we are now....
    Yes, p52p6 can do something like C<BEGIN { warnings->unimport unless $^W }>
    For Perl 5 programs this does leave us in the same situation as
    we are now... but then that's the point of p52p6, isn't it?

    Maybe what we really should be talking about is a way to let site users
    customize what flags are on by default? Just like customizing which
    modules are dynamically vs. statically loaded. I know this issue got
    beaten to death in the language RFC process already, but... if there are
    truly 2 groups with opposing viewpoints, why not add to Configure:

    Command-line flags on by default [-T -Mstrict -Mwarnings]:
    We already beat this to death with the .perlrc discussion. You'll
    break reams of Perl code you probably don't even know you have this
    way. For an illustration of the consequences, run: "file /usr/bin/* |
    grep perl", take the first result and run it like "perl -Mstrict
    /usr/bin/822-date" and watch the fireworks.

    For this to work, you'll have to have a /usr/bin/perl configured
    normally and a /usr/local/bin/myperl or something configured your way.
    Aside from being a colossal waste of disk space, this isn't much
    better (probably worse) than just remembering to use -w and C<use
    strict>.

    It destroys the portability of Perl programs.


    --
    Michael G Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
    Perl6 Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
  • Nathan Wiger at Feb 26, 2001 at 7:35 pm

    schwern@pobox.com wrote:
    Command-line flags on by default [-T -Mstrict -Mwarnings]:
    We already beat this to death with the .perlrc discussion. You'll
    break reams of Perl code you probably don't even know you have this
    way.

    It destroys the portability of Perl programs.
    Yup, I agree. I actually was on the "this is a bad idea" side of the
    discussion the first time around. Just throwing it back out there.

    Not too sure about the whole -w on by default thing. Really makes me
    nervous. All I keep thinking about is the crap that Java spits out every
    two lines. Makes stuff really look unpolished, and the warnings change
    based on the JVM platform and version you're running. In Perl, this
    would create problems if new warnings are introduced later. All of a
    sudden scripts that have been working correctly now start spitting out
    warnings, and either you or your client is terribly confused.

    Maybe I just need some time to warm up to it, but it still makes me
    nervous... I think there's going to be so much stuff different in Perl 6
    that the more similar we can make it to Perl 5 the better, otherwise we
    risk driving people running from the building. And this is one thing
    that seems like a "no brainer" for maintaining backwards-compat
    behavior...

    -Nate
  • Piers Cawley at Feb 27, 2001 at 5:05 pm

    Nathan Wiger writes:

    schwern@pobox.com wrote:
    Command-line flags on by default [-T -Mstrict -Mwarnings]:
    We already beat this to death with the .perlrc discussion. You'll
    break reams of Perl code you probably don't even know you have this
    way.

    It destroys the portability of Perl programs.
    Yup, I agree. I actually was on the "this is a bad idea" side of the
    discussion the first time around. Just throwing it back out there.

    Not too sure about the whole -w on by default thing. Really makes me
    nervous. All I keep thinking about is the crap that Java spits out every
    two lines. Makes stuff really look unpolished, and the warnings change
    based on the JVM platform and version you're running. In Perl, this
    would create problems if new warnings are introduced later. All of a
    sudden scripts that have been working correctly now start spitting out
    warnings, and either you or your client is terribly confused.
    How about having

    require 6.0.0

    set the 'warnings level' to generating only those warnings that were
    in the specified version.

    --
    Piers
  • Michael G Schwern at Mar 1, 2001 at 9:55 pm

    On Mon, Feb 26, 2001 at 11:35:43AM -0800, Nathan Wiger wrote:
    Not too sure about the whole -w on by default thing. Really makes me
    nervous. All I keep thinking about is the crap that Java spits out every
    two lines. Makes stuff really look unpolished, and the warnings change
    based on the JVM platform and version you're running. In Perl, this
    would create problems if new warnings are introduced later. All of a
    sudden scripts that have been working correctly now start spitting out
    warnings, and either you or your client is terribly confused.
    Well, this is just the "shut warnings off when you ship" philosophy.
    Whether its removing -w from your programs before shipping or adding a
    -q, same thing.


    A friend of mine was talking about how old WWII era analog fire
    computers, mechanical devices which calculated how much powder and at
    what angle a ship's main guns must be fired at. They had a special
    switch, "Battle Mode". In this mode, the computer would never stop.
    It would ignore all errors and just keep cranking out numbers. It might
    give wrong answers, it might melt down, but it would never stop. In
    the middle of a fight, you don't want your fire computer to crash.

    Asserts use this sort of philosophy, which is why they have an NDEBUG
    flag which allows you to shut them off program-wide.

    PERL_BATTLE_MODE environment variable anyone? ;)


    --

    Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
    That which stirs me, stirs everything.
    -- Squonk Opera, "Spoon"
  • Peter Scott at Mar 1, 2001 at 11:24 pm

    At 03:56 AM 3/1/01 -0500, Michael G Schwern wrote:
    A friend of mine was talking about how old WWII era analog fire
    computers, mechanical devices which calculated how much powder and at
    what angle a ship's main guns must be fired at. They had a special
    switch, "Battle Mode". In this mode, the computer would never stop.
    It would ignore all errors and just keep cranking out numbers. It might
    give wrong answers, it might melt down, but it would never stop. In
    the middle of a fight, you don't want your fire computer to crash.

    Asserts use this sort of philosophy, which is why they have an NDEBUG
    flag which allows you to shut them off program-wide.

    PERL_BATTLE_MODE environment variable anyone? ;)
    $SIG{__DIE__} = sub { die $ENV{PERL_BATTLE_MODE} ? <<"FNORD" : shift};
    Python 1.5.2 (#1, Feb 1 2000, 16:32:16) [GCC egcs-2.91.66 19990314/Linux
    (egcs- on $^O
    Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
    SyntaxError: invalid syntax
    FNORD

    --
    Peter Scott
    Pacific Systems Design Technologies

Related Discussions

Discussion Navigation
viewthread | post