> > Basically, I want '-w' back as a useful tool.
>
> That's interesting, why isn't it useful now? And why is that related
> to making it the default? (I'm honestly curious)
Its because '-w' is a global switch. To wit:
--AA.pm--
my $a = undef;
print $a;
--a.p--
use AA;
my $a = undef;
print $a;
If you run this, it will print:
Use of uninitialized value in print at AA.pm line 5.
Use of uninitialized value in print at a line 6.
So what happens when a 3rd party comes out with a module that doesn't
have a warnings policy?
I run my script, and get tons of *their* warnings, ones that may or may
not be helpful. And I shouldn't have to sift through their warnings
to see which ones are relevant and which ones are just the case of
sloppy programming.
> I'm not sure what you mean by a policy. Do you mean you want people
> to have to say C<no strict; no warnings;> explicitly? Do you want to
> make it a conscious decision to shut off the safeguards?
>
Yes!
> > Of course, I wouldn't mind if the newbie found the switch. Ultimately, I bet
> > lots of the newbies outgrow the switch though. And note that the switch
> > is there and *WELL ADVERTISED*. Not hidden in the docs.
>
> I don't understand what you mean, and I think I didn't make myself
> clear either.
If you put a note in the script after each time an error comes up,
something like:
Global symbol "$ab" requires explicit package name at a line 5.
Execution of a aborted due to compilation errors.
----
NOTE - if you are seeing this error and wondering what the hell it means,
perl's policy towards errors has changed since perl5. It now
checks for declarations stronger than it did before. If you want
the old behaviour, use the '-q' switch. If you want to disable
these upgrade messages, do xxxx.
People will get the point pretty quick.
> Using -w and -Mstrict *isn't* going to solve most basic software
> engineering problems. Neither is -q. No single command or function
> or switch will. You've got to have the whole process in place, you've
> got to make a conscious decision to do it.
>
> Do I have to invoke NSB? ;)
I don't understand what you are saying. Brushing my teeth won't help
me become rich, but it'll give me a tangible demonstratable benefit...
> > But that's the point. You *are* supplying your own discipline. You
> > are proactively stating by using '-q' that you want do have *lax*
> > discipline, more lax than the perl interpreter has to offer by
> > default.
>
> Now I'm completely lost. Making perl quiet is a *bad* thing in the
> long run. Its a symptom of a lack of programming discipline. That
> you're giving up on trying to make your program run properly.
Think of it this way - you'd sell '-q' as 'training wheels' for your
bike. Something to soften the learning curve.
> When I say supply your own discipline, that doesn't mean you shut off
> warnings and audit your own code for mistakes and errors. It means
> you consciously decide to work in a strict environment. However, it
You are consciously deciding to work in a strict environment. You are
consciously deciding not to use the '-q' switch.
> doesn't mean somebody *else* decides you should work in a strict
> environment. We have enough languages which do that TYVM.
Well, not many languages provide you with training wheels...
> > So - how about it? As I see it, the new points are:
> >
> > 1) the fact that forgetting 'use strict' is painful and forgetting
> > the proposed '-q' or '-z' is painless.
>
> I like strict, you like strict, lots of other people really, really
> don't like it. Large-scale Perl programmers want strict on,
> small-scale like to have it off. I'm not going to repeat the reasons
> here, dig through the perl6-language-strict archives for them. Both
> have valid arguments, both represent large chunks of the community.
well, like I said what's the big bloody deal about typing 2 extra
letters? I mean *come on*. Is it a badge of shame? Is it the computer
equivalent of a scarlet A? So frickin' what - *hell*. ITS NOT THAT BIG
A DEAL.
And anyways, in another post I offered to have an extra flag that
indicates warning/strictness, and to have strict+warnings by default
in modules. That'd satisfy me, because it would solve the main problem
that I see on CPAN.
Although that's truly a shame though. Lots of people who don't know
that strict + warnings are your friends and will save you tons and tons
of time will never go into them because they won't bother to play around
with them...
But that's their issue, not mine. So, yes, that would satisfy me, if
warnings and strictness were on by default in modules.
> We have a case where the two sides win conditions are conflicting.
> Keeping strict off has one major advantage, it won't break any
> existing code. Turning it on by default will break probably the
> majority of code out there. That would be Bad. We don't want
> everyone to have to run their entire code-base through p526. The net
> result will be people running 5.6 in 2010.
No, as far as I know we will be able to put 'use perl5' up on top of
their scripts, and they will convert over in their leisure.
And if some people choose to keep 'use perl5' up top, that's fine.
Although I'd say that I don't want to see their warnings by default.
>
> That's what is boils down to.
>
>
> > 2) the fact that I'm NOT trying to hide '-q' from users, but advertising
> > its existence upto the point where it comes along with every single
> > perl command that has errors for the beginning two iterations of
> > perl.
>
> Yes, people will find it and they will use it. Thus defeating the
> point of having warnings and strict default.
No it doesn't. Like I said, they will use it - hopefully later on they
will discard it. It provides an easier upgrade path because it makes
people type *less* and it puts strict and warnings up front
>
> If you try to enforce discipline without understanding they will
> simply work around it.
>
>
> > 3) the point that I am not aiming for a software standards but
> > for the modules on CPAN to have a strictness and warnings *policy*.
>
> Assuming a policy is C<no warnings; no strict>, what's the net gain
> here? What does having this in hand really do for us?
See up above. The policy towards warnings and strict is default positive,
and takes an action to become negative. In my experience, people focus
on the default behaviour.
>
>
> > 4) that '-w' is fundamentally broken as it stands and has to be fixed.
>
> Hello, what? I missed this, could you point me to the discussion?
Again, see up top. '-w' is a global flag, and hence you get thousands
of global warnings.
> > In addition, I think that the whole idea of 'upgrade NOTES' is
> > something worth exploring.
>
> Is this different than a perl6delta man page? I must have missed
> this, too.
the point is that the notes would come at the bottom of every single
compilation. They would point out - by example - exactly where perl5
and perl6 differ. if we do what I'm suggesting, and turn
$a, $b, $c = $d, $e, $f;
into
($a, $b, $c) = ($d, $e, $f);
then code that looks like:
($a = $b, $d);
would generate a warning:
WARNING: scalar assignment to a list. NOTE - this has changed since perl5
$a = $b, $d now parses as ($a = ($b, $d))!
> > And don't dismiss 1 as trivial. I personally have spent hours
> > tracking down simple bugs that I otherwise would have found within
> > SECONDS with 'use strict'.
>
> So turn on strict!! First thing, before you start debugging. Perl
> does not supply the discipline, that way Java^WMadness lies.
That's the point - I do turn on strict 95% of the time. 5% I forget to
type it. And it causes me hours of heartache.
However, if a '-q' switch existed, and someone forgot to type it, they
would get instant feedback. And hence what this is saying is that
their couple of extra seconds to type -q and not deal with warnings is
worth my hours of suffering, and the hours of suffering that people
garner from errors that otherwise would be caught, and yet make it to
CPAN.
> No, its really not. You're just charging back and forth over the same
> old No Man's Land. No matter what the decision, one side or the other
> will be cheesed off and no real net gain will be had.
I disagree. Like I said, I think a compromise can be made - provide
strictness by default in modules, and non-strictness in scripts. That
satisfies me.
> Good programmers will still be good programmers and bad programmers
> will still be bad, no matter how many switches you flip or pragmas you
> make them use.
>
> No language will solve this. No Silver Bullet.
Right, but I'm not asking for a silver bullet. Maybe a silver slingshot,
or a BB gun. Making a language useful is the process of having several
small incremental improvements, not one big one.
Ed
