"Programs must be written for people to read, and only incidentally for machines to execute."
Not this. x1.
Now if this were true, you would read these programs as you would literature. But you don't. Instead, you only use these programs as you would a tool and then complain when they don't do what you want them to do fast enough or reliably enough.
In literature, you have expectations but not certainty about the ending. Only with a bad tool do you expect anything but certainty about the ending. Indeed the hallmark of a good program is that you don't have to read it to know how it ends.
Another anti-parallel is that literature (literate programming) admires originality whereas good engineering admires plagiarism.
You seem to be willfully abusing the relationship between literature and literate programming. Knuth was being provocative in his paper in linking them, but these are very clearly not the notions Knuth has in mind.
His purpose is altogether simpler. From his paper, the literate programmer focuses on "exposition". He or she "chooses the names of variables carefully and explains what each means", and "strives for a program that is comprehensible... using a mixture of formal and informal methods that reinforce each other."
Literate programming is not there to entertain you. It's there to be understood. Beware the programmer who disdains comprehension of their programs.
No, I am not willfully abusing but thank you anyways.
Programs must be written for people to read, and only incidentally for machines to execute.
Literate programming is not there to entertain you. It's there to be understood. Beware the programmer who disdains comprehension of their programs.
Programs are pieces of engineering. As such they are meant to be used. Beware the programmer who admires their programming too much. If they have elegantly solved a problem that will come out in their solution's use and not in its literate form.
Yes, programs are there to be used. Literate programming as a technique, however, is designed to facilitate those programs being understood. I'm not sure how you conclude that this has anything to do with programmers "admiring their programming."
Did it for code reviews when I was code reviewing C[1]. It really does help. Paper still has a place. Its amazing what you see on a page of paper that doesn't get seen on the screen.
1) which, since I was doing the code reviews, I wasn't allowed to write any production code, because who would review my code? :(
For any non-trivial program, you can not keep the entire program in your head at once. Flawed human memory means that we forget details of the code six months later.
This means we need to read code, even our own code, to understand what it's doing. Code that is harder for us to read is harder to work on.
do you really disagree with the idea that writing code, like writing prose, should strive for human clarity? that you should be able to easily understand it without mental gymnastics? that the writer should revise, rewrite and edit the code, and take pride in succinct clarity? because the computer doesn't give a poop, but people do (including your future self)?
you seem to be making ancillary points while being deliberately obtuse about the central one.
Clarity is great. Clarity is really most awesome. Myself, I write clean readable code because the person who has to read it the most is me. Where I utterly disagree with the SICP drivel is its only incidentally nod to efficiency. What fatuous gratuitous twaddle.
Programs are meant to be used and only incidentally for people to read. Some programs, we'll call them closed source, can't even be read, not even by Richard Stallman.
BTW, SICP was a required text in 61A when I took it. Required but then like many bibles, never assigned and never read. A few years later, I tried to but couldn't and so I sold my copy on Amazon. Got $25 for it.
And regardless of the intention, code are read many, many more times than it is written, especially when you work in a company with multiple teams and that is spread out on multiple sites. And in my experience, badly written code causes bugs because the original intention is not clear.
Not this. x1.
Now if this were true, you would read these programs as you would literature. But you don't. Instead, you only use these programs as you would a tool and then complain when they don't do what you want them to do fast enough or reliably enough.
In literature, you have expectations but not certainty about the ending. Only with a bad tool do you expect anything but certainty about the ending. Indeed the hallmark of a good program is that you don't have to read it to know how it ends.
Another anti-parallel is that literature (literate programming) admires originality whereas good engineering admires plagiarism.