[resent to perl6-language, sorry for any duplicates]
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
