I think its hard to get a one-size-fits-all policy here. I am thinking specifically of the polytope code in polyhedra.py - I am very happy with the progress so far, but its still young code that has bugs and some architectural issues. In the last few months more people have started looking at it and using it, and Arnaud and Sebastien have begun contributing. The growing number of users means that of course we should avoid breaking things, but as more developers take a serious look at it I expect some substantial changes will be desirable. As much as possible that will be done on the back end, but I can easily imagine becoming convinced that an overhaul would be worthwhile.
-Marshall On Feb 10, 2:57 pm, Stan Schymanski <schym...@gmail.com> wrote: > +1 for maintaining backwards compatibility as much as practically possible. > > Mathematica 5.2, probably considered a mature program, was upgraded to > Mathematica 6.0 and broke most of my code. This gave me the final > incentive to look for alternatives as I would have to spend hours and > hours to fix my old code and understand the new syntax, anyway. That's > how I found SAGE. If SAGE started to break code with every release and > require hours of work just to get the old code to work again, I would > become very frustrated, and possibly a range of others that use SAGE for > their day-to-day work, too. So please, please, try to minimise the > amount of work needed to port people's code to new versions of SAGE. I > know, it's a cost/benefit consideration and I don't have a good > apprehension of the costs, but I wanted to add my 2 cents to the > benefits of maintaining backward compatibility. > > Thanks again for the great work done so far and for openly discussing > these questions. > > Stan > > PS: To reduce some of the costs, why not just remove deprecated > functions from the tab completion list but still leave them in the name > space? > > > > mabshoff wrote: > > > On Feb 10, 4:08 am, Martin Albrecht <m...@informatik.uni-bremen.de> > > wrote: > > > Hi Martin, > > >>>> 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. > > >> I have to admit that I don't have any concrete example, so I take your > >> point. > >> It is a somewhat fuzzy even psychological issue I think. But since I have > >> to > >> admit it is fuzzy, I take it back until further notice. > > >> I can think of hypothetical examples but nothing concrete right now from > >> the > >> top of my head. > > > :) > > >>>> 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. > > >> Sure thing: > > >>http://www.sagemath.org/hg/sage-main/annotate/b3006824b208/sage/rings... > > >> broke my code in a subtle way, i.e. it didn't crash but gave wrong > >> answers. Of > >> course, I could easily track it down and fix my code. Sure thing it wasn't > >> intended to break my code but it did. Maintaining backward compatibility > >> for > >> this function however would have meant to stick with my ad hoc decision > >> that > >> digits() should have base two. > > > Yes, in retrospect "#2796: digits default base changed to 10 instead > > of 2." was not the best decision we make. It certainly should have > > been prominently mentioned in the release notes (I do not recall > > details), but the motivation was to make the various interfaces' use > > of digits and bits consistent IIRC. > > > But I think that we are still talking about different kinds of > > backward compatibility. > > >> At least some code in Sage is not based on a lengthly well thought through > >> design process but on a developer's 'taste'. The backward compatibility > >> rule > >> would mean to stick to this decision until the end of time. > > >>> I think you really overestimate the pain deprecations and removal of > >>> functionality does cause to the casual user. > > >> Do you mean to say 'underestimate'? > > > Yes, I saw my mistake once I hit "post", but I assumed it was clear > > that I meant underestimate, so I did not send a correction. > > >>> 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. > > >> Sure, stuff like this happens (a lot), but I really like Roman's answer to > >> this: Make sure your new version is 10x more awesome than the last one and > >> people will switch. > > > Yes. The way det() vs. determinant() is handles in Maple certainly > > seems a little odd, i.e. after five or more years I would expect that > > the slow functionality would give the user some kind of indication not > > to use it. I do not have Maple documentation handy, but maybe the > > documentation in paper form/html gives the user a clue. > > >> Also, GAP3 was a mature system, Sage is not. I think we should build the > >> system before thinking about maintaining bug-by-bug backward compatibility. > > > We are not talking about bug-for-bug compatibility, we are talking > > about removing functionality that is maintainable at next to zero > > cost. If something is buggy it will get fixed and I don't think we > > ever kept something buggy around not to break anyone's code. > > > And even though GAP 3 was a mature system the breaking of > > compatibility was intentional and while I am certain GAP 4 is a better > > system than GAP 3 the changes were significant enough that some people > > did not follow even half a decade or later. We had had conversations > > off list with some GAP 3 use who did consider switching to Sage since > > the GAP 3 -> GAP 4 transition of his code was significant work and so > > he considered Sage. The reason he no longer wanted to use GAP 3 was > > not so much its limitations, but the plain and simple fact that GAP 3 > > was 32 bit and hence the limited RAM was too little to run his > > computations. > > >>> 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. > > >> Think about e.g. the planed break up of gen.pyx into elements that make > >> sense. > > > Sure, but that will happen transparently without any impact to the > > user's code. > > >> Maintaining bug-by-bug backward compatibility will be a nightmare because > >> the > >> file is pretty messy. I'm sure one can do all kind of weird things with > >> gen.pyx right now that one shouldn't be able to do. Shall we keep this > >> functionality for backward compatibility? > > > Probably not. But if someone knowingly or unknowingly abuses and > > interface code will break. Can you give an example of what you mean? I > > don't mean this in a negative way, I am truly curious :). I know that > > gen.pyx could certainly use a spring cleaning and that in general as > > the coverage creeps up we will encounter all kinds of bad code that > > has been around for a while and no one has touched it. Sage must also > > be made more consistent and in the process we will have to break some > > things - this is unavoidable. It would be nice if we had something > > like a major version jump to clearly indicate the before and after, > > but it seems that this will be hard to accomplish consistently. > > > I don't know which bugs you are referring to, but as mentioned above > > bugs will be fixed. This is not at all what from my POV deprecation is > > about and again: I am all for removing cruft and fixing bugs, but > > breaking up files and so on is not what my statements were about. > > >> 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 > > -- > ________________________________________ > > Stan Schymanski > Scientist > Max Planck Institute for Biogeochemistry > Postfach 10 01 64 > D-07701 Jena > > Phone: +49.3641.576264 > Fax: +49.3641.577274 > WWW:http://www.bgc-jena.mpg.de/~sschym > > Biospheric Theory and Modelling Grouphttp://www.bgc-jena.mpg.de/bgc-theory/ > _________________________________________ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
