On Tue, May 6, 2014 at 2:22 PM, Tim Daly <d...@axiom-developer.org> wrote:

> Gregg,
>
> > My original comment on litprog ("bad bad bad") was admittedly a little
> > strong.  I think its bad for some things, fine for others.  And it's
> > possible litprog conventions will evolve to address the problems some of
> us
> > see with using it for programming in the large etc.
>
> Could you explain what "some of the problems some of us see with using
> it for programming in the large" might be? It is hard to refute
> "bad bad bad" and other assertions without specific examples.
>

Hi Tim,

I'm afraid it may take me a few days to find the time to respond properly.
In the meantime, aside from some of the responses in this thread, see
http://stackoverflow.com/questions/2545136/is-literate-programming-dead .

And here's a bit from Knuth (http://www-cs-faculty.stanford.edu/~uno/lp.html
):

"Literate programming <http://www.literateprogramming.com> is a methodology
that combines a programming language with a documentation language, thereby
making programs more robust, more portable, more easily maintained, and
arguably more fun to write than programs that are written only in a
high-level language."

"[T]hereby"???  This is an obvious non-sequitur.  To my knowledge neither
Knuth nor anybody else has ever produced a shred of evidence in support of
this kind of claim.   Probably because it is false on the face of it.  Note
the implicit claim, that litprog is an "effective methodology" that, when
followed, "thereby" results in all sorts of smooth buttery goodness
(compare "effective procedure").  But litprog is a norm or style, not a
methodology.  It provides no rules (methods) that all by themselves bestow
excellence on your text.  You can write crappy literate programs.

He continues: "The main idea is to treat a program as a piece of
literature, addressed to human beings rather than to a computer."  *Rather*
than to a computer?  I think not; nobody is interested in programs,
literate or not, that computers do not understand.  Furthermore, program
text is, has always been, and always will be a form of literary text, by
definition.  Knuth's use of the term "literate programming" is a mere
rhetorical trick since it (falsely) implies that programming that does not
conform to his (very personal) notion of what counts as literate is ipso
facto illiterate.

Ross Williams (funnel web guy) (from http://www.literateprogramming.com/):

"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."

I consider this a major part of what "classic litprog" means, and I think
it is preposterous, to be honest.  Just think of code and documentation as
text and commentary.  One writes commentary about texts, not the other way
around.

Of course, this is not necessarily what everybody has in mind when they
hear "literate programming".  In fact I gather it is not uncommon for
people to use "literate programming" to refer to tools that merely support
some kind of structured documentation syntax mixed in with code together
with some kind of tools to support fancy typesetting.  On that view
javadocs counts as literate programming.  But I think that's a confusing
abuse of terminology, since that isn't what litprog originally meant.

There's a lot more to be said about it, of course, but that'll have to do
for now.

And on the other hand, I'm entirely pragmatic about this stuff.  If
something works and people use it, who am I to argue?  I just don't think
it (classic litprog) works, at least not for certain important classes of
problem (programming in the large, with distributed very heterogenous
groups of programmers, etc.)  But there are lots of good docs tools that
draw inspiration and techniques from classic litprog even if they
themselves don't fit the profile precisley.


> Axiom (1.2 million lines of lisp) is being rewritten into a literate
> program. So far I can't think of a problem. Clojure is being reworked
> into literate form already


That's news to me.  Are you saying the core Clojure team is rewriting
Clojure in *classic* litprog style?  That would flabber my gast, to put it
mildly.

-Gregg

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to