Re: Axiom project goals

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Axiom project goals

Tim Daly
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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/axiom-developer
Reply | Threaded
Open this post in threaded view
|

Re: Axiom project goals

Tim Daly
In the spirit of the game I'm moving the buglist to be a full
literate volume, published like all the others. This will allow
automation, extraction and testing of various bugs
during build time and keep the bug list up to date and public.

I'm also re-ordering it so that the various bugs/warnings/etc
are grouped logically (e.g. interpreter, category, domain, etc)
rather than the prior "stack by most recent" orientation. That
will make it easier to find duplicates as well as simplify the
focus of any debugging effort.

This will be followed by a review of all outstanding bugs to
see if they are still valid.

There goes another few weeks.



On Mon, Aug 1, 2016 at 8:23 AM, oldk1331 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/axiom-developer
Reply | Threaded
Open this post in threaded view
|

Re: Axiom project goals

oldk1331
Bug tracker in book form? I don't think that's a good idea.

On Fri, Aug 5, 2016 at 4:17 AM, Tim Daly <[hidden email]> wrote:

> In the spirit of the game I'm moving the buglist to be a full
> literate volume, published like all the others. This will allow
> automation, extraction and testing of various bugs
> during build time and keep the bug list up to date and public.
>
> I'm also re-ordering it so that the various bugs/warnings/etc
> are grouped logically (e.g. interpreter, category, domain, etc)
> rather than the prior "stack by most recent" orientation. That
> will make it easier to find duplicates as well as simplify the
> focus of any debugging effort.
>
> This will be followed by a review of all outstanding bugs to
> see if they are still valid.
>
> There goes another few weeks.
>

_______________________________________________
Axiom-developer mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/axiom-developer
Reply | Threaded
Open this post in threaded view
|

Re: Axiom project goals

Tim Daly
> Bug tracker in book form? I don't think that's a good idea.

Because?

I can already see benefits.

Organizing bugs in book form makes it easier to search. The
chapter (e.g. hyperdoc), section (e.g. content, typo, wishlist),
and cross-reference (e.g. to the other books) make it easier
to find already-reported bugs.

The ability to intertwine words with the bugs means that what
appears to be a bug (e.g. lack of simplification) can be explained.

The ability to extract literate chunks means that the testing of
bugs can be automated. They can be extracted at build time,
added to the test suite, and run with the other test cases. Using
Axiom's --SRE testing markup, the "expected bad results" can
be tested against the actual results to highlight changed behavior.
So a bug that "succeeds", that is, one that still exists, can be
tested to see if the behavior has changed ("fixed").

Known bugs are just another volume in the series. They can
be cited and cross-referenced from the interpreter or the algebra.
So when an algorithm has a known bug but no-one can agree
on the "proper fix", the discussion can be cited. This will be
especially useful in the Computer Algebra Test Suite where
bug are mostly "limitations" (e.g. can't simplify nested sqrts).

Promoting bugs to book form also means that they get regular
review. They are not "someplace else", such as a bug tracker
on a website. Submitting a bug report is the same process as
submitting a patch.

I've always thought of bugs as something-but-not-code. I have
come to understand that all systems always have bugs. Why not
make bugs "first class", just like code?

On Fri, Aug 5, 2016 at 6:58 AM, oldk1331 <[hidden email]> wrote:
Bug tracker in book form? I don't think that's a good idea.

On Fri, Aug 5, 2016 at 4:17 AM, Tim Daly <[hidden email]> wrote:
> In the spirit of the game I'm moving the buglist to be a full
> literate volume, published like all the others. This will allow
> automation, extraction and testing of various bugs
> during build time and keep the bug list up to date and public.
>
> I'm also re-ordering it so that the various bugs/warnings/etc
> are grouped logically (e.g. interpreter, category, domain, etc)
> rather than the prior "stack by most recent" orientation. That
> will make it easier to find duplicates as well as simplify the
> focus of any debugging effort.
>
> This will be followed by a review of all outstanding bugs to
> see if they are still valid.
>
> There goes another few weeks.
>


_______________________________________________
Axiom-developer mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/axiom-developer