Bubbles_glow

≡ Literary Systems ≡

 
Corner_fold
  • Citation
  • Extension
  • Response
  • Comment
Hopo_catalog
 
Flowchart_grey_24

Literate Programming

If there is a godfather of code, a Don Corleone of algorithms, then it is certainly Donald Knuth. His multi-volume masterwork, The Art of Computer Programming, is widely regarded as the definitive treatment of the field. It's legendary both for its difficulty — the example problem sets range from simple homework to major unanswered research questions — and for its mathematical rigor. But this man, whom many would consider to be an engineer's engineer, has a decidedly different attitude when it comes to the art of computer programming. Since the early 1980s, Knuth has been a vocal proponent of something that he calls "Literate Programming." He writes:
"Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to a human being what we want a computer to do. The practitioner of literate programming can be regarded as an essayist, whose main concern is with the exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of the variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its contents have been introduced in an order that is best for human understanding."

"I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature."
The kind of code style that they teach you in school is to write the obvious. To avoid cleverness, aim for minimal complexity, and use standard, unexotic techniques. This sort of lowest-common-denominator coding style may or may not be an efficient way to write programs in large, corporate groups, but it's most certainly bad literary style. Writing novels in the language of "See Spot Run" makes very little sense, and, as writers, we certainly wouldn't listen to the argument that it needs to be written at a 2nd-grade reading level so that everyone can (potentially) read it. Knuth understands this, and so his call for a Literate Programming is not a call for pedagogy, but a call for literature. The complexity at the heart of interesting programs can never be vanquished, just pushed around, spread out, or polished up and presented, jewel-like. These baroque complications call for sophisticated, multi-level, clear communication, bearing the reader along a well-defined trajectory of thoughts, leading to the inevitable ending. Execution.



 
InformIT.com has a recent interview with Knuth, in which he gives an explanation for why literate programming has never caught on:

"Literate programming is a very personal thing. I think it’s terrific, but that might well be because I’m a very strange person. It has tens of thousands of fans, but not millions.

In my experience, software created with literate programming has turned out to be significantly better than software developed in more traditional ways. Yet ordinary software is usually okay—I’d give it a grade of C (or maybe C++), but not F; hence, the traditional methods stay with us. Since they’re understood by a vast community of programmers, most people have no big incentive to change, just as I’m not motivated to learn Esperanto even though it might be preferable to English and German and French and Russian (if everybody switched).

Jon Bentley probably hit the nail on the head when he once was asked why literate programming hasn’t taken the whole world by storm. He observed that a small percentage of the world’s population is good at programming, and a small percentage is good at writing; apparently I am asking everybody to be in both subsets.

Yet to me, literate programming is certainly the most important thing that came out of the TeX project. Not only has it enabled me to write and maintain programs faster and more reliably than ever before, and been one of my greatest sources of joy since the 1980s—it has actually been indispensable at times. Some of my major programs, such as the MMIX meta-simulator, could not have been written with any other methodology that I’ve ever heard of. The complexity was simply too daunting for my limited brain to handle; without literate programming, the whole enterprise would have flopped miserably.

If people do discover nice ways to use the newfangled multithreaded machines, I would expect the discovery to come from people who routinely use literate programming. Literate programming is what you need to rise above the ordinary level of achievement. But I don’t believe in forcing ideas on anybody. If literate programming isn’t your style, please forget it and do what you like. If nobody likes it but me, let it die."