250bpm

I've spent some time thinking about the subject. Critique: http://akkartik.name/post/literate-programming. My current improvement on it is a notion of layers: http://akkartik.name/post/wart-layers. My current project is at 9kLoC programmed entirely using layers.

Are you familiar with orgmode and babel? http://orgmode.org/worg/org-contrib/babel/

If you want to see literate programming done right, look at the book "Phyically Based Rendering" by Pharr and Humphreys. Now imagine that you just joined a project. They give you the book, send you to Hawaii for a couple weeks, and then see how well you can maintain and modify the project.

If real projects were maintained with the same level of human-to-human commuication there would be a lot fewer "legacy" projects. The U.S. is still using air traffic code from the 1960s. The Railroad retirement board has a huge legacy code base they can't maintain. Many other government agencies have the same problem.

In fact, you might run into the same problem if you ever get a chance to write code you wrote 10 years ago. You'll know WHAT it does but not WHY it does it. Literate programming is about writing down the WHY, not HOW.

Another application of literate programming is writing verifiable documentation. I like using Dredd. You write documentation for you REST API in Markdown and the document itself can be validated. It saves a lot of time during development, especially on communications.

Link: https://github.com/apiaryio/dredd

Looking forward to the answer to that question. I am interested in the interaction of software to the users of the software and how they can adapt it.

I've written a couple of literate programming plugins for Pandoc ( http://pandoc.org ), which I've written about at http://chriswarbo.net/essays/activecode/index.html

I tried to use Babel, as mentioned in another comment, but found it too bloated and complex. My approach is pretty simple in comparison: code blocks can be annoted with a shell command, which they're piped into, eg.

‘``{pipe="python"}
echo ’Hello world'
```

Most actions can then be achieved in a regular Unix way (eg. by reading/writing files, calling programs from scripts, etc.)

Addressing this problem is the basic idea behind this research: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6344472&filter%3DAND%28p_IS_Number%3A6344456%29

It is generally about documenting and sharing problem-solving knowledge. As you note, this means one sort of thing for a computer scientist writing a paper, but something more pragmatic to an end user or business.

The software evaluated in this research was more of a traditional spreadsheet and GUI design, but other work looked at a test-based approach with something like Markdown. Something similar is going on in the data science community with "notebook" tools like Jupyter and Beaker.