Re: [Axiom-developer] User Interface Help

[root]

>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