From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f34f1a1939dc0c40 X-Google-Attributes: gid103376,public From: Florian Weimer Subject: Re: conditional compilation Date: 2000/08/03 Message-ID: <87vgxjgv3q.fsf@deneb.enyo.de>#1/1 X-Deja-AN: 653904773 References: <87d7jvp3qq.fsf@chiark.greenend.org.uk> <39857E5F.33C40014@acm.com> <3985FB16.82D140BB@below.for.email.address> <8m6log$r3a$1@nnrp1.deja.com> <398749EF.15829554@below.for.email.address> Organization: Enyo's not your organization Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-08-03T00:00:00+00:00 List-Id: Robert A Duff writes: > Simon Brady writes: > > > Been there, done that... I think the literate programming crowd offer a > > useful insight here: programs aren't the same thing as representations > > of programs, and what the compiler sees isn't necessarily what the > > programmer should see. > > I don't like so-called literate programming for the same reason I don't > like C macros. In order to understand the code, you have to imagine the > actual output of the macro preprocessor. (I admit that C macros are the > worse of the two, of course.) I think this argument is valid only to a limited extent. After all, there are plenty of language constructs which can be used to hide details, and if a programmer has hidden the wrong details, this will always make maintenance unnecessarily complicated. Of course, the C preprocessor is bad, and its usage results in quite a lot of bugs. (IIRC the study carried out by Bell Labs on some of their telephone switching software showed this quite drastically.) Many of them are extremely non-obvious because there are many common idioms associated with C macros which you tend to ignore when reading the source, but which are quite intrusive and can cause bugs by itself. For example, after a while, you start to overlook the "do { ... } while (0);" construct to make a macro expansion a statement---until a "continue;" statement is part of the macro, which is supposed to effect an outer loop. :-/ (I guess C macros are used quite regularly to obfuscate flow of control because you can't use subroutines for that.) I don't have any experience in maintaining literate programs, but the last time I tried to read such code, the algorithms were in fact nicely documented, but even at the lower levels, the data flow was very hard to trace even locally (in contrast to the control flow, which was properly outlined, but which you could hide as well). In my experience, understanding the data flow is quite important if you want to do some non-trivial changes to existing code. I doubt that the literate programming approach as exemplified by TeX is really that maintainer-friendly. If you are interested in such stuff, TeX is very nice to read, but it's generally considered a dead end regarding future development. In fact, TeX has already been reimplemented in Java, AFAIK not in strict literate programming style. (Well, this reimplementation is also an involuntary case study in the portability of Java code with rather disappointing results.) > In any case, from a language design point of view, if you think the > compiler should see things in a different order or different > organization than human beings, then clearly the programming language is > poorly designed. This is a very good point. On the other hand, with most programming languages, you need some separate documentation for the overall structure of the code, general design decision and so on. AFAIK literate programming tries to merge this kind of documentation with the actual code.