On 30 April 2015 at 16:06, William Stein <wst...@gmail.com> wrote: > On Thu, Apr 30, 2015 at 12:34 PM, Bill Page <bill.p...@newsynthesis.org> > wrote: >> ... > You stated 'that the Sage developer emphasis on "doc tests" has > resulted in any fewer errors or problems in Sage in comparison to > other systems.' I'm not sure if I should respond to this, but I'm > going to.
Yes, I guess we do so at our own risk. :) My intention was not to flame but rather just expressing my reaction after reading http://sagemath.org/doc/developer/git_trac.html#chapter-git-trac and considering the possible fate of my 3 line patch if I don't find the time to do things this way. It just occurred to me that for such simple things there should be simple solutions. And I guess there is: find some else to do it. I am serious that perhaps this is not such a bad thing provided of course that there are enough people willing to do this. > Note that Sage is mostly *interpreted* so having extensive > doctests is critical to maintain any possibility of sanity over time > and with a large number of developers (512 people listed at > http://trac.sagemath.org/ right now). I am (or at least once was) one of these people registered trac but I was never comfortable with the workflow and review process. As a system for reporting bugs and submitting patches it seemed OK but now things seem more complicated. It is a good thing that Sage has attracted enough developers who are fluent in this process. > I won't claim that Sage's > doctests make Sage have "fewer errors or problems" than the other > systems you use (they surely have their own approaches to testing). > However, I absolutely claim -- and I'm sure anybody with nontrivial > Sage development experience will agree -- that the Sage testing > standards are critical to Sage having any chance of survival and > usability at all. It's entirely an internal issue. OK. I don't doubt your sincerity but like a lot of things in software development I find it hard to imagine how your claim could be evaluated objectively. > Please also note that Sage is mostly interpreted and not statically compiled > like > some software, which further increases the need for extensive testing. > > Also, the testing in Sage serves an important dual purpose -- it makes > it easier for people to actually use Sage -- instead of trying to read > documentation and deduce via logic how to compute something, you > have the option to try an example that does work, and adapt it to > your problem. In contrast, I just tried browsing the FRICAS api > documentation [1], and couldn't find a single example. That's true however this web site is only the result of one FriCAS developers effort to make FriCAS documentation more accessible. To really learn to use FriCAS I think it is important to learn to use the built-in FriCAS browser (hyperdoc) and of course to read the book. > If I wanted to just play around a little to see how things work > following [1], it would be incredibly difficult for me. Sure but I still experience exactly the same feeling when I sit down to try to do something in Sage. > > There are also many people who have contributed massively to Sage by > working on porting, valgrinding, etc., who simply wouldn't have been > able to contribute anything of value without the test suite existing. I am certainly not arguing against the concept of testing or the importance of a test suite. My reaction was just in how it is treated as an integral part of the sage-trac process. > > [1] http://fricas.github.io/api/genindex.html > Bill. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
