Re: [Axiom-developer] Lisp

[Bill Page]

> > "Bill Page" writes:
> > > ... but all of my experience with Axiom over the last
> > > few years demonstrates to me that using Axiom is still
> > > really rather difficult - too difficult for most people.
> >
> Martin Rubey wrote:
> > I don't think that this is the reason. I believe rather the
> > problem is that axiom just can't do many things
> > mathematicians want to do.  As a recent example, the
> > solver seems to be especially week.  How come that
> > Mathematica spits out the solutions to Rainer Gluege's
> > problem without any tricks, while axiom cannot do it at
> > all?
>
On 3/5/08, Waldek Hebisch wrote:

> I agree to the general statement: there are many problems
> that Axiom can not do -- most beginers will probably give up
> concluding "Axiom is too hard to use" and not realize that
> what they want to do in not doable using Axiom.
>

I think you need to define more carefully what you mean by "axiom just
can't do many things mathematicians want to do" and "not doable using
Axiom". Axiom is a programmable system and SPAD is a programming
language (that can, if necessary even resort to calling functions
written in Lisp), so in principle Axiom can do anything actually
doable by a computer. True, there are probably many things that
mathematicians want to do that might be included in this category, but
then the same statements would apply (in principle) to any other
computer algebra system. So usually we need to translate such
statements into a language that refers to *how difficult* something
might be to do using Axiom, rather than whether it is "doable" or not.

I think there are several reasons why using Axiom is more difficult.
One is simply that Axiom (in spite of it's age) is still rather
immature. For most of it's life it was "research in progress" and when
it tried to go commercial it failed. So really, as open source Axiom
is still at the research stage. With the development of the Axiom fork
projects things have improved considerably, but as we all know there
is a lot more work to do.

The second thing is that for new and naive users Axiom's strongly
enforced static type system quickly gets in the way. Attempts to solve
this problem in the Axiom interpreter through the mechanisms of
automatic coercion, type inference, and type ducking (domain Any) are
largely failures but experience with systems like Axiom have lead to
the development of other more recent strongly typed systems like
Haskell and Ocaml where the type inference mechanism is much more
powerful and transparent to the user/programmer. And in the meantime
dynamic strongly typed languages (such as Python) have re-gained a
considerable lead in popularity with the new generation of
programmers.

I think that in principle both of these problems could be solved in
Axiom, but I now have some considerable doubt about whether this will
ever happen. There are only very limited volunteer resources available
who can be attracted to this sort of project and for the most part
they are already fully occupied with projects of their own (e.g. Sage
and other projects more closely associated with Sage than Axiom).
Further, I think that it is unlikely that any of the commercial
computer algebra companies or even some active and well-funded
research group will come to Axiom's rescue and supply funds to hire
developer talent. Unfortunately we have not even been able to attract
Google Summer of Code funding in the last two years.

(Yes, it's "Google Summer of Code" time again, but I do not think I
have the energy this time to try to present Axiom as a possible
candidate.)

Still, I am very very glad that you (Waldek) and Gaby and Tim continue
to develop your versions of Axiom along the paths that are of interest
and make most sense to you personally. While these projects are alive,
there is still a chance that somewhere out of the Internet blue, some
new users and developers of Axiom will appear.

> ...

Regards,
Bill Page.