[Axiom-developer] Boot vs. Lisp

[C Y]

--- Bill Page <address@hidden> wrote:

> Tim,
> 
> On October 31, 2005 7:05 AM you wrote:
> 
> > > 
> > > A related topic: I recall you saying that you have once 
> > > rewritten all the boot code in lisp? Does this code still
> > > exist?
> > 
> > nope. huge discussion. lots of religion. bad timing and all 
> > that rot... so i simply erased it. it's coming back again
> > though. look at src/interp/bookvol5.pamphlet in --patch-46
> 
> Argggh!!! Bad Tim. Bad Tim.
> 
>   Documentation GOOD.
>   Rewriting boot into lisp BAD.

Heh - I'm betting some developers out there are getting deja vu
feelings right about now...
 
> Here's the new bookvol5.pamphlet on MathAction:
> 
> http://wiki.axiom-developer.org/axiom--test--1/src/interp/Bookvol5

Great! Thanks!  *grabs pdf*

> 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)

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.

> As I said earlier several times, I think what you are doing here
> is wrong. I wish I could call on the spirits of the Axiom Founding
> Developers to help prevent this forking of the Axiom code. So far
> open source Axiom has remained very close to the prior commercial
> release and also to most of the other versions still "out there".
> I think the commercial release still provides a very valuable
> baseline against which to measure the open source release.

But since those versions are commercial, with source code invisible,
how are they useful except possibly for feature comparisions and
consistency?

> If you continue to do this kind of re-writing, very soon we will 
> loose this baseline. And we may lose the input of those people who
> are still running these versions.

Won't they still be able to compare mathematical results with the
current Axiom?

> Of course, sooner or later open source Axiom will have to
> "go it's own way". Maybe it already has. But I think we need to
> decide the direction very carefully and not simply on the basis
> of one person's whim. (Although I must say in spite of this,
> I do have great respect for your whim's. :)

I agree, both counts.

> Sigh. I know this is nature of open source development - things
> will move in the direction the active developer(s) decide. *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.  GCL is seldom a target platform for
such tools right now.  But hopefully with ANSI GCL and ANSI Axiom we
can start to leverage the work out there by the Lisp community.  It's
speculative, I admit, but BOOT will present another learning curve to
new developers and has virtually no development community behind it.  I
should state that I consider a learning curve to be more than learning
what the syntax of a language is and how it works - the programmer
needs to be able to "read" the code with reasonable fluency.  I agree
the BOOT code looks easier to read to an eye used to reading Axiom's
SPAD code, and might even be more compact and efficient in expressing
ideas relevant to that part of the Axiom system.  But most of the
Lisp/BOOT level code will be written once and then never touched again
(hopefully).  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.  Most of the significant work on
Axiom in the decades to come will hopefully be in the level of
SPAD/Aldor - e.g. the language for mathematical functionality - and not
in either Lisp or BOOT.  I view these two levels as two completely
different levels of coding, and with any luck most of the need and work
will happen in Aldor.  Hopefully functionality written at Lisp/BOOT
levels will be a documented, solved problem.  If the expectation is
that only infrequent work will need to be done at the Lisp/BOOT level,
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.  If the
literate documentation is written well the language of the code itself
should be little more than a detail.

As I said before I'm willing to be convinced that the BOOT code adds
enough functionality and power to justify imposing a second (however
minor) learning curve on new programmers, but I can't do it on my own. 
Aldor/SPAD I can see because the programming at that level is tailored
to one specific job - the expression of mathematical knowledge.  Other
than that, 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.  Aldor/SPAD code and code below that
level are in my mind two completely separate jobs, just like writting C
code is different from writing the assembler needed to translate C to
machine code.

> The documentation is great, but recoding
> things in lisp just seems to be moving the goal posts further
> away from me. :(

That in itself is definitely an argument in favor of BOOT - you're
worth quite a few speculative lisp coders!  I definitely think there
should be a discussion on this point, if only to make sure we've
spotted all the issues involved with both courses of action.

Cheers,
CY


                
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com