Front page | perl.perl6.language.strict |
Postings from February 2001
Re: Warnings, strict, and CPAN
Thread Previous
|
Thread Next
From:
schwern
Date:
February 16, 2001 16:32
Subject:
Re: Warnings, strict, and CPAN
Message ID:
20010216173324.E6921@magnonel.guild.net
This is a cross-over from perl6-language.
First off, I'd like to make it clear that I'm *not* arguing against
the advantages of having strict and warnings on. I turn them on for
every program I write (except strict for one-liners) and strongly
advocate that everyone else do the same. However, I'm not about to
shove my style down other's throats.
On Thu, Feb 15, 2001 at 09:09:59PM -0800, Edward Peschko wrote:
> yeah, there are programmers and there are people who contribute to CPAN.
> I'd say they were a separate subset.
Any schmoe can post code to CPAN, there's nothing magical about it and
it doesn't suddenly make one a better class of programmer. But I
think you were implying a higher class of quality controls for CPAN
code due to their potential wide-spread impact. This is true, but its
a whole 'nother ball of wax.
> > strict by default is right out. That's not the sort of language Perl is.
>
> that's no argument. That's a solipsism.
I think its a tautology. ;)
Anyhow, there's two camps on this issue, those who use Perl for big
things and those who use Perl for small things. They have different
requirements and will (and have) argue until they're blue in the face
about them.
I say, if you're writing 10 lines, adding another (no strict or -q) is
annoying. If you're writing 1000 lines, adding another is no big
thing.
Let Larry figure out how to slice this knot.
> > I'm the bloody QA chair and I don't even think its a good idea anymore.
>
> what difference does that make?
In and of itself, none. But I do deal with this sort of thing all the
time. How do you make software more readable, more maintainable,
higher quality, less bugs, easier to write? I read books and papers
on the subject. I (try) to teach people and watch them struggle with
the process. I have to read, document and refactor reams of other
people's code. I practice it all myself (and screw up alot).
What I have found is shoving extra strictness and verbosity down a
newbie's throat generally doesn't work. Often, they just either learn
to ignore it, shut it off or otherwise work around it. It all depends
on the person, but humans, as a rule, don't like things which increase
short-term work (even if it'll decrease their long-term) until they've
already made their own mistakes and wasted that long-term time.
Also, programmers hate computers telling them they're wrong (users
seem to expect it) without having asked them. Its a big, nasty
sociological and psychologial problem.
> 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)
> Exactly. That's the point - everything breaks. I don't want people to be
> forced to 'use strict' and 'use warnings'. All I want is their files to have
> a POLICY towards 'use strict' and 'use warnings'.
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?
> > You have to do all this anyway, flipping a few command line switches
> > isn't going to solve fundemental software engineering problems. Yes,
> > it would be nice if warnings were on by default, but it has too many
> > caveats. Its also all to easy to be shut off (and don't think that's
> > not the first switch a newbie will find).
>
> 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.
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? ;)
> > Supply your own discipline, don't make the language do it or you will
> > be sorry. (Devo moment... "Freedom of choice is what you got, freedom
>
> 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.
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
doesn't mean somebody *else* decides you should work in a strict
environment. We have enough languages which do that TYVM.
> 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.
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.
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.
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?
> 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?
> 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.
> 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.
> > Instead of Yet Again arguing back and forth on this, go write me some
> > code auditing tools.
>
> hey, but this fight is worth fighting.
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.
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.
Thread Previous
|
Thread Next