FAQ

Re: Closures and default lexical-scope for subs

Edward Peschko
Feb 15, 2001 at 9:49 pm

I personally think that this is something Larry is going to have to
decide. However, I would like to note that leaving these off by default
lowers the transition curve to Perl 6 immensely for those people that
use Perl as a glue/scripting/sysadmin language.
Right, but what I don't understand is that its two extra characters at the end
of a command line... whats the big deal about typing '-q' on one line in
scripts? Its easy enough to advertise '-q' and put it in big lights...

My point is that '-w' is pretty much useless because people contribute modules
to CPAN that don't have '-w' turned on, and you get lots of junk output from
your scripts because other people don't adhere to the '-w'.

Hell, *I* don't use '-w' because of this.
Key: Not everyone becomes a Perl expert. Many people never leave
novice/intermediate level. This doesn't mean that we should design the
language for these people, but it also doesn't mean we should thumb our
noses at them.
So - why is it a religious issue then? I respect the fact that you want to
write scripts without 'use strict'. I do this all the time. But I really think
that its a small price to pay to put '-q' on the #!/usr/bin/perl command line
for the vast benefits that it would give us all as far as CPAN goes.

So - in the place of a '-q', would you support a mechanism for making sure that
CPAN is '-w' clean? If so, how would you enforce it?

Ed

(
ps - if you want to take this offline, its fine by me. If this issue has been
covered before, you can tell me the arguments for/against it.

But right now I do consider '-w' broken because of this; and it doesn't
give me much comfort that lots of the modules on CPAN could have hidden bugs
in them because -w is too difficult to use.
)
reply

Search Discussions

1 response

  • Nathan Wiger at Feb 15, 2001 at 10:54 pm ⇧

    Edward Peschko wrote:
    I personally think that this is something Larry is going to have to
    decide. However, I would like to note that leaving these off by default
    lowers the transition curve to Perl 6 immensely for those people that
    use Perl as a glue/scripting/sysadmin language.
    Right, but what I don't understand is that its two extra characters at the end
    of a command line... whats the big deal about typing '-q' on one line in
    scripts? Its easy enough to advertise '-q' and put it in big lights...
    Yes and no, I think. As Alan Burlinson pointed out earlier, this is
    *not* a purely clean-slate we have here to work with. There are lots and
    lots and lots of users who know how Perl works. Many of these users
    don't even know that you can do this:

    my $x = 5;

    Let alone that this:

    my $x, $y, $z;

    Doesn't DWIM, again according to what most people think.
    Key: Not everyone becomes a Perl expert. Many people never leave
    novice/intermediate level. This doesn't mean that we should design the
    language for these people, but it also doesn't mean we should thumb our
    noses at them.
    So - why is it a religious issue then? I respect the fact that you want to
    write scripts without 'use strict'. I do this all the time. But I really think
    that its a small price to pay to put '-q' on the #!/usr/bin/perl command line
    for the vast benefits that it would give us all as far as CPAN goes.
    Let's separate the CPAN thing out for a moment. "use strict" and "use
    warnings" are not the universal solutions to CPAN quality issues, at
    least as far as I'm aware.

    As for the -q thing, I think it is far *less* of a burden to add "use
    strict" and "use warnings" when you're writing a big piece of code. When
    you're writing 5 lines, every extra character counts. When you're
    writing 500 or 5000 lines, 2 lines of "use" statements are nothing.
    So - in the place of a '-q', would you support a mechanism for making
    sure that CPAN is '-w' clean? If so, how would you enforce it?
    Absolutely, 100%. But this is a separate issue. For example, a big
    problem with CPAN is also packaging. There's lots of modules that don't
    use the h2xs/Makefile.PL approach. Also, many modules on CPAN have been
    in beta for years, and not just 0.99 beta but 0.02 beta, broken and
    uninstallable. There's also a lot of modules that don't run under -T.
    But "strict" won't fix these issues.

    If we're interested in increased CPAN quality, there's a bunch of stuff
    we can do. We can have a standard test suite that's run against every
    module uploaded to check if it's installable and compiles basically. We
    can check for -w, -T, use strict, and tons of other stuff. We can check
    for the packaging to make sure that "perl -MCPAN -e shell" will install
    the stuff cleanly. If there's simple problems (misnamed tar files, a
    $VERSION split onto multiple lines), we can even auto-fix this. Then
    send all the results to the user who uploaded the module.

    Heck, I'd even volunteer to head up a project to do this. But I think
    it's a separate issue from "use strict" and "use warnings", let's not
    confuse the two.

    -Nate

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl6-porters @
Notice: Undefined variable: pl_domain_short in /home/whirl/sites/grokbase/root/www/public_html__www/cc/flow/tpc.php on line 1543
categoriesperl
postedFeb 15, '01 at 9:49p
activeFeb 15, '01 at 10:54p
posts2
users2
websiteperl6.org

2 users in discussion

Edward Peschko: 1 post Nathan Wiger: 1 post