I would suggest to read Norvig's old Common Lisp code from his Paradigms Of Artificial Intelligence Programming masterpiece (and the whole book, of course).
AIMA and SICP are obviously good reads - the code is polished like fine poems.
Norvig's new Python courses on Udacity are also absolutely wonderful, but the classic books are still the classic books.
And then arc.arc, of course!)
That is sure mainstream.
For an example of what I mean, see underscore.js  and the prettyfied version of the source .
That said, my critique: http://akkartik.name/post/literate-programming (I actually read many of the programs in OP to write that.)
Code can be presented in a way that best suits the reader (versus the writer or the compiler). Though Knuth's examples usually seem to dive right in, lacking the introduction to be provided by the latest stuff in TAOCP.
When I use it, I write it like a paper decorated with code, where the code can be extracted and run. I usually include the necessary make file and perhaps some test data. Entries in figures/tables are sometimes generated automatically by the program being described.
There are lots of old papers and critiques about LP, by Knuth and others. You should check 'em out.
So, a lot of complexity is added to a program just so that it can be understood and maintained in a formal language; but he also states that many modern comment styles go a long way towards literate programming.
Having worked on large codebases I concur that using literate programming to construct these seems far-fetched and too academic, yet I am enticed by the idea of optimizing code by literate programming since I have seen far too many abstractions for the purpose of maintaining easy to read code.
> CWEB is a version of WEB for documenting C, C++, and Java programs. WEB was adapted to C by Silvio Levy in 1987, and since then both Knuth and Levy have revised and enhanced the system in many ways, notably to support C++ and ANSI C. Thus CWEB combines TeX with today's most widely used professional programming languages.
> If you are in the software industry and do not use CWEB but your competitors do, your competitors will soon overtake you---and you'll miss out on a lot of fun besides.
I guess it never took off due to the "I'll do it latter when I have time mantra". Documenting and testing are always seen as low priority.
Trying to convert maxcliques.w but it rightfully warns about missing gb_types.w
Is there a zip file with all programs and dependencies?
texlive-binaries ctangle also seems to be losing some formatting.
Literate programming is an interesting idea from academia, but in the engineering environment of most startups it's a waste of time. Our program sources are annoying byproducts of a business, not something of value unto themselves.
I've seen quite a few startups fail because they had a smart, but completely undocumented code base. Then the smart programmers leave and who is left cannot handle the code and new hires take too long to get into it. Then funding runs out and the apparent lack of progress ensures that nobody wants to put more money into the company.
> Literate programming is an interesting idea from academia, but in the engineering environment of most startups it's a waste of time.
Amazingly, we're actually getting back to something that resembles literate programming - via TDD. Instead of asking for a proper spec, we now ask for test definitions that the code must pass. Those can even be written in something that is pretty close to natural language (cucumber etc) so that management can write them. Then we spend time to make the test framework understand all those pseudo-natural-language test definitions and then we finally write the code. Is that really faster? Or are we just missing the tools that would allow us to tie a natural language specification to code?
This sounds so familiar ...
Then the engineers get to program in a less-powerful, more cumbersome language.
Maybe not ruined, but certainly severely hampered. I worked for several months with an original author of a 1M LOC application, and he was let go because the company was too cheap to re-up his contract. The documentation in that time was barely passable and it took many months of tweaking and breaking things just to get back to the point of becoming productive again. No one had a well-documented procedure on how to even compile the code until I decided to set my tasks aside(to my own schedule's detriment) so I could document all the steps and dependencies along the way. Luckily for them the company was well established and could afford the wait, others may not have that luxury.
I didn't say it had no value in general, just in a particular context.
brew install cweb
On my GNU/Linux box:
tar -xzf sgb.tar.gz
okular back-pdi.pdf &
gcc -o back-pdi back-pdi.c
back-pdi 2 1
If I remember correctly, the GraphBase source files start with the gb_ prefix (sorry, I'm ony phone so can't check).
Note: the Stanford GraphBase for me is an example of how a full blown library can be beautifully written in a literate style. Worth buying the hardcopy and reading it.
You could make things much more readable by just using decent formatting and descriptive variable names. I know, it's decorated C code, and academic C code at that, but damn, some of that stuff is a mess to try to read.
Maybe I've been in C#/Java/Python/JS land for too long, but javadoc/xmldoc/docstring documentation is a lot more readable. If you really want to, you can dump in markup, pictures, non-ASCII characters, etc into the html-based documentation.
The more I look at it, this stuff must be a monstrosity to try to actually write. I can't see it being at all attractive, unless you were doing well-defined, algorithmic code. Or you could write it in normal C and package it as a library that people might actually use.
It's hard to miss that it's on Knuth's website. Just because it's published by one of the gods of computer science doesn't mean that it is code in a style that anyone should be encouraged to emulate.