On Thursday, September 01, 2005 5:34 AM Clifford wrote: > > Least anyone think I have abandoned this, I just want to give > a brief update: > > [writing design documentation] > > ... so I'll try to cram in all the potentially important > information. I suspect what I'll wind up with might be > overkill, but it can always be trimmed down.
I shall always remember that a famous physicist (Dirac, I think) once started his presentation at a conference by apologizing that "he did not have enough time to write a shorter paper" ... The point being, I guess that it is relatively easy to but down a lot of poorly organized stuff dealing generally or maybe in too much detail with partly the wrong stuff, etc. But he made an apology because he felt that by doing so he was being somewhat discourteous to his audience. One of his responsibilities as a writer is to say clearly and exactly what the audience needs to know and this takes *more* time than being verbose. A related issue is that we need to take account of the fact that human beings have some built-in limitations when it comes to appreciating complex subjects when they are presented with too many unorganized ideas at once. If it is at all possible we need to choose a mode of expression that is more powerful, i.e. say more with less but carefully chosen words. This is often where mathematics ( = 10,000 words) , pictures (= 1,000 words) and demonstrations ( = 1,00 words) should come into play. While I appreciate all of the documentation that exists about Axiom (It is much better than if there was none at all!) but I am rather afraid that we are already well past the point of having to apologize to new people who come to our documentation and our web site to understand as quickly as possible what they need to know about Axiom. :( Even give Axiom's "30 year horizon" and the chance that I might actually live that long, I do have doubts that I will ever end up reading all of the material about Axiom that we already have. I am thinking more and more these days that we have to think about improving the quality of what we have (and therefore reducing it's length) while at the same time producing more quantity. > ... > Thought we'd get more comment (other than from me anyway) on > William's overall design ideas - maybe we got too longwinded > and lost the audience? ;-) > Aw, proving my point above! In fact I did read all 60+ pages, but I must say that at some point I began to feel like I had lost the path to enlightenment. :) So that's when I went back to the first few emails and put Martin's example code on the web: http://www.axiom-developer.org/zope/mathaction/UnitsAndDimensions After seeing Martin's idea work almost exactly in the way you originally imagined that it might, I became less convinced of of my original presumption that there should be a close connection between units/dimensions and Axiom domains. Now I would like to see what Ralf sketched in Aldor written and demonstrated in about this same level of detail and functionality. Then perhaps we could code something similar to William's approach (to the extent that I understand that it differs from both Martin and Ralf). Then after experimenting with these "toy" examples a little, I expect/hope that I might be able to see it "fall into place". Some people might be concerned that writing code too soon risks freezing-in less suitable ideas, but lately I am beginning to take a more "extreme programming" point of view: writing code is in fact the whole point of the exercise. Yes it needs to be documented and understood, but this is (and will often continue to be) a moving target. We should be prepared to write, correct, re-write, factor and re-organize our code fluently while making an effort to keep it clear, concise and easily understood by others. We need to think-build-experiment-rebuild-rethink- build ... in an iterative and hopefully inspired manner. Of course this is not possible. :) Our tools and our skill are not (yet) quite up to this task. But at least in the open source world, I think it is clear that this approach works much better than the classical engineering "design, implement, test, and sell" model. There. Now I've probably written more than even I will be willing re-read and have, finally, illustrated my own point. Carry on. Cheers, Bill Page. _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
