POS == Pile of Sand Since we only had 4K of memory, programmers used overlay linkers and include files. Include files were needed because compilers were single-pass and needed forward references. These "hacks" never died.
Files were small, normally less than 4k for obvious reasons. If the file got too big the compiler choked, your flowchart generator failed, and you used too many punched cards. Sematics existed in 7 or 8 character file names and in variable name conventions (Fortran I-N were integers). Back in the day hard drives had gotten large enough that some bright-spot decided that a flat organization was bad. So they invented directories. These "hacks" never died. Of course, directories needed names but space was still tight so names were short but "meaningful", like src, doc, inc, etc. and a 'standard organization' was born. Your include files were looked for in 'inc', libraries in 'lib', etc. Once that standard was common, Stewart Feldman created 'make' to handle the complex task of finding and updating all of this nonsense. Now you could write down the way to build your program. (Now automake. Save us). Of course, the doc directory, then as now, is blank. So we have a history of sematics encoded in the whole directory.file.function.variable name, which should be good for any possible form of semantic transfer to any "real" programmer. Now we have "layered" IDEs on top of this POS pile and teach this to students as "the eternal way". But programs have outgrown this organization. Back in the day (said the old man), a "complex" program was 'grep' and an operating system could still be printed in a 30 page book. Whole compilers were printed in BYTE magazine. It isn't even the size of the listing that has outgrown the organization. It's the size of the ideas. I could read the PASCAL compiler source and have a clue. But I can't read the LEAN source. I can read C++, of course, but LEAN needs much more background 'theory' to begin to understand what rules the code implements. You don't write code just to get PROLOG to work. You write code to express an idea like 'functional prolog'. Anyone trying to read your source code without a lot of associated words would have no way to reverse engineer your Naur-like 'theory'. Yet you still use the POS orgainization rather than a literate program. You're writing to express an idea, a new theory, yet you bury most of it in 3 letter directories. Why? The machine doesn't care about your theory, the people do. Why are you writing for the machine? I should be able to sit and read your ideas with their associated source code in a single afternoon. Your source code is nothing more than the usual equations in a physics textbook. You could write a physics textbook without the equations but why? Creating a POS structure for the compiler from a literate program is trivial, a single command. Do you want me to REALLY understand linear logic? Write a distributed program with queues using linear logic and explain exactly what problem it solves and how it solves it. Show me ALL the code so I don't have to imagine it or dig it up out of the POS pile. Include the rules with their code implementation. Include chapters on theory and biblio references. Include a chapter of 'bad code' so I can compare it with your new theory. Communicate ideas to humans.Write literate code. I will try to turn your program into a literate form so you can see what I'm ranting about. Tim _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org https://lists.nongnu.org/mailman/listinfo/axiom-developer