[Top][All Lists]

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

Re: [Axiom-developer] Must hear...

From: Martin Baker
Subject: Re: [Axiom-developer] Must hear...
Date: Mon, 12 May 2014 08:21:54 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

On 11/05/14 21:33, Tim Daly wrote:
Unless there is some overarching reason it is hard to see the need to
rewrite existing code. A new design that regularizes many domains
might make a good reason. A complete extension of the whole area, such
as a major matrix package might make DHMATRIX a useless subset. But
changing the API of an existing domain so that old code doesn't work
is, by definition, broken.

Mistakes in the code will occur both in old code and in new code.
Unfortunately new mistakes are only likely to be uncovered by new
people using the new code... which by recursion on the motivation
to rewrite the code...  leads to yet a different set of mistakes.

Code doesn't rust. It doesn't "get old". Especially computational
mathematics code. Tearing down the cathedral because we now know
how to make stones that lasts longer seems ... I don't know ...
disrespectful of the genius of the original architects?

One of the ideas I seem to be getting from the Robert Lefkowitz talks is that most of the life-cycle of a piece of software is in maintenance (i.e. change) and that is why this type of documentation is needed. It seemed to me that a corollary of that is that, if the code does not need to change, then documentation is not required.

The thought also occurred to me that the wider axiom community has two types of factions, those who want to change without documentation and those who want to document without change. I don't mean this to be taken seriously, its totally unfair of me to write down such an untrue thought. I apologise unreservedly to people who are working very hard to improve a program they believe in strongly.

I agree about the genius of the original architects who were years ahead of their time. I think more history should be made available to let more people know about this.

However I don't want to use, or work on, software that is a museum or shrine to the genius of the original architects. I have convinced myself that the sort of changes, that I would like, are driven by real needs to support new mathematical structures and so on and not just a wish to tweak the margins of the program for the sake of it.

see my wish list:

I think what you are hinting at is that the original scratchpad software was written by a large number of brilliant people and I am a single, humble individual who is very far from being a genius. I assure you, I know that already. I really should set myself more realistic goals.

It seems to me what Robert Lefkowitz is saying is that programs need to change over time, and for that they need documentation and of course the meaning of the word 'documentation' changes over time and everyone understands the meaning of words differently. Mathematical truth may not change over time, but the way that people use it, what is considered important, notation and just about everything else does change. Perhaps 'documentation' does not mean what I think it means but, for me, its about not freezing the program in time.


reply via email to

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