> Calling the idea that code should be readable by humans "almost twee" just makes me think that the writer has no idea what they're talking about. This is a s

> Calling the idea that code should be readable by humans "almost twee" just makes me think that the writer has no idea what they're talking about. This is a strange criticism, and ironically it seems to reveal your own misconception of what "literate programming" actually is. Setting aside the discussion of how languages and design philosophies make tradeoffs that affect readability, Knuth's particular brand of "literate programming" pushes a concept that is orthogonal to language design, and substantially different than the precepts of style and commenting practices offered by things like PEP8. "Literate Programming". From Knuth's homepage [0]: > The main idea is to treat a program as a piece of literature, addressed to human beings rather than to a computer. From the literateprogramming.com page that Knuth's homepage links to, an excerpt from Ross Williams: > Instead of writing code containing documentation, the literate programmer writes documentation containing code. No longer does the English commentary injected into a program have to be hidden in comment delimiters at the top of the file, or under procedure headings, or at the end of lines. Instead, it is wrenched into the daylight and made the main focus. Here's a HN thread about docco, one of the few real-world tools related to literate programming: https://news.ycombinator.com/item?id=2089912 https://news.ycombinator.com/item?id=2089912 "Literate programming" is not just about readable code, it's about fundamentally restructuring the entire program to be read as one would read a work of literature. And this is something that is not at all standard practice, nor a philosophy that everyone agrees to even be ideal in theory. Here's Peter Norvig's criticism [2]: > I think the problem with Literate Programming is that assumes there is a single best order of presentation of the explanation. I agree that the order imposed by the compiler is not always best, but different readers have different purposes. You don’t read documentation like a novel, cover to cover. You read the parts that you need for the task(s) you want to do now. What would be ideal is a tool to help construct such paths for each reader, just-in-time; not a tool that makes the author choose a single pth for all readers. So saying Knuth's philosophy of "literate programming" is "twee" is not at all inaccurate. The sentence structure from the NYT article could be rejiggered so that it's clearer that "twee" refers to Knuth's philosophy, and not "code that is readable by humans" in general. But the author is absolutely right to describe Knuth as being a pioneer in literate programming, and that it's a paradigm not followed in practice by mainstream software development. [0] https://www-cs-faculty.stanford.edu/~knuth/lp.html https://www-cs-faculty.stanford.edu/~knuth/lp.html [1] http://www.literateprogramming.com/ http://www.literateprogramming.com/ [2] https://www.johndcook.com/blog/2016/07/06/literate-programming-presenting-code-in-human-order/ https://www.johndcook.com/blog/2016/07/06/literate-programmi...