In our "lightweight" approach to literate programming, the biggest simplification is to eliminate the markup that creates the hierarchical structure of cross-references among the code fragments. Instead, the fragments simply appear in the document in the same linear order in which they will appear in the executable program. Many practitioners of traditional literate programming, as Knuth defined it, would not consider this approach to be "literate programming" at all: they would say that an essential part of literate programming is the freedom to present code sections independent of the order in which the programming-language compiler or interpreter will see them.

However, we believe that the key concept of literate programming is the emphasis on exposition to humans, in which the primary artifact is a document -- more specifically, an essay -- with the code of the program embedded in it. Knuth's original approach is one possible means to that end, but is not necessarily the only one. With apologies to Knuth, then, we take the liberty of stretching the definition of his term "literate programming" to include the lightweight approach presented here.

In our work, we seldom find it difficult to present code fragments in an order that we think works well for exposition, yet is acceptable to the compiler or interpreter of the programming language. Most modern languages allow much more freedom of ordering than Pascal, the language that Knuth used. Furthermore, some of these languages -- in particular, the object-oriented ones -- allow and encourage the programmer to place together, in modules and classes, constructs of various kinds that are logically related. They would belong together for purposes of exposition anyway, and quite naturally fall into sections and subsections in our literate-programming documents.

Yes, our lightweight approach sacrifices some of the freedom of expression of Knuth's approach but, to compensate, we believe that we make it significantly simpler and easier for programmers to do "literate programming" in practice. As an engineering tradeoff, we consider this a win.