> > 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/integer.pyx 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. 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'? > 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. 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. > 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. 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? Cheers, Martin -- 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 -~----------~----~----~----~------~----~------~--~---
