You've either failed to read the post, or are just being deliberately obtuse in order to dismiss it.

The only one I'l come back at you on is 7: If the interleaved prose is not a secondary attempt to explain the algorithms and operations of the code it interleaves, why it is interleaved?

If it isn't an attempt to re-describe the code--and both your example and those in Knuth's original paper show otherwise--then there is no logic at all in keeping with the code, let alone interleaving it.

And the answer of course is that it is an attempt to describe the code. And syntax, used to describe algorithms, is programming by any other name. So now you have two descriptions of the same thing.

• One in a specifically designed, targetted, concise and precise language with clearly defined syntax and semantics.
• The other, a never designed, always changing, variably written, spoken and interpeted, verbose, imprecise language with capricious syntax and multiple semantics.

And both need to be maintained and synchronised.

Maybe if you are writing a book or academic paper, there is some merit, but for production code...it simply does not make sense. To me at least, but whatever floats your boat.

I will say that having been there and done that--and in a much less intrucive form; no reordering or pre-processing--it was a nightmare to both write and maintain. And that was with the benefit of a folding editor that would hide the verbiage at a keystroke.

By way of example, you're in there fixing a bug. Do you fix the prose or the code first?

• If you do both, and then the code fix fails, you have to undo both.
• If you fix the code first, where's the incentive to go back and fix the prose?
• And if you fix the prose first--there;s no way to verify it.

Any way you look at it, it's simply extra work for little or no gain.

By way of example, you're in there fixing a bug. Do you fix the prose or the code first?

If that's an argument to literate programming, then that's an argument to write any form of documentation or comments.

Note, I'm not making any argument against or in favour of literate programming.

I disagree. A bug is bug because it creates an unexpected behaviour which differs from the documentation. Once fixed there should be no reason to touch the docs. Of course it can also be the other way round, the documentation is outdated because of a "urgent feature" got implemented.


holli, /regexed monk/