Literate programming tries to make every line of code traceable to English (or some other natural language). It's as hard as writing the same program twice in two languages. Perhaps harder: one is for programming a modified lump of sand. Another is for programming humans. The latter is a lot harder to do well than the first.
Then the question becomes: which one is correct? Maybe it's just easier and cheaper to write in the language the lump of sand understands and be done with it.
You don't get it Nick - that lump of sand doesn't understand your code at all.
It only understands the machine code emitted by the run-time engine (assuming Java/Python etc here).
The language you write in has been developed, at enormous expense, to allow you to express your logic, in a way that you, a human, can understand.
If it were not necessary for you (or other developers) to understand the code, then high level languages would not be needed.
In short, you have got it exactly barse-ackwards: the programming language you use is for humans - and only for humans.
The only reason it is apparently "hard" has nothing to do with computers, and everything to with the inescapable fact that correct, consistent and reproducible logic patterns are hard.
I respect Donald Knuth very highly, but in that literate programming thing he is wrong - it is the code itself that must be clear and readable.
Accuracy comes second, efficiency is third and 'elegance' is dead last. IMHO.
I think you make a few too many assumptions about what I know. Why do you assume that because I said that the programming language is actionable to a modified lump of sand that I believe isn't also communicating to the programmer? Its first goal is the latter. But until English can be executed by a computer, you must use programming languages to get the lump of sand to do stuff.
Easier, yes. Cheaper, no - with LP learning a new codebase takes much less time than usual.
As someone else noted programmers tend to be less than proficient writers (to say the least). That's unfortunate. Someone else mentioned that he sees value in LP in the context of education. That's because LP does make understanding the code both easier and faster. If it's good in education, why would it be bad in "normal" programming?
Instead of declaring LP as "too hard for normal people to use" we should try to teach people to be better writers. It's not necessarily one or the other, you can easily learn how to write prose (LP texts) along learning how to write code.
The only real problem with LP (besides lack of relevant skills in programmers) is ensuring that comments and code are in sync. But, how is it worse than the situation with documentation we have now? If anything LP makes it easier to keep docs and code in sync: they are in a single place and you can alter both simultaneously.
Of course, LP is a fuzzy concept. For example I call a certain style of writing comments LP, while others say that you need to have a tool like CWEB and the like to do LP. What's important is the push towards making the code more understandable by humans. There are different techniques to this end and LP is one of the more powerful among them.
> Easier, yes. Cheaper, no - with LP learning a new codebase takes much less time than usual.
Unless the program is different than LP work. Then, which is correct? The LP work or the program? It's been tried many times. It's been called the Rational Unified Process. It's been called Roundtrip Engineering. Not worth the extra cost.
Then the question becomes: which one is correct? Maybe it's just easier and cheaper to write in the language the lump of sand understands and be done with it.