Hello! [email protected] 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... _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
