axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Release?


From: William Sit
Subject: Re: [Axiom-developer] Release?
Date: Thu, 16 Dec 2004 02:58:20 -0500

Hi Bob:

Bob McElrath wrote:
> 
> William Sit address@hidden wrote:
>> At CAISS, we believe that if we can get Axiom into the courses, we can
>> get a huge user base. But a prerequisite for that is a Windows version 
>> with easy user interface. I think the user interface of Mathematica is
>> way ahead, not just because of the fancy fonts or layout or palettes,
>> but also the style sheets and PROGRAMMABLE Frontend. I used a lot of 
>> these features in my DiffEqn package. There are of course many 
>> weaknesses (and strengths) in the design of Mathematica.
> 
> I strongly, strongly disagree.  

I suppose you are disagreeing with the "way ahead" claim.  I am talking mainly
about what CAN be done, not how easy it is done nor how elegantly it is done,
with the Frontend programming. To do what I did (mainly in 1998-2000) in the
DiffEqn package is very difficult, if not impossible, say with existing Maple
worksheet. 

> The programmability of the front-end is
> one of the biggest drawbacks of Mathematica.  

Why? The Frontend is a separate program from the Kernel of Mathematica. Most
users may not even be aware of its programmability. By programmability of the
Frontend, I mean one can dynamically update a notebook using Mathematica
commands (like inserting, deleting, editing, copying results or groups of cells
into a notebook when the command is started from another notebook, with its
source in yet some other notebook).

> They have a programming
> language with: list-based, object oriented, functional programming, and
> user-interface programming, not to mention thousands of mathematical
> objects and operations.  Thus they have the most complicated programming
> language in existance, and with it the inherent complexity, bugs, and
> learning curve.  This also forces them into a backwards-compatability
> nightmare forced by early design decisions.

I don't disagree with the above. Mathematica derives its "power" from such
complexity, just as Axiom derives its "power" (in different ways) from other
complexities. The problems you described are not unique to Mathematica.

> If a programmable user interface is desired (e.g. writing worksheets for
> students) it should be decoupled from axiom itself so that bugs can be
> isolated, complexity controlled, and interaction of various parts
> understood.  I think texmacs + command-line math plugins, emacs +
> command-line plug-ins, and the latexwiki/web interface we're developing
> are all good examples of this.  Programmability of the user interface
> should be targetted to these separate, external applications.

This (separation), I agree, is desirable; but as I said, Mathematica's Frontend
is separate from the Kernel even if their language syntaxes are similar. The
user interface has to, by necessity, interact with computation through input and
output. From a 2D "scratchpad" point of view, Mathematica's Frontend allows one
to go back and edit a command, wrap a previous command to perform more
computation, etc. You cannot do that as easily in Axiom, Maple, or Matlab.

> Eventually I would also like to see a Mozilla/Gecko interface, with
> Axiom emitting MathML that is rendered by Mozilla.  Scripting of the
> interface can be acheived by DHTML, CSS, and javascript, in ways that
> are quickly becoming familiar to a wide array of web-developers and
> others.

Sure, that's coming RSN. Of course, new languages keep coming to solve old
problems. In hindsight, you may say Mathematica is behind the times (but they do
have Webmathematica), and remember, MathML and javascript weren't there.
Backward compatibility is important (destroying that is a sure way to stimulate
the economy). And would you say that mixing MathML, DHTML, CSS, javascript,
web-browsers, texmacs, emacs, latexwiki, with Axiom's lisp-based,
type-hierarchies, procedural programming, BOOT, interpreter language, compiler
language, maybe Aldor, thousands of domains and operations, not to mention all
the coercions, is easy?

I am neither a fan nor a critic of any of the systems. I use whatever is most
suitable and available for the tasks at hand.

Regards,

William




reply via email to

[Prev in Thread] Current Thread [Next in Thread]