Re: 30 Years

[mshapiro@manta.nosc.mil (Michael D Shapiro)]

In article <CCFB85.82@inmet.camb.inmet.com> 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)]