On Sun, 2011-01-30 at 13:52 -0800, William Stein wrote: > On Sun, Jan 30, 2011 at 9: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. > > How long do you mean by "a few years"? The major packages, Maxima, Reduce, Axiom, Mathematica, Maple, and others of that ilk are 30+ years old. So I would define "a few years" as the time it took the project to move from the primary authors to a "second generation" support role.
How long will this take for Sage? Well, as I recall you have said that you plan to move on to doing number theory work rather than system development. Indeed, I suspect that the pSage effort is a first move in that direction. However, a good computational mathematics platform is a "forever" thing in the sense that the results it gets ought to be forever valid. So given the difference between the startup timeframe and the lifetime timeframe of Sage there is a question of how to survive that transition. > > > At the moment most of the code being contributed > > is supported by the original authors. > > I don't know what you're basing this vague claim on... > > > The algorithms are complex > > and some implementations are only competitive when optimized into > > Cython, despite the "Sage is Python" mantra. > > There is no "Sage is Python" mantra. Sage is a mathematical > software system, some parts of which are written using Python, and the > interpreted user language of Sage is indeed Python. Umm...ok. It has been my impression that "Sage is Python" has been one of the major bullet points of the project. I remember a discussion about rewriting things like integration into python. But my memory is not what it used to be so perhaps I'm mistaken. > > > 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? > > I can easily think of at least a dozen people immediately. But given > that you're worried about "a few years", and you didn't define what > this phrase means, it's perhaps not possible to answer your question. There is a distinction between "those who can" (e.g. Victor Miller) and "those who will", especially if the bug is upstream. Tracing a bug through the inheritance hierarchy, into Cython, and then into an upstream linked library is not a trivial exercise. > > > Who will even know that it is broken? Is it broken now? > > Yes, it is broken. It's computer software, after all. > > > 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. > > And for exactly these reasons there are far more people involved in > fixing bugs in various parts of Sage. If you total all the people who > have worked on code that is part of Sage during the last year, you > would likely easily get over 1000 programmers. I bet you can't say > that about Axiom (and perhaps not about Mathematica, Matlab or Maple, > either.) Also, the modularity of Sage makes the problem easier in > some ways. > > > Is the elliptic curve code failure due > > to Sage-owned python changes or spkg changes? > > Sometimes one, sometimes the other, sometimes both. > > > What happens when > > python itself changes and upstream packages make the move to > > python 3.0? > > There are no Python packages at all in Sage that involve elliptic curves. I agree that you win the pedantic point about elliptic curves in python. Pick a python-implemented algorithm of high complexity and we can reconsider the point, possibly algorithms with subfield structures and uniqueness of finite fields? Surely there must be some high complexity algorithm in python that depends on upstream libraries. Choose one. > > But incidentally, when the Python dependencies of Sage fully support > Python 3, then Sage probably will too. Matplotlib is a biggie that > we're waiting on. > > > The problem isn't "really bad code". The problem is code rot. > > Both are problems. > > > 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. > > That's an opinion. > > > How do we architect systems to survive the loss of the authors? > > Was scaring off most of the contributors to Axiom a few years ago a > way for you test your theories on this? Maybe you could report on > how that turned out. Well, I suppose you could consider that the 2 forks of Axiom were motivated by "scaring off contributors". One of the forks has the same goal as Sage which, if I recall correctly, is to compete with Mathematica. Axiom never had a project goal of competition and this was a point of contention. That fork is still available but I don't think Mathematica is feeling the heat. The second fork had a goal of adopting existing code structuring standards (autoconf/config/make/make-install) and maintaining and extending the internal Boot language. Axiom has a project goal of being fully literate which conflicts directly with the idea of tiny-files-in-many-directories development. Axiom has a project goal of a single language (Lisp) which conflicts directly with the Boot language. That fork is still available but I don't know if the Lisp code has been rewritten into Boot. I suspect not, as Boot is a language nobody speaks. In both cases the forks conflicted with published project goals. If I started rewriting Sage into Lisp, for instance, we would eventually have a parting of the ways and my only alternative would be to fork Sage, as that would conflict with project goals. So that's the report you asked for. I don't know if creating a divergence from the stated project goals would be correctly characterized as "scaring off most of the contributors" but you're welcome to your own description of the process. Now that we've gotten past the axiom-directed non-issue I again ask: 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? > > It will have at least a 6-year lifespan. :-) Well I believe that you have the basis for an existence proof of your statement. :-) I believe there is an emerging discipline of computational mathematics which requires both a deep mathematical background and a deep programming background. Sage could make the claim that it is a good basis for an interdisciplinary degree or even a separate department that provides an equal focus on both subjects. If Sage, with both its mathematical and algorithmic focus, was brought forward to the NSF as a broad-curriculum basis I believe it could be funded as such. The NSF has a goal of supporting such broad educational efforts. In fact, as an open source effort, Sage offers what Mathematica and Maple cannot, namely the ability to see and modify the algorithms. From that we can train "computational mathematicians". Eventually we might not have to ask "I'm a programmer..." style questions. We need only look for a Bachelors of Computational Mathematics degree. This might require a proposal involving several universities and, unfortunately, I am not in a position to write proposals for NSF grants (I've asked several times). So I'm suggesting that there is an opportunity to think big (whole degree programs), long term (30+ years), and fundamental (how to architect for survival). Axiom, by the way, has exactly these goals. But I welcome and encourage the competition as I think it will help us all. 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
