Re: 30 Years

[stt@dsd.camb.inmet.com (Tucker Taft)]

> > 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.  
> > . . . 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.

> In article <CCFB85.82@inmet.camb.inmet.com> stt@inmet.com
>   (Tucker Taft) writes:
> 
> > I guess I don't understand this concept of "formality" at all.
> > . . .

In article <9309081721.AA18798@manta.nosc.mil>
  mshapiro@manta.nosc.mil (Michael D Shapiro) writes:

> 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.  
> . . .
> 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 see you are defining formality in terms of the kinds of
compile-time checks that "Lint" performs.  First of all,
essentially everything that Lint requires is also required by
C++ (and ANSI C).  In particular, in C++ you must have a 
"prototype" for a function before you call it.  Furthermore,
there are strict rules w.r.t. implicit conversions between types in C++.

You seem to be saying that if a project is sufficiently "short"
then you don't really care that your types don't match up when
you call a function, or that you mistakenly forgot a "break"
statement on a C/C++ switch arm.  It is a bit hard to believe
that the time you save by being this sloppy pays off except
in creating debugging headaches or total lack of faith in the
result of executing the program, presuming it produces any
results at all.

In any case, if you are talking about the requirement to have
types match up in function calls as "excessive formality" then
I think we are on different wavelengths, and it is probably not
worth trying to convince one another any further.

On the other hand, I would agree with you that there do
exist languages that make it easier to program a small
program quickly.  These tend to be interpreter-oriented, 
dynamically typed languages like SmallTalk or CLOS.
However, it is not really the dynamic typing that makes
the big difference.  The big difference is that most 
interpreter-oriented systems seem to come with a huge 
library of reusable code (e.g.  the "Collection" classes 
of SmallTalk, the standard CLOS library, etc.).  

Dynamic typing is admittedly convenient when trying to write certain
kinds of polymorphic algorithms, though statically typed
languages can come close to the same flexibility through
the provision of generics/templates and inheritance, while providing
much stronger static correctness guarantees.  

These static correctness checks make debugging and maintenance
so much easier, that even for a very small program, the
modest loss of flexibility is often rapidly paid back.
In addition, the required declarations often make the program
easier to read and understand.

> 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.

Is this your conjecture, or is it based on some actual
experience with Ada?  One can write quick and dirty programs
in Ada.  If portability and maintainability are not the issue, 
then one can use the predefined numeric types Integer and Float,
anonymous array types, etc., and quickly write a program that
essentially mimics any C program that actually works.
Here is an example of a quick and dirty Ada program:

with Text_IO; use Text_IO;
procedure Print_Squares is
begin
    for I in 1..100 loop
       Put_Line(Integer'Image(I) & " squared = " & Integer'Image(I**2));
    end loop;
end Print_Squares;

It is interesting to note that in C, one would actually have
to explicitly declare the variable "I" since a for-loop in C 
doesn't implicitly declare the loop index.

> Okay, that's the way I use "formal" -- "following or adhering to
> accepted forms, conventions, or regulations." . . .

It is true that the culture of Ada tends to encourage programmers
to think in terms of defining reusable packages with well-defined
interfaces, but it certainly doesn't require that.  Some OOP languages
do force all code to be part of some "class."  In Ada, the style
of putting all substantial code inside an appropriate package develops 
naturally in any big project, but small projects can stick
with a loose collection of stand-alone subprograms should they
so choose.

If anything, compared to some newer OOP languages, Ada is
less "formal" in that it doesn't force all projects to embrace
a package/object-oriented paradigm (though most Ada projects do).

There are plenty of things to argue about when it comes to
the relative merits of various languages, but it seems odd
to use the excuse that Ada is "overly formal" to justify not using it.
In any case, if you really believe Ada is overly formal, 
you should at least be more specific -- talk about things
like parameter type mismatch, missing "break" statements, or whatever it 
is that Lint catches that you prefer to have uncaught in your "small
projects."

> Michael D. Shapiro, Ph.D.                      e-mail: mshapiro@nosc.mil
> NCCOSC RDT&E Division (NRaD) Code 411            San Diego CA 92152-7560

S. Tucker Taft   stt@inmet.com
Intermetrics, Inc.
Cambridge, MA  02138