Live data from Hacker News

Ask HN: Why did literate programming not catch on?

news.ycombinator.com

101–103 of 103 posts

Re: Ask HN: Why did literate programming not catch on?

#101

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…

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.

Re: Ask HN: Why did literate programming not catch on?

#102
post #75

TeX 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 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 obvious, and it doesn't matter which ones of them are true.

Re: Ask HN: Why did literate programming not catch on?

#103
post #75

Earlier 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…

> If the choice isn't testable in any way, it's not worth commenting on.

Choices about architecture are hard to test in a unit-test sense, but are worth commenting on.

Post reply on HN