Zach, >So, I am extremely new to Axiom, in fact I pretty much don't know how to do >anything I want with the system, even after reading the introductory >materials. But I just want to say that Alasdair has some good points from >my point of view.
Please look at my reply to Alasdair. There are links to other free material. >When I was searching for a free CAS I found Maxima first (around 6 years ...[snip]... >This is really big, but perhaps not for the reasons one might think. I have >read some of Prof. Woollett's chapters and they leave something to be >desired for anyone not brand spanking new to the system. In fact, for any >advanced usage information, nothing seems to replace the mailing list which >is perhaps 10 times as active as axiom-developer and axiom-math put >together. What this does show is that Maxima has a user base that cares >about it. Archaic languages such as C survive because they have a large >user base, which creates more development/ease of >use/portability/efficiency, which draws more people to the language. The >fact that more people seem (are?) interested in Maxima makes it seem that >the project is healthier than Axiom. ...[snip]... >Perhaps some public relations work would help? > <humor>Perhaps we could offer pay-per-post?</humor> Seriously, though, I have no idea how to increase mailing list posts. >> 5. The various forks: Axiom, FriCAS, OpenAxiom, also must make it hard >> for the new user - which one to choose, and why? The many many >> distributions of Linux make choosing one awfully hard for the beginner - >> even I, who've been using Linux exclusively for over 15 years, get >confused >> on the rare occasions I have to install a new system. Axiom has the >same >> problem. > >Once again, this seems to point to an overall relative unhealthiness in >Axiom as compared to Maxima. When projects fork, it necessarily applies >stress to the users (and I assume developers). But more importantly, it >makes the choice more complicated for new users. As a newcomer, it looks >like rats leaving a sinking ship, but should you trust a rats assessment of >the ships status? As sad as it may be, people, in my experience, do not >like choices. Tell me, is there any bad blood behind the forks? There was a disagreement about the vision and long term goals of the Axiom project. I cannot speak for any other project but Axiom has the goal of making a sustainable system that can form the basis for the science of computational mathematics. To be sustainable means that users must be able to understand, maintain, and modify the system. Understanding the system implies that people can know the "why and what", that is, why a piece of code is written the way it is and what the code actually does. The "why" is generally not available in most systems, even though this is fundamentally important (e.g. writing the code in a special way was done to optimize cache-load times). The "what" is generally only available from published algorithms cached in pay-per-view databases (e.g. ACM) or other expensive sources (I just paid $350 for a copy of Luke's special function books). Worse yet, the actual algorithm is both an original algorithm from a paper plus later, possibly never published, improvements. Even worse yet, even if you understand the algorithm and read the code you'll find it a challenge. It is vitally important to understand the details before changing the system. Axiom has grown beyond the complexity bound where local fixes can be safely applied without understanding. (Witness the two incidents in the past related to algebra fixes). Unless these are caught by comprehensive, system-independent mathematical test cases (e.g. the Computer Algebra Test Suite (CATS)) they pass quietly into incorrect results. Axiom has been recast into literate documents. The point of this exercise is to draw together the source materials, the "why" explanations, the "what" explanations, the test cases, and all other related pieces of information. This is intended to be written in a "literate" style so one can just sit down and read the system like a book, with the important information being introduce when the discussion motivates it. In the long term you should be able to read Axiom from cover to cover (unlikely given the volume of material) and get an education in both Axiom and the underlying computational mathematics. When you decide to improve the system you can enter into a "conversation" with the prior developers by updating the surrounding discussion as well as the code, giving your motivations and insights. People should be able to publish literate documents at a conference which you just drag-and-drop onto your system (perhaps during their talk) and it "just works". Since this is a long term effort, as indicated by the phrase "The 30 Year Horizon", it will take a while to approach these goals. Not everyone cares about this. Some would rather continue building systems "the old fashioned way", or make it different without caring why it is the way it is. Documenting code is hard and much more time consuming than just writing code. And few people are willing to sacrifice their own time now to benefit other people later. So Axiom's goals are quite controversial. Thus, the forks. Its not bad blood. It's a difference of goals. Everyone involved has excellent and admirable motives for what they do. >> Future releases will have a primitive Firefox front end to Axiom, >similar in spirit (but not design) to the MMA, Maple, and Sage notebooks. >> I'm working on various tools in javascript but they are not ready for >> release yet. I'm also in design discussions with a graphics designer >> to try to maximize the user viewpoint. This will take a few release >> cycles to fully emerge. > >Tim, please tell me that Firefox will not be the only way to interface with >Axiom. It will still be possible to write an Emacs mode for it, something >like IMaxima? Also, why only Firefox, why not any browser? Well, any browser is fine. But all I have available is Firefox. I'm not a browser-agile developer so I have no idea what is required to get new fonts into Opera, or canvas tag support in IE, or graphics in graphics in Lynx :-) Hyperdoc was the original help system in Axiom and was way ahead of its time in the functions it presented. It was designed to allow users to create new pages, for instance. But over the lifetime of the system only NAG developed a few new pages. Hyperdoc is difficult to port and requires an X11 system, special socket handling, etc. Hyperdoc is special purpose C code I need to maintain. The new browser front end is designed to allow users to develop new material in html and javascript, while interacting with Axiom. It should be completely portable without any special requirements. There will be no C code to maintain, although there is new, minimal javascript/css code. I did write a wxAxiom (using a fork of the wxMaxima code) but decided it was yet-another-pile of code to maintain. I like wxMaxima. I just don't see the advantage of special purpose code when I can leverage the browser functionality better. I did have to figure out how to create CSS-based drop-down menus but that's my learning curve issue. The new browser front end is forming the basis for the Crystal interface (see the mailing list archives), although this won't be readily apparent for quite a while. I believe Martin Rubey (copied on this) has an Emacs mode. You might consider trying that. You'll still have all the old interfaces to Axiom, although once the Firefox front end works I plan to remove all the old hyperdoc and graphics code. This will significantly improve the ability to port Axiom to other platforms since most of the issues of porting have to do with the "portable" C code. Tim _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
