Re: [Axiom-developer] Terms of Surrender (was: BAD tim)

[William Sit]

C Y wrote:
> I'm
> just saying that in an open source project discussion without code
> ultimately goes nowhere.  I don't think that's a danger here, but it
> has been known to effectively kill projects in the past.

Is that (projects getting killed) necessarily bad?

> > The running of Spad depends on the underlying modules. Having to
> > backup to where we are now in three years' time is not progress, but
> > of course, I hope this will never happen.
> 
> Spad does of course depend on the underlying modules, but shouldn't it
> (in theory) not need to care how they are implemented?  Sort of the
> same way ANSI lisp code should run in any ANSI lisp implementation,
> without worrying about how the enviroment underneath it is coded up?

True, but we are talking about maintaining the system, not just the algebra
code. There are bound to be modifications, if only because versions of Lisp has
changed.
 
> > In this case, it may be fortunate that we have a working code as
> > backup, but I bet that if we were to need to backup, the Boot code
> > would have been broken.
> 
> Some of the newer mathematical code might depend on language
> capabilities that the older Boot code couldn't support, but I would be
> surprised if things diverge that badly, particularly if we are able to
> use Aldor as the primary language for new work.

Even my limited experience tells me that codes will break if allowed to stay
stagnant.
 
[snipped]

> If I'm not mistaken, the approach Tim has taken so far with vol5 is
> resulting in documentation that applies equally well to Lisp and Boot
> code - at least, the level of documentation he has started writing.  If
> it helps, perhaps the current state of included auto-generated lisp
> code could represent proof that the current documentation is in fact
> applicable to both Boot and Lisp code (where the documentation covers
> such things instead of SPAD code) since they are demonstrably identical
> at this stage.  If you parse out the lisp includes and build the book
> again, viola - documented boot code.

Glad to know that.

[snipped]
 
> > I think your proposal is well worth considering by both sides. So
> > far, we have heard how bad Boot is and how powerful Lisp is. I am
> > waiting for Tim to tell us what the eventual architecture the Axiom
> > system will be in his vision and how Lisp supported that vision. I
> > can still be convinced his way (and I will not commit myself to
> > coding for either camp -- that's full disclosure).
> 
> Thanks!  I have always heard Lisp is real good at redefining itself to
> particular tasks, so perhaps this is a good opportunity for it to do so
> - that would leave pure lisp abilities for things like FFIs with
> libraries and graphics, and still allow targeted coding for SPAD
> purposes.  Eventually of course the ideal thing to do is rewrite all
> relevant foreign libraries with the relevant research information in
> Spad or Aldor, but for things like the CERN libs that could take some
> doing :-).
> 
> The overall architecture of the Axiom system is definitely interesting,
> even without language questions :-).  On Maxima I starting trying to
> use Graphviz to map key relationships between systems, with the idea of
> eventually creating successive nested graphs that would constitute a
> roadmap of the entire system.  I didn't get much further than the
> toplevel control loop, but even that was useful (to me anyway):
> http://maxima.sourceforge.net/toplevel.png

Tim has done that type of analysis on Axiom more than anyone else. But what I am
looking for is even coarser: just the major components and how Lisp helps.
 
> My original vision was that each package would have one of these types
> of graphs as it's second page (sort of an "inside the cover" addition
> if it were a book) that would allow a new programmer to immediately get
> a feel for the workflow of this particular part of the system, and what
> parts it relates to.  Maybe this could apply to pamphlets.  Also it
> might allow programmers unfamiliar with how the system works to quickly
> zero in on which functions were possibly relevant to a particular bug.
> For real fun perhaps these diagrams could be autogenerated by the
> SPAD/Aldor parser as part of the compile :-).  Of course, higher level
> ones might have to be done by hand, depending on how smart the output
> routines were...

That would be useful for Tim's Crystal vision.

William