Re: [Axiom-developer] Minor insight

[Tim Daly]

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