[Axiom-developer] The 30 Year Horizon

[root]

> Tim, first I must question your monopoly on stating Axiom goals. 

Really? Why? Axiom didn't drop magically from the sky.

I picked up a collection of source files that were being removed from
commercial distribution and thrown out. The collection was not
complete and not functional.

As one of the original authors of the code, prior to its becoming
a commercial product, I was quite upset to see that all of that 
fundamental research in computational math was going to be destroyed.

It took nearly 3 years of my work to put Axiom back together.

I spent a great deal of time in discussion with others and pondering
the past to decide what killed Axiom and what might keep it alive.
I attended a research conference in France and called old developers.
Further, I spent time discussing goals that would make it interesting
30 years from now. Out of these discussions came the project goals.
That's not a monopoly, that's cooperation. I'm open to discussing
goals but not in this "we're right, you're wrong" adversarial
approach. The goals define the project and the development, not the
other way around.

After Axiom started working I set up a new project on Savannah
and Sourceforge. Based on limitations of these services I purchased
my own domain and server (axiom-developer.org). I ran a conference
on Axiom. I recreated our prior book and constructed a second book.
I lectured on Axiom. I attended conferences and recovered old
connections with people I knew and constantly try to form new ones,
such as the sage connection and the numerical mathematics consortium
connection.

I work on Axiom probably 60 hours a week and have done so into
the distant past. I spent about $4000 in the last twelve months
in server support costs, freely distributed books, CDs mailed to
people, purchasing special purpose hardware such as a MAC, attending
conferences, and trips to visit universities to discuss ideas. I've
worked to get old research brought into free code and am still 
working to free vital work such as Manuel's before it gets lost.

I created the project from nothing and brought it to where it is 
today. The project is an open source effort to achieve certain
fundamental goals, one of which is literate programming. I rewrote
virtually every file in Axiom into a document form and rebuilt the
whole build machinery to use that form. There is still much work
to be done and many ideas to explore which tighten the relationship
between the literate tools, the pamphlet files, and the gestalt
which is the future of axiom. Doing things like removing the
prototype version of the document command or splitting off the
"documentation" from the "source"  make it clear that either
you don't understand this or you don't agree with the goal.

Working under the assumption that you don't understand it I've asked
that you step back, stop slicing off "dead" portions of the project,
and try to invent, extend, and enhance the prototypes so they can
achieve the long term goals. Instead of removing duplicate
documentation, as in the asq discussion, you should propose a long
term idea, like arranging pamphlet file machinery which can share
sections, and construct new literate tools to make it work.

If, however, you don't agree with the goals then you're clearly
not working on Axiom but working on your own project under the
guise of working on Axiom. That's a fork. If this is the case
then I ask two things:
  1) Please set up your own savannah project under a different name.
     You're welcome to take any code, as per the license agreement.
  2) As a professional courtesy please stop using the Axiom name.
     I've invested a lifetime of work in defining what it means.






> In open source project all members choose goals.  If members
> goals are fundamentally incompatible, then there is time to fork.
> However, (as I belive is in Axiom case) if goals differ slightly,
> it should be possible to work togehter (compromising on lesser
> goals if needed).

Axiom is a project with stated goals. Those goals are supposed
to set the direction of the project. Axiom's been quite flexible
about methods of reaching those goals. For instance, Bill has 
insisted that the browser be the basis for future user interface
work. He's been very convincing and at this point I agree with him.
The Crystal effort and the new hyperdoc browser are trying to use 
the firefox browser as a base.

However I see the build-improvements branch completely ignoring goals.
When *I* don't understand why decisions are being made and how they
fit the future direction I have to say something fundamental is broken.

I'm watching the build-improvements branch fit Axiom to the tools
rather than the other way around. Axiom's being laid upon a 
procrustean bed, with parts being cut off because they don't "fit"
the tools. 

* I see files being rewritten because noweb can't handle them.
* I see patches to tools being rejected as inappropriate, treating
  the tool as more important that the project.
* I see files being rejected and modified because SVN has a problem.
* I see files being thrown out, like the document command, because
  they don't fit some standard.
* I see the designed structure of Axiom, rather than being implemented
  using autoconf, being restructured to fit the dictates of autoconf and
  the free software foundation.
* I see the idea of literate programming being pulled apart into
  "source" and "documentation" to fit ideas foreign to the project
  in the name of "today's standards".

Axiom is not about the tools. Axiom is about creating new ideas.
Axiom had a browser before browsers existed. Axiom created clef
with features that enhanced Axioms useability. Axiom created
object-oriented programming before the idea existed and still
does things that some other OO systems don't such as distinguishing
on return types. These ideas were ahead of their time.

Axiom needs to be ahead of its time so that it is alive and
interesting in 30 years. We can't do that by following the crowd.
Each issue should raise a question about the best way to do it
regardless of whether current tools support the idea or current
standards support the idea. Instead I see the tool defining the
chosen solution.

This isn't about compromise and this isn't about standards. This is
about inventing the future. I hear people complaining about keeping
a snapshot of GCL and how "wrong" this is to subsume other projects
(even though GCL has several projects subsumed in it). I can't
imagine the outcry when Axiom swallows ACL2 in order to support
a program proof technology, one of the stated goals.






 
> Secondly, I read many times what you wrote about Axiom goals and
> I find it still not clear -- there are nice dreams (which I share
> with you) and implementation strategy (which I doubt will work).

If you don't understand the goals of the project or they are unclear
perhaps the proper course of action is to discuss what you plan to
implement to see if it conforms to the goals rather than implement
something and claim the project goals need to compromise.

Yes, Axiom has dreams. Dreams of the 30 year horizon. Almost nothing
we see today as "standard" will be interesting or useful in 30 years.
I believed "top-down structured programming" and "decision table"
programs were the only way to program. I now know enough to know
that autoconf standards are a passing fad. They fix problems that
don't need to exist in the first place. Strong literate programming,
however, attacks a fundamental problem, namely that the research is 
now separated from the implementation. That is a fundamental flaw in
computational mathematics. We must dream and invent new ways, both
social and technical, which overcome this fundamental rift. That's
why I am trying so strongly to make my case. Axiom has a fundamental
project goal to eliminate the distinction between "documentation"
and "source". I'm trying to implement "drag-and-drop" research
papers. I'm working with Carlo Traverso, head of the math department
in Pisa to create a peer-reviewed "live", literate journal. I'm on
a program committee of a conference related to the topic.

I'm trying to craft a multi-fuel transportation system for the next 30
years and you're busy optimizing the gas engine for speed by removing
the experimental modifications.

I see that you're doing excellent work and that you're making great
strides in adapting Axiom to today's technology. And you've clearly
energized people by showing such rapid progress in optimizations and
adoption of standards. Your car will be blindingly fast.

But you've missed the goal.

Tim