duff writes: I've been of the "don't warn me about things, I know what I'm doing" camp for years now but lately I've had a complete 180 degree change of heart.
Ask any perl expert what's one of the first things they tell newbie perlers and invariably ``always put a "use strict;" at the top of your program and turn warning on'' is in the top 3. So why not make that the default and provide a simple command line option to turn them off?
In perl's early days only "experts" used perl, so the "don't warn" policy was correct as perlers either knew what they were doing or they knew enough to figure it out when things went wrong. But today, perl's user base is many orders of magnitude larger and the expertise of its users more varied. It seems to me that perl should adapt to these new conditions by helping the newbies while still apeasing the experts. I, for one, wouldn't mind warnings and stricture on by default as long as there was a simple method to turn them off.
What does the rest of the use Perl; community think?
I think no way until we get lexical warnings! Oh, wait ... never mind.
Maybe... Build-time decision, perhaps?
jzawodn on 2000-06-03T03:16:06
It'd make a nice option that I could switch on when I build a new Perl. Then if I forget to ``use strict'' sometime, my butt would be covered.
Wonder how many of my old scripts would croak as a result... Hm.
Inane warning used only once: possible typo
siracusa on 2000-06-03T04:29:06
As wonderful as warnings are for debugging, I refuse to explicitly defeat the warning system in an effort to create an artifical silence. The "used only once" bit has got to be one of the most annoying, and I can't believe how much code I see with some pointless "second use" of a var followed by a "# keep -w happy" comment of some kind.
I've barely dipped my toes into perl 5.6 so I'm not sure how much better things have gotten, but the "used only once" test is a good indicator as far as I'm concerned. I should never be forced to choose between code that is "warning free" and code that is "sensible."
Re:Inane warning used only once: possible typo
pudge on 2000-06-03T11:12:54
Well, as "helpful" as that warning can be, I turn it off in much of my code. In Slash.pm itself I put this:
BEGIN {
# this is the worst damned warning ever, so SHUT UP ALREADY!
$SIG{__WARN__} = sub { warn @_ unless $_[0] =~
/Use of uninitialized value/ };
I dont agree
grufolone on 2000-06-03T12:38:34
I dont agree for two different reasons:
1. probably many old scripts that did not use strict would break;
2.(most important reason) I believe Perl is a language for free people - it doesnt want you to do things in a unique way. You have objects, but you dont have to use them. You have coding guidelines, but yount have to follow them. You can write pretty obscure and buggy cose if you want to. TIMTOWTDI. This is in my opinion one of the most important philosophical points of the whole thing, and this is one of the reasons i do love the language. If any beginners script break or misbehave, well, I think that learning it the hard way will make you both mature and confident with the language. And if you dont like the idea, use strict
:-D
Support scripts?
crysflame on 2000-06-03T19:48:38
Do all of the support scripts that come with perl support being forced into use strict mode? This change would break a lot of script that would need a 'no strict; no warnings' at the beginning to fix, but in the actual Perl tree, i'd like to see cleanup instead, if it's needed.
Not a good idea....
chip on 2000-06-03T23:42:06
.... because Perl is not
only a tool for programming in the large. Just think of all the nice JAPH-ish things we can do on the command line with
-e. I don't want to have to shut up warnings for those.
As for the ``possible typo'' warning, the new our $var construct should finally make it convenient to avoid.
Re:our() and "possible typo"
siracusa on 2000-06-04T02:16:52
I don't think our() will help avoid the "possible typo" warning that much unless someone is accustomed to slinging around globals without using "strict" and "vars" (in which case they deserve what they get). But pity the poor programmer who wants to, say, alias a subroutine name for backwards compatibility via
*foo = \&goo; "Used only once! Possible typo! Check your oven!" Bleh.
Re:I dont agree
alleria on 2000-06-04T04:23:15
I originally thought opposite, but then realized that you just made a really good point: Perl's design is to allow the maximum amount of freedom possible with the default 'configuration', and then allow the user to pick and choose what he wants to restrict, and be warned about. Having stricture and warnings on by default would, in this sense, be somewhat inconsistent.
Re:Inane warning used only once: possible typo
glauber on 2000-06-04T11:55:26
I disagree. This has saved me much time (5 minutes at a time) by warning when i have misspelled variable names.
BTW, is there really ever a need to use a variable only once?
glauber
Re:Inane warning used only once: possible typo
pudge on 2000-06-04T17:19:43
Yes.
Consider:
# foo.pl
$foo = 'bar';
-----------
#!/usr/bin/perl -w
# myscript.plx
require 'foo.pl';
print $foo;
__END__
Yields:
# Name "main::foo" used only once: possible typo.
File 'Bourque:Desktop Folder:Untitled #2'; Line 3
bar
Huh? Oh yeah, I use it only once _at compile time_. Oopsie. Wrapping the require statement in BEGIN { } "fixes" it.
Re:Inane warning used only once: possible typo
micmath on 2006-07-13T08:58:59
Yes, there are "good reasons" to use a variable once, or at least once in a package space. If you need to, you can do this...
use warnings;
{
no warnings 'once';
print *Another::Package::used_once = sub { 1 };
}
Re:I dont agree
duff on 2000-06-05T14:43:21
I dont agree for two different reasons: 1. probably many old scripts that did not use strict would break;
This is bogus. We already have the situation where an upgrade of perl may break old programs. Anyone who upgrades perl blindly is a fool.
2.(most important reason)
I believe Perl is a language for free people - it doesnt want you to do things in a unique way.
Warnings and stricture don't force you to do things in a unique way. Perl has no ego, it doesn't care how you do things. If 80% (just pulling a number out of my ass here) of the perl programmers out there need warnings and stricture why shouldn't perl adapt to those conditions?
Re:Support scripts?
duff on 2000-06-05T14:47:07
Do all of the support scripts that come with perl support being forced into use strict mode?
This is a good question. And last time I checked there was a movement to make all of the scripts and modules that come with perl warning and strict safe.
Re:I dont agree
pudge on 2000-06-05T15:59:31
If 80 percent of Perl users thought grep should grep a file for some text, should we change it to do so?
I don't think such numbers matter much. I think right and wrong, when applicable, matter. And I think they are applicable here. I think it is wrong to force me to have to type an extra flag or something to get my hundreds of one-liners and short scripts to compile.
So let's talk about numbers in this manner: you think it is bogus to say old programs would break, that old programs are broken by many new versions of perl. But how many? How many programs were broken from perl 4 to perl 5, or 5 to 5.003, or 5.003 to 5.005, or 5.005 to 5.6? Not nearly as many, put together, as I imagine would be broken by this change. Of course, that number is out of my ass, too. But I like my ass better than yours.
:)
perl -w
koolade on 2000-06-06T04:26:27
I think warnings are great, but there are a lot of times where I know what I'm doing and I don't want warnings cluttering up the screen or the logfiles. The one that bugs me the most is the "Use of uninitialized value at..." where it really doesn't hurt in some cases to use an uninitialized variable.
As with the 'use strict' pragma as well, it slows your program down a bit, so I usually keep the warnings while developing, but then take them out on production code.
Speaking of warnings... from Slash.pm
dlc on 2000-06-06T12:11:53
This is from Slash.pm, the main module that powers slashdot and use.perl.org. I always thought this was some of the silliest hackery I'd every seen:
BEGIN {
# this is the worst damned warning ever, so SHUT UP ALREADY!
$SIG{__WARN__} = sub { warn @_ unless $_[0] =~ /Use of uninitialized value/ };
}
darren
Re:I dont agree
duff on 2000-06-06T14:08:43
How about this? Perl comes in two flavors, the default is no warnings/stricture and the other flavor is warnings/stricture on by default.
perl and newbie-perl.
I hope I don't have to put the smiley for you to tell that I'm joking here.
stricture and warnings compiled in
KM on 2000-06-06T19:33:57
I like the idea of warnings and stricture on by default (I will even take it a step further and say -T could be on by default as well). I would think maybe some options when building Perl like USE_STRICT, WARNINGS, and TAINT which would have Perl use these by default, and then a developer would need to turn them off explicitly (Maybe something in Config.pm would denote if these are on or off).
I think it could be useful, and here is why. As duff said, there are many new programmers which we always tell them to use strict, -w, and -T (for CGI). This way, whomever the admin of the box is can make them do so. This will likely create better Perl folks, and also break bad scripts people find (like those from MSA). As far as keeping -T on, it would be great for shops that use Perl mainly (or only) for CGI. This way I don't need to yell at minions to use tainting, since they are then forced to do so. May also help on the corporate front when you can say 'Perl is safer because you can have taint checking on by default'. We all know the biggest security risk is the ill-informed programmer.
As not to ramble, I will say I agree there should be a way to have strict, warnings, and tainting on by default. This could surely be used by many people, and adding the option wouldn't hurt those who do not want to do it.
Cheers,
KM
