At 05:33 PM 2/16/01 -0500, [EMAIL PROTECTED] wrote:
>This is a cross-over from perl6-language.
Good, I love cross-overs. It's not as good as a The Tick/Eraserhead
cross-over, but it'll do.
>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.
Eh? It's no different from arguing for no strict/no warnings as the
default being shoved down people's throats.
>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.
It's not necessarily big vs small, there's also novice vs adept. More on
this in a minute.
>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.
Agreed, and he will; that's never stopped the rest of us
flam^H^H^H^Hdiscussing it.
>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.
I just can't see this as a justification for lax reporting being the
default. If you leave -w/strict out, dollars to donuts it'll lead down the
road to bizarre run-time errors or incorrect behavior. But you don't leave
it out, you already said so. Why should we not give newbies the same
advantage until such time as they decide to turn it off for a JAPH or whatever?
Which is where I disagree with Edward; -q is not the training wheel, the
lack of it is.
>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, although they could say -q instead of all that, or -e will still imply -q.
>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.
Of course they aren't going to solve most/many/who cares how many basic
problems. I'm not claiming that we should advertise the feature that way.
I am saying that I have come across far too many people who were admittedly
far too lazy and who never bothered to find out about -w and use strict and
so got themselves into far more trouble than was necessary. If they had to
develop with those on, by the time they found out how to turn them off they
might be more enlightened. Or they would give up, figure that Perl was too
hard for them (possibly true; or that they were too dumb to be programming
anyway), and go away instead of causing havoc on clpm.
> > 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.
But it *isn't* a matter of someone else deciding you should work strict,
since you can turn it off with two characters. That's the training wheel
aspect; either someone gets to the point of finding out how to disable it
(and whether or not they should be doing that, at least they'll *know* they
are disabling messages), or they're just not cut out for tasks like reading
manuals, programming, or tying shoelaces. And if they *never* find out how
to disable the messages, then at least they'll generate better code with
strictness turned on, and won't end up driving people insane in clpm
pasting "run your code under -w and you'll see why it failed" in replies.
>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.
Maybe. It might also improve the majority of code out there to the point
where Perl's reputation is improved. In this area, it could stand it, IMHO.
> 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.
If 1/10 of the stuff mooted for P6 gets in there, it'll be sufficiently
different from P5 that this will be a minor change.
> > 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.
With the difference that this time they'll know they're doing it, rather
than not knowing they're not enabling reporting.
>If you try to enforce discipline without understanding they will
>simply work around it.
I don't see this; unless perl6 is turned to spit out "Run again with -q to
remove this message" after every error, I don't think there's likely to be
a large underground movement of newbies papering "Run all your Perl
programs with -q" notices on lampposts. Point being, by the time they've
expended the effort to find out about -q, they should have a bit more of a
clue as to why it's not the default. Plus perlrun can say next to -q, "IF
YOU RUN WITH THIS FLAG NO-ONE WILL GIVE YOU ANY HELP, LUSER."
> 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.
Now now, there's tons of discipline that isn't supplied even with
strict. And discipline that is supplied without it. strict/-w do not
constitute Java madness or you wouldn't be using Perl.
> > > 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.
True, but I'm not claiming that changing the default will accomplish this,
only that it will accomplish what I already described. Look, the docs
already say that the fact that -w is not the default is a bug. What should
we do, change the docs? Or leave it in there for P6 and build a new
language with an admitted bug in it from the beginning?
>No language will solve this. No Silver Bullet.
Yes, but not the point.
--
Peter Scott
Pacific Systems Design Technologies
