That literate programming is fully justified for Axiom is, well, almost axiomatic. But the issue is more how to boost the ability to invert the process and reverse engineer non-literate code piles into literate documents.
What, in your opinion, would be the most effective type of tool that could be developed to render the literacy project more tractable? Eugene J. Surowitz On 11/8/2011 9:46 AM, [email protected] wrote:
Yet to me, literate programming is certainly the most important thing that came out of the TeX project. Not only has it enabled me to write and maintain programs faster and more reliably than ever before, and been one of my greatest sources of joy since the 1980s -- it has actually been indispensable at times. Some of my major programs, such as the MMIX meta-simulator, could not have been written with any other methodology that I've ever heard of. The complexity was simply too daunting for my limited brain to handle; without literate programming, the whole enterprise would have flopped miserably. If people discover nice ways to use the newfangled multithreaded machines, I would expect the discovery to come from people who routinely use literate programming. Literate programming is what you need to rise above the ordinary level of achievement.I believe that Axiom's complexity is large enough to demand literate programming. There are several reasons. First, computational mathematics requires people to be exceptional at mathematics and programming. This is a small subset of already small sets. We might as well add another subset of those who can communicate their ideas in writing. Second, there are many design decisions that are necessary to reduce a mathematical idea to implementation. Some of these design decisions are mathematically arbitrary (e.g. branch cuts) or computationally arbitrary (e.g. sparse versus dense) or programatically arbitrary (e.g. all Spad versus Spad-and-lisp). These design decisions need to be documented so people who maintain and modify the program know why the decisions were made. Without this knowledge it would be trivial to accidently destroy important optimizations. Third, nobody is an expert in the range of mathematics that Axiom can and will implement. It is important to present some portions of the theory associated with domains so people have a clue about the ideas being encoded. Imagine what would happen if all of the math textbooks only contained equations but no human-readable text. You might be able to "read" a calculus textbook but not an infinite group theory textbook. Fourth, a million line program is too large to put into your head. You need to have some background on the data structures, control flow, any special tricks (e.g. funcalls through the symbol-plist), database design, communication protocols (e.g. between Axiom and Hyperdoc and Graphics), parsing structures, and a million other details. At best, the code tells you HOW it does something but not WHY, not what it depends on, not what depends on it, etc. Fifth, a program this large and this long-lived will eventually no longer have the authors around to ask questions. Several of the Axiom authors are already dead and most are not associated with it anymore. Some of those authors are the world's expert in their subject matter. That is a steep hill to climb if you want to understand the code, especially if you have to debug or modify it. Sixth, in the 30 year horizon view, we need to pursue a new level of excellence. As Knuth said: "Literate programming is what you need to rise above the ordinary level of achievement" For all these reasons, and more, Axiom needs to be literate. Tim Daly _______________________________________________ Axiom-developer mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/axiom-developer
_______________________________________________ Axiom-developer mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/axiom-developer
