Why is this entire thread not on sage-flame? What does software engineering, documentation, test code, etc. have to do with "Creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab."?
I found the entire thread really amusing. I would parody the hell out of it, but there are people here who I do not want to offend. Software often seeks to be: 1) Fast 2) Correct 3) Comprehensible 4) Complete 5) User friendly 6) Developed in a timely manner Open Source projects also have the aims: 7) Attract developers 8) Compete with commercial products These are all competing aims. No one is going to rewrite all the underlying C libraries in Python, ever, because of aim 1. No one cares about broken spkgs because of 4, 6, 7. No one is going to take the time to learn about software engineering, program proving or even literate programming because of 6, 7 and often 1. Any software project which chose Python as the primary language certainly doesn't really care about 1. Any project which uses a whole pile of inconsistent C libraries written by mathematicians, without proper test suites, certainly doesn't care much about 2. Any project which doesn't demand that all code be written in a literate style, fully documented, doesn't really care about 3. Any system which is developed by individuals implementing their fancy, maybe whatever their research interest currently is, doesn't really care about 4. Any software which gives a Python stack trace when something goes wrong, probably didn't care that much about 5. Any project which isn't completely modularised and which requires code review and merging of patches into a single monolithic code base probably didn't care about 6. Any project which doesn't immediately merge contributions of contributors before they bit rot isn't really hitting number 7. Any project which has very few sources of serious funding certainly might not manage 8. Why attack Sage. It is what it is. Why defend it. It certainly didn't/ doesn't get everything right. One thing is for sure. Whatever is wrong with Sage, it is almost certainly too late to fix it. Whatever is right with Sage certainly made it popular. If you want to make Sage seriously innovate to solve one or more of the above, you need a *large* group of like-minded volunteers who can help you. You won't do it on your own, no matter how many years you work, nor how hard. Many of the things Tim and David say resonate with me. I'd really, really love a tremendously efficient, well-documented, reliable, Open Source mathematical project. Having seen how insanely difficult even just goal number 1 is for just the domain of arithmetic, I honestly think we haven't got a chance. Not ever. The expertise don't exist in sufficient quantity. And even those with the expertise, don't have the time. So, looks like we are stuck with what we got. By the way, does anyone know what the current state of program proving is? How does this work? Does one write the proof by hand then formalise it in code in a formal system until it "parses"? Can someone give me some references on this. I am genuinely interested. I've read some comments about SML being good for program proving (why?), and that the Haskell type system amounts to giving a "proof" under some circumstances. But it is baking my noodle how any of this has anything to do with proving programs, especially in mathematics. The "monad" idea in Haskell gave me some hope, because it sounds mathematical, but I simply didn't understand it, at the end of the day. Moreover, what is the current state of artificial intelligence, with respect to automated theorem proving? Do we understand anything at all about the process which leads to the discovery of proofs? I can't shake the feeling that language design is intimately interwoven with these concepts. But I can't figure out if it is just because Lisp was developed as part of a funded AI programme, or if there is something more to it. Is there more to it than that a computer language is a "way of interacting with a machine", which is a kind of "artificial intelligence"? Will Sage eventually be artificially intelligent? Bill. On 29 Aug, 23:09, "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. > > > 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. > > > At the moment I see Sage writing test cases for > > python > > code but I don't see the same test cases being pushed into the spkgs. > > Even where > > external test cases are available (e.g. the computer algebra test suites > > for Schaums > > and Kamke) I don't see them being run. > > That is changing. I've gone through the packages and created a list of those > that are missing the spkg-check files that will allow the self tests to be > run. > > http://trac.sagemath.org/sage_trac/ticket/9281 > > The new Pari package will run the test suite if SAGE_CHECK is set to "yes". > I've > personally sorted out a couple of packages recently and are just doing > cliquer > now. > > Robert agreed with me the other day that running short test suites from > spkg-install (i.e. every build) was reasonable. > > > The conclusion that "blaming the Sage community for poor coding practices > > in external code" as being "a bit unfair" is not valid. > > Agreed. The Sage community, in the most general sense, made decisions. > > > 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. > > > 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. > > > Writing new code is always fun. Maintaining old code you didn't write is > > painful. > > But from an end-user perspective "it is all Sage" so all bugs are "Sage > > bugs". > > That may seem unfair but the end-user won't know or care. > > Exactly. > > > The belief that Sage will gradually rewrite the code pile it has (5 > > million lines?) into > > higher quality seems odd. > > As you say, it will not happen. > > > > > > > So at the time Sage was being developed there *were* standards in place. > > You seem > > to feel that Sage was started "pre-standard" (2005?) and "pre-referee" > > (ISSAC?). > > I see reviews of bug fixes but I don't see reviews of spkgs. We are now > > over 50 years > > into the development of computational mathematics and Sage has the goal > > of competing > > with systems developed in the 1970/1980s, over 30 years ago. This would > > be a great > > thing if Sage were to deeply document the algorithms, develop the > > standards, and/or > > prove the code correct but I don't see anyone advocating any of these. I > > don't see anyone > > advocating alternative ideas that would "raise the bar" in computational > > mathematics. > > Given what you said a few days back, that there were few institutions teaching > computational mathematics, would you agree with my point that getting more > computer science skilled developers into Sage is a step in the right direction > to raising the bar? > > Architects design buildings. Builders build them. The architect and the > builder > communicate and the result is decent building. > > > Tim Daly > > (curmudgeon and rjf wannabe) > > Dave -- 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
