At 09:36 PM 2/16/01 -0500, [EMAIL PROTECTED] wrote:
>On Fri, Feb 16, 2001 at 06:08:20PM -0800, Peter Scott wrote:
> > But if you want P6 to be so backwards
> > compatible that the largest issues are smaller than "@", an awful lot of
> > good stuff ain't gonna make it in, it seems to me. 'Sides, we already got
> > some clues that P6 won't have to be that backwards compatible with P5.
>
>Perl 6 is going to break things, fine. But break them for a better
>reason than saving a few keystrokes, please.
S'not about saving keystrokes, as many times as I do type the same things
in every file; it's about giving newbies the right introduction to the
language and providing appropriate feedback at the appropriate level of
individual development.
> > I repeatedly tell people, "If you're handed a program that doesn't have
> > -w/use strict in it, hand it back and say, Please insert -w/use strict,
> and
> > give it back to me when you've eliminated all the resulting messages,"
> and
> > many of those people have thanked me for that instruction. So far,
> > no-one's said it was a bad idea.
>
>That's fine if people know why. Some people don't. Some people know
>why and decide otherwise. Complicate it by the fact that its no
>longer a human rejecting your perfectly valid code, but a computer.
>People will resent it.
strict/warnings are not that picky; the odds that the code is more wrong
than right are very good if they complain. "But it produces the right
answer" is not a defence. You know that; why else would you develop with
them? Anyone who resents the feedback is in the wrong business.
>You also have to take into account the legions of sysadmins who use
>Perl as more powerful shell scripting. Do not equate not using strict
>and warnings with "newbie".
Okay, but these people are not going to be put out by sticking -q on the #!
line.
> > I don't get this. If someone's developing code right now with "use
> > warnings", and they want to ship with warnings disabled, they gotta edit
> > the code anyway.
>
>They're not using the warnings pragma, they're mostly using -w when
>its run and tested. Alternatively, you can set PERL5OPT='-w' on your
>development machines (though I haven't heard of this in wide
>practice).
Eh? I still don't get it. You're saying that instead of typing 'foo',
these people are typing 'perl -w foo' every time, to save themselves from
putting -w on the #! line? That's insane.
>Code style is a very, very emotional and personal issue. Adding any
>default enforcement is going to piss off lots and lots of people.
Just like the lack of it has already pissed off lots of people :-)
>Just look at how much discussion this topic has generated all over the
>lists! What's the net gain? Some vague ideas about making people
>more aware of warnings and saving a few keystrokes.
I don't find the ideas vague... and they could save clpm from descending
into a cesspool of iniquity. Oops, too late...
>Instead, let's concentrate on some more tangible areas of need. Perl
>is almost completely lacking in code metric tools. We have no
>statistical analysis tools, our coverage library is barely there and
>our two profiling tools are anemic and underdocumented. Our lint
>checker is an early alpha. CPAN has no security checks, no author
>signatures, little auditing. Vast sections of perl's core libraries
>and source code are not covered by tests, etc...
All agreed, and orthogonal. So you concede the point, eh? :-)
--
Peter Scott
Pacific Systems Design Technologies
