Re: [Axiom-developer] literate programming and Claerbout's Insight

[Stephen Wilson]

Hi Bill,

Just trying in these posts to get a few concrete suggestions on how
the problems raised can be solved. 

[...]
> ... the majority of the new Axiom users would seem to prefer to be
> able to use Axiom in essentially the same way as if it were a
> commercial product. If it doesn't work rather quickly for them, then
> they just look elsewhere rather than joining the project and trying to
> improve it. Only a small minority are willing to do that.

How does noticing this help the situation?  Are new users more likely
to join in and help improve the project when they get the impression
that the system `just works'?  Certainly this is true for the
algebra, but for the rest of the system?  What is the best approach to
getting a high quality compiler/interpreter/hyperdoc etc working which
does not require rethinking the current system or building new tools?

> > > | As for relic technology, do you mean Axiom's current Algebra
> > > | algorithms or use of Lisp?  Or maybe the 1980s look of Hyperdoc
> > > | and graphics?
> > >
> > > Almost all of those.
> >
> > Well, we've had the Lisp issue out many times before.  As for the
> > others, I agree too - but fixing them is non-trivial.
> >
> 
> But the point is that these would better be addressed *first* before
> settling in to even harder to achieve long term goals like making all
> of Axiom a literate program.

What is harder: Fixing the system and documenting it along the way. Or
fixing the system and documenting it afterward?  I believe the second
approach is much more difficult.  It is almost equivalent to fixing
the system twice.  If you think literate programming should be a long
term goal but not an immediate goal, how do we plan today for the
things we want to do tomorrow without complicating future plans? 


[...]
> I still believe literate programming to be a worthwhile long term
> goal - especially for the the Axiom library (Spad) code. I am just
> not convinced that we really know how to do it.  And I don't think
> this should stop the further development of Axiom until we learn to
> do it right.

How do we learn how to do it without trying?

[...]
> I seriously doubt that this "literate re-write" will ever really
> occur. Instead it seems most likely to me that improvements will
> continue to be made via bug fixes and by major new contributions by
> researchers and dedicated Axiom users if there are a sufficient number
> of these so that chances of someone both motivated and qualified is
> sufficiently high.

I partially agree.  For example, for myself, it is much easier to
write new code in literate form than it is to re-write the existing
system into literate form.  Bug fixes and so on can be accompanied by
modest documentation which can be `reworked' over time into a polished
form if the code it describes is not superseded by other work.
Such modest documentation is not that much different than writing
normal code and supplying a decent paragraph of in-source comments.

[...]
> > CAS developers, at the moment - those interested in what a CAS CAN be,
> > rather than what they are today.  We are building the tools.  They must
> > be built before they can be used.  Who our audience will eventually be
> > depends entirely on what we can create.
> 
> I think this is completely the wrong attitude. It is the "If you build
> it, they will come." approach. (Do you remember that movie of a decade
> ago about the guy who built the baseball diamond on the middle of his
> corn field? What was the title?) Even in the big wide world of the
> Internet I do not think there is any reason to believe that this
> approach will work.

What is the right attitude?  Should I stop building anything more and
just contribute bug fixes?  I might be willing to do that if someone
was paying me.  Perhaps you have an answer which is both productive
and enjoyable?


Thanks,
Steve