I'm a huge believer in literate programming. In fact I'm trying to
embed a complete computer algebra system (Axiom) in literate
form [0]. The PDFs listed on that page contain the actual source
code that creates Axiom.
I believe you've achieved 'the letter of the literate concept'
but missed the 'spirit', as expounded by Knuth.
Your ACM article on Literate Executables
inverts the approach I've taken. I like your proposal.
In your approach the executable is the primary carrier.
For small, stand-alone executables this is an excellent idea.
It has the potential to eliminate code-rot in supporting tools.
For a large system like Axiom, one key struggle is that Axiom
has various layers and subsystems. Working on one part of the
system does not affect other parts.
However, even more fundamental is that literate programming is
about Explanation, not Documentation. Think of a physics textbook.
The equations (code) are quite opaque without the surrounding
paragraphs of explanation. The same is true for complex software.
In Axiom's approach the PDF is the primary carrier (the textbook).
The development cycle is to change the latex source code
for the PDF. Then type 'make' which (a) recreates the PDF
and (b) recompiles the code. Rinse and repeat. At all times
the PDF and code are in sync. The purpose of the PDF is to
explain the concepts and hold the related code.
My point is that your use of 'literate' in 'literate executables' is
(slightly) missing the fundamental point of literate software.
It is true that it keeps the code in sync with the executable and
keeps the code available for any given version. However, it
misses the fundamental literate point of 'Explanation'.
Tim Daly
[0] Axiom