On Thursday, June 23, 2005 6:52 AM William Sit wrote: > In general, I do not like that the result of a command depends > on its screen location. > > Bob McElrath wrote: >> A worksheet is read from top to bottom, as a document, not a >> batch-system-dispatcher. As a document, it should make sense >> if I read it in order. The idea that a command's result is >> independent of its screen location forces the user to keep >> considerable state information in his head. By putting the >> state information into the document, in order from top to >> bottom, the user is freed from having to keep *any* state >> information in his head, because he can simply read it off >> the document. >
Yes, that's it exactly! I think this view is very much in keeping with the intentions of Axiom's original designers. Axiom was originally called "ScratchPad" (written with a internal capital letter just like WikiWord, still ahead of it's time). Hmmm... that gives me an idea: Why don't we name the *new* Axiom user interface ScratchPad? Anyway, I think the type of user interface we want should be a kind of "intelligent" scratch pad, not just a plain dumb old piece of paper. If I erase something that I previously scratched- in near the top of the page and replace it with something better, I want my intelligent ScratchPad to be able magically re-assemble itself as if that was what I had written all along. No more, rewriting, crumpling up old pages, and throwing them in the waste basket. It would be even nicer if it could warn me more gently using shading and color that my change is going to affect two or three others things way down near the bottom of the page but not anything in between. These in between calculations were ok and don't need to be re-done. But the other things might need more attention or maybe they just need to be repeated rotely with some simple substitution of values or symbols. > I don't disagree that most *finished* worksheet read from > top to bottom, and the commands run from top to bottom, but > that need not be the norm. Document is a good analogy: modern > documents are not linear, because we now have hyperlinks; > we can, and want to, skip around! A program is the same, > the code need not be linear in structure: we may have parts > A, B, C in parallel followed by D that depends on A, B, C; > code can even have a circular structure (like Axiom > domains). Compilers do code optimization by exploring the > non-linear structure of the code. I think that that is a very good point. The "Intelligent Paper" (tm) described above is one kind of smart user interface, but you are right that the way we use the web and other smart document interfaces these days is gradually changing the way we view what used to be limited by the nature of the recoding technique on ordinary paper. To work in this new way, we need to be able to "navigate" easily and fluently through a network structure in a sort of multi-dimensional manner. This is exactly what excites so many people about the Web. So I agree completely that the new ScratchPad needs to be very much aware of and integrated with the (still evolving) Web point of view about organizing pages into a very dynamic kind of "document", i.e. web site. What Tim Daly calls "Doyen" is exactly this kind of web site - a kind of Public ScratchPad. The Axiom MathAction web site is a kind of prototype for what Doyen should eventually become. We need the new personal ScratchPad to integrate smoothly with this Public ScratchPad. This is the way that private mathematical "work in progress" may someday be published and shared rapidly with others. It seems to me that right now the planets must surely be in a favorable alignment since we seem to be recognizing this need for a new approach just at the time that exactly this new kind of web technology is being experimentally developed. For example I think we can learn a lot from this project: http://www.tiddlywiki.com Bob McElrath already has a version of this web interface that provides pretty mathematics in addition to all of the other editing and hyper linking features: http://bob.mcelrath.org/tiddlymath/tiddlyjsmath.html I think that for people who are already comfortable with this new multi-dimensional hypertext way of writing and working as one of their own personal tools, we also need to be able to provide this kind of flexibility for the new ScratchPad user interface. > During development of this final product, just like writing > any essay, we gather together ideas, pieces, expand them, > rearrange them, put them into sections, chapters. Until the > document is finished, it is *not* consistent! The state of > consistency is approached only gradually. That is certainly one way of working that we need to accommodate. Another approach that is perhaps more popular among computer programmers than it is among mathematicians is a kind of iterative approach. In this way of working one strives to always maintain one's creation in a consistent state. Programs are dynamic things that have complex and sometimes apparently unpredictable behaviors. In order to place some bounds on the amount of complexity that we have to deal with, we often write programs in small iterative steps. First a very simple version of the program is written that does some basic things - makes certain limited calculations - but does them right and consistently. Next we begin to make small iterative improvements, testing each improvement in an attempt to ensure that we have not "broken" anything by our changes. I think that as more and better computer tools become available for mathematics, more mathematics may actually be done in this way. > So in developing a computation worksheet, as I often do in > Mathematica, I start with exploratory routines, test ideas, > revise, expand, change, etc and finally reorganizing this > into a logical sequence of commands. The entire sequence is > not necessarily linearly ordered, as the location of some > functions (especially those defined with SetDelayed, which > I would consider as library functions) are unimportant except > for grouping into some theme. The main executable (using > immediate assignments) sequence would be linear mostly. What you are describing reminds me very much of the literate programming style that was promoted by Knuth and which Tim has adopted so whole heartedly for the Axiom source code. Literate programs a complex documents which can be processed and viewed in several different ways. Most notably there is the "weave" view of the document which is most similar to a paper-based kind of publication. But there is also the "tangle" view that is necessary to extract the programming code for the computer. I agree that this kind of flexible multiple views of a single complex object is probably also a very good paradigm to adopt for literate mathematical programming, i.e. what most people want to do with Axiom. > Why should I need consistency during the development? If > I am only working on some single subroutine, why shouldn't > I be able to test this in isolation? To my mind these are two very different things. We need consistency during development in order to help manage the complexity which otherwise could very easily overwhelm our limited human abilities. Yes, testing and working with smaller pieces of a mathematical calculation, or proof, or program, is often best done in a isolated more controlled "environment". Programmers often set up special "test harnesses" which are special programming environments specifically for isolating and testing specific features of some new piece of code. This is very similar to the practices in other types of engineering and also in experimental sciences. In engineering terms this is usually called "unit test". It is one important step in the development of complex systems. I agree that the new ScratchPad user interface should be able to support this kind of use. > If I keep track of dependencies with SetDelayed, there is > no need to worry about the eventual consistency. Even if I > can place code in a linear space order, why can't I prefer > just a linear logical order? All I need is consistency of the > final code, which if it works, is automatic. "which if it works, is automatic" ... that is the common presupposition of many less experienced computer programmers and software development companies with whom I have worked. They are often very reluctant to become involved in system testing and business case scenarios because they usually feel like this a waste of time since they have already shown with there unit tests that everything "should" (implying that it "will") work. But in every case that I know of, these people have been wrong. There is a whole computer science literature on this subject. > For developers, it is the revision cycle that is time > consuming. I would like to have all the freedom available. Reducing the revision cycle time is exactly what lazy re-evaluation is all about. I don't think that it needs to restrict your freedom in any way. Regards, Bill Page. _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
