[Axiom-developer] RE: Boot vs. Lisp

[Bill Page]

On October 31, 2005 11:34 AM C Y wrote:

> ...
> Bill Page wrote: 
> > I am glad to see that you have at least retained the
> > original boot code adjacent to the lisp. In every case
> > I very much prefer the original boot code to the new
> > lisp code.
> 
> I take it you are looking at things like interloop?
> (pg. 21, or 30 by Acrobat's counter at the bottom)
> 

Sure that's a pretty good example, but my comment still
applies to all the other cases as well. In this case the
lisp style seems especially obtuse. Perhaps Tim did not
spend much time here cleaning up the original boot
compiler output?

> My first reaction is to wonder if this is normal lisp
> indentation?  (By normal meaning the cl-indent style
> that SLIME uses?)  It seems like a large number of line
> returns in some of these, but maybe that's just the nature
> of the beast.

To me the indentation style seems motivated by the "pile
syntax" used by boot and spad. Does SLIME impose something
different?

> > *If* the changes you are making could possibly result in
> > more people being able to actively develop and debug axiom,
> > *then* *maybe* I not feel quite so strongly about this. But
> > so far, I do not see any evidence of this.
> 
> Lisp has a wide variety of tools written for it, SLIME being
> a prime example.  We don't see as much of this as might be
> because we are using GCL and thus (up until recently) miss out
> on much of the ANSI code development that has occurred.

As Kai Kaminski has pointed out, Axiom's pamphlet format and the
current build process does not lend itself easily to these lisp
development tools.

Kai has done a lot of development in lisp for the AxiomUI project.
In a separate email (still off-list, I think) he has commented
about the difficulty of using "modern" lisp tools with the Axiom
source code. I think he has the intention of writing something
about his approach for posting on MathAction, right Kai? :)

>...  The best arguments I know for using one language over
> another is the expressive power gained by using that language,
> and the support available for that language.

+1 and 0 for boot, I guess. But we could move support to +1 for
boot if we could write some good documentation about how it
works. After all, the Axiom code already contains a lot of good
examples.

> ...
> I would prefer literate well documented Lisp code to literate
> well documented BOOT code for the simple reason that Lisp has
> survived for decades.  The skill to understand and debug lisp
> is likely to be more common down the road than the same skills
> for BOOT code.

Well, BOOT has also survived for decades inside Axiom. And as
Tim Daly has said, we can think of BOOT as an early experiment
in high level dynamically typed languages similar to Python.
So as much as I do respect lisp, I have serious doubts about
the claim that "The skill to understand and debug lisp is likely
to be more common down the road". For example, I think that in
the short time that Python has existed (relative to lisp), it
currently has many many more active programmers than lisp. Of
course BOOT is not Python, but my point is that a typical Python
programmer (e.g. "me" :) has much less resistance learning BOOT
then learning lisp.

> If the literate documentation is written well the language
> of the code itself should be little more than a detail.

Of course that is true only up to a point. In writing any
documentation one is forced to make some assumptions about the
skills and backgrounds of the readers. It is usually impractical
to teach someone how to program in a particular language while
trying to describe how a particular program works.

> ... Lisp's development environment, long track record, available
> development tools like SLIME, and the potential of tools like
> McCLIM make BOOT a hard sell for me.

As you know BOOT is written in lisp, so I don't see any problem
in principle using these tools with BOOT - the complications of
dealing with pamphlet files and literate programming in lisp not
withstanding.

Regards,
Bill Page.