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

[C Y]

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

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

Agreed.

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

True, but those can be fixed up over time.  Often the hard part is
figuring out what on earth a particular block of code is trying to
accomplish in the first place.

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

I think we can agree there is no optimal solution.  The only way I know
to COMPLETELY specify something other than using program code itself
would be the B Method or some other formal method.  I'd love to be able
to do this, but it's far beyond our current resources, particularly
given the lack of good free tools for working with the B Method.

If we can establish a standard for thorough, exaustive, exacting
documentation which is still usable early on, I think it will go a long
way towards establishing the right kind of momentum.  Ultimately, human
readable documentation and code is all about conveying ideas.  Details
always have to be handled on a per-implementation basis, but the fewer
implicit and undocumented behaviors the better.  A description of an
algorithm, for example, should be implementable in any language. 
Details if its implementation in that language can't be specified
without actually writing it, but if the algorithm is clearly and
completely described that should be enough.
 
> > ...
> > 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.

It is my hope that very little maintainance will need to be done once
this phase of the project is complete.  ANSI Lisp is now a defined
standard, and if we can implement all of the core (non-graphical)
functionality in that language we should be able to function as
designed on any ANSI Lisp implementation.  (Fortunately, this is
currently testible.)  If our designs are sound and don't need a
significant amount of change in the future, worrying about Axiom below
the level of SPAD/Aldor will hopefully become a thing of the past.  

I admit this is likely impractical, but hopefully we will be able to
approach this ideal closely.

That's one of the reasons I actually favor building up McCLIM and
implementing all the core plotting and graphics abilities in it -
McCLIM will need to adapt backend code to changing graphics systems on
various operating systems, but the logic defined for Axiom will
hopefully remain constant and unchanging.  In the same fashion, lisp
implementations will have to adjust to shifting operating system
developments, but the Axiom core won't need changes as long as it
relies only on the features in the ANSI standard.

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

Sorry, I should have said the CAS development community.

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

Right.  I guess the best way to the group I mean is CAS "implementers"
who build these higher level systems.

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

I think it's better to try to approach things from the standpoint of
wanting to ensure that CAS users and "highlevel developers" don't have
to be come CAS implementers.

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

Given a stable Axiom core and Aldor compiler that do not need major
tweaking, the most that should have to be done is an occasional minor
bugfix or portability change.  This type of task can be accomplished by
someone familiar with the implementation language, and I'm hoping once
we're done with this phase no modifications more significant than that
will be needed.  Endless redesign of the languages of Axiom is not a
project goal - the languages should, as nearly as possible, be fixed in
stone.

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

Right.  But the latter task (extending the libraries) I'm hoping will
be a completely different set of tasks than whatever minor "under the
hood" work will be required, and that the ability to do the latter will
require only adjusting to some minor syntax change or package locking
adjustment in the lisp implementation. 

> In general I don't think trying to learn mathematical programming
> from the "bottom-up" so to speak is a good idea.

oops.

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

I thought it was high level to avoid the need of mathematicians ever
becoming programmers (the "ten year" requirement), but I suppose maybe
that's overly optimistic.

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

That's what grad students are for - "here, fix this" ;-).  I think we
should try design so that there is little to no work of this type to be
done in the first place, but I concede this is likely to be not totally
achieveable in practice.

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

Yes, but the number of people who take the latter path are EXTREMELY
few, perhaps in part because so few are qualified and have the luxury
to do so.  The vision I prefer is programmers doing low level work to
keep Axiom running and mathematicans using it to get things done, like
auto mechanics and drivers.  The mechanic isn't concerned about the
route or the destination, just that the car works.  Likewise, most
drivers don't want to know HOW the car works, just that it does and is
reliable - they want to learn how to drive, then go places.  I tend to
view software the same way.
 
> 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.

Agreed!  In many cases with software written by scientists it's clear
that the software is simply a means to an end, and the effort put in is
only that effort which gets them the answer they need.  I think Tim
made a comment about this once the 3x3x3 phenomena involved with
implementing software for different purposes.

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

I should :-).  I'd need to make the distinction though - how many want
to fix an annoying bug that shouldn't be there in the first place, vs.
how many want to explore new methods of CAS implementation.  I'm
betting most of the yeas would be in the former category.

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

I'd be curious - how many of these bugs are due to mathematical errors
(e.g. algorithms that are incorrect) vs. "programmer level" bugs (e.g.
"whoops, semicolon there")?  (Not rhetorical - I really am interested.

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

That's true (and a very nice thing!) but we want to make sure they make
that choice out of desire rather than necessity, to the extent that is
possible.  I have a feeling most programs written today could be
improved on in that respect.

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

True.  I also think our being able to achieve that goal is the only
possible way for us to gain market share in the mathematical and
scientific communities.  Mathematica has a great deal of inertia and
work already done in it, and so (perhaps to a slightly lesser extent)
does Maple.  We are going to have to be compelling, and the only way I
can think to do that is to be as bug free as humanly possible, both
from a mathematical algorithm standpoint and a programming standpoint. 
Otherwise the cost and inconvenience of the know, established, standard
commercial programs becomes less than the cost of the time required to
build up the new platform.

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

Oh, oops.  Yes, I read that wrong.  I agree the people currently on the
project (mostly) have a lot of other experience.  But the people on the
project now are also for the most part a rare breed - those willing to
pioneer a new system in the face of stiff competition.  Academic folk
are by nature rather conservative about such things (understandably)
which leads to things like journals being able to charge hundreds of
dollars for a single subscription.  The opportunity cost and risk of
switching systems (or journals) is very very high, and so the lure must
be very strong.  Most of us currently on the project are not active phd
mathematical researchers, am I right?  At this stage of the project I
would not expect us to appeal to that audience - we need to be strong,
stable, friendly from an interface standpoint, and demonstrate
compelling abilities.  We have to make it so NOT using Axiom looks like
a dangerous decision. ;-)

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

Currently, I agree.  But I think it's a worthwhile goal to keep in
mind, because we have an uphill battle ahead of us.

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

Huh.  Is the same true for Aldor?

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

Ugh.

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

But also a chance for us, if we can enable this in a way that current
systems cannot.  Axiom's top level language and literate programming
style might be considered "doing math."  That's the goal, at least.  So
if the "program" parts of Axiom can be made robust enough so they don't
get in the way, we might get mathematicans who are funded only for
"mathematics" to give Axiom a look.

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

Thanks :-).  

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

Kai, did you do that because you wanted to avoid having to run the UI
in the same thread as Axiom itself or because of toolkit limitations?

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

Really?  Are the plotting routines written in BOOT?

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

I guess I would have tried making a cl-svg package in the hopes of
getting help from projects outside of Axiom, but that's just me.

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

Er, yeah :-).  Clearly Tim has been very productive very often.

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

It's not a silver bullet, true, but a silver bullet is in fact
impossible when it comes to conveying information - there is no one way
that is going to work for all people in all situations.  The best way I
know of to think about it is to try and treat it like a proof - define
one's core concepts, what they are based on, and then build on those
concepts assuming as little prior knowledge as is practical and stating
assumptions when made (and what to do in case they are invalid - e.g.
if a document assumes familiarity with CLOS provide links to allow the
reader to become familiar with CLOS if they aren't, as opposed to just
mentioning that CLOS familiarity is assumed and going on.)  That's why
I love the idea of literate documents as academic papers - the idea of
citing references, building the understanding of the subject up from
the basics, etc.  If I were documenting the algebra, I would try to
start at the set theory that underlies the whole global design itself -
what is set theory, why it's interesting, which versions Axiom makes
use of and why, "casual" vs. "formal" set theory and reasons for each,
etc. (I don't know enough about it to know what all I would need) and
once that foundation was solidly laid, build on it in describing the
next level.  I would like to see Axiom's mathematical structure in
effect represent the dependancy logic tree of all of mathematical
theory, from the foundational assumptions right up through to PDE
solution techniques and numerical algorithms.  That's also why I would
like to formally specify what properties of the underlying language
(BOOT, Lisp, whatever) the top level definitions are relying on to
implement their ideas, since a violation of those assumptions could (in
theory) subtly break Axiom or allow for incorrect results.  I guess
that's another reason for my preferring not to have too many languages,
since if an attempt is made to do this each language would have to lay
out these assumptions.  In the case of Aldor->Lisp it is only necessary
to identify what properties of the lisp functions Aldor is relying on
for performance to be as designed - this is in effect a slightly more
casual approach to formal methods programming and would lay the
foundation for someone with expertise to make it truly formal.

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

Well, once I get the units package figured out (if I ever do...
grumble...) I'd be glad to start trying to document the foundational
design principles of set theory used in the Axiom libraries. (I guess
that would be the core of the SPAD/Aldor language design as well?) I
should point out I'm totally unqualified, but in a sense that might be
an advantage since if I can document it so that I understand it, anyone
should be able to - I won't make any hidden assumptions because I don't
know enough TO make the assumptions.  Of course, there's also the
chance I'll royally mess it up, but I'm game to take a shot at it... 
It can only be educational, and worse case scenario my stuff could be
thrown out and someone else better qualified can take a shot at it.

Cheers,
CY


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