[amelius]

I think a problem with literate programming is that programs are never written from top to bottom, at least not in conventional programming languages. The same holds for books, of course, but not in such a dramatic way. Therefore, I think the best way to read a program is not from top to bottom, but rather by using some kind of search tool.

By the way, does anybody know of an automated way to "grade" the quality of code documentation? I think this is what we need on repositories such as github, as it could stimulate the production of documentation of better quality (in most cases the documentation of OSS projects is rather poor).

[tunesmith]

Yeah, it just seems to me that wonderfully written literate documentation would be poorly organized software, and wonderfully organized software would be poorly organized documentation.

I guess what I mean by that is that as software scales out, your code will be more along the lines of "do this logic whenever this function/method happens to be invoked". So it would be great for documenting the workings of a function/method, but it would be poor for actually documenting the lifecycle of a logic path, like the lifecycle of a request. I certainly wouldn't have one file where I handle a request, do some business logic, and interact with a database, even though that is how you might document a lifecycle the request.

[bshimmin]

I fully agree with this and the grandparent. I've written a handful of literate programs, and I found that it worked nicely for a parser, which read from top to bottom in a single file, and it worked quite well for some unit tests, where the extra documentation and the tests themselves - which are quite self-documenting anyway - sat together rather nicely (though it was less well-received by my colleagues, who decried it as neurotic and pointless). My other attempts - particularly a small web app with a bunch of GUI components - were much less successful.

[jostylr]

Did you write it as a single file that breaks up into multiple files or was each separate file corresponding to a separate literate document?

My tool takes the approach of more of a literate-project approach where one file may generate multiple files (and multiple files could generate one file). The idea is that the organization is completely up to the author with no boundaries between how they want to organize it.

And referring to earlier comment, I would write the same flow of logic for a single thought in the same place. There is the flow of a single process and there are commonalities across processes. I think a good literate programming allows the uniqueness of a single flow to be put into one place and the commonalities to be extracted and applies to such a flow.

[mbrock]

I believe Knuth published the entire source code for TeX as a book consisting of the output from his CWEB tool. I would love to browse through it...

I mean, regardless of whether literate programming is viable for "enterprise software" or whatever, that's a wonderfully interesting cultural artifact... Inspiring!

Some implementations of Unix were also published as books, as well as the original source code for PGP (as a free speech trump card to defeat cryptography export restrictions).

These books, I presume, are archived by the Library of Congress, and will be around for a long time. Maybe one day we'll need them. Like if GitHub suddenly explodes and all the world's software is lost!

How to read and write programs is still something of an open question, as far as I'm concerned. The effort involved in caring for a "literate" code base, and indeed the literacy required, is probably too much for most projects. I don't think that makes it a "bad" model. It seems good to have tools available, and for people to try it out.

The Haskell world does a bit of literate programming, and tools like lhs2TeX are quite nice for preparing papers and such. There's something very beautiful about carefully written code that makes enough sense to be published as a "literate" paper.

[CuriousSkeptic]

I wonder, might a better metaphor be that of a journal, instead of a book?

A program has history, which, by the way, is stored in VCS, planning tool and communication, not the source code it self,

So how about a literate VCS?

Maybe you start with a tree structure to outline release planning and done branches, and break it down to individual updates against the current state of the source.

Might even keep contextual history like annotated repl invocations and throw away test code around.