[Axiom-developer] RE: axiom, browsers, and crystal

[Page, Bill]

On Monday, June 20, 2005 11:48 PM Tim Daly wrote:

> i agree standards are a *good thing*(TM) but standards come
> after practice, not before.

On the contrary, many standards have value even though they
may never be put into practice. Standards (should) drive design.
But standards are meant to be broken (and then fixed, again
and again).

> when they come before practice they are generally large,
> expensive, and overbuilt (e.g. XML)

In what sense do you think XML is expensive or overbuilt? The
syntax of XML consists of just three production rules.

  xml :== tag [ xml | value ] /tag
  tag :== <name [att]>
  att := name=value

where [ ] means optional and | means alternative. The rest is just
semantics and that gets complicated no matter what language you
choose.

> i agree that browsers are a good thing. they are platform
> independent, use standards, and allow marvelous things to happen.
> or not. in particular they explicitly do not allow themselves to
> be used as a useful front-end for local programs.

Have you used a Linux desktop lately? If you have, chances are you
have probably already used a browser as a front-end for local
programs and not even known it. Web browser front-ends are also
becoming very popular for embedded applications like network routers,
printer configuration. One of the most popular web browser front-ends

http://www.webmin.com

provides a complete system management interface for Linux servers.

> ...

think about what we want. we want a portable front-end to axiom
that we can extend in various ways to do truly cool NEW things.

Agreed.

> we want the end user of axiom (the spad programmer) to be able
> to make the front-end do truly cool NEW things.

I am not sure that "spad programmer" is a good description of
the Axiom end user since I expect many people will use Axiom
without programming in spad. But I agree that the gui front-end
needs to be easily accessible to the more ambitious Axiom
programmer.

> we want our documentation (pamphlets) to be magic drag-and-drop,
> clip and execute, inline moving graphics, managing multiple
> programs like axiom, our graphics, ACL2, and other tools.

Agreed.

> We want to be able to save state back into a representation
> that axiom and the front-end can both use.

I think the separation between the front-end state and axiom
state is undesirable. State is something that Axiom should
manage. The front-end just needs to be able to render that
state accurately in a variety of visual/audio/tactile ways.

> ...
> yes, you can do some of those tricks with acres of javascript,
> special certificates, plugins, cookies, and other hacks. but
> think of all of the code you have to write in javascript, html,
> xml, C, etc. it will only get MUCH worse as you try to write
> javascript to read the semantic network problem data structure
> and render the appropriate html.

Tim, I really think you are just "fear mongering"! In fact most
of the things you mention are already possible in a browser
like Mozilla very little or no any additional JavaScript coding.
JavaScript is mostly required just to provide the glue.

> javascript is a horrible language and we have two great languages
> (spad and lisp).

I am not at all fond of Java in general. JavaScript is just a
dialect of Java specialized for the browser API. I don't think
that it is any worse than Java in general. And Java has been
touted as a kind of "lisp for C programmers"... well, I wouldn't
have exactly said that, but it can't be that bad given the effort
spent on it's development and the amount of open source code that
is available in java.

> i'd agree with your approach if we could do something like graph
> the algebra hierarchy without a ton of java and a plugin or draw 
> a graph on a tab from lisp. 

Well, as you know TouchGraph (a Java application integrated with
the MathAction website) can already do a credible job of graphing
and navigating a complex network.

Kai has demonstrated that drawing a graph using SVG on a browser
can be done with a few hundred lines of GCL lisp code.

> ...

Sigh. The debate wears thin ... :)

Regards,
Bill Page.