necessary to re-run successful chunks. Toggle code display. In a formal publication one may not want any of the underlying code to be visible on the output. Meanwhile it is often valuable to show the (nicely formatted, syntax-highlighted) code that produces the results in the output format when you want the reader to see exactly what you are typing. Community. Perhaps the most compelling advantage of this approach over a homebrewed solution is the number of folks familiar with the model and trying to improve it. Lots of nice examples of other features can be found on the knitr webpage demos , including tools for "lightweight publishing" or sharing on the web. Many of these features help make this approach more compatible with one's general workflow, rather than something to do only when writing the manuscript. Historical footnote. While rooted in Knuth's "literate programming", as the name suggests, the emphasis is quite different, as literate programming focuses on connecting software code and documentation (in the R community that role is played by Roxygen , which traces its roots to a different branch of the "literate programming tree"). Going beyond In principle we might ask much more from a dynamic document, such as the ability of the reader to change the inputs and see the outputs without having to edit and recompile the entire document, for instance, using an interactive online platform. XDynDocs may be a step in this direction. Other approaches In a slightly different approach: A growing number of