🚀 go-pugleaf

In article <1992Sep10.152641.1878@informatik.uni-bremen.de>, ms@lehre23.informatik.Uni-Bremen.DE (Martin Schroeder) writes:
> I think Literate Programming is quit appealing, but as far as I know the only
> large literate programs are TeX and Metafont. 8 years after Knuth's article this
> isn't very much. So:
>  - Is Literate Programming only for the academics?
>  - If it is: Are there any experiences with LARGE programs?

I will surely not qualify, since I'm an academic, but what the heck:

In the last 10 years we have written (and successfully maintained)
about 30 MB of code in languages of the WEB family. Systems range
from a few 100KB to 10MB source. The average system has between 1 and
2 MB source code.
    Sources are mainly concerned with the interpretation and handling
of formal languages. Btw, we don't use (Pascal) WEB. Many of our old
sources are in C, with lex and yacc parts. (Ever tried to understand
an old lex source written by someone else who is not reachable any
more?) Newer sources are in C++, Prolog, etc.

But, I don't consider systems of this size as `LARGE programs'. (But
we never write large PROGRAMS anyhow, we write software systems. ;-)

So, why do I answer? Because I think your question is a wrong one.
    Eg, we now know that Structured Programming is not a good way to
write large software systems. Ie, it is not appropriate for the
problems of Programming-In-The-Large. But does this make Structured
Programming obsolete? No: One still needs it for the realization of
the components during the various implementations phases of a
software life cycle.
    IMO the same applies to Literate Programming. It's a method for
Programming-In-The-Small, and questions about it's usability for the
problems of Programming-In-The-Large (not to speak of Wegner's
Megaprogramming) are of course answered negatively. A pencil is not
the best tool for creating a 3D-plan of a Space shuttle. But it still
has its place.

Our experiences with LitProg in the realization of components (read:
classes or modules, depending on your SE standpoint ;-) are _very_
good, especially with our high fluctuation of people (a lot of
students are working for us). Since our specifications are marked up
in TeX anyhow, the documentation can more easily link the
implementation back to the specs. The development costs are higher,
but this pays off during maintaining phases. (Code review times have
shortened, though.)
    What is still missing, is support for the documentation of the
link between the design specs and/or the requirement docs and the
component specs/implementations. Not to speak of CM stuff. (But that
will come.) Oh yes, and the automatized check of (documented) links
between the info created by a test coverage system (like gct) and the
regression test cases is also on my wishlist... The connection of
LitProg concepts and hypertext techniques seems to promise a lot.
    So what, shall I stop using an approach which has shown to be
very good in our work just because there are still open problems?
Problems that are not solved otherwise as well? It simply tells me
that there are still open problems which we should attack, nothing
less, nothing more.

--
Joachim

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: schrod@iti.informatik.th-darmstadt.de
    Technical University of Darmstadt, Germany
    Computer Science Department
    WG Systemprogramming