Re: [Axiom-developer] A Canonical Axiom GUI

[Kai Kaminski]

C Y <address@hidden> writes:

> I won't argue with those who will point out that this doesn't mean
> anything about how good the mathematical abilities of the software are
> - indeed, I agree with them.  But for those who will evaluate Axiom as
> a tool to use, the metrics they will be using in some form are:
>
> 1.  Does this project look like a serious, able, and high quality
> production?
> 2.  How friendly is it to use to do what I need to do?
> 3.  How much time will it take me to learn enough with this tool to
> become productive?
I'm not sure how these objectives depend on the existence of a
canonical user interface. Besides what looks great to the beginning
student might look like a toy to a researcher. What looks great to the
latter might look like a pile of unintellegible crap to the former.

> It takes enough time and energy to evaluate a tool such as Axiom in a
> non-trivial way that the motivation to do so must be extreme.  (How
> many people here have seen a sub-optimal tool used simply because
> people already knew it and thought it would be faster to use that tool
> instead of learn one they knew might be better?
The tool doesn't change, only the GUI. Do you know any other
successful language that has a canonical GUI? Certainly not C/C++,
Java, Smalltalk, Lisp, Python, Ruby, Fortran.

> I would personally prefer that there exist a GUI for Axiom that is
> designed by the same people who are intimately familiar with the system
> itself, and (for example) might be able to teach a graphical
> environment to associate type information with graphical behavior in
> the GUI.  (Imagine, for example, a GUI that would let someone drag a
> polynomial into an integration template but would refuse a matrix as an
> incompatible type.  Or a formula template for ballistic motion that
> would reject anything with the wrong type in its slots.  The visual
> display may or may not contain all of the important information for the
> user, but a GUI working with the type system itself could be far more
> intelligent.)  My guess is 3rd party graphical systems are not likely
> to be interested in this type of work, preferring instead to simply use
> Axiom as a mathematical engine to get answers to common problems.  
I certainly hope that implementing the two examples you give doesn't
require one to be an Axiom expert. Why do you assume that 3rd parties
are not interested in developing powerful GUIs? Non of the free Lisp
implementations has an IDE and most people are using Slime, which is
just great (even though not nearly perfect).

> I think it would be desirable for people who download and install
> Axiom, when they type "axiom" or click their Axiom icon, to have a GUI
> environment available that is similar in concept to the Maple and
> Mathematica environments, but perhaps with more or different
> functionality.  Our "first impression" with potential users is what
> they see when they start the program, and I would personally like there
> to be a smooth, polished, and professional GUI as our first foot
> forward.
Why can't you provide this experience without a canonical GUI? Linux
doesn't have a canonical GUI, it doesn't even have any standard
software. That's why mere mortals don't just download the kernel, but
instead install Ubuntu, or whatever the latest hip Linux distribution
is (I don't mean to disparage Ubuntu, as far as I know it's a fine
system).

> Of course, someone would need to create such an environment, and code
> always speaks louder than emails.  I have looked at these issues a
> little bit and will attempt to pursue them further, but I know the
> problem is significant.  I guess it boils down to this:
>
> 1.  I think a default GUI for Axiom would be a Very Good Thing
As I said, I'm not convinced.

> 2.  The project is not yet a a point where this should be a major focus
> for the project as a whole.
That depends on what you mean. I believe the most important thing is
to make it developer friendly. In particular we must be able to use
all the open source Lisp libraries that are available. Also, writing
tools (especially GUIs) for Axiom should be easy.

> 3.  The work to make Axiom more friendly to ALL GUIs should be more
> important, because it will be useful to a very broad spectrum of
> applications.  (Indeed, even the command prompt probably should work
> off of the same API some day.)
It most certainly should.

> 4.  Code counts more than opinions, so I'll be quiet until I have more
> of the former ;-).
I'm not so sure about that. How can anyone start coding if there is no
consent of what the core of Axiom is and what features it should offer
to GUIs?

Finally I'd be interested in how we could get such a canonical GUI. I
see two ways, each of which has its fair share of problems.

1) We discuss what features the GUI should have and what modifications
   to Axiom's core are necessary. Then some poor soul starts coding
   and after some time (probably measured in years) we end up with the
   canonical GUI as the Axiom gods ordered it (that's us).

   What if it fails for whatever reason? What if some third party
   builds a GUI that is much more attractive to users than the
   canonical one? Look at GNU Hurd and Linux. I seem to remember that
   Hurd is the 'canonical' GNU OS. Does anyone care?

2) We modify the Axiom core to allow easy development of GUIs. People
   start building them, first simple, then more involved ones. We pick
   the 'best'.

   What if two years later a different GUI is much better? Do we
   change the canonical GUI? For how long does it have to be the
   better one?


Finally let me point out that there really is no best GUI. On Mac OS X
the perfect GUI must support AppleScript and satisfy the expectations
of Mac users, who are very picky about UI design. Recently I witnessed
a discussion about the subtle differences between a window's
maximize/close button on OS X and Windows.

Since a single GUI might support several system at once (see Bill's
work), why not turn the whole thing upside-down? People download
bundles consisting of a single GUI and several cores (Axiom, GAP,
whatever).

Kai

PS: I don't mean to say that there shouldn't be a nice, downloadable
package on Axiom's website featuring a specific GUI. What I'm after is
independence. Axiom's main branch should contain no GUI-related code
other than the implementation of the Axiom<->GUI protocol.