sommar@enea.se (Erland Sommarskog) (03/26/88)
Frank Adams described who he would reduce a natural-language variable name. I applied his methods on natural language to show the defects. Ed Biagioni thought I was serious and objected strongly. Then Jonathan Eunice wrote: >If your aim is to be precise, symbolic notation wins every time. But >when your aim is to communicate, to be understood, then including the >redundancy is a Good Idea. Not just in natural language, mind you, but >in programming, mathematics, logic, and so on. The shortest statements >can take the longest time to read, because the reader must figure out >what it means, must translate or interpret it at read-time. Isn't this >why math, logic, and some C programs are so hard to figure out? It's >the classic space-time tradeoff: represent more compactly, but then you >must spend more time generating the desired information or details upon >retrieval. Efficiency of reading should be measured by how long it >takes to understand the material, not how long it takes the eyes to >scan it. When evaluating a notational scheme, such as a programming >language, it's the time-to-understanding figure that's important. > >Writing programs is a form of communication, with the machine somewhat, >but with yourself and other programmers, moreso. You must understand >your own code/theorems/methods to use/revise/prove/improve them, and >this is not as easy as it seems. That's often why bugs creep in -- >don't tell me you don't have bugs, even in the most precise symbolic >notation -- we often do not fully understand the >effects/side-effects/implications of our own code/decisions/methods. I usually try to keep quotes short, but this an exception. These words are just so good that they well deserve to be sent world-wide once more. I just couldn't agree more. To apply this further more, let me present one of my favourite thesis. (Which is more based on feelings than scientific research.) And, I am not talking just program code here, but rather documentation in general. In one sentence: You cannot make a description shorter than the information contained therein. More developed: A document may well be too verbose, contain redudant and irrelevant information which obscures the central meaning. Also you take much of the reader's time. (Or none at all if he ignores reading it. Even worse.) So it is a good aim to try to keep it short and concise. But, there is limit of short you can make it. If you go below this limit, the reader won't benefit of your page-cutting. The same amount of information is there, and the reader has to grasp it. I think many of you agree here. However, we do probably have different notions of where the limit goes. The discussion between me and Richard Harter on identifier names is one example. Another is the man-page for C-shell. I have heard those who have complained over its 18 pages, taking Bourne shell's five as a model. Myself I feel that this page is an typical example of over-compacted information. Now, many parameters are involved here. As for the man-page, different readers have different experience. (Myself, I am not a very experienced Unix user.) And its not any easy task to find the right level. And when it comes to such things as specification, you have issues as templates or not. I could go on, since this is an area that interests me. But I have to stop somewhere. I'm uncertain if this is the right newsgroup for discussing these issues, but I couldn't think of another that seemed fit for it, so I haven't cross-posted my article. If you have an idea of a better group, please introduce that one. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP