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. _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
