Knuth's concept of Literate Programming (LP) has been around since he published his paper in 1984. (Auspicious year!) If it is such a good idea, how come that after 28 years, there are so few examples of real-world use?
Short answer: Because most programmers are not writing code for use as examples in books or academic papers, nor do they seek the understanding of those illiterate in the (programming) language of choice the code is written in.
Longer answers (not necessarily in order of importance or frustration factor!):
It's meaningless because: the compiler won't compile it; the interpreter won't interpret it; and nothing on earth will test it!
Is the phraseology clear? Are there no deceptive misspellings? No ambiguous punctuation?
Are the correct algorithms used? Is the logic, logical?
And when it comes time to re-factor a portion of one of the code snippets, that we move the appropriate subsections of the the original description to where ever the refactoring takes that portion of code.
Six times as many ways to cock up, and none of the unnecessary five will likely ever have any automation tools that can be applied to them. At least, it's very unlikely in the working careers of anyone currently earning a living as a programmer.
If you doubt that is a problem consider: Will compiler detected errors be reported in terms of their LP form line numbers or their post-processed form line numbers?
If you've used Inline::C (or any Inline::* language), they'll you'll undoubtedly be familiar with the game:
Doh! This ./_Inline/build/yourFile_dead_pl/yourFile_beef.xs Discard it!
*********AAAAAAAAAAAAAAAAAAARRRRRRRRRRRRGGGGGGGGG!!!!!!!!!!!!!**********
To see the point at its extreme consider the readmore in Re^3: WIN32-API Purgetory. Those 4000 lines of unintelligible code, manually extracted from amongst 26,000 lines filtered from a file containing 114,000 lines, are the result of applying a pre-processor to just 785 lines of source code input.
If you want easy maintenance?
Polluting the programmers primary workspace, in the ratio of 3 or 4 lines of noise to every line of productive code; and re-ordering the useful bits in some arbitrary fashion; using textual substitutions to further obfuscate things; and then adding another layer of indirection between what the programmer writes and the processor attempts to run --there are already too many levels--is not the right way to go about it.
Architects do not record their stress and strain calculations, or materials assessment tests on either their blue prints, or on the side of the building and bridges the design.
Or consider your lawyer presenting you with legal documents liberally strewn with footnotes and margin annotations of the form:
++Consider the term habeas corpus and the clarification of that term as laid out in Simpson v. Flanders (1999) and its the subsequent refinement in Itchy v. Scratchy (2001)
The programmers job is to write programs--not teach newbies how to program. There are schools and courses for that.
If you've any musical ability (I've none), then maybe this will convince you.
Imagine your average orchestra musician sitting down to a score like this:
At the start of this piece the mood is melancholic. Don't be too s +trident. If you're playing the piano, press that "quiet pedal" a lot. If you're the tympanist, use your left hand to dampen the ketties +for the first few bars. Violins, blur the transitions between strings and 'bend' from note + to note. ===== ... ==*== ... ----*-... In these few bars, we start to get the sense of something awaking. + Piano, use the "soft pedal" less and less from beginning to the en +d of the passage, Toward the end, add the "loud pedal" on occasional sharps and flat +s. The kettles should be allowed to ring a little; and little more as + the passage progresses. Violins: Slowly clean up you transitions and blur them less and le +ss. = = - Bassists: This is your regular rhythm to be maintained throughout +the piece: = = - But there are two variations on this which you alternate between for the first two bars at the start of every other stanza--after t +he first four-- and for the last two bars of the alternate stanzas. = ... = ... = ... = ... - ... - ...
But also because their restricted syntax makes it easier to write correct, unambiguous and verifiable descriptions of algorithms. Neither English, nor any other natural language is a suitable substitute. And I'll stick my neck out and say: and never will be.
And the idea that writing code twice--once in the computer language; and a second time in an unverifiable, inherently ambiguous, infinitely variable of style--will some how render programs more reliable doesn't hold water.
In reply to Re: An Introduction to Literate Programming with perlWEB
by BrowserUk
in thread An Introduction to Literate Programming with perlWEB
by adamcrussell
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |