[Top][All Lists]

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

Re: [Axiom-developer] [fricas-devel] documentation standards

From: Bill Page
Subject: Re: [Axiom-developer] [fricas-devel] documentation standards
Date: Mon, 29 Dec 2014 16:05:16 -0500

On 24 December 2014 at 20:31, Eugene Surowitz <address@hidden> wrote:
> Ralf is only telling it as it is,
> but I wish I could be even as pessimistic as him.

I am definitely not as pessimistic as either of you!

> This is a crisis disguised as another documentation squabble.

It seems to me the crisis actually began many years ago when IBM
abandoned Axiom as a research project (gave it to NAG) and it
eventually failed as a commercial product.

> As I see the status of PanAxiom:
> OpenAxiom - One developer - little to no activity = dead branch.

It is remarkable to me how our perceptions differ! When did you last
look at OpenAxiom? I think the effort in OpenAxiom has been mostly of
an internal nature: extensions to the SPAD language, improvements in
coding style and preparations for re-basing the system on LLVM rather
than Lisp.  Last summer FriCAS had a Google Summer-Of-Code funded
project with similar goals. But Gaby has also implemented an alternate
graphical user interface for OpenAxiom.

> FriCAS    - One developer - one developer - system being devolved.

This opinion also seems odd.  What do you mean by "devolved"?  As I
see it from the point of view of mathematics, FriCAS is the only
project that has made any substantial progress. FriCAS is also the
only project that supports Aldor as an alternate library compiler.
Both FriCAS and OpenAxiom are (or were recently) used in teaching and
research.  This sounds more like evolution to me than devolution.

> Axiom     - One developer - when he goes Axiom goes.

I think that you are probably right here that "when he goes the
[original] Axiom project goes". I am not aware of anyone motivated to
continue the work in the direction that Tim Daly has taken it.

But I do agree with the implication of your initial characterization
of the problem as being "disguised as another documentation squabble".
I no longer think that (lack of) documentation is the central issue.
It may sound rather arrogant to say so, but it seems to me the problem
is more likely to be simply that Axiom was and still is ahead of its
time: the majority of computer algebra system users simply do not yet
have the level of sophistication or necessary experience to appreciate
it. This is not likely to be changed much by the presence or absence
of documentation or even tutorial training materials.  To see this I
think one only needs to look at the marketing strategies of the
commercial computer algebra systems.

Oddly perhaps things were different back when Axiom was under
development at IBM; then (1970's) it seems that nearly everyone who
worked with Axiom was a sophisticated expert. There has been an
explosive growth in the interest in computer algebra systems but very
little progress in passing on that early expertise to the next

So the original Axiom open source project now seems of only marginal
interest to me.  Nothing that Tim is working on right now is
particularly relevant to how or why I remain interested in Axiom (or
more specifically, FriCAS)..

> The basic issue that I see is that PanAxiom is really a
> software engineering project before it can continue to live.

No, I think the days when we could usefully and optimistically speak
of "PanAxiom" are gone.  There are now clearly three separate projects
with a life (or death) or their own (four if you want to count Aldor).
I also disagree that any of these projects are fundamentally "software
engineering projects" except maybe Aldor.  As I see it Axiom as a
concept is still fundamentally a research project - as is the entire
field of computer algebra as a whole.  The most that software
engineering can offer is minor improvements in technique.

> The literate approach that Knuth created has no answer to
> mass of existing code problem: that is, he didn't think out
> a mechanism for the curious to dynamically add insights to
> the system's code even if literate.  Inverses are sooo.. hard.

Do you mean some kind of "reverse engineering"?  I think you are right
that literate programming methodologies do not make this any easier.
Once I thought that a user supported and maintained web site (wiki)
might be an answer to this.  Although the FriCAS project still
supports the wiki that started in the early days of the original Axiom
project, I would say that it also counts as a (mostly) failed

> Oh, and PanAxiom has no systematic development of basic numerology.

I suppose it is worthwhile to ask what you might mean by "numerology"?
Obviously not ...  Maybe
"number systems"?

Bill Page.

reply via email to

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