John Porter <[EMAIL PROTECTED]> wrote:

 > Simon Cozens wrote:
 > > John Porter wrote:
 > > > But you need to remember it anyway, so remembering it for time() is
 > > > no added burden.
 > >
 > > Uhm. NO! Remembering that $x+1 things have changed is an "added
burden"
 > > over remembering that $x things have changed.
 >
 > Not as x approaches infinity.
 >
 > I'm responding to the argument that, when perl6 has hit the
 > streets, a perl programmer should not have to remember whether
 > she's programming in perl6 or perl5.  Since that is an
 > impossibility, using it as an argument to support not changing
 > feature Y doesn't work.
 >
 >
 > > > "Perl should remain Perl" (once known as RFC 0) is bogus
 > >
 > > If you want things that *aren't* Perl, you know exactly where to find
 > them.
 >
 > RFC 0 continues to be bogus, despite its repetition.
 > Perl6 will be Perl, even though it won't be Perl5.
 > It will be a different language, yet it will still be Perl.

Correct. However, the lack of that argument doesn't mean that we should
arbitrarily slaughter the language. Keeping the time() function the time()
function _if_possible_ while perhaps adding a millitime() function from a
library or perl kernel whatsis or however it's added. Our hope is to
minimize the incompatibilities, not create them because we decide that a
function should suddenly do something totally other than it currently does
just because.

 > Please knock it off with the "Keep Perl Perl" non-argument.

Non sequitur. Perl 5 and Perl 6 will be different because we can't, not
because we don't wanna. Otherwise, we no longer have perl, but lrep.

Making changes that slaughter existing code just because we can is a
decidedly Microsoftish thing to do, and that makes me feel all ooogie.
(Anybody know what database engine we're supposed to use right now?)

p


Reply via email to