Knuth's "Literate Programming" was kind of otherworldly for me. I liked the idea that software could be written in a form indistinguishable from literature. I could not quite believe that it was reality -- and I'm still not sure it holds up in the real world -- but it's such a cool idea to have wrapped my head around at least once.
I think a cousin of Literate Programming that does work well is computational notebooks, like Jupyter. Interleaving code and textual description fits the exploratory workflows and scientific communication well. My favourite is Observable (https://observablehq.com/), where code has reactive structure (resolving a DAG like a literate program would at tangle-time), you can choose to keep some code hidden by default (to reduce clutter, make the document end-to-end readable), and use code to make the notebook fully interactive.
In terms of Knuth-style literate programming, Org Mode in Emacs, with its Org Babel feature, is a very good tool for this. It's an outliner with rich markup, and where you'd ordinarily insert a code block, in Org Mode, you can also execute it (works with any language you've configured Emacs to connect to) and feed the results to further code blocks. So it works like a computational notebook. You can also tangle the blocks to produce a separate source file, the Knuth way. One common application I've seen is making literate Emacs configuration - people prepare the minimum necessary to set up Org Babel, and then tangle the proper (often large) config from an .org file, where it's written in literate style.
As for my own experience, I occasionally try literate programming on small things, and so far - outside using org mode as a Jupyter alternative - I didn't feel more productive with it. I often flesh out the idea of a solution while writing it (I alternate between coding/recoding and design phases), and literate programming adds extra work - refactoring code means also refactoring the surrounding prose. On top of that, the narrative structure seems to interfere a bit with program's own architecture. I know it shouldn't (thanks to the way tangling works), but it somehow does in my head.
Org Mode and Observable are both performant enough. Unfortunately, they have their own limitation. In Emacs+Org Mode, you're working with a rich text display as a canvas, so while you can output images easily, forget about interactive GUI (charts, control sliders, what not) - at least without some dark hacking magic.
Observable - that's a true joy if you want fast feedback and interactivity. It's as fast as your browser, since your notebook is entirely client-side executed JavaScript. It's an order of magnitude better option than regular notebooks if you want to do some exploratory or scientific visualization. It's main drawback: JavaScript. That's what you're limited to. So forget about your favorite Python or R libraries (at least without dark hacking magic).
Observable did not handle my rendering requirements involving several hundreds of data points for my parallel coordinate plot. That said I'm not sure how it would fare outside of the notebook setting.
It should be as fast as equivalent visualization done in the frontend of a web page; after all, what you do in Observable gets directly executed by your browser. I wonder what your particular requirements are. On my end, I had acceptable performance on interactive prototypes involving updating multiple histograms, where inputs had tens of thousands of points.
”and I'm still not sure it holds up in the real world“
Writing literature is a solo endeavour.
Modern programming is more like writing scientific literature, where multiple persons collaborate, and reading and understanding earlier work and maintaining a correct set of links to such works is half the work, if not more.
That, I think, is why literate programming doesn’t quite work. It works for Mathematica notebooks, iPython notebooks and the like, but not for larger works.
For anyone who hasn't read it, I very much encourage it. I'm also deeply skeptical of its practicality, but modern takes on "literate programming" don't seem to capture what Knuth describes (and did). It's interesting.
