The unpopularity and inherent goofiness of literate programming, and the way Knuth always mentions it in interviews, feels like a sort of elephant in the room whenever a new interview appears.
A literate program, Physically Based Rendering, recently became the first book to win an Academy Award for it's technical contributions to the film industry. In the acceptance speech, the writers thanked Knuth for the concept. http://www.youtube.com/watch?v=7d9juPsv1QU
The book can be compiled into the production-quality renderer http://pbrt.org/
It's not popular, but I don't see it as at all goofy. When I have a well-defined but difficult segment of an application to write, I whip out my literate-programming tools so I can get it right the first time, document the heck out of it, and be able to get back into its complexity if I ever need to change it. It's a fabulous, almost magically successful technique, even if I don't use it for most of the code I write.
I think of it as analogous in feeling and usage to how a musician practices a difficult passage slowly, with a metronome, perfecting it at gradually increasing speeds until they can play it perfectly at speed. It's tedious and time-consuming, so I tend only to use it when I feel the need, but when I do, I'm glad it's there.
The closest thing I've seen to literate programming "in the wild" is the ipython notebook concept, which encourages you to intersperse your code with explanatory text to give it context and structure (eg http://nbviewer.ipython.org/github/corbt/city-weather/blob/m...). I don't think it's the right fit for all (or even most) programming, but I like it for that class of programming because often a reader is more interested in why you chose to do what you're doing, rather than what the code actually does.
I always understood literate programming as a tool for teaching and not as a tool for writing software.
As I've written more and more about code I wrote, I've found myself inventing weird ways of making sure the code samples are compilable, runnable and correct. I've done it enough that now I'm considering using a literate programming tool next time.
(To be clear, I'm not referring to traditional API documentation with examples. There exist good tools for testing examples without resorting full-hog to literate programming. I am referring to more general prose whose aim is less specific than documenting an API.)
The only example of actual literate programming with CWEB I've seen in the wild - aside from TeX, whose source code I've actually not read - is Adam Langley's extracted crit-bit trie code, taken from DJB's C stuff: https://github.com/agl/critbit
The excellent book "C Interfaces and Implementations: Techniques for Creating Reusable Software" by David Hanson as well as "A Retargetable C Compiler: Design and Implementation" by the same author are both written in the literate programming style.
I'd definitely say it's unpopular, but hardly goofy from a pedagogical point of view. C Interfaces and Implementations is such a beautiful book and the literate programming style really compliments it well.
There are two aspects to Knuth-style literate programming:
(1) the primary emphasis is on the description and commentary rather than on the code;
(2) the order of presentation is determined by the description rather than the program.
The first is a useful and valuable tool. The second is an artefact of using a language like Pascal which has a strict inflexible order to its code and no suppor for modules. If you have a decent language then literate programming is just a different kind of comment syntax.
