Re: [Axiom-developer] BAD tim

[C Y]

--- Camm Maguire <address@hidden> wrote:

> "Future-proofing", IMHO, is a continous process by any living
> project.  It requires an active developer base intimately familiar
> with the system details which can only be acquired gradually through
> time.  Developing this base is the key issue IMHO.

True.  I think, though, that the literate pamphlet structure has a
better chance of robust future-proofing than any system I have heard of
before.  It takes the focus from the code to the design and ideas, and
that's about as future proof as you can get.

[snip] 

> One might make the argument that the whole thing should be written 
> in vanilla C for maximal mindshare, power, and available code to 
> learn from, but most would find this extreme I suspect.  

Heh - what better time to mention Greenspun's tenth rule:

"Any sufficiently complicated C or Fortran program contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of Common
Lisp."

[snip]
> > Not being a lisp programmer, it is entirely unclear to me what
> > advantages ASDF might have over more general tools like 'make'
> > especially considering that the Axiom source files are actually
> > literate programming documents (pamphlets), not lisp source code.
> 
> I agree with Bill here, though I don't yet grok asdf.

Well, as I understand it the lisp source code (or any other code for
that matter) is untangled from the pamphlet files into source code
files before compiling takes place, so pamphlet files don't really pose
a problem.  The advantage of using asdf (IMHO anyway) is it reduces the
dependency of Axiom on external tools and the guarantee that they will
behave the same way.  (Make itself isn't so bad I suppose, but I
shudder thinking of the headaches I have had trying to compile programs
written for different versions of autoconf/automake.)  asdf, being in
lisp, will guarantee that the build logic will function correctly on
any platform the lisp implementation does.  It is unlikely that all
build logic can be contained in asdf, particularly system interactions,
but the build logic for lisp files can be handled by asdf and is a
technique very familiar to most current lisp programmers.
 
[snip]
> > Axiom is now open source and is at least potentially exposed
> > to a much larger range of people than ever before. I believe
> > that in the future there is a good chance that the people who
> > may help to maintain and further develop Axiom will be those
> > people who started by writing Axiom library code in SPAD.
> > From SPAD it is a natural step down the ladder to programming
> > in boot. I expect that many of these people would never have
> > had any previous exposure to lisp. So forcing them to program
> > in lisp just to maintain Axiom would probably feel more like
> > "falling off the ladder" than just stepping down. 
>
> Well, witness maxima.  Lots more developer contributions on a
> project, which while magnificent in its own right, has far less 
> potential than axiom IMHO.  And all of these people are writing in
> lisp.

Heh - hopefully with any luck we will eventually be able to match all
the functionality present in Maxima, although things like the tensor
packages will take some doing.

[snip]

> Bill has a point IMHO that modern OSes provide a remarkable amount 
> of generic glue between differing programs via shell pipelines, 
> php/cgi scripting, etc.  

A problem with that though is many of those methods are not really
usable across different platforms :-(.

> But it will never be the same as integrating programs in core 
> memory for anyone wanting to push the limits of what their
> system can do.  Lisp makes this easy, and having acl2 in the same
> image opens up numerous possibilities.  Should we wish to integrate
> the theorem prover into the spad compiler, for example, do we really
> want to output Coq input through a shell pipe and parse the results?

I would prefer to have that as an option - e.g. an alternative method
for verification at user option - but I agree as a default standard
method it is undesirable since it relies on platform specific methods.

[snip]

> > Still I am hopeful that among the thousands of
> > new people who have recently been exposed to Axiom, there will
> > be some who will want to take up the challenge of dealing with
> > what's on the inside. If/when they arrive, I think it is more
> > important to have good documentation than it is to have pretty
> > code.
> 
> I agree with this.  One could easily take the position that we have
> more important fish to fry, and what we have works.  But if we are
> considering a code simplification, I feel using lisp is clearly the
> best choice from where we are now.

We could take that position, but I think documentation time is also a
good time for this type of simplification, at least when the guy
writing the documentation is also project chief and architect :-). 
Writing the kind of documentation Axiom needs is almost the same thing
as (re)designing it, in some ways - you really have to understand what
you're documenting to be able to succeed.  (Would that more of the
programming world was like this...)  Converting to lisp is relatively
trivial as a first step thanks to BOOT already compiling to lisp, and
since he's documenting as he goes the important work is getting done. 
We may want to clean up and polish the lisp code later, but that can be
done at leasure.  I don't think the current level of lisp conversion is
adding much to the effort, and also if he is able to simplify things in
a functional fashion that reduces the amount of documentation he needs
to write.  Of course, all this is ultimately up to him - my conclusion
is we don't need to worry on that count.  Now if only we could stick
him in a duplicator, or almost as good convince a university to hire
him to work on Axiom...

Cheers,
CY


                
__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs