On Sun, Aug 29, 2010 at 3:09 PM, Dr. David Kirkby <david.kir...@onetel.net> wrote: > On 08/29/10 09:56 AM, Tim Daly wrote: >> >> tl;dr old curmudgeon flaming on about the dead past, not "getting it" >> about Sage. >> >> Robert Bradshaw wrote: >>> >>> >>> In terms of the general rant, there are two points I'd like to make. >>> The first is that there's a distinction between the Sage library >>> itself and the many other spkgs we ship. By far the majority of your >>> complaints have been about various arcane spgks. Sage is a >>> distribution, and we do try to keep quality up, but it's important to >>> note that much of this software is not as directly under our control, >>> and just because something isn't as good as it could be from a >>> software engineering perspective doesn't mean that it won't be >>> extremely useful to many people. Even if it has bugs. We try to place >>> the bar high for getting an spkg in but blaming the Sage community for >>> poor coding practices in external code is a bit unfair. I hold the >>> Sage library itself to a much higher standard. >> >> The point that "software is not as directly under our control" is not >> really valid. > > Agreed. > >> The statement that Sage tries "to place the bar high for getting an spkg >> in" isn't >> actually much of a claim. I've watched the way spkgs get voted onto the >> island >> and it usually involves a +1 by less than half a dozen people. Would you >> really >> consider this to be placing "the bar high"? > > No, I don't think it places a high bar either. > > It is probably seen as a high bar by those that do not have a software > engineering background. To those that do, I suspect they would conclude the > same as you and I. > > Take a look at Sqlite's testing proceedures. The test code is 647 times > larger than the actual code for the database. I doubt that attention to > detail would have been very useful in Sage development. > > One needs to find a sensible compromise.
Yep. One quote I like is "Add tests until fear turns into boredom" (not sure who that's originally from). Of course relative tolerance of fear and boredom can vary from individual to individual. >> I'd consider developing a >> test suite, >> or an API function-by-function code review, or a line-by-line code >> review to >> be placing the bar high. > > Yes, though one does need to be practical about it. Those sorts of things > are essential in code for specific applications (medical, aeronautical), but > are probably not practical for Sage. I doubt anyone at Wolfram Research has > ever gone through every line of ATLAS code, but they use ATLAS. +1. We certainly have room for improvement here (and kudos to you, David, in particular for doing a lot of work in cleaning/testing what we do have). It's a question of allocation of limited resources. >> Still to come will be the "code rot" issue. Open source packages tend to >> have a >> very small number of active contributors. Projects tend to stop when >> those people >> drift away. > > I think this can be avoided to some extent by not adding to the core Sage > library very specialised items that are only of use to a few people. Just > because person X developers some code during his PhD, no matter how useful > that may be to him, I don't think it needs to be a standard part of Sage if > its only going to be used by very few people. I agree. The gulf between standard and optional is too large. >> Now that the wave of new spkg adoption has slowed I expect to see a >> growing >> need for maintaining "upstream" code. By *design*, their problems are >> now your >> problems. Who will debug a problem that exists in 500,000 lines of >> upstream code? >> Who will understand the algorithms (e.g. sympow) written by experts, >> some of >> whom are unique in the world, and debug them? > > How do you expect Wolfram Research, Maplesoft and similar deal with such > issues? They must hit them too. I suspect they have a few nightmares with > this, but the best way is probably to have decent documentation. If code is > well commented, and has references to papers where the algorithms are > published, then it sill probably be maintainable. They don't have a public bug repository, show their code, or let people compile it on their own machines. As an employer, they have more power to tell people what to work on. And they've got a lot more experience at it. Whatever their "secret," I doubt they'll divulge if we ask them :). In what I've seen, they are also aiming at (or at least hitting) a much smaller target audience in terms of cutting edge research. - Robert -- 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
