Nobody uses/wants to use literate programming

The tools are/have been too complex. The first literate programming tool (WEB) offered too many commands and it was hard to get into the new paradigm if there are so many new things to learn about it that the cost of learning the language may outweigh the benefits. In addition, too much time was spent fiddling around with WEB's prettyprinting rules. [2,3]

My opinion: All literate programming tools are very simple compared to the computer language and the formatter language themselves. If people are not able to read 15 pages of documentation and learn some (not even all) new commands, they should better go and find a new job. In addition, learning how to write a good literate program takes you much longer than learning how to master the tool. Conclusion: You can learn how to write literate programs with any tool. In case of CWEB which is regarded as a rather `complex' tool: Just forget about the formatting commands, if you are trying to get into the new paradigm.

Literate programming does only cover a small part of the life cycle (namely implementation and maintenance). Most if not all programs published as examples for literate programming are either small or do not come with their specification and design document that have to be taken into consideration when reading an example for a literate program that should illustration how to use this new technique. [4]

My opinion: Literate programming was never meant to cover the whole life cycle of a software project. People should try to understand that there are no step-by-step methods that are water-proofed guides to the `perfect solution'. In addition---as indicated by the same authors in [5]---literate programming should only contain the design document and is not necessarily a design language in its current form. I have the impression, programmers still are waiting for the final big-bang solution that will make programming an easy task. Small improvements are generally ignored. Note that some `tools' that do not even introduce new paradigms promise 100% more productivity. In other words: you can do the same project in half the time, something that you could only achieve if you can eliminate, say, the whole implementation and test phase of your project. (I am not talking about new tools for formal software verification, they are usually announced with much less enthusiasm). Literate programming does not and can not claim such impressive (and ridiculous) increases of productivity. However, it seems that managers are more willing to take a look at tools than at new paradigms because tools are usually simpler to introduce and don't require that much effort than a whole new paradigm which does not promise much more than `quality', something customers are not ready to pay for, yet. Conclusion: Literate programming does not make traditional approaches of software engineering obsolete. It is just another little piece in the mosaic generally known as `software engineering'.

Both arguments given in the papers above are true up to a certain point, but neither the effort you have to make to master the tools nor the fact that literate programming does not provide a solution to the software crisis are the reason why literate programming is not accepted by a wider audience. Some of the `real' obstacles are:

• Writing a literate program seems to take too much time and in `real life' projects, time is always short. Although Knuth wrote in [1] that he made the experience that writing programs with WEB takes him no longer than writing an ordinary PASCAL or ALGOL program, no empirical studies exist (However, I tend to agree).
• `Modern' programming environments are very monolithic (they call it: integrated). Most new applications are for MS operating systems and the compilers on these systems have an integrated editor which does not accept anything else but pure C/C++ code. No way to run a preprocessor. Since most universities use UNIX, maybe this also explains why literate programming is still more or less academic. Many parts of the user interface are automatically created by `visual' programming environments which create C code. This code does not fit into the literate style.
• Maybe the biggest hurdles: Programmers that have been working with an environment they are used to avoid everything that's new and could force them to change their way of working. If not true, why are there still that many people who start writing new COBOL programs?
• Literate programming is always associated with documentation and documentation is something most programmers as well as their managers regard as a nuisance, something you have to do but which does not really contribute anything real. Programmers are against literate programming because they are afraid of having to document even more than now.

I found out that the more talkative people are the more likely they are to accept the new style. So, is literate programming something for people who like to talk to an audience (like Knuth) and to explain what they are doing? Is it only by chance that most people who have published literate programs also publish `ordinary' articles and books? Or is there any chance that it will gain more acceptance in the future? Discuss.

[1] D.E. Knuth: Literate Programming. The Computer Journal, 27(2):91-111, May 1984

[2] Ramsey, Marceau: Literate programming on a team project. Software---Practice and Experience, 21(7):677-683, July 1991

[3] Norman Ramsey: Literate-Programming Tools Need Not Be Complex Report at ftp.cs.princeton.edu in /reports/1991/351.ps.Z.

[4] D. Cordes, M. Brown: The Literate-Programming Paradigm IEEE Computer, 24(6):52-61

[5] M. Brown, D. Cordes: Literate programming applied to conventional software design. Structured Programming, 11(2):85-98, 1990

Good question. I know that whenever I try to introduce literate programming techniques on a project most of the team responds "Literate what?" or "what's that?" I think what literate programming lacks is commercial exposure. Everyone has heard of Java because of the marketing force behind it. No one is pushing literate programming in the marketplace.

True. However, I write all of my interface code using literate programming while learning a new library (API). Only after getting comfortable with it do I turn to the tools to create the UI for me. This way I have documented samples of code for reference.

Yes. To the literate programming novice literate programming may seem like a ton of work. However, after getting acquainted with it I failed to see anyone proclaim it a bad thing. The trick is to get them to use it.

Literate programming is for people (programmers) who like explain what they are doing. Knuth has published literate programs but I am willing to bet that he has many more unpublished ones. I have many unpublishable literate programs that I work with.

I don't think so because the authors probably would have published anyway. They merely chose literate programming as a form of presentation for technical problems.

I am betting on it.

Funny you should mention Java. An article in the recent Dr. Dobbs brought something to my attention... the Java SDK comes with a literate programming tool, javadoc. So what's that about literate programming not being pushed in the marketplace like Java? I think, it's just a matter of time before any programmer exposed to literate programming "comes around". I am still in the process of that myself, in fact. Twelve years may seem like a long time, but we're not talking about going from C to C++ to Java (with a stop at Objective C along the way)... we're talking about a complete about-face in the way things are done. But, "it's just done that way."

Sometimes I thought it might be a habitual effect or--inertia. The dread of the new. The threatening words: ``Tell me what you are thinking!'' Could that be overcome by the strong force of entrepreneurial pressure? Or by just trying it and finding it works? (``Now, that wasn't that hard, was it?'') What about a competition?