Language change and code breaks

[Peter Hansen]

Nick Efford wrote:
> 
> On Mon, 16 Jul 2001 10:48:42 -0600,
> Bjorn Pettersen <BPettersen at NAREX.com> wrote:
> 
> > Getting Python accepted in an organization as a viable alternative to
> > Perl requires a lot of hard work. Once you've got a foothold it seems
> > stupid to shoot yourself in the foot by introducing random
> > incompatibilities that may or may not provide better traction for
> > non-users (not to mention the hackish solutions to long division that
> > would be introduced).
> 
> IIRC, aren't Perl-ers contemplating incompatibilities of
> a similar degree for Perl 6? (albeit with some kind of
> automated Perl 5 --> 6 conversion tool provided to ease
> the transition...)

I would think that even with Python's dynamic nature, it would
be possible to make a "Pareto scanner" which would uncover
80% of the possible problems with 20% of the work it would
take to make something more sophisticated.  I think "divscan.py"
could work...

> > I'm not against making this change per se, however, I think it should be
> > in the context of an overhaul of the entire numerical system, and it
> > definitely deserves a 3.0 labelling since that would indicate that there
> > are incompatible changes involved with upgrading.
> 
> Yes - I also like the idea of using a 3.0 version number
> to signal the importance of these changes.

That would be the point of a transition period, I think.  Starting
in the near future there would be support for the new style of 
division (future statement?) which would be optionally enabled
for new code.  Later on, when all the real work has been done,
version 3.0 would be released: this would be the first version
actually to *break* code, not the 2.3 or whatever release...

-- 
----------------------
Peter Hansen, P.Eng.
peter at engcorp.com