From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: Wed, 8 Sep 93 10:21:19 -0700 From: mshapiro@manta.nosc.mil (Michael D Shapiro) Subject: Re: 30 Years Message-ID: <9309081721.AA18798@manta.nosc.mil> List-Id: In article stt@inmet.com (Tucker Taft) writes: > In article <9308251529.AA07664@manta.nosc.mil> > mshapiro@MANTA.NOSC.MIL (Michael D Shapiro) writes: > > > . . . > >Because I believe Ada cannot always be used cost-effectively for small > >or short projects (using my definition of a project), I do advocate > >that more appropriate languages be used for small or short projects > >where they are more cost-effective. We need some guidelines as to > >where the cost-effectiveness breakpoints come. I think the language > >choice really does not matter on true small/short projects because no > >one will need to look at the source code except the developers. Ever. > > > >Probably what we should really hope that someone is looking for the > >successor to Ada and C++ and {insert your other favorite language here} > >that takes the most appropriate properties of each and combines them > >into a new tailorable language. As I see it, this language should have > >multiple formality levels. High formality would be required for huge > >systems. Informality would be allowed for throwaway programs. > >In-between systems would need to conform to some intermediate formality > >levels. > > I guess I don't understand this concept of "formality" at all. > Of course any document that is an ISO standard has to be formal. Take a look > at the seven phases of source processing defined in the ANSI/ISO > C standard. If they ever produce an ISO standard for Visual Basic > I am sure it would be huge and unreadable. As I look in my American Heritage Dictionary, one of the standards for American English, I can see why there could be some confusion over my use of "formal" or "formality." It has several definitions. I mean to use the term in much same the way that one speaks of multiple formality levels in the American English language. As Tucker points out, we can write highly technical, usually precise, documents such as standards in a formal version of the language. For documents composed quicker and intended to have a shorter life-span (such as this message), we use a more informal version. If I send a copy of this message to a printer and want some additional copies made, I might tack on a Post-It[TM] Brand Note with the text "5 xeroxes plz" and someone might understand. I could not publish that note formally. I would no doubt get a letter or phone call from Xerox Corporation attorneys for using their trademark in an incorrect manner. That's what I mean by the formality level of a language. You can use a programming language like C in a very formal manner or in a highly informal manner. Some years ago, when I was doing product development in C on the PC, I wanted a formal level. I used Gimpel's PC-Lint with a certain set of options and was not satisfied the code could be released until the utility produced no warnings. On the other hand, I've thrown together quicky C code at a very informal level. It did the job I needed, but I might get many warnings from PC-Lint or the compiler. I didn't care because I didn't intend to use the code again. (If I did need to dredge it up, I could always run it through PC-Lint to tell me the probable bad points.) For this reason, I think of C as a wide-level language. The language, with add-on tools, has high-level formality when I need it and low-level when I want it. C++ started as an extension to C and seems to support an even wider level of formality. I believe Ada's acceptance problem is that it requires a high level of formality all the time. It assumes every program must be written in maintainable style. People become uncomfortable when they must work at that level of formality all the time. So they reject Ada, even though they probably should use it some of the time. Okay, that's the way I use "formal" -- "following or adhering to accepted forms, conventions, or regulations." (From a formal definition -- standardized by observing the usage every ten years or so -- of a common wide-level language.) Michael ======================================================================== Michael D. Shapiro, Ph.D. e-mail: mshapiro@nosc.mil NCCOSC RDT&E Division (NRaD) Code 411 San Diego CA 92152-7560 Voice: (619) 553-4080 FAX: (619) 553-4808 DSN: 553-4080 [Until January 1992 we were the Naval Ocean Systems Center (NOSC)]