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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to