On Feb 10, 2:02 am, Martin Albrecht <m...@informatik.uni-bremen.de>
wrote:
Hi,
> > We should never intentionally break people's code like that if there
> > is no pressing issue. Adding deprecation warnings is ok to point
> > people in the right direction, but from discussions about this at SD12
> > and in other places it has become clear at least to me that six months
> > is not even remotely long enough for people to change their code and
> > adapt.
>
> I disagree, we should break whatever we dislike for a *X.0* release (+
> DeprecationWarning for some months) Sage is a young agile fast moving project
> and shouldn't be burdened with all kinds of old stuff just lying around. I
> really liked Roman's comment on this matter, i.e. that we should change stuff
> around while we can.
Well, there are enough people around that if you remove right_kernel()
or whatever will end up with broken code. Having it deprecated for a
year or two seems to have zero cost to me.
> It seems to me: Sage isn't done yet and pretending it was does more harm than
> good by making it more difficult to contribute.
Why? Can you make a concrete example at what you are driving at?
Methods with underscore are exempted from the deprecation rule since
those are internal, but while some people including you have claimed
that certain APIs in Sage are holding back progress I have not seen
anyone give me an example.
> Also, this whole 'don't break people's code' thing is a sham to some extend
> anyway since the behavior of functions changes so much even in minor releases
> anyway. Also it is those kind of changes that lead to subtle bugs that are
> hard to notice in contrast to someting like an AttributeError.
Again: Please give an example. Behavioral are either unintentional or
bugfixes AFAIK.
I think you really overestimate the pain deprecations and removal of
functionality does cause to the casual user. The GAP 3 -> GAP 4
transition with ample breakage was quite painful to a lot of people
and there are even some examples of very nice code that never moved
from GAP 3 to GAP 4 to this day, either because the author didn't care
because he kept using GAP 3 or alternatively because the author had
left academia and was no longer interested in porting the code.
Another example of when a user community to a large extend did not
move from one version to the incompatible followup release is Macaulay
2.
Overall: I am all for removing cruft, but given that we deprecated
less than 10 functions over the last 8 months or so this API cruft
must not exist to the extend you claim. I talked to Burcin about this
and he raised some concrete examples, but he might want to describe
them since my recollection is hazy.
> Cheers,
> Martin
Cheers,
Michael
> --
> name: Martin Albrecht
> _pgp:http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
> _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
> _www:http://www.informatik.uni-bremen.de/~malb
> _jab: martinralbre...@jabber.ccc.de
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
