>>Suppose you have software A which has very few documentation and it has
>>a bug B.
>>
>>You can produce from that two systems A1 and A2.
>>
>>A1: Fix the bug today. Fix the documentation in 1 year.
>>A2: Fix the bug together with the documentation in 1 year.
>>A3: Fix the bug today. Fix or don't fix the documention.
>
>
>A4: Fix the program. Which, in Axiom, means fix the literate
> document, which implies fixing the documentation as well
> as the code.
Just to give you an analogy from last week.
Last week I went to my mom's funeral. Because she had been sick
for a while her house was shut down. I arrived and turned on the
kitchen appliances. Everything worked but the microwave. I finally
figured out that the outlet was dead even though all other outlets
worked. The fuse box in the kitchen was fine.
My older brother arrived and pointed out that the outlet goes thru
the fusebox in the back of the house (about 20 meters away). When
I enabled that box the outlet worked.
So what is the proper action in this case?
a) having found the bug and not understood it I could call an
expert (an electrician)
b) having understood the bug from my brother I could have fixed
the problem by enabling the distant fusebox
c) having understood the problem and fixed it I could have
"documented" the problem by writing "fusebox A5, shop" on
the coverplate so the next owner knows what my brother knew.
What is the proper fix? It depends on what you want to optimize.
Axiom is optimizing for the long term. Why? Because I want this
code to live.
Tim
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
