[pdftex] Re: TeX and friends and literate programming (was Re: [pdftex]
pdftex compression -- proposed addition to manual)
M. Wroth
mark at astrid.upland.ca.us
Mon Sep 10 22:59:24 CEST 2001
At 04:16 PM 9/7/01 -0400, Ed L Cashin wrote:
>"M. Wroth" <mark at astrid.upland.ca.us> writes:
> > One of the *reasons* I'm a believer in literate programming is that
> > it both gives good facilities for and strongly encourages good
> > commenting. Very few literate programs live up to Knuth's standard
> > of being enjoyable essays in their own right. But they seem to get
> > better comments than illiterate* programs.
>
>I was very excited about literate programming when I first heard about
>it, because I respect Don Knuth so much and because TeX is great
>software.
>
>However, when I learned specifics on how it works, I noticed that the
>things that it does can be done more succinctly in the code itself.
I'd be the first to admit that there are no literate programming
documentation / coding languages that combine the factors that I'd really
like to see in a tool. Programming languages have advanced in this regard
since I learned to program, and there are some nice features in various
languages (I like the docstrings in Emacs LISP, for example).
I would also freely admit that using literate programming is no substitute
for appropriate choices in variable names, function names and scope, and so
on (and I think Knuth would agree, if I recall the articles he wrote on the
subject correctly).
However, I believe that using literate programming tools in addition to
such techniques can help the maintainability of a piece of code
significantly. LP tools provide additional facilities for explaining what
is being done -- they don't have to take away from the inherent readability
of the code (although they can be abused to do so).
[...]
>While Knuth's code can create a nice book to read all the way through,
>it isn't the kind of code you can understand at a glance.
I doubt very strongly that any method will allow someone to completely
understand a program that does what TeX does at a glance -- the overall
logical structure of what needs to be done is too complex.
That's different than saying that individual snippets of code can or cannot
be understood quickly and easily. I find Knuth's code difficult to follow,
at least at times. But it's not at all clear that I'd find it easier to
follow if it was "plain" source, regardless of what other choices of
naming and scoping were made -- he apparently did a lot of work in TeX to
make it portable and efficient. That tends to conflict with easy to
understand and modify.
> And from
>what I hear it's not too easy to modify or extend. The reason it's
>successful is that it's so wonderfully efficient, effective, and
>bugfree. But I'd rather see a future with readable code than literate
>programs.
I'd like to see a future where appropriate documentation, targeted at the
intended human audience(s), is as much a part of writing code as the
computer itself is. I don't view that as a choice between readable code
and literate programs -- the two aspects of writing code are complementary,
not competitive.
But in the context of this list, what are you suggesting? I have suggested
that going to a literate programming tool would add capability in
documenting the pdftex code for better maintainability, and that this would
be a good thing. Possibly not the best thing -- but a good thing.
I debated setting up a couple of straw men for your suggestions, but
decided that such rhetoric would be counterproductive. What do you think
the maintainers (and developers) of pdftex should do?
Mark B. Wroth
<mark at astrid.upland.ca.us>
--- StripMime Report -- processed MIME parts ---
multipart/alternative
text/plain (text body -- kept)
text/html
---
More information about the pdftex
mailing list