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…
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 leve…
Ask HN: Why did literate programming not catch on?
101–103 of 103 posts
Re: Ask HN: Why did literate programming not catch on?
#102TeX benefited from literate programming because it was written in a higher level assembly language. (Also, it was written by someone who liked to write books, and if a book was about software, he wanted to integrate the writing of the book and the software.) Better than literate programming is to write code that explains itself. Don't write two things, one of which executes and the other explains it; write an explana…
> Don't write two things, one of which executes and the other explains it; write an explanation which also executes. I can see how your code can explain the `what' and `how'. How are you going to answer `why' and even more important `why not'? By `why not', I mean, a short description of why some reasonable alternative choices were not made. Eg why we use algorithm A and not B and not C.
If the choice isn't testable in any way, it's not worth commenting on.
In general, in many programs we can find algorithms that could be replaced by better ones (such that no test cases break). There is no need to explain why that is the case; all the various possible reasons for that are obvious, and it doesn't matter which ones of them are true.
Re: Ask HN: Why did literate programming not catch on?
#103Earlier quoted context omitted.
> Don't write two things, one of which executes and the other explains it; write an explanation which also executes. I can see how your code can explain the `what' and `how'. How are you going to answer `why' and even more important `why not'? By `why not', I mean, a short description of why some reasonable alternative choices were not made. Eg why we use algorithm A and not B and not C.
If the choice is testable, you can write a test case for it. B and C don't work because they break the test case; A is required. If the choice isn't testable in any way, it's not worth commenting on. In general, in many programs we can find algorithms that could be replaced by better ones (such that no test cases break). There is no need to explain why that is the case; all the various possible reasons for that are o…
Choices about architecture are hard to test in a unit-test sense, but are worth commenting on.