RE: [Axiom-developer] Unit package question

[Page, Bill]

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.