Why aren't 'warnings' on by default?

[Chris Richmond - MD6-FDC ~]

Seems to me that nobody will support help requests until warnings
are turned on, let alone maybe strict. Why isn't it turned on
by default? Its a good idea 99.99% of the time. Then the
..01% when it isn't, make the user shut it off.

Chris

 

[mjl69]

Seems to me that nobody will support help requests until warnings
are turned on, let alone maybe strict. Why isn't it turned on
by default? Its a good idea 99.99% of the time. Then the
.01% when it isn't, make the user shut it off.

When your program works and it is ready for real world use, you can turn it off.
When posting here, it's like you're in school.

mjl

 

[Chris Mattern]

When your program works and it is ready for real world use, you can turn
it off. When posting here, it's like you're in school.

I don't think you understand his question. He's not complaining about
having to use warnings, he's wondering about why it isn't *on* by
default if it's that universally useful.

Basically, mjl, it's the cause of probably 90% of the evils in
software design: backwards compatibility. -w (the precursor of
use warnings) as we know it today and the restrictions it puts
on your code are relatively recent (of course, in this case
"relatively recent" still means over ten years ago...). Since
there's a lot of old perl code out there written before this,
if you made use warnings the default, that code which had been
running perfectly fine would suddenly start emitting warnings.
This would make a lot of people unhappy...

--
Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"

 

[Peter Scott]

Seems to me that nobody will support help requests until warnings
are turned on, let alone maybe strict. Why isn't it turned on
by default? Its a good idea 99.99% of the time. Then the
.01% when it isn't, make the user shut it off.

Many people, myself included, agree with you. Even
the perl man page is on your side:

BUGS
The -w switch is not mandatory.

It is not going to happen in Perl 5 for backwards
compatibility reasons. The question sparked heated debate
during development of Perl 6. It is a sore point of
contention for some.

 

[Big and Blue]

Many people, myself included, agree with you. Even
the perl man page is on your side:

BUGS
The -w switch is not mandatory.

However, if you have to remember to switch it on it might switch on
other parts of your brain, and that will help with your coding.

 

[John Bokma]

Basically, mjl, it's the cause of probably 90% of the evils in
software design: backwards compatibility. -w (the precursor of
use warnings) as we know it today and the restrictions it puts
on your code are relatively recent (of course, in this case
"relatively recent" still means over ten years ago...). Since
there's a lot of old perl code out there written before this,
if you made use warnings the default, that code which had been
running perfectly fine would suddenly start emitting warnings.
This would make a lot of people unhappy...

Yup. I have been working 2 years ago on a huge Perl project, and one of the
first things I did was turning strict and warnings on.

I found quite some weird/bad constructions and actual bugs that way, but it
took a lot of time to got it running under strict and warnings.

 

[Peter Wyzl]

: Chris Mattern wrote:
:
: > Basically, mjl, it's the cause of probably 90% of the evils in
: > software design: backwards compatibility. -w (the precursor of
: > use warnings) as we know it today and the restrictions it puts
: > on your code are relatively recent (of course, in this case
: > "relatively recent" still means over ten years ago...). Since
: > there's a lot of old perl code out there written before this,
: > if you made use warnings the default, that code which had been
: > running perfectly fine would suddenly start emitting warnings.
: > This would make a lot of people unhappy...
:
: Yup. I have been working 2 years ago on a huge Perl project, and one of
the
: first things I did was turning strict and warnings on.
:
: I found quite some weird/bad constructions and actual bugs that way, but
it
: took a lot of time to got it running under strict and warnings.

First thing I do when looking at someone else's code is turn them both on,
and look at the resultant errors/warnings.

A recent example is a publicly available 'blogging' script that does use
'my' declarations, but inappropriately (ie, declares the same variable name
three times in the same scope - 'declaraton masks earlier in same scope').
That gives some idea about the types of problems to be encountered
elsewhere. Gives you some idea of what the original programmer does or
doesn't know.

P

 

[Anno Siegel]

Chris Mattern wrote:
[...]

there's a lot of old perl code out there written before this,
if you made use warnings the default, that code which had been
running perfectly fine would suddenly start emitting warnings.
This would make a lot of people unhappy...

Yup. I have been working 2 years ago on a huge Perl project, and one of the
first things I did was turning strict and warnings on.

I found quite some weird/bad constructions and actual bugs that way, but it
took a lot of time to got it running under strict and warnings.

A general recommendation is to make old code warnings-clean, but not to
bother with strict "vars" (the hard part of strict). As you have observed,
it takes a lot of time, and you don't gain very much with a program that
was written without a view to lexical scope. Variables simply won't *have*
the small scope they could have, and changing that is far from trivial.

Of course, if the code has a long future ahead it may pay to do the
necessary partial re-write. Hey, "Refactoring Perl 4 to 5" would
have been a big success... ten years ago.

Anno

 

[Anno Siegel]

However, if you have to remember to switch it on it might switch on
other parts of your brain, and that will help with your coding.

Doesn't work. Once you decide to use strict and warnings regularly, you'll
find means (like a template file), that let you forget about coding them
every time.

Anno

 

[John Bokma]

Chris Mattern wrote:
[...]

there's a lot of old perl code out there written before this,
if you made use warnings the default, that code which had been
running perfectly fine would suddenly start emitting warnings.
This would make a lot of people unhappy...

Yup. I have been working 2 years ago on a huge Perl project, and one
of the first things I did was turning strict and warnings on.

I found quite some weird/bad constructions and actual bugs that way,
but it took a lot of time to got it running under strict and
warnings.

A general recommendation is to make old code warnings-clean, but not
to bother with strict "vars" (the hard part of strict). As you have
observed, it takes a lot of time, and you don't gain very much with a
program that was written without a view to lexical scope. Variables
simply won't *have* the small scope they could have, and changing that
is far from trivial.

Luckly the project was not that bad coded (close: it had a lot of
duplicated code oh, and over 650 (!) modules, and yes, zero
documentation).

Of course, if the code has a long future ahead it may pay to do the
necessary partial re-write. Hey, "Refactoring Perl 4 to 5" would
have been a big success... ten years ago.

:-D. I considered it necessary. I had to start somewhere to clean up the
code, which was needed (probably still is, since I got fired, long
story, not Perl related).

 

[John Bokma]

: Chris Mattern wrote:
:
: > Basically, mjl, it's the cause of probably 90% of the evils in
: > software design: backwards compatibility. -w (the precursor of
: > use warnings) as we know it today and the restrictions it puts
: > on your code are relatively recent (of course, in this case
: > "relatively recent" still means over ten years ago...). Since
: > there's a lot of old perl code out there written before this,
: > if you made use warnings the default, that code which had been
: > running perfectly fine would suddenly start emitting warnings.
: > This would make a lot of people unhappy...
:
: Yup. I have been working 2 years ago on a huge Perl project, and one
: of
the
: first things I did was turning strict and warnings on.
:
: I found quite some weird/bad constructions and actual bugs that way,
: but
it
: took a lot of time to got it running under strict and warnings.

First thing I do when looking at someone else's code is turn them both
on, and look at the resultant errors/warnings.

A recent example is a publicly available 'blogging' script that does
use 'my' declarations, but inappropriately (ie, declares the same
variable name three times in the same scope - 'declaraton masks
earlier in same scope'). That gives some idea about the types of
problems to be encountered elsewhere. Gives you some idea of what the
original programmer does or doesn't know.

You aren't talking about GreyMatter are you ? (Yikes)

 

[Chris Mattern]

Anno Siegel ([email protected]) wrote on MMMMCLXXVI
September MCMXCIII in <URL:..
.. A general recommendation is to make old code warnings-clean, but not
to
.. bother with strict "vars" (the hard part of strict). As you have
observed,
.. it takes a lot of time, and you don't gain very much with a program
that
.. was written without a view to lexical scope. Variables simply won't
*have*
.. the small scope they could have, and changing that is far from
trivial.


Well, using strictness doesn't do anything with reducing the scope of
variables. Declaring your variables at the top of the file with 'my'
make strict very very happy - but you still have variables with a broad
scope - and global if you don't use other modules.

But even so, it helps; catches every time you've misspelled a variable
name, if nothing else.

--
Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"

 

[Peter Wyzl]

: Peter Wyzl wrote:
:
: > : > : Chris Mattern wrote:

<snip>

: > First thing I do when looking at someone else's code is turn them both
: > on, and look at the resultant errors/warnings.
: >
: > A recent example is a publicly available 'blogging' script that does
: > use 'my' declarations, but inappropriately (ie, declares the same
: > variable name three times in the same scope - 'declaraton masks
: > earlier in same scope'). That gives some idea about the types of
: > problems to be encountered elsewhere. Gives you some idea of what the
: > original programmer does or doesn't know.
:
: You aren't talking about GreyMatter are you ? (Yikes)

No. Bloxsom. No doubt there are others as bad or worse.

Some of the concepts in these programs are 'non scalable' at best. For
example, reading in all the entries, formatting them and printing them out
dynamically for every hit, instead of converting them to static pages and
only updating for new entries. The unnecessary server load for busy
blogging servers is rather huge.

P

 

[Bill Smith]

A general recommendation is to make old code warnings-clean, but not to
bother with strict "vars" (the hard part of strict). As you have observed,
it takes a lot of time, and you don't gain very much with a program that
was written without a view to lexical scope. Variables simply won't *have*
the small scope they could have, and changing that is far from trivial.

Of course, if the code has a long future ahead it may pay to do the
necessary partial re-write.

--snip--


I agree. Blindly declaring every
variable with "my" just to make
old code "strict" compliant has
little advantage. Using the
warnings to find 'every' variable
retains spelling errors in the
original code.

Changing to lexical variables may
introduce errors because there
are a few constructs which
require package variables. New
warning will probably be
generated.

Properly scoping all variables
can be a huge task, especially if
the code uses formats.


Bill

 

[DJO]

Seems to me that nobody will support help requests until warnings
are turned on, let alone maybe strict. Why isn't it turned on
by default? Its a good idea 99.99% of the time. Then the
.01% when it isn't, make the user shut it off.

Chris

Because strict and warnings pragmas were not built in to early Perl
versions. Generally, Perl version updates strive to not break existing
code. Defaulting to strictures and warnings being "on" would definately
break older code that didn't count on them being there.

 

[RedGrittyBrick]

mjl69 wrote:



I don't think you understand his question. He's not complaining about
having to use warnings, he's wondering about why it isn't *on* by
default if it's that universally useful.

Basically, mjl, it's the cause of probably 90% of the evils in
software design: backwards compatibility. -w (the precursor of
use warnings) as we know it today and the restrictions it puts
on your code are relatively recent (of course, in this case
"relatively recent" still means over ten years ago...). Since
there's a lot of old perl code out there written before this,
if you made use warnings the default, that code which had been
running perfectly fine would suddenly start emitting warnings.
This would make a lot of people unhappy...

Hmm, maybe perl (the interpreter) could check the date on the file of
Perl statements and adjust its behaviour accordingly?

e.g.
foo.pl has last modified date < 1/1/2006 : strict & warnings *off*
unless specifically turned on.
foo.pl has last modified date >= 1/1/2006 : strict & warnings *on*
unless specifically turned off.

 

[Peter Wyzl]

: Chris Mattern wrote:
: > mjl69 wrote:

<snip>

:
: Hmm, maybe perl (the interpreter) could check the date on the file of
: Perl statements and adjust its behaviour accordingly?
:
: e.g.
: foo.pl has last modified date < 1/1/2006 : strict & warnings *off*
: unless specifically turned on.
: foo.pl has last modified date >= 1/1/2006 : strict & warnings *on*
: unless specifically turned off.


So if I do a minor edit on an old program suddenly everything gets broken
with no obvious reason? If the interpreter/compiler changes behaviour based
on the file date, imagine the difficulty in troubleshooting. "All I did was
copy the file from one place to another and now it has all these errors!"

P

 

[Joachim Pense]

Am 06 Feb 2005 15:35:44 GMT schrieb Abigail:

Turning warnings on by default also means it becomes more awkward to
write one-liners.

I do not think a one-letter no-warnings option would really hurt.

Joachim

 

[John Bokma]

: Peter Wyzl wrote:
:
: > : > : Chris Mattern wrote:

<snip>

: > First thing I do when looking at someone else's code is turn them
: > both on, and look at the resultant errors/warnings.
: >
: > A recent example is a publicly available 'blogging' script that
: > does use 'my' declarations, but inappropriately (ie, declares the
: > same variable name three times in the same scope - 'declaraton
: > masks earlier in same scope'). That gives some idea about the
: > types of problems to be encountered elsewhere. Gives you some
: > idea of what the original programmer does or doesn't know.
:
: You aren't talking about GreyMatter are you ? (Yikes)

No. Bloxsom. No doubt there are others as bad or worse.

Another program to avoid. GreyMatter, last time I looked at it, was
badly written. The maker(s) had plans to port it to PHP... Aargh.

Some of the concepts in these programs are 'non scalable' at best.
For example, reading in all the entries, formatting them and printing
them out dynamically for every hit, instead of converting them to
static pages and only updating for new entries. The unnecessary
server load for busy blogging servers is rather huge.

Yeah, can imagine. I have a small site/blog, and my access_log of last
month was over 100 MB :-D.

 

[Hendrik Maryns]

Abigail schreef:
<something very important>

<-- >
A perl rose: perl -e '@}>-`-,-`-%-'

This doesn't do anything for me?

H.