On 10/20/20 11:32 AM, Nathan Dunfield wrote:
Yes, I am all too well-aware that all code requires some level of maintenance. The question is how often and how much, and I don't think the fact that maintenance is inevitable is a good argument for increasing the amount required unnecessarily. Especially in the context of software used by mathematical researchers. Enough trivial changes add up to something nontrivial, and my main point is that for a lot of Sage users, something like this is not trivial and has the potential to turn mathematicians away from Sage to one of the "M" tools that are likely more stable (I'm not sure about that, I of course avoid the M's when at all possible ;-).
This is a bit of a digression, but I personally take the Linux kernel approach with my own published code. The SageMath website can make whatever guarantees it wants about backwards-compatibility, but the reality is -- especially in a dynamic language -- that it's quite impossible to not break anything at all. Nobody has time to deprecate every buggy result, and many things simply can't be deprecated.
But, SageMath is open source. And like the Linux kernel, it's pretty accepting of strange research algorithms useful to like five people on the planet. We also have an *enforced* policy of not breaking existing doctests... which means that we can't break library code, since "all" library code is tested.
So, when I publish an algorithm, I add the code to Sage itself. The output in the paper may become obsolete, but when readers follow the reference, they should get some nice, up-to-date, working documentation and a potentially improved implementation.
-- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/c8785199-3c8f-9de8-8a73-74438bccfc91%40orlitzky.com.
