4 ms·

I've read Knuth's article on this and here's my thoughts. It's meant to be used with a single language (Pascal), which is sometimes good (because the tool reall

I've read Knuth's article on this and here's my thoughts. It's meant to be used with a single language (Pascal), which is sometimes good (because the tool really understands Pascal and can parse these code snippets to produce a cross-reference), but it's also a curse, because many of the tool's constructs are actually workarounds for Pascal shortcomings. Also, it only generates a single file, but today's projects are both multi-file and multi-language. So it's a bit dated. I think the idea itself is so simple it doesn't really need any extensive book. Basically you take any text preparation system and add three elements: a code fragment, a reference to a code fragment, and a file, which is a fragment that will be written to disk. (I myself use such a system based on reStructured Text. I want to post it on Github when it's ready, but it's not there yet, so I cannot show exactly how it works. But I use it to write a moderately complex personal project with C and Python mostly, and all the tooling, e.g. Makefiles. I found it very helpful; it does make the code much cleaner, that is it strongly urges you to. And it's invaluable when you want to remember why you did things that way.)

crististm 10y ago
Isn't Knuth's CWEB used for C?
- Mikhail_Edoshin 10y ago
  CWEB is for C and the original WEB was for Pascal. (C is a good fit, by the way, because you can use #line directive to make the compiler to report the line numbers in your original literate files instead of the irrelevant line numbers in generated files.) But as far as I remember it still produces a single C file and a single TeX file.
  - e12e 10y ago
    When experimenting with NOWEB and Java (1.3 I believe) I discovered that one of the things that those LP systems did was encourage something like macro based code re-use, somewhat "lifting" the rather basic language up towards something a little more high level. This was good and bad; bad like unhygienic macros can be bad. As far as I could figure out it was a poor match for OO/"inheritance oriented" programming. It was a better match for procedural style programming - "writing C in java" - then the LP "macros" didn't confuse things. But when mixing OO-style java, I found things seemed to become uncomfortably verbose. NOWEB might in some ways be the worst of both worlds - it knows (and cares) nothing about the programming language - but that also means blocks can't be parameterized. This is annoying if you're using variables to hold iterators and state (traversing a graph stored in arrays as edge/node lists etc). You end up with dangerous variable name re-use or code duplication (and too big code blocks).

crististm 10y ago

Isn't Knuth's CWEB used for C?

Mikhail_Edoshin 10y ago
CWEB is for C and the original WEB was for Pascal. (C is a good fit, by the way, because you can use #line directive to make the compiler to report the line numbers in your original literate files instead of the irrelevant line numbers in generated files.) But as far as I remember it still produces a single C file and a single TeX file.
- e12e 10y ago
  When experimenting with NOWEB and Java (1.3 I believe) I discovered that one of the things that those LP systems did was encourage something like macro based code re-use, somewhat "lifting" the rather basic language up towards something a little more high level. This was good and bad; bad like unhygienic macros can be bad. As far as I could figure out it was a poor match for OO/"inheritance oriented" programming. It was a better match for procedural style programming - "writing C in java" - then the LP "macros" didn't confuse things. But when mixing OO-style java, I found things seemed to become uncomfortably verbose. NOWEB might in some ways be the worst of both worlds - it knows (and cares) nothing about the programming language - but that also means blocks can't be parameterized. This is annoying if you're using variables to hold iterators and state (traversing a graph stored in arrays as edge/node lists etc). You end up with dangerous variable name re-use or code duplication (and too big code blocks).