> This thread is first and foremost about reducing the friction involved in making code that depends on the Sage distribution available to the world. > Based on feedback I get from users, this friction is a very, very significant problem to the growth of Sage.
Let me recall something that comes up often, but that I haven't seen yet in this thread nor at the Sage days. Just two weeks ago I was said: "We are going to make our student write code in Magma, because we want something future proof. We've used Sage a couple of times before, but each time Sage updates break our code in <1yr, and it takes too much work to know why and update our code". Let me stress that these are highly skilled researchers who develop amazing software and have a very deep knowledge about programming. One of them develops a library that is a core piece of infrastructure for Magma, and which is responsible for a good fraction of the benchmarks where Magma crushes Sage. If we could make these people stick to Sage, I can only imagine benefits for us. I have this experience myself, though, being more involved in Sage, I make the effort to patch my code to work with the latest stable. At some points in time, it has even been impossible to have code that works both with the latest stable and the latest beta (and/or the version in SMC). This is something that should only happen at major version bumps, if ever. Of course, this is not easy to solve, but having a more modular distribution (at least for some meaning of "modular") might help. -- Luca -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
