Of course, the whole point of "literate programming" is to provide hints and structure for the human reader. This is done not by creating some structure in the code that makes sense to the compiler and a human, but by breaking up a program into pieces that are put together later.
I feel that this is really nothing that a good compiler couldn't do with a higher level language today. However, in doing so I would wind up with a heavily polluted namespace of helper methods and such that really don't help me understand what I was trying to do.
So, in the vein of reading code. I've only read a few sections of "The Stanford Graphbase," as I just got it a couple of weeks ago, but I can already tell this would have been a much better introduction to a few graph algorithms than I had in my undergrad.
Further, all of the "literate" programs I have written have been much easier for me to jump back into. Precisely because I have much of my "decoding" notes. So, code isn't literature, because we don't write it with a narrative for humans in mind. But, there is no real reason we couldn't.
I feel that this is really nothing that a good compiler couldn't do with a higher level language today. However, in doing so I would wind up with a heavily polluted namespace of helper methods and such that really don't help me understand what I was trying to do.
So, in the vein of reading code. I've only read a few sections of "The Stanford Graphbase," as I just got it a couple of weeks ago, but I can already tell this would have been a much better introduction to a few graph algorithms than I had in my undergrad.
Further, all of the "literate" programs I have written have been much easier for me to jump back into. Precisely because I have much of my "decoding" notes. So, code isn't literature, because we don't write it with a narrative for humans in mind. But, there is no real reason we couldn't.