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. Hence, my title: "Literate Programming. Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do. The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means.
|Published (Last):||17 October 2014|
|PDF File Size:||9.72 Mb|
|ePub File Size:||18.21 Mb|
|Price:||Free* [*Free Regsitration Required]|
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. Hence, my title: "Literate Programming. Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.
The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.
A traditional computer program consists of a text file containing program code. Scattered in amongst the program code are comments which describe the various parts of the code. In literate programming the emphasis is reversed. Instead of writing code containing documentation, the literate programmer writes documentation containing code.
No longer does the English commentary injected into a program have to be hidden in comment delimiters at the top of the file, or under procedure headings, or at the end of lines. Instead, it is wrenched into the daylight and made the main focus. The "program" then becomes primarily a document directed at humans, with the code being herded between "code delimiters" from where it can be extracted and shuffled out sideways to the language system by literate programming tools.
The effect of this simple shift of emphasis can be so profound as to change one's whole approach to programming. Under the literate programming paradigm, the central activity of programming becomes that of conveying meaning to other intelligent beings rather than merely convincing the computer to behave in a particular way.
It is the difference between performing and exposing a magic trick. Listings generated by the WEB system are unlike any other form of program listings in existence. They resemble programs from computer science textbooks rather than listings from executable programs. WEB utilizes the TeX document compiler, which includes a typesetting command language capable of tremendous control over document appearance. TeX automatically handles details such as microjustification, kerning, hyphenation, ligatures, and other sophisticated operations, even when the description part of the source is simple ASCII text.
WEB adds functions which are specific to computer programs, such as boldface reserved words, italicized identifiers, substitution of true mathematical symbols, and more standard pretty-printer functions such as reformatting and indentation.
The whole concept of code sections, indeed structured programming, is to reduce the amount of text that must be read in order to determine what a piece of code is doing.
The code section is a form of data reduction in that the section name is a placeholder representing the code contained in that section.
Anything that is logically part of the section should be moved into it, thereby reducing the complexity of the code where it is referenced. I use the following list of requirements to imply a definition of a literate program and the minimum set of tools which are needed to prepare, use, and study the resulting code. WEB's design encourages writing programs in small chunks which Knuth called modules he also used the term sections.
Modules have three parts: documentation, definitions, and code. At least one of these three parts must be non-null. The documentation portion is often a verbal description of the algorithm. It may be any textual information that aids the understanding of the problem. These usually describe the problem independent of the chosen language for implementation. It should be an unusual but not exceptional case when a module contains no documentation.
The key features of literate programming are the organization of source code into small sections and the production of a book quality program listing. Literate programming is an excellent method for documenting the internals of software products especially applications with complex features. Literate programming is useful for programs of all sizes.
Literate programming encourages meaningful documentation and the inclusion of details that are usually omitted in source code such as the description of algorithms, design decisions, and implementation strategy. Literate programming increases product quality by requiring software developers to examine and explain their code.
The architecture and design is explained at a conceptual level. Modeling diagrams are included UML. Long procedures are restructuring by folding portions of the code into sections. Innovative ideas, critical technical knowledge, algorithmic solutions, and unusual coding constructions are clearly documented. Literate programs are written to be read by other software developers.
Program comprehension is a key activity during corrective and perfective maintenance. High quality documentation facilitates program modification with fewer conceptual errors and resultant defects. The clarity of literate programs enables team members to reuse existing code and to provide constructive feedback during code reviews. Organization of source code into small sections.
The style of literate programming combines source code and documentation into a single source file. Literate programs utilize sections which enable the developer to describe blocks of code in a convenient manner. Functions are decomposed into several sections.
Sections are presented in the order which is best for program comprehension. Code sections improve on verbose commenting by providing the ability to write descriptive paragraphs while avoiding cluttering the source code. Production of a book quality program listing. The typesetting language enables all of the comprehension aids available in books such as pictures, diagrams, figures, tables, formatted equations, bibliographic references, table of contents, and index.
The typographic processing of literate programs produces code listings with elegantly formatted documentation and source code. Listings generated in PDF format include hypertext links. Remember the Basics. There are many factors involved in developing excellent software.
Literate programming is just a single technique to be used along with all the other well established software engineering practices. Here are some software practices related to program documentation:. I had a discussion with him in approximately ; I'm trying to remember the exact time, maybe , yes, , perhaps when I visited Newcastle?
I don't recall exactly the date now. He said to me that I should publish my program for TeX. Hoare had heard rumors about my work and he wrote to Stanford suggesting that I keep publication in mind. I replied to his letter on 16 November much earlier than I remembered. As I was writing TeX I was using for the second time in my life ideas called "structured programming", which were revolutionizing the way computer programming was done in the middle 70s. I was teaching classes and I was aware that people were using structured programming, but I hadn't written a large computer program since In I wrote my first structured program; it was fairly good sized-maybe, I don't know, 50, lines of code, something like that.
That's another story I can tell you about sometime. This gave me some experience with writing a program that was fairly easy to read. Then when I started writing TeX in this period I began the implementation of TeX in October of , and I finished it in May 78 , it was consciously done with structured programming ideas.
Professor Hoare was looking for examples of fairly good-sized programs that people could read. Well, this was frightening. This was a very scary thing, for a professor of computer science to show someone a large program.
At best, a professor might publish very small routines as examples of how to write a program. And we could polish those until Tony Hoare was a great pioneer for proving the correctness of programs. But if you looked at the details I discovered from reading some of the articles, you know, I could find three bugs in a program that was proved correct.
Now, he says, take my large program and reveal it to the world, with all its compromises. Of course, I developed TeX so that it would try to continue a history of hundreds of years of different ideas. There had to be compromises. So I was frightened with the idea that I would actually be expected to show someone my program.
But then I also realized how much need there was for examples of good-sized programs, that could be considered as reasonable models, not just small programs. I had learned from a Belgian man I had met him a few years earlier, someone from Liege , and he had a system-it's explained in my paper on literate programming. He sent me a report, which was pages long, about his system-it was inspired by "The Ghost in the Machine". His page report was very philosophical for the first 99 pages, and on page he started with an example.
That example was the key to me for this idea of thinking of a program as hypertext, as we would now say it. He proposed a way of taking a complicated program and breaking it into small parts. Then, to understand the complicated whole, what you needed is just to understand the small parts, and to understand the relationship between those parts and their neighbors.
And I showed that to Tony Hoare and to several other people, especially Luis Trabb Pardo, and got some feedback from them on the ideas and the format. Then we had a student at Stanford whose name was Zabala-actually he's from Spain and he has two names-but we call him Inaki; Ignacio is his name.
TeX-in-Pascal was distributed around the world by , I think. Then in or , when I was writing TeX82, I was able to use his experience and all the feedback he had from users, and I made the system that became WEB. At that time, we had about 25 people in our group that would meet every Friday. The "Holon" concept has been introduced in biological and behavior sciences by Koestler.
This concept proceeds from the work of Simon. It is used for instance to analyze complex living organisms or complex social systems. This neologism is from Greek "holos", i. A holon is a "part of a whole".
I started finding myself making excuses for my lack of ability. Programming books are universally boring. Typically they also like to mention that the arcana will be demystified in another chapter. One where I could interact with the example code as I typed it. I wanted to end up with a full understanding before I pressed that run button for the first time, not after.
Learn To Program With Literate Programming
Literate programming is a programming paradigm introduced by Donald Knuth in which a computer program is given an explanation of its logic in a natural language , such as English, interspersed with snippets of macros and traditional source code , from which compilable source code can be generated. The literate programming paradigm, as conceived by Knuth, represents a move away from writing computer programs in the manner and order imposed by the computer, and instead enables programmers to develop programs in the order demanded by the logic and flow of their thoughts. Literate programming LP tools are used to obtain two representations from a literate source file: one suitable for further compilation or execution by a computer, the "tangled" code, and another for viewing as formatted documentation , which is said to be "woven" from the literate source. Literate programming was first introduced by Knuth in