[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Axiom-developer] RE: Boot vs. Lisp
RE: [Axiom-developer] RE: Boot vs. Lisp
Tue, 1 Nov 2005 07:35:46 -0800 (PST)
--- Bill Page <address@hidden> wrote:
> After this reply, I promise to "give it a rest" ... :)
Heh - sorry, I can't resist replying. Ignore me if
if you like - the short version is if I were to vote
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.
Bill, one point is that the the current codebase already
works and uses BOOT, so if at some point in the future
we discover that Lisp was in fact a mistake (I doubt that
but I'll postulate it for discussion) we can just come
back to where we are now, grab the BOOT code, stick it
in in whatever the current literate documents are in place
of the Lisp code, and fill in the holes. That's the
real beauty of the whole literate document idea - the IDEAS
will work regardless of the language, and while it would
be annoying having to redo the work in BOOT it would just
be a question of implementing the ideas in BOOT, as opposed
to puzzling out Lisp code and THEN writing them in BOOT. So
I don't think it's irrecoverable in any case, no matter what
happens, since we are in the decidely unusual position of
starting not from scratch but from a fully functional system.
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.
> On November 1, 2005 1:16 AM you 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
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 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. 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. 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? They
want it to solve problems without their needing to do that. Since we
want to become a rising force in the mathematical community our goal
has to be to provied 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.)
> > By writing in a language no one has ever heard of, the project
> > will be doomed to those that already know it, and those that
> > have a lot of time on their hands. Open source development
> > is "itch scratching" and if it takes a month to figure out how
> > to scratch the itch, most people won't do it.
> I cannot help but counter this view with another quote from
> Teach Yourself Programming in Ten Years
> "Researchers (Hayes, Bloom) have shown it takes about ten
> years to develop expertise in any of a wide variety of areas,
> including chess playing, music composition, painting, piano
> playing, swimming, tennis, and research in neuropsychology
> and topology."
> He claims this applies to programming as well and I doubt
> that he would have any objection to adding computer algebra
> systems to the list.
I agree, but isn't this in fact what Axiom is trying to address by
bringing the program closer to the mathematics? To allow researchers
who have put in the ten years to get good at mathematics to use a
significant part of those abilities as is in Axiom? The goal is to
allow mathematicians to be mathematicians without being programmers any
more than actually necessary to completely specify their problems,
which is one of the brand new things about Axiom.
> Of course we aren't talking about learning to program just to
> make small changes to Axiom. 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
> 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.
> > Complexity of software scales as exp(size). Doubling the
> > size (maintaining a compiler too) means far more than double
> > the work, and will require far more than double the coders.
> 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 don't really care what language is used. I've used around
> > 40 in my life and can learn another. But Axiom will die if it
> > is necessary to maintain a compiler also,
> 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.
> > and it will die if other people can't pick it up quickly and
> > contribute. KISS.
> That might be true. But I think we need to be very clear what
> you mean by "pick it up". If you mean "learn to use Axiom to
> solve some relatively simple algebraic problem", then I don't
> think Axiom is much worse off than any other computer algebra
> system in that regard.
There, I agree.
> From there to programming Axiom library
> routines is not such a big step.
> And there are other things
> that one would need to "pick up" before one could start making
> changes to Axiom itself.
True. But 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. 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.
In the end, Tim is being very producive, and that's a really rare
thing. 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 :-).
Yahoo! Mail - PC Magazine Editors' Choice 2005
- Re: [Axiom-developer] RE: Boot vs. Lisp, Bob McElrath, 2005/11/01
- RE: [Axiom-developer] RE: Boot vs. Lisp, Bill Page, 2005/11/01
- RE: [Axiom-developer] RE: Boot vs. Lisp,
C Y <=
- [Axiom-developer] RE: Boot vs. Lisp - various, Bill Page, 2005/11/01
- [Axiom-developer] RE: Boot vs. Lisp - various, C Y, 2005/11/02
- Re: [Axiom-developer] was: Boot vs. Lisp / a smaller project, Martin Rubey, 2005/11/02
- [Axiom-developer] StepThrough, C Y, 2005/11/02
- RE: [Axiom-developer] StepThrough, Bill Page, 2005/11/02
- RE: [Axiom-developer] StepThrough, C Y, 2005/11/02
- Re: [Axiom-developer] StepThrough, Martin Rubey, 2005/11/03
- RE: [Axiom-developer] StepThrough, Bill Page, 2005/11/04
- Re: [Axiom-developer] StepThrough, Martin Rubey, 2005/11/04
- Re: [Axiom-developer] StepThrough, C Y, 2005/11/04