> > "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. _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer