[Axiom-developer] On the ideas of building everywhere and "just working"

[C Y]

I've been thinking a little about the problems encountered with
bundling everything we need into one place and also about the desire
expressed by Tim that Axiom "just work".  If I may, I'd like to put
forth a discussion on these ideas and see if it can help define
priorities/methodology for us as a project.  I have no idea if this is
useful or not, but I am trying to organize the arguments.

Everything starts from goals, and many of them work against each other.
 For example, I think two reasonable goals for Axiom are:

a.  Utilize freely available work to enhance Axiom's functionality.
b.  Work without problem in a broad range of environments.

The problem, of course, is that often using external tools impose
increased demands on the quality assurance that must be done per
release, as there is no guarantee that external tools have not changed
under Axiom in a way that might break something.  Making Axiom work
with multiple cases of external program behavior is a net increase (a
large one) in the QA work that must be done per-package.  Not to
mention sometimes an upgrade to an external tool Axiom needs to have is
not present and will not or cannot be installed.  However, by the same
token, using external libraries and tools can save Axiom itself vast
amounts of effort which would constitute re-invention of the wheel. 
So, roughly, speaking the problem is to find the minimum point in:

  Total Work = Time spent fixing external tool problems -
               Time gained by not duplicating effort +
               Time spent coding logic "in project."

So, what are the approaches?

1.  Include all programs you might need in your own tree and maintain
them as part of your tree, up to some limit. (Current approach)
2.  Check for working required software when building/running, and stay
in sync with external tool changes as much as possible. (Autotools
approach).
3.  Minimize all external tool needs and supply as much logic as
possible within the development framework. (A LOT of work.)

Tim has gone for #1 I think because it is the most platform independent
way that can get us up and running quickly.  I must confess I have had
the most luck building the gold branch out of any of the various
iterations.

Gaby is working on the #2 approach, with an optional fall back to #1. 
This holds considerable promise but a concern is that it makes it
easier to avoid the "literate programming" part of building and using
Axiom, as Tim has defined it.  Opinions differ on whether this is a
serious problem or not - it undoubtely makes it easier to create a
working Axiom environment for more users if piecemeal building is
possible, but it may promote source code development without the
accompanying human explanation.  This is particularly true with
relatively small platform specific "tweaks" which are sometimes made.
The temptation to not document such "annoyance" changes is greater than
with the math code, I think. The issue is in some sense "one off" from
the interesting problems and may in fact be obsolete in a few years (or
even less).  Why then sink the time into documenting it?  (Yes, I know
the reasons, but it's a question that will be asked.)

The #3 approach I don't think has a lot of serious support, just
because of the sheer magnitude of the task.  While in one sense it has
the potential to simplfy things in the long run, the amount of work
needed to bring the code base over to something less "sprawling" in its
requirements is frightful, and would require building a lot of
"reinvent the wheel" in terms of supporting libraries/routines.  I
still contend that this work is something that will need to be done
anyway to make Axiom fully literate, but undoubtedly the incremental
approach is more realistic in a limited resources situation.

That said, I would like to add one more thought to the mix.  With
regards to having Axiom "just work", I think the difficulty of reaching
a "just works" stage in a program and maintaining it can be directly
related to the stability and extent of the "tower of software" needed
to run it.  The term "tower of software" I heard back on the Maxima
list (I believe from Dr. Fateman) and I find it a very useful
illustration.

Let's say, for example, that I wish to prove some properties about
algebra code in Axiom.  For those proofs to be meaningful not just in
theory "yes if your software platform works as described this will
work" but in fact "yes if your hardware works according to specs this
will work" the entire software stack from the machine level on up (and
really the hardware design itself as well) needs to be formally
verified.  In practice this is not currently something that is
workable, because I am not aware of any system ever designed with that
level of verification, but it is a very interesting goal.  If such a
platform were to emerge, the next question is "what would need to
happen for Axiom to make use of it?"  Axiom itself would need proof
decorated code (what that means is a bit fuzzy to me, but we'll go with
it) and it would need to run on a Lisp implementation that was also
verfied.  The Lisp implementation would need to run on the formally
verified platform.

That sounds like a lot of work, but imagine how much worse it gets if
we expand the tower of software beyond this minimum.  If we add C or
Fortran libraries, suddenly the issue of proving that code correct
becomes important, and the correctness of the C and Fortran
implementations (e.g. compilers) becomes important as well.  In this
situation, every non-essential language/library/etc. becomes a target
for elimination due to its added formal proof burden.  The cost of a
large/wide tower of software becomes exceedingly high.

Of course proving sofware properties is an extreme case and is not
(yet) a practical concern of Axiom, but the point remains.  Every new
language, library, and external program we introduce into Axiom
increases our burden of support - even if we don't bundle it into the
source tree, our reliance on it means that if it breaks and no one else
is there to fix it it becomes our problem.  And external tools will not
be literate, by and large.

This is one reason I like the idea of implementing as much
functionality as possible in Lisp - if someone starts a project
targeting formal verification of everything down to the machine level,
only one language implementation would need to be considered for
verification problems.  Another is that once we are in Lisp, it's like
being on the Java virtual machines - the portability problems are
abstracted out to another level and we can focus on features.  (The
current exception to this is graphics but that's another discussion,
and if we don't have an "official" GUI beyond the command line it's not
a problem anyway).

I tried to find some way of illustrating the relative complexity of
"include everything" vs. "minimize the tower of software" - I don't
know if it really helps, but I put together a graphviz file to try and
get a handle on the "this depends on this which depends on this"
issues.  I don't think it's fully correct, but it's a start.  There are
two, one for the "current technology" situation and one for a "nice
theoretical" situation.  I know there are holes - for example, the
requirements to view a browser based interfaces aren't considered.  But
maybe someone can build on it.  To turn them into postscript files: 
dot -Tps TowersOfSoftware.dot -o TowersOfSoftware.ps

My personal preference is to build towards the minimized tower of
software, but I can see the viewpoints of the other methods too. 
Anyway, just thought I'd see what other thoughts people had on this
subject.  Maybe there are even studies on it?

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

TowersOfSoftware.dot
Description: 3597048513-TowersOfSoftware.dot

TowersOfSoftwaresmall.dot
Description: 3054299682-TowersOfSoftwaresmall.dot