Re: 30 Years

[news.bu.edu!inmet!spock!stt@decwrl.dec.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.  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.

Perhaps what is meant by "formality" is compiler-oriented vs.
interpreter-oriented.  Or perhaps it is strong static
type-checking (e.g. Ada, Eiffel) versus strong run-time type-checking 
(e.g. SmallTalk) versus weak static type-checking (e.g. ANSI C, PL/I --
quite a lot of implicit type conversion and anonymous types) versus
weak run-time type-checking (e.g. old-style LISP where pretty
much every abstract data type is represented by a list).

If we are talking about type checking or interpretation, why
not be explicit?  The term "formality" is very ambiguous, and doesn't
seem particularly relevant if it somehow relates to the
formality of the document that defines the ISO standard.

>From what I have read and heard, I believe that Ada9X will not meet
>these requirements of my proposed new language.  Does anyone know if
>anyone is working (even on just the requirements) on a next generation
>highly formal language for huge systems that can be used easily and
>less formally on non-huge systems?  I have the feeling that no current
>mainline language can do the job.  

Again, in what way is the language "formal"?  Presuming you
are talking about the strength and staticness of the
type checking, it is the case that an object-oriented programming
language that supports run-time polymorphism, even if statically type 
checked, is significantly more flexible from a type-checking perspective 
than a programming language that lacks run-time polymorphism.

The inclusion of run-time polymorphism is probably the most significant
"paradigm shift" from Ada 83 to Ada 9X, so in that sense, it should
be found to be more flexible, less constraining, or whatever, whether
the project is small or large.

On the other hand, if we are talking about compiler-oriented versus
interpreter-oriented, it seems that the world is actually moving
a bit away from interpreter-oriented languages, and instead embracing
compiler-oriented languages so long as they have a highly interactive 
and responsive support environment.  The reason is that some amount 
of static error checking is wonderful, even in the smallest project.

The GWAda/Ed system recently announced on comp.lang.ada is (presumably) an 
example of this kind of interactive/responsive environment for Ada 83.

With the wide availability of a high-quality and essentially free
implementation of Ada 9X (GNAT), such a highly interactive and responsive
environment for Ada 9X will almost certainly appear, either commercially
or in the research world.

> . . . If we only continue bickering about
>current languages, we'll delay movement toward meeting our real future
>needs.  Since I feel that Ada is the most advanced language currently
>around for some of the needed concepts, this group may be a reasonable
>discussion arena.

In any case, since I don't really understand your use of the term
"formal" I may not be addressing your concern at all.  Perhaps
if you were more specific about what features of a programming
language and support environment were, in your view, particularly 
advantageous for small projects (other than "informality" ;-), we could 
meaningfully discuss which languages/environments exist that do now or 
could some day provide those features.

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