> It's not impossible in literate programming. There's nothing about LP that impedes this, I do it all the time. I have a quick obvious implementation (perhaps a naive recursive solution) and throw it in to get things working. I revisit it later when I need to make that naive recursive one faster (memoization, DP, or just another algorithm all together). It's no harder than what I'd do with an ordinary approach to programming.
Do you do it as literate program, which is to say, your text first expounds on a naive solution to the problem, and then later outlines for the reader the complete solution?
Or do you write one literate program, and then update the file containing the text of your program after you realize the better solution—no different from anyone writing conventional programs—thus thwarting the fundamental promise of LP (since the "why" of changes like that—and the absence of answers to those whys—is exactly what makes it such a battle to understand unfamiliar programs).
The author is very obviously talking about the first problem. Your comments and failure to elaborate strongly suggest you're doing the latter.
I've done both.
> your text first expounds on a naive solution to the problem
That's not how every literate program is written, nor is it the entire purpose of literate programming.
> Or do you write one literate program, and then update the file containing the text of your program after you realize the better solution—no different from anyone writing conventional programs—thus thwarting the fundamental promise of LP (since the "why" of changes like that—and the absence of answers to those whys—is exactly what makes it such a battle to understand unfamiliar programs). [emphasis added]
I think you misunderstand LP. Keeping history is not essential to literate programming. Having a series of evolving programs from naive to fastest possible is not the point of LP. Having an explanation of the program with the code is the point of LP.
Sometimes that means leaving history, sometimes it means removing it. A literate program is not a dead program. It's a living object that can be edited and changed over time. Keep the elements that are essential to the text. If the naive version is clearer (often it is) then retain it so you can explain the more complex fast version as it relates to the naive version. If it has no explanatory value, then drop it. If you implemented something incorrectly, it's not necessarily worth keeping unless the wrongness of it has value in itself.