home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!gatech!purdue!mentor.cc.purdue.edu!noose.ecn.purdue.edu!samsung!nighthawk.clearpoint.com!transfer!m2c!jjmhome!smds!rh
- From: rh@smds.com (Richard Harter)
- Newsgroups: comp.lang.misc
- Subject: Re: Indentation
- Message-ID: <1992Aug31.014156.9282@smds.com>
- Date: 31 Aug 92 01:41:56 GMT
- References: <1992Aug23.215627.22233@smds.com> <1992Aug16.045245.9912@smds.com> <7050@charon.cwi.nl> <1992Aug18.065110.20337@smds.com> <id.Q0KS.MS1@ferranti.com> <1992Aug27.201810.20982@usenet.ins.cwru.edu>
- Reply-To: rh@ishmael.UUCP (Richard Harter)
- Organization: Software Maintenance & Development Systems, Inc.
- Lines: 106
-
- In article <1992Aug27.201810.20982@usenet.ins.cwru.edu> ah739@cleveland.Freenet.Edu (Leslie J. Somos) writes:
- >
- >In a previous article, rh@smds.com (Richard Harter) says:
- >[...stuff...]
- >>Too general. [This sentence no verb.] One can distinguish between
- >>forcing a choice between essentially equivalent alternatives and the
- >>eliminating the alternatives altogether.
-
- >Let's have some more choices than just 2.
- >"Anybody who says there are two sides to any question
- >suffers from a lack of imagination." -- ?
-
- Bah, humbug. You are making ontological commitments on my behalf that
- I do not acknowledge. The mere fact that I say that I can distinguish
- between red and blue does not mean that I am denying the existence of
- yellow and green, to say nothing of heliotrope.
-
- >>Consider the language FL (short for fascist layout).
- >[...]
-
- >OK, I believe most people would agree that choices in program layout are
- >just fluff, unimportant (in languages that don't care).
-
- >>Now consider the language FVN (short for fascist variable names).
-
- >STOP RIGHT THERE. I, for one, will not agree that choice of variable
- >names is not important. Of course, the compiler doesn't care, about
- >names or layout, that's why obfuscating programs work.
- >But variable names are _very_ important to humans who must read
- >programs.
-
- Er, one of us missing the point [assuming that there is one :-)]. In
- the deleted original it was assumed that names were drawn from predefined
- dictionaries. Consider the following argument.
-
- The term, computer language, is a misnomer. When I refer to
- a natural language such as English or French, I am referring
- to the both the grammar and the dictionary. Except for neologisms
- everyone writing English uses the same words from the same
- dictionary. When people speak of a computer language they
- specify only the grammar and a handful of words that are
- grammatical terms.
-
- Each program constitutes a language in its own right; the
- declarations in the program are its dictionary. Programs in
- a "computer language" are actually a family of languages, each
- sharing a common grammar.
-
- Suppose, when we read a book we had to first read the dictionary
- for the book that told us what each word meant. Suppose that
- we had to write a new dictionary afresh for each book we wrote.
- Not only would literacy plummet, with the vocabulary of each book
- being a major study in its own right, but the quality of the
- vocabularies would suffer, since each author must reinvent the
- English dictionary de novo.
-
- Surely we would consider such a state of affairs to be absurd.
- Yet we accept this state of affairs in computer software
- without question. Programmer A in program X uses the variable
- fooby; it is an integer signifying the number of chickens in a
- chicken coop. Programmer B in program Y uses the variable fooby;
- it is a character string in a class instance signifying the
- name of the city dogcatcher. The term, fooby, means nothing,
- or at best its meaning is a shadow written on the sand.
-
- How much better it would be if I could go from program to
- program and find that the meaning of variable names did not
- change capriciously. How much better would it be if I, as
- the author of a program, did not have to invent my own mini
- language anew with each new program.
-
- >You can have all kinds of constraints on what a compiler will/won't
- >accept, or relax them all you want. From a programmer's point of
- >view, the most important audience for a program is a programmer.
- >We don't care how hard it is for the compiler to handle it, we
- >would like to make it easy to understand a program that we have to
- >look at.
-
- I think you are assuming that the point of a FVN language is to simplify
- life for the compiler writer. Not at all. The point is to remove choices
- for the programmer that should not have to be made.
-
- You might very well argue that a FVN language is not practical, or that
- the notion is ill-judged, or that there are compensating advantages in
- creating separate notation for each program. However to simply claim
- that names are important to a programmer is to miss the point.
-
- I am far from claiming that FVN is the way to go. However there is much
- to be said for it, and obeisance is made to the concept in practice.
- Programmers do use standard include files and standard notation. The
- use of idiosyncratic substitutes for standard notation is generally
- recognized as creating maintenance problems, regardless of the merits
- of the idiosyncratic substitute.
-
- When I wrote English prose I do not feel handicapped by having to use
- words from the dictionary. I still have the freedom to choose which
- words to use and how to arrange them. Indeed, the quality of my prose,
- such as it is, would suffer immensely if I had to invent my own words
- and carefully explain them before I could say anything. One can at
- least entertain the suspicion that the same might be true of computer
- programming.
- --
- Richard Harter: SMDS Inc. Net address: rh@smds.com Phone: 508-369-7398
- US Mail: SMDS Inc., PO Box 555, Concord MA 01742. Fax: 508-369-8272
- In the fields of Hell where the grass grows high
- Are the graves of dreams allowed to die.
-