Tim, Your point that the code should be well structured and documented is important for long term usefulness. However, even well documented code will not remain useful if someone does not maintain it. One of the goals of the leaders of the SAGE project should be to groom new leaders.
Jonathan On Jan 30, 11:23 am, daly <d...@axiom-developer.org> wrote: > > 3) I think the issue of crackpots and bad code dragging things down is > > not much of a problem. The reason is that it takes quite a bit of > > perseverance to get code into Sage. My experience with my Jmol > > contributions is an example. I would not claim to be the best coder, > > but think my Jmol contributions addressed some issues people had. > > And certainly the code is not yet ideal, but it does do most of what I > > understood people to want. Because of the load on people doing > > testing, it has taken months to get much feedback on it. This means > > anybody submitting code has to be willing to stick with it and prod it > > along over the long term. People who are not serious won't do this. > > My example may be a little slower than many people's because I also > > have very little time to contribute to this, but I still think you are > > unlikely to get really bad code included using the present model. > > To quote the above "This means anybody submitting code has to be > willing to stick with it and prod it over the long term". > > The real problem with Sage's development model will not show up > for a few years. At the moment most of the code being contributed > is supported by the original authors. The algorithms are complex > and some implementations are only competitive when optimized into > Cython, despite the "Sage is Python" mantra. > > The real problem will arise when these authors leave the project. > Code rots. People make simple changes. Linux changes libraries. > Who will be able to debug research-level elliptic curve code > when some minor, unrelated change breaks it? Who will even know > that it is broken? Is it broken now? > > And since the Sage code base is owned by other people with other > goals, that is, all of the spkg files from upstream projects, > the potential for code rot is much larger and the debugging > problem is much harder. Is the elliptic curve code failure due > to Sage-owned python changes or spkg changes? What happens when > python itself changes and upstream packages make the move to > python 3.0? > > The problem isn't "really bad code". The problem is code rot. > What does a programmer need to know to maintain the system? > How can a new programmer join the project and contribute? > If it is not easy now it won't be possible later. > > How do we architect systems to survive the loss of the authors? > How do we architect systems to survive the changing platforms? > Will Sage live? > > Tim Daly -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
