I'm reading some of the debate surrounding literate programming in the devel logs...
One of the primary reasons mentioned for not doing LP, indeed for not writing any prose at all, is that there is no academic benefit. Having worked at 3 Universities and chased a PhD at another I can fully understand that line of reasoning. However, Axiom isn't being developed as a stepstone for academics. Research is important and will continue to play a role. But for Axiom to live there has to be a way to teach it. The target audience for Axiom is teaching. That implies that there should be proper explanations for WHY we call certain functions (e.g. the resultant for common subexpressions) so the student or future developers have a clue. The current crop of developers are experts in the field and see no need to explain why they choose to call resultant. Indeed, the attitude extends upward to all their code which, as the developer they fully understand, so that they see no need to explain any facet of their work. The focus is on "the bigger picture" they are trying to solve (and, likely, a "publish" for academic credit). Of COURSE everyone understands regular chains, right? If not, go read Kalkbrener's PhD thesis. ... as if anyone ever read a PhD thesis as part of a class assignment. Everyone understands Hensel lifting or field extensions or branch cuts. If not, go read the code (ha). So there is a fundamental divide that won't ever be crossed. That divide has long term implications. If what you care about is tenure, money, promotions, and a career then a CAS algorithm is just a tool, not a goal. Once the publish occurs it doesn't matter if the code or the whole CAS dies, which it will. If what you care about is survival and adoption of Axiom then an LP algorithm is a goal, not a tool. Literate Programming is about communicating ideas to people as well as machines. Literate Programming is about writing code that lives. Either motivation is legitimate but only one is about the long term. Tim On Mon, Aug 1, 2016 at 8:23 AM, oldk1331 <[email protected]> wrote: > To Ralf: > > > So subscription is not a big issue, I think. > > Once signin github, one can config to use email to reply to github > issues, instead of web interface. > > > Do you have a more concret pointer? Would be nice to be able to > > automatically download and commit a new issue when it comes in from some > > user. Actually, I am somewhat sure that behind the scenes github already > > ehandles issues as git repositories internally. > > https://github.com/joeyh/github-backup can backup github issues, > it's written in Haskell, and I haven't used it before. > For "automatically doing things", there are github APIs. > BTW, github wiki is a git repo itself. > > > To Tim: > > > That said, it might help to realize that a bug report is a major time > sink > > for a lead developer. People expect a fix, or at least a response, rather > > immediately. Often bug reports don't contain enough information to > > reproduce the bug. And, if you can reproduce it, you might not understand > > it enough to decide IF it is a bug. Responding to a bug report can cost > at > > least one-half day. > > The bug tacker not necessarily be a lead developer's thing, it's intend to > be community driven. False bugs posted by novice users can be quickly > replied by more experienced users. And details of the bug can be filled > when more and more users reply. > > > More issues arise if a "fix" is posted. Does the fix compile? Not > everyone > > does a full system build to check before posting. Does the fix actually > > fix the bug? Perhaps the bug is deeper than the surface fix. Is there a > > failing test case and does the fix 'fix' it? > > There's a thing called CI (continuous integration), and it can be > integrated > with github. > > > Ideally there should be someone who is a "second-in-command" that > > handles things like bugs... but I can tell you from experience that > > a "second-in-command" can undermine a project from within and is > > a very risky decision. > > If you have some experience with github bug tracker and its culture, > you will find bug tracker is actually a community thing, and very > "democracy". >
_______________________________________________ Axiom-developer mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/axiom-developer
