[Top][All Lists]

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

[Axiom-developer] axiom, browsers, and crystal

From: daly
Subject: [Axiom-developer] axiom, browsers, and crystal
Date: Mon, 20 Jun 2005 22:47:43 -0500

we're debating, not disagreeing. although you're clearly wrong :-)

i agree standards are a *good thing*(TM) but standards come after practice,
not before. when they come before practice they are generally large,
expensive, and overbuilt (e.g. XML)

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.

i agree that we don't want to re-invent the world and that we want to
follow standard practice. However i disagree that we should work solely
within standards.

what i see us doing is using cheesey work-around languages like javascript
and badly designed data structures like DOM. we're going to end up with
  (a) a program that is "more of the same"
  (b) is in a hard to maintain language that isn't very portable
  (c) hamstrung by the standard-per-browser problem
  (d) encoding our information in latex -> XML -> javascript hacks
  (e) unable to "really communicate" with the user thru the browser
  (f) bending the world to fit the doorway
  (g) unable to start local programs, save state, really interact

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. we want the
end user of axiom (the spad programmer) to be able to make the front-end
do truly cool NEW things. 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. We want to be
able to save state back into a representation that axiom and the front-end
can both use.

current browser technology won't allow us to "extend" it in various ways
(such as making one of the tabs be an axiom shell session). it won't 
read and write pamphlet files (inline latex, inline chunks). it won't
allow drag-and-drop of pamphlets. it can't start or manage local programs.
it can't handle giving up screen real estate as canvas areas. it can't
write to the file system, etc.

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. javascript
is a horrible language and we have two great languages (spad and lisp).

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. 

i can almost envision the C code necessary to start axiom (or some other
program) from the browser, hand it the screen area of a tabbed pane, and
present an API from the browser code to draw. if it is 1000 lines i'd
be astonished. all the cross-platform work is already done.

use the browser, keep the standards. but extend the tool to do what you want.
i don't change GCL, i simply extend it to be useful. 
i don't change noweb. i simply add functionality i need.
we won't change the browser, we just need to extend it to be useful.

think of the browser as having solved the cross-platform problem and as
a large library of useful code. now we want to make it sing and dance
to our new ways of thinking. we still do what a browser does (we have
the same base code) but we do so much more.


reply via email to

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