Literate programming in the form just described has attracted and retained a certain following since its development in the 1980s. There is an actively-maintained web site, http://www.literateprogramming.com, that has links to most of what has been published or made available by the practitioners of literate programming. But literate programming has never become really widespread in the programming world; especially, it has not penetrated industrial practice to any extent.
One reason for this, certainly, is that literate programming takes more effort than ordinary programming. Writing the explanations and commentary may or may not add extra work: one can argue that this is documentation that should be written in some form anyway. But it does take time to learn how to use a literate programming system. Perhaps worse, it takes extra effort as we are writing to mark up the document and to create the interconnections among the program fragments. For many of us, this is a distraction when we need it least, and not worth the trouble in the long run. It even takes a bit of extra effort to learn to read a literate program.
We believe that, for a technique like literate programming to be really attractive to the average programmer, it must be made as effortless and unobtrusive as possible. Programmers are notorious for resisting demands to document their work. On the other hand, Steve McConnell, a well-known writer on software engineering, says:
Most programmers enjoy writing documentation if the documentation standards aren't unreasonable. Like layout, good documentation is a sign of the professional pride a programmer puts into a program. ([McConnell] p. 453)
This is perhaps a bit optimistic, but we agree that it is true of many of the better programmers. We would add that we should make documenting as easy as possible on the programmer in all ways, including easy-to-use tools and techniques as well as reasonable standards, if we want the best chance of getting good documentation.