axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Axiom project goals


From: Tim Daly
Subject: Re: [Axiom-developer] Axiom project goals
Date: Tue, 2 Aug 2016 09:03:11 -0400

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 <address@hidden> 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".


reply via email to

[Prev in Thread] Current Thread [Next in Thread]