[Axiom-developer] Re: OpenAxiom-1.2.1 released

[Aleksej Saushev]

  Hello!

address@hidden writes:

>> As I understand it, you could easily prevent forking by pushing Axiom to
>> user more actively, it could have the functionality of OpenAxiom or FriCAS,
>> but it has lost the momentum. From user point of view the confusion is
>> of no importance as long as one of fors works and another one does not.
>
> Aleksej,
>
> As I understand it, one fundamental difference between OpenAxiom and Axiom
> lies in the project goals related to the boot language. Approximately half
> of the Axiom internals is written directly in common lisp. The other half
> is written in a "syntactic sugar language", called boot, which compiles to
> common lisp.
>
> The Axiom project had, since it was released as open source, the
> stated goal of removing the boot language code. Indeed, this was a
> goal I had while working on Axiom before it was ever released from IBM
> in the late 80s.
>
> The OpenAxiom project has the exact opposite goal of writing everything
> in boot and developing boot as a language.

Alright, now that becomes more clear. What is common between Axiom and
OpenAxiom then? Do they implement the same high level language?
Do they have the same mathematical library?

> Given that the goals of OpenAxiom are directly opposed to the stated
> project goals of Axiom, how do you see that this difference should be
> resolved?

I repeat, that from user point of view the difference between projects
is that one builds and another does not. While I can build FriCAS and
OpenAxiom, I cannot boast it with Axiom. And the impression from my side
is that you handle build problems ad hoc (cf. Slackware build problems):
each linux-based system gets its own configuration file with quite
uncommon content.

What should be done, if I happen to need Axiom on HP-UX, is unknown.

At the same time FriCAS and OpenAxiom use portable Common Lisp
implementations (GCL is far from being portable), they are packager
friendly (they don't ship bundled publicly accessible software),
and they use well-established configure-make build process.

I remember you stated "it should simply work" as one of arguments in
favour of shipping gcl and other software bundled. In practice it works
quite the opposite way: I have to patch CLISP in order to make it not
fail on fragile shell code, I have to patch ECL in order to install
libraries properly on Darwin, I have to patch noweb in order to make it
behave (it uses hardcoded prefix and wrong icon program). Sometimes
these patches are done by other people and look magic to me. All these
customizations are to be reused, but Axiom doesn't do that.

In short Axiom doesn't build and doesn't play nice, when I'm going to
fix build problems myself.

And from my user point of view, Axiom should adopt either FriCAS' or
OpenAxiom's build system, whatever is closer, or develop similar one,
if Axiom is meant to be used by non-programmers. I believe you know
that there're enough engineers who are not and do not wish to be
programmers or system administrators.

Note, that I'm not interested in your political agenda, like to Boot or
not to Boot, or to tangle or not to tangle. I'm interested in real world
applications, those used by real life engineers, researchers or students.
As for now I can offer them OpenAxiom and FriCAS, but not Axiom, because
of severe maintainance problems. I'd like to change that but it seems to
contradict your political views, and I'm not ready to maintain substantial
patches.


-- 
BECHA...
   CKOPO CE3OH...