Ondrej, >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.
The needs and opinions of potential developers are based in the last 30 years of code development. C programs live in tiny files because I only had 4K of memory on my PDP 11/40. Include files exist so I can tell the compiler what it can't figure out because it won't all fit in memory. Makefiles exist because these tiny sand-grain files exist. Libraries exist and have to be included (in order) because my paper tape reader needed to make one pass in order to copy all of the required libraries directly to the output punch. /* comments exist because I cannot write real documentation in source code. Autoconf exists because unix systems people can't agree where to keep the piles of sand (include files). Documentation is a burden and an afterthought. Good documentation involves clever variable naming. And all the great research in computer science is published in "Numerical Recipes in C". You look at all of this and think this is the best way; clearly the standard way; absolutely the only way to build systems. I look at all of this and search for a better way. I believe literate programming is fundamentally better. Tim _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
