>If available time is an important issue, why choose to use a >browser/javascript solution for the Axiom front-end and documentation >system when almost everything will take much longer to develop than >with a Java-based solution?
Why would it take longer? Most of what gets displaying is hyperlinked text files (hyperdoc). These are being hand-rewritten into xhtml because I also want to review and reformat the information for the new environment. That takes time but its just the cost of quality. The graphics code is going to require a rewrite no matter what solution gets chosen because we don't want to assume an X11 front end. The graphics code uses some pretty low level (drawline) X11 primitives so I expect a canvas version to be within the possible targets. Certainly There is no such thing as simple job (TM) but a Java implementation is no easier or harder than a javascript implementation for this particular problem. Now that the html canvas object is finalized I can put this task back on the todo queue. One upside of the current (hyperbolic graph) work is that this will naturally fit back into the graphics and eventually Spad as part of the port effort so Axiom will be able to do a lot more on the graphics side. >Java is currently the most widely used language for both commercial >and open source use >(http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html) and >this means that there is a huge amount of free Java package available >to help solve almost any problem. Beyond this, Java's development >tools are some the best available and most of them are open source. I >have found that the combination of open-source Java packages and >high-quality development tools translate into significantly increased >development speeds. As I've mentioned before I have nothing against Java code as I've used it to develop both open source and commercial applications. I used to code exclusively in Java for a few years. >For example, MathRider represents about 7 months of part time work by >one person and it already has the following capabilities: > > * Supports multiple scripting languages for both extension of the >application and general use (including Clojure). > * Interactive 2D graphics (including XY plots and network graphs). > * Interactive 3D graphics (on the way). > * Syntax highlighting for over 150 file types (SPAD syntax >highlighting would be easy to add). > * Numerous programmer's text editor tools. > * Multiple Console interfaces. > * Sage-like worksheet interface. > * A Robust plugin architecture that enables MathRider to be >extended to almost any feasible level. > * A default CAS with the ability to easily support additional ones. > * Graphic viewing of the CAS's runtime environment, including the >global state, user functions, and builtin functions (I just added this >capability today and graphic viewing and interaction with the CAS's >data structures is on my todo list.) > >Have you had a chance to look at MathRider yet (http://mathrider.org)? > If not, I encourage you to compare this Java-based solution to the >browser/javascript based solution Axiom is currently working on. > I looked at MathRider briefly. I had two impressions. The first was that it looked somewhat similar to Joris's Texmacs idea, although Joris does not seem to implement the graphics, which you've done a nice job on. The second impression was that it was an "editor-like" or IDE-like front end. I have to say that I'm (religiously? fanatically?) wedded to emacs as I've used it every day for the last 25 years or so. I can't imagine interacting with a machine in any other way (even my macbook machine has 20+ emacs xterms open at the moment). But I'm a curmudgeon by nature so you should ignore my opinions on your work. >The Crystal system you envision for Axiom would be much easier to >implement in something like MathRider than any browser-based solution >and the nice thing is that almost all of the code can be written in a >scripting language (like Clojure :-) Indeed, I've mentioned Clojure on this list as a potentially interesting thing to watch. Clojure (runs on the JVM, which you obviously know) scales in parallel because it implements "apparently mutable" immutable data structures. It is these data structures and clever locking that seems to give Clojure its edge. I've ordered a copy of Purely Functional Data Structures by Chris Okasaki in order to look at implementing these data structures within Axiom so we could exploit some of the parallelism (especially within my proviso research work). As to the general direction of using the browser as a front end, I have to credit/blame Bill Page for this one. He initially argued that we should adopt a browser front-end and I strongly disagreed. Over time, with help from Arthur on the Mathml and with a lot of education on my own (javascript, ajax, json, etc) I've come to agree that the browser is the minimum-cost, maximum-leverage front end for future work. While my own learning curve was quite steep, the end-user learning curve is very shallow if there is any at all. The only code I have to maintain is the javascript that actually implements Axiom-related functionality. All of the other issues (platform portability, navigation, user-training, build/install etc) are assumed from the standard browser experience. Given that the browser implements javascript I don't have to have any compiler (e.g. the JDK) in Axiom. The total impact of using javascript is just chunk extraction of code from pamphlet files. Using Java implies that I can build the class files so the JDK is required and compile time is needed. So using the browser reduces build time (the C code goes away), reduces maintenance (same reason), minimizes training and support, eliminates code and associated porting issues, enables interaction with other web-based sites (e.g. linking to axiom-developer for downloads, recent news, etc), is platform independent (thus the windows port will only require moving the lisp code), enables functionality like printing, and gives me a way to dynamically add and distribute functionality (REST architecture). Tim _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
