On Jan 21, 2008 9:30 PM, root <[EMAIL PROTECTED]> wrote: > >>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.
I think this should be written on the front page of the axiom project, because my personal opinion is, that many people want to know the strategy behind the project. Also, I think, but maybe I am wrong, that most people prefer the "fix it now, instead of tomorrow" strategy. So one should then ask - do I want to create a project that most of the people would agree with the course of development (strategy of fixing bugs)? Or do I want to create a project that most people disagree with the strategy, but maybe in 30 years there is some chance that axiom will become very popular. I, personally, prefer the former, because I (but that's just my opinion) prefer my project to be joined by a lot of people now, not in 30 years. And with this perspective, I think (again just my opinion) that even if you want to optimize the project over 30 years, the strategy is wrong too, because it's imho essential that people join the development. I think the best strategy is to optimize for the needs and opinions of potential developers in 2008, not 2038. Ondrej _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
