On Tuesday 20 February 2001 22:03, Edward Peschko wrote:
> > I *like* the interpretation of undef as 0 and "". It's useful.
Sometimes.
> > Sometimes it's not. And that's fine.
>
> No that's NOT fine. It leads to 'find the needle in the haystack' sort of
> problems. If you get 1450 'use of undef value' errors, they are all
useless.
>
> If you get 10 of them, and you know that the only time you are going to
get
> 'use of undef value' errors, they are very valuable. And how valuable
they
> are grows as the size of your project increases.
>
> > There's no reason in the world why that should replace undef -> 0 and
"".
>
> See above.
>
> > > Or how about "I'm feeling particularly lazy today, I think I'll sleep
in.
> > Lets
> > > worry about any mistakes I might make another day."
> >
> > Well, Laziness is One of the Three.
>
> Exactly. Perl lets you be as lazy as you want. It just shouldn't do it by
> default, because warnings and strict are great teaching tools.
>
> > Let me rephrase.
> > Perl shouldn't bitch at me for valid perl.
>
> '-q'.
None of that is the point.
I don't disagree that having loads of warnings are a good thing.
I don't disagree that having strict parsing rules, variable declarations,
and the ilk are a good thing.
There is no technical reason why warnings and strictness can't be the
default.
You with me so far? Everything you have said is perfectly valid, and if we
were designing a brand-spanking new language, I might be arguing *for* you.
But we're not, we're tweaking Perl. Perl, remember that language? The
language that advertised all the above laziness? That the above laziness
was part of its drawing power?
This isn't an addition to the language that you're talking about - it's
changing some of the fundamental behavior of the language. It's saying
that no longer is Perl a loose, powerful language - oh, you want B&D? well,
we can do that for you too - but rather that Perl is just another
conventional programming language, (although if you flip this switch,
you'll get its old, horrible behavior.)
Sure, it will be easier to learn - it had better be, because
*e-v-e-r-y-o-n-e* is going to have to learn it. Again.
Look, most folks are probably sick of us going round and around about this,
so I'll sum up my position.
1. There is no technical reason why warnings and strict can't be on by
default, why undef must be able to promote to 0 or "", or just about any
other feature a computer language can have. No technical reason. It may
break some things, but those things can be fixed in their own right.
2. There are many non-technical reasons not to change codified behavior.
This is why the last serious revamp of English spelling and grammar rules
were aborted by the publication of the dictionary, why Americans adamantly
refuse any doings with the metric system (except the 2 liter bottle), and
why sports fans hate the instant replay. To change what some consider the
philosophical essence of Perl is akin to a bait-and-switch, and I, for one,
would feel cheated, (and if you'll allow me to wax melodramatic, betrayed).
3. While the argument is internal to us, I will remain steadfast in my
stance against any arbitrary, widespread reversal of the language.
4. Should the Perl cabal deem that, for Perl to improve, it *must* undergo
these radical changes, I will, to the best of my meager abilities, attempt
to implement them.
My position may seem a bit extreme - after all, didn't I, in the second
RFC, attempt to autoprint statements in a void context? I started in the
middle of the road, but as arguments like this have continued, I've moved
waaaay to the minimalist's side. Hey, overhaul Perl to your heart's
content so that you're able to do x, y, and z; just so long as Perl itself
doesn't do x, y, and z.
--
Bryan C. Warnock
[EMAIL PROTECTED]
