[Axiom-developer] RE: Boot vs. Lisp - various

[Bill Page]

On November 1, 2005 10:36 AM C Y wrote:
> ...
> I'd cast my vote for Lisp, somewhat because of my own
> bias but mostly because Tim is accomplishing a lot
> of stuff and I'm eager to see that continue.
>

People seldom vote during a war :) but I agree that Tim is
accomplishing a lot of stuff and I am also eager to see that
continue. I believe Tim is very committed to Axiom and I doubt
whether my haranguing him about his intentions to replace boot
with lisp will have much affect on that.
 
> ... That's the real beauty of the whole literate document
> idea - the IDEAS will work regardless of the language,

I think you put entirely too much faith in the concept of
literate programming. The description of an idea is very
different than the implementation of an idea. Very seldom,
if ever, is a description written in a natural (human)
language a sufficient basis of an implementation. There
are always loose ends and forgotten details. And some
people are much better writers than others (programmers
are in general notoriously bad). I don't mean by this that
literate programming is a not a good thing - just that it
has its limitations.

> ...
> All mathematical work done in SPAD/Aldor doesn't have to
> care one way or the other, so that work survives regardless,
> and I'm really hopeful that we will reach a point where
> most significant work in Axiom takes place at that level,
> because that will mean Axiom is functioning as a mathematical
> and scientific research platform.

In my opinion we are already at that point. Or rather, we are
anxiously waiting for more research-oriented users to show up.
The work that Tim is doing now is mostly aimed at the longer
term that will not immediately affect Axiom's suitability as
a research platform. The issue of boot vs. lisp is a similar
issue. It doesn't have any immediate impact on the usability of
Axiom, but it (may) have a large impact on it's maintainability.

>  
> > On November 1, 2005 1:16 AM Bill Page wrote:
> >
> > I agree with this. But from my point of view the BOOT
> > language embedded in Axiom is much easier to "jump into
> > quickly" compared to lisp, if your starting point is
> > SPAD or if you had previously programmed in Python
> > (unless you also happen to be a lisp programmer).
> 
> Two points I wish to mention - 1) The CAS community is a
> small subset of the total programming community, but within
> that community Lisp is a much bigger deal than otherwise -
> I think it is this community we are likely to attract,
> rather than the general community

I don't agree that CAS users are a subset of all programmers.
I think a large number of people use systems like Mathematica
and Maple without programming at all. Most CAS *developers*
i.e. CAS users who write new applications within some given
environment,  of course must program in some language or other
but then usually only at the highest level language available.
I think only a small fraction of them might also know lisp.
So if we target primarily the lisp programmers in this group,
we are limiting ourselves unnecessarily.

> 2) SPAD will only be a starting point for people who have
> programmed a lot of SPAD code (not many currently) and also
> want to work on the internals of Axiom the program.  I'm
> hoping this will actually work a bit in reverse -programmers
> who are not up on the heavy duty mathematics side so much
> (for high level math that's most of them, at a guess) will 
> start out by working on the Lisp side (with its documentation,
> tools, etc. to help them getting started with Lisp) and then
> graduate to working on the mathematical side, where learning
> SPAD/Aldor will be part of learning to express high level
> mathematics in a computer.

I have a very hard time understanding what someone who does not
know SPAD might be able to contribute to internal programming
in Axiom. I don't think having a lot of experience in SPAD is
necessary - only the basic syntax and usage plus a knowledge
of how SPAD fits into the overall Axiom design is really
important. In general it is not necessary to know a lot of
mathematics to program in SPAD. However the Axiom library that
is written in SPAD does represent a considerable amount of
mathematical knowledge and to use it and extend it effectively
does require some of this knowledge.

In general I don't think trying to learn mathematical programming
from the "bottom-up" so to speak is a good idea. I am certain
that this is not what the original designers of Axiom had in mind.
That is why SPAD is such a high level language when it comes to
expressing mathematics.

> Actual honest to goodness mathematical researches and scientists
> are probably the LAST people who want to work on the guts of
> Axiom except out of need for a working tool - they want to USE
> it to do other stuff.

Yes I agree. But in spite of that I do think that these people
are still the mostly likely people who *will* do this kind of
work. The other stuff that they really want to do is what
motivates them to dig in and do whatever seems necessary to
get the computer system to do what they need. Inevitable some
of them adopt new "deeper" goals and spend most of their time
implementing CAS internals and helping other people do what
they really want to do. It seems to me that this is how it
has gone in a very large number of cases since the beginning
of this field.

In fact I think the design of some computer algebra systems
has sometimes suffered because those most motivated to do the
work did not have particularly strong backgrounds in computer
science, being perhaps excellent mathematicians but often
self-taught in compiler design and user interface design. In
this regard I think Axiom was exceptionally fortunate to have
among it's developers people with both of these skills.

> They'll be working at the Aldor/SPAD level, and any need to
> go lower will probably get reported as a bug to be fixed by
> the team.  After all, how many scientists would request to
> hack on the Mathematica source code?

I think you really should take a poll. :) For example, from my
experience I know a lot of researchers who would be very glad
to get a chance to "hack" in the internal code of Maple. Very
few of them would say they are entirely happy simply letting
the developers solve the bugs. That is one of the reasons why
there is a lot of pressure among CAS users for open source.

> They want it to solve problems without their needing to do
> that.

As I said, I agree that that is what they want to do but not
what all of them end up doing.

> Since we want to become a rising force in the mathematical
> community our goal has to be to provide a program where people
> can focus on the math rather than the program.  (Of course,
> this is all speculation so it may or may not be worth anything.)

If we could accomplish that goal, than I think it would be
worth a lot. I think that Axiom comes closer to that goal
than most of the other systems.

> ... 
> > We must assume that the people who choose to work on Axiom
> > already have quite a lot of other relevant experience
> > including programming in several languages.
> 
> I disagree - I think we want to appeal to mathematicians
> and scientists, who quite often are NOT (or don't want to be)
> computer programmers.  

I am sorry. What I meant was for this assumption to apply
to people who want to work on the *internals* of Axiom, i.e.
Axiom developers, not Axiom users. I agree with your statement.

> 
> > I think this is what limits the potential developers much
> > more than just learning another new language.
> 
> Maybe I'm alone in making the distinction between Axiom the
> programmer's challenge and Axiom the mathematical environment,
> but I'm hoping that level of abstraction is possible because
> it is likely to appeal to non-programmers.

I think you are right in making this distinction but things
are not quite as separable as you seem to imply.

> > 
> > Maintaining both a library compiler (SPAD) and an interpreter
> > (an integral part of the user interface) is inherent in the
> > design of Axiom. BOOT is closely related to SPAD (or perhaps
> > better said, SPAD is closely related to BOOT). So really
> > there is no additional compiler to maintain.
> 
> You mean the same compiler compiles both BOOT and SPAD
> with no additional complexity added due to compiling BOOT?

I mean that the problem of compiling BOOT is essentially
a subset of the problem of compiling SPAD. In a sense BOOT
is just SPAD but with a very limited set of types. So yes,
conceptually speaking there is really not additional complexity
added due to compiling BOOT.

But from what I have seen and understood so far, Tim is right
that the current Axiom code contains a lot of "cruft" and is
in some cases quite far from optimal even though it works.
So in the case of BOOT and SPAD I expect that a lot of the
essentially similar code is actually duplicated or implemented
in slightly different ways.

If you look at some of the older SPAD code you can even see
some of the original boot syntax appearing right at the surface,
e.g. the "append"/[...] construct.

> > 
> > I don't agree. I think maintaining a compiler as part of Axiom
> > is essential.
> 
> But mathematicians aren't going to want to work on a compiler
> (it's hard to get funding for things like that.)  They want to
> do math.

Ah, there's the rub.

>...
> I think wanting to make changes to Axiom itself will be a
> different job from wanting to create new mathematical abilities.
> It is quite possible there are others (like me) who are not
> likely to make any spectacular mathematical contributions to
> Axiom but are interested in providing features and functionality
> for those who can.

If you can complete your work on a units system for Axiom then
I think that would potentially be quite spectacular.

> For folks like me, the guts of Axiom being similar to the high
> level language is pretty much totally irrelevant.  In THAT
> situation, there is a clear advantage to not using a custom
> language, because hypothetically if I were a good Lisp programmer
> (Granted I'm not at the moment) I could hook in FFI bindings to
> the GNU Scientific Libraries.  Starting from BOOT I haven't got
> the faintest idea of how to proceed.  Lots of things like that
> will crop up over time, and Lisp already is working on the
> problem of being able to interface with a large number of
> foreign libraries via FFI.

Exactly that issue came up in Kai Kaminski's work on Axiom UI.
In that case Kai choose initially to use an entirely separate
lisp process (in fact written in clisp rather than gcl because
of ansi compatibility) and to communicate with Axiom via a
pipe or socket. But gradually and during the latter stages of
his work he discovered that he had to make changes in some
boot code in Axiom in order to support Scalable Vector Graphics
in the AxiomUI browser. Now as gcl approaches full ansi
compliance and after Axiom is ported to the ansi standard
(see another recent thread on this subject), I wonder if Kai
might have used a different approach and written more in
boot?

> 
> In the end, Tim is being very productive, and that's a really
> rare thing.

I presume that you mean something like "productivity in open
source is a rare thing"? Or did you really mean to imply that
Tim is not usually so productive? :) I don't think so.

> I'm cheering him on regardless - literate documents will
> make sure Axiom survives any language.  If someone wants
> someday to do a new CAS, we want to set things up so that
> to do anything other than start associating code with the
> documentation part of the Axiom literate pamphlets wouldn't
> make any sense at all :-).
> 

I don't think literate programming is really such a "magic
bullet", but I am all for the writing of documentation. Three
cheers for Tim! And I hope that real soon now, some other
axiom developers will come along to help out with this
enormous task.

Regards,
Bill Page.