Re: 30 Years

Re: 30 Years

[Michael D Shapiro]

In INFO-ADA Digest V93 #560m Bob (so what happened to Paramax?) Munck
     {munck@STARS.Reston.Paramax.COM} wrote:

> In INFO-ADA Digest V93 #559, Michael (I miss NOSC) Shapiro
> <mshapiro@nosc.mil> said:
>
> >I have no doubt that, at the moment, Ada is likely the best candidate
> >language for huge (in size or duration) projects.  But most software
> >written today isn't for these huge projects. ... perhaps we should ...
> >answer the question, "What is the minimum size or duration project for
> >which Ada is the most cost effective language?" ... could make the
> >mandate workable.
> 
> It's not the duration of the project that matters, it's the expected
> lifetime of the code, as a whole system and broken into component
> parts.  I hope you're not advocating a return to the chaos of
> "Pick-your-own-language" for DoD programming, just restricting it
> to "unhuge" projects.

Sorry, I keep forgetting that people don't think the same way I do
about what a software project entails.  I count a software project as
lasting from the time people start coming up with a blurb describing
what it does until the last maintained version is turned off.  This is
roughly the management paradigm I proposed in my article "Software is a
product . . . NOT!" in the September 1992 IEEE Computer magazine (p.
128).  A basic idea is that the cost of a project is every cost a
software group has associated with their software throughout its
lifecycle.

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.

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

         Michael

{These ideas are, of course, my own and not necessarily those of my
employer.  It would be kind of nice if they would adopt them, though.}

========================================================================
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)]

Re: 30 Years

[cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!wellerd]

In article <9308251529.AA07664@manta.nosc.mil> mshapiro@MANTA.NOSC.MIL (Michael
 D Shapiro) writes:
>
>Sorry, I keep forgetting that people don't think the same way I do
>about what a software project entails.  I count a software project as
>lasting from the time people start coming up with a blurb describing
>what it does until the last maintained version is turned off.  This is
>roughly the management paradigm I proposed in my article "Software is a
>product . . . NOT!" in the September 1992 IEEE Computer magazine (p.
>128). 

I recommend this article to many people.  It's posted in my office. :-)

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

IMHO, you just defined "research project", in which case, I couldn't
agree more.  It's only when we have a process (notice, not product :-)
where the user /= development organization that we actually need _some_
form of standardization.

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

This is certainly agreeable, with the caveat that the definition of
"throwaway" be VERY CLEARLY defined.  I've watched too many little
software projects that were labeled throwaway (or worse, "prototype")
grow into 100KSLOC+ long-term projects.

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

Well, there's always DRAGOON :-)


-- 
type My_Disclaimer is new Standard.Disclaimer with record
	AJPO, SEI : Cognizance := Disavow_All_Knowledge;
end record;--)

Re: 30 Years

[cis.ohio-state.edu!pacific.mps.ohio-state.edu!math.ohio-state.edu!uwm.edu]

>From article <9308251529.AA07664@manta.nosc.mil>, by mshapiro@MANTA.NOSC.MIL (
Michael D Shapiro):
> In INFO-ADA Digest V93 #560m Bob (so what happened to Paramax?) Munck
>      {munck@STARS.Reston.Paramax.COM} wrote:

	{Much deletion}
> 
> 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.

Why do you think we need a "one-language-fits-all" solution?  In a previous
long-term (>30 year) project, we used two languages:

	HP's Rocky Mountain Basic for rapid prototyping

	Fortran for production code

Flame all you wish, but we were a collection of legacy systems that were
"protected" from the mandate.  I thought that environment worked very
well, largely because Rocky Mountain Basic (circa 1975) was a "Fortranized" 
dialect of Basic.  This made conversion into production code much easier.

We had the best of both worlds.  We could "run a solution up the flagpole"
with a quickie Basic prototype, and if "someone saluted" we could efficiently
recode the algorithm into Fortran.  If it turned out that the program was 
not that useful, we could trash the prototype or reuse pieces to solve 
other problems.

I found that I did just a bit more than half of my coding in Basic because
we wrote more throwaway stuff than production stuff.


<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Dave Willett          AT&T Federal Systems Advanced Technologies

The biggest mistake you can make is to believe that you work for someone else.
			
			-- Anonymous

Re: 30 Years

[agate!doc.ic.ac.uk!uknet!rsre!trout.rsre.mod.uk!trout!rigotti]

>IMHO, you just defined "research project" 

Research projects are no different, not successful ones anyway :-)

Kevin

--
--
Email : rigotti@hermes.mod.uk   (MIME & ATK)
Fax   : +44 (0)684 894109.
Post  : ATC Systems Division, DRA Malvern, Malvern WR14 3PS, England

Re: 30 Years

[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

Re: 30 Years

[cis.ohio-state.edu!math.ohio-state.edu!darwin.sura.net!seas.gwu.edu!mfeld]

In article <25rci4$aj1@europa.eng.gtefsd.com> rrenner@mtgy.gtegsc.com writes:
>>
[deleted]

>>You'll like this stuff, especially for the price, but if anyone thinks
>>it's a line-at-a-time interpreter or whatever else interactive/responsive
>>is supposed to mean, they'll be disappointed. What it is, is a really
>>nice, free, Ada83 system for Macs and DOS boxes. Nothing less, nothing more.
>>
>
>You mention here that you will putting out a Mac version of the compiler.  Wha
t version of the Mac operating system will it use?  Could you be more specific 
on the time frame for this version and whether it will full Ada compilation sys
tem.  We are currently stuck on a project where the Compiler vendor we were use
ing for the MacIntosh is not longer supporting that platform.
>
Ummm - sorry. I thought I mentioned that this is a Mac version of Ada/Ed,
like our enhanced DOS Ada/Ed. It's not for real project work, only for
education - the compiler puts out code for a virtual machine, which is
then interpreted.

By "current vendor" I take it you mean Alsys, because they have dropped
(very stupidly, IMHO) their Mac product. The only commercial company making
Ada for Mac is Meridian. Their compiler is fine, at least in my experience,
and works fine with System 7 and includes a "thin" System 7 binding. It
runs under MPW; the MPW basic system is bundled with it.

To my knowledge, this is the only Ada/Mac compiler on the market. Meridian
will start investing in improvements, I presume, if they perceive a market
for it. In my view, nobody ever recently tested the market potential
for Ada on Macs. In the early Mac days, it didn't make sense, but now 
with the typical industrial-strength Mac being a big, pretty fast machine,
Ada could sell if only the vendors would broaden their view.

TeleSoft had an A/UX compiler, but now TeleSoft=Alsys and it's gone,
I think.

Hope this helps.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  co-chair, SIGAda Education Committee
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5253 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
"We just changed our CONFIG.SYS, then pressed CTRL-ALT-DEL. It was easy."
-- Alexandre Giglavyi, director Lyceum of Information Technologies, Moscow.
------------------------------------------------------------------------

Re: 30 Years

[agate!howland.reston.ans.net!darwin.sura.net!source.asset.com!shilling]

In article <1993Aug30.030627.22749@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael
 Feldman) writes:
>[much deleted]
>TeleSoft had an A/UX compiler, but now TeleSoft=Alsys and it's gone,
>I think.

Gone.  But not forgotten.  Has quite a ring to it:
					TeleSoft=Alsys and it's gone.

-- Keith Shillington: (UCSD Pascal->SofTech Microsystems->TeleSoft->...)
-- 
  Keith Shillington               /---------\   "No matter where you go,
email: shilling@source.ASSET.com   /=======\     There you are."
voice: (619) 944-5134               /_____\          -- Buckaroo Banzaii
fax  : (619) 944-7089                 | |         office: (301) 924-0050

Re: 30 Years

[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)]

Re: 30 Years

[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

Re: 30 Years

[Michael D Shapiro]

In <CCDG8D.Js5@cbnewsl.cb.att.com> willett@ucbvax.Berkeley.EDU
     (david.c.willett) writes, regarding some earlier comments:

> From article <9308251529.AA07664@manta.nosc.mil>, by mshapiro@MANTA.NOSC.MIL 
(Michael D Shapiro):
 	{Much deletion}
> > 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.
> 
> Why do you think we need a "one-language-fits-all" solution?  In a previous
> long-term (>30 year) project, we used two languages:
> 
> 	HP's Rocky Mountain Basic for rapid prototyping
> 
> 	Fortran for production code
> 
> Flame all you wish, but we were a collection of legacy systems that were
> "protected" from the mandate.  I thought that environment worked very
> well, largely because Rocky Mountain Basic (circa 1975) was a "Fortranized" 
> dialect of Basic.  This made conversion into production code much easier.
> 
> We had the best of both worlds.  We could "run a solution up the flagpole"
> with a quickie Basic prototype, and if "someone saluted" we could efficiently
> recode the algorithm into Fortran.  If it turned out that the program was 
> not that useful, we could trash the prototype or reuse pieces to solve 
> other problems.
> 
> I found that I did just a bit more than half of my coding in Basic because
> we wrote more throwaway stuff than production stuff.

No flames at all from me.  Over my desk I have a list of 23 programming
languages I've used in various projects over the years.  And I've
probably left some out.  Most people like to use the tools with which
they're familiar.  I started a couple of products with Dan Bricklin's
Demo system.  Some people call it a programming language; others call
it "an expert system for building vaporware."  The nice thing with
building prototypes with it was that it didn't actually produce code
that worked outside the demo environment.  Then someone had to come
along and provide a tool that translated its files to C code.  Oh well.

The point of discussing the possibility of a single programming
language is that one idea of Ada was to provide precisely one
programming language for the DoD community.  To some, Ada should be
used for everything, whether or not it's appropriate.  To others, Ada
should never be used, because it's not appropriate for some
applications.  Still others take a position between those extremes.

Long ago, when I was a graduate student studying compiler construction,
I recall a professor remarked that while people kept looking for UNCOL,
the UNiversal COmputing Language, nobody had succeeded in finding it
yet.  And likely wouldn't.  A few years earlier that professor, Maurice
H. Halstead, had written a book entitled "Machine-Independent Computer
Programming" (Spartan Books, 1962).  He described work done by the Navy
at the Naval Electronics Laboratory (NEL) in San Diego (now NCCOSC
RDT&E Div.) on developing a portable language named NELIAC, based on
Algol '58.  A parallel effort produced JOVIAL for the Air Force.  While
both those languages had some successes, neither became the UNCOL.
Later, some had hopes that Ada could become the UNCOL for the DoD
community, despite its shortcomings in many application areas.  [Yes, a
few years later he developed the software science theories, basis of
the Halstead Numbers of software estimation.]

In summary, my point is that IF we need a single computing language for
the future, it will not be Ada, C++, nor any other existing language.
We will need a language with the best properties of each, tailorable
for each task domain.

      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)]

Re: 30 Years

[cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!progers]

In article <9309081721.AA18798@manta.nosc.mil> mshapiro@manta.nosc.mil (Michael
 D Shapiro) writes:
>
  [reasonable stuff to this point]

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

  I followed your discussion until this point.  What is it that
_requires_ this style?  One can write a program in Ada in as "informal"
a manner as desired.  One need not use encapsulation, abstraction, 
even strong typing in Ada.  (Once you're good at it, it doesn't take much
more time, though.)  I beleve people reject Ada out of ignorance and
half-truths, not for technical reasons.

pat rogers

Re: 30 Years

[Mark C. Carroll]

In article <1993Sep10.114905.6908@sei.cmu.edu> progers@ajpo.sei.cmu.edu (Pat Ro
gers) writes:
>In article <9309081721.AA18798@manta.nosc.mil> mshapiro@manta.nosc.mil (Michae
l D Shapiro) writes:
>>
>  [reasonable stuff to this point]
>
>>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.
>>
>
>  I followed your discussion until this point.  What is it that
>_requires_ this style?  One can write a program in Ada in as "informal"
>a manner as desired.  One need not use encapsulation, abstraction, 
>even strong typing in Ada.  (Once you're good at it, it doesn't take much
>more time, though.)  I beleve people reject Ada out of ignorance and
>half-truths, not for technical reasons.

I agree with you partially. I don't think that the formality of Ada is
a problem at all: there are numerous people out there using Pascal,
Modula-2, Modula-3, Oberon, Turbo-Pascal, Eiffel, Sather, etc., which
have the same level of formality as Ada.

And part of the problem with Ada *is* ignorance and bigotry. Ada's
gotten a whole lot of bad press, most of which it doesn't deserve.

But another part of the problem is the fault of Ada. I think that the
biggest problem hurting Ada is its perceived size.  Ada is a very
large language. And the way that its reference manual is written makes
it seem even larger.

I got interested in Ada recently, because I considered using it for a
research project involving extending object-oriented languages with
data parallelism. I rejected Ada because of its size. It's a terrific
language in a lot of ways, but it's got so many features, which
interact in so many ways, that to keep track of it all is difficult.

This is made even worse by the way in which Ada documents describe the
language. I got the annotated reference manual for Ada9x, and went to
print it out. How long could it possibly be? I use languages similar
to Ada all the time, and the manuals are between 30 and 100 pages
long. The Ada manual is over *500* pages, the overwhelming majority of
which is bureaucratic twaddle. 

It was certainly enough to drive *me* away. I'd like to use Ada. But
when it comes down to writing an implementation, and I need to know
every detail of what's interacting with my extensions, I can't afford
to search through an overblown, oververbose, overly bureaucratic
manual, hoping that I don't miss anything.

I'm still looking forward to having GNAT. I'd like to be able to
program in Ada, and I expect I'll use it a lot, once I have access to
a decent compiler. But I won't use it for my research.

Too many Ada haters try to say that it's a lousy language, and that
everything about it stinks. But too many Ada lovers refuse to
acknowledge the problems in the language and its presentation, and try
to blame everything on the Ada haters.

	<MC>
-- 
|| Mark Craig Carroll: <MC>     ||"Don't ever think that you can't
|| CIS Grad, Univ of Delaware   ||    change the past
|| PGP key available            ||       or the future"
|| finger carroll@udel.edu      ||  - _Love_and_Anger_, Kate Bush

Re: 30 Years

[Robert Kitzberger]

progers@ajpo.sei.cmu.edu (Pat Rogers) writes:

> One need not use encapsulation, abstraction, even strong typing in Ada.

But can you do it without feeling guilty?  ;-)   

There's something about Ada that makes me fully aware when I'm just
hacking, and fully aware when I'm doing The Right Thing.  If a person
hacks a lot, and doesn't like being reminded of that fact by their
language, then perhaps it's a guilt avoidance reaction that makes them
avoid Ada?

;-)  ;-)  ;-)    <--- flame-proof humor indicators

	.Bob.
--
Bob Kitzberger                          Internet:   rlk@rational.com
Rational, Grass Valley, CA              CompuServe: 70743,1550
"Vulgarity and stupidity are two very vivid facts in modern life.
One regrets them naturally.  But there they are." -- Oscar Wilde

Re: 30 Years

[Robert I. Eachus]

In article <26qc0u$k0b@louie.udel.edu> carroll@gloin.cis.udel.edu (Mark C. Carr
oll) writes:

  > This is made even worse by the way in which Ada documents describe the
  > language. I got the annotated reference manual for Ada9x, and went to
  > print it out. How long could it possibly be? I use languages similar
  > to Ada all the time, and the manuals are between 30 and 100 pages
  > long. The Ada manual is over *500* pages, the overwhelming majority of
  > which is bureaucratic twaddle. 

     How many programming language standards have you read?  The
Pascal standard is small and readable, but, for example, the Algol 68
standard probably wins all the prizes for obscurity and
impenetrability, the size of the PL/1 standard (not PL/1 subset G)
makes the Ada standard look like light reading, and (not to ignore
popular languages) the COBOL RM easily surpasses even the AARM in
bureaucratic twaddle (and size for that matter).

     Language standards are usually designed to be read only by
compiler implementors.  Ada broke that tradition by having a reference
manual that really was laid out for users of the language to
reference.  But it was certainly not intended to be an introductory
textbook.  In Ada 9X, the RM is still intended for users, and the AARM
is a bonus document (replacing the Ada 83 Implementors Guide) to help
compiler writers.

   > It was certainly enough to drive *me* away. I'd like to use Ada.
   > But when it comes down to writing an implementation, and I need
   > to know every detail of what's interacting with my extensions, I
   > can't afford to search through an overblown, oververbose, overly
   > bureaucratic manual, hoping that I don't miss anything.

   Let me guess, you much prefer the Oberon manual, or any others of
the species, where you don't have to worry about missing all those
details, because they aren't in the manual.  The interactions are
still there, it's just that the reference manual ignores them.  (Flame
protection...there is no reason for the author of a language AND a
compiler to put ANYTHING about implementation tricks and interactions
anywhere other than in comments in the compiler.  That is only
necessary much later when there are several different root compilers
for the same language.)
   
   > I'm still looking forward to having GNAT. I'd like to be able to
   > program in Ada, and I expect I'll use it a lot, once I have
   > access to a decent compiler. But I won't use it for my research.

   Are you sure you don't have access to a decent Ada compiler?  UDel
is a pretty large place.  (If Bob Cavendish is still there say hi for
me.)

   > Too many Ada haters try to say that it's a lousy language, and
   > that everything about it stinks. But too many Ada lovers refuse
   > to acknowledge the problems in the language and its presentation,
   > and try to blame everything on the Ada haters.

     Which group do you put yourself in?  I think I qualify as an Ada
lover, but I don't try to blame Ada haters for the flaws in the RM, I
try to fix them.  If you think there are places where the AARM can be
cleaned up, send your comments in.  (But you should probably wait for
the next version of the AARM which should be ready in a week or two.)
   
     There was a lot of discussion on this subject (the apparent
complexity of the standard) at the August meeting, and some progress
was made, but if you have any ideas about how to make the presentation
less daunting, let Tucker know.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: 30 Years

[Tucker Taft]

In article <EACHUS.93Sep10152513@spectre.mitre.org> 
  eachus@spectre.mitre.org (Robert I. Eachus) writes:

>In article <26qc0u$k0b@louie.udel.edu> 
  carroll@gloin.cis.udel.edu (Mark C. Carroll) writes:

>  > This is made even worse by the way in which Ada documents describe the
>  > language. I got the annotated reference manual for Ada9x, and went to
>  > print it out. How long could it possibly be? I use languages similar
>  > to Ada all the time, and the manuals are between 30 and 100 pages
>  > long. The Ada manual is over *500* pages, the overwhelming majority of
>  > which is bureaucratic twaddle. 
>
>     How many programming language standards have you read?  The
>Pascal standard is small and readable, but, for example, the Algol 68
>standard probably wins all the prizes for obscurity and
>impenetrability, the size of the PL/1 standard (not PL/1 subset G)
>makes the Ada standard look like light reading, and (not to ignore
>popular languages) the COBOL RM easily surpasses even the AARM in
>bureaucratic twaddle (and size for that matter).
>
>     Language standards are usually designed to be read only by
>compiler implementors.  Ada broke that tradition by having a reference
>manual that really was laid out for users of the language to
>reference.  But it was certainly not intended to be an introductory
>textbook.  In Ada 9X, the RM is still intended for users, and the AARM
>is a bonus document (replacing the Ada 83 Implementors Guide) to help
>compiler writers.
> . . .
>     There was a lot of discussion on this subject (the apparent
>complexity of the standard) at the August meeting, and some progress
>was made, but if you have any ideas about how to make the presentation
>less daunting, let Tucker know.

Yes, please do as Robert Eachus suggests.  Furthermore,
we have recently decided to stop encouraging the "general"
public to read the Annotated Ada 9X Reference Manual (AARM),
exactly because of the problem you cite.  It has so much
stuff in it that it clearly detracts from overall understanding.
The AARM will continue to be available to the public, but we
will emphasize that the unannotated version will be the official
standard, and is the only one explicitly intended to be reasonably
accessible to the average programmer.  Even better, hopefully,
will be the Rationale document, a new version of which will
be released shortly.

Perhaps the surprising thing about the Ada standard is that
average Ada programmers actually do read it, whereas average
Cobol or Fortran programmers rarely read the corresponding
Cobol or Fortran ISO standards.

It is a real challenge trying to address the requirements for
precision and completeness that is appropriate to an
international standard, while addressing the requirements
of ease of reading and understanding that is appropriate to
a manual that will be read by typical programmers.

The Ada 9X reference manual has probably swung a bit
too much over to precision and completeness and away
from understandability, and we hope to swing it back a 
bit during the public review process.  Please let us know
if you find clauses that are generally mystifying or full
of unnecessary "bureaucratic twaddle" (B.T.).  We will do our
best to slim them down, without abandoning completeness
and precision completely.  The typical solution will be
to move the B.T. to the AARM, so don't expect that document
to become any easier to read.  The unnannotated reference
manual, however, will hopefully become easier to read
as a result of the review.  

As someone great once said, "If we had more time 
we would have made it shorter..."


>					Robert I. Eachus

S. Tucker Taft    stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138

Re: 30 Years

[agate!howland.reston.ans.net!usc!cs.utexas.edu!csc.ti.com!tilde.csc.ti.co]

Pat Rogers (progers@ajpo.sei.cmu.edu) wrote:
: In article <9309081721.AA18798@manta.nosc.mil> mshapiro@manta.nosc.mil (Micha
el D Shapiro) writes:
: >
:   [reasonable stuff to this point]

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

:   I followed your discussion until this point.  What is it that
: _requires_ this style?  One can write a program in Ada in as "informal"
: a manner as desired.  One need not use encapsulation, abstraction, 
: even strong typing in Ada.  (Once you're good at it, it doesn't take much
: more time, though.)  I beleve people reject Ada out of ignorance and
: half-truths, not for technical reasons.

And this is the sort of remark that causes language flamewars and
leaves people wondering just why it is that *some* Ada advocates can't
justify their positions any better than by the old, traditional Usenet
approach of "either you agree with me or you are stupid and
ill-informed" -- which is pretty much what Mr Roger's statement
equates to.  Just the sort of approach to lead people to want to
reevaluate the use of languages that have worked just fine for them in
the past.  All it does is leave the propronent themself looking like
they have been fed on "ignorance and half-truths".

Is it *really* so hard to avoid these sorts of silly judgements?
In some groups, it seems that it is.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: 30 Years

[Richard A. O'Keefe]

In article <EACHUS.93Sep10152513@spectre.mitre.org>, eachus@spectre.mitre.org (
Robert I. Eachus) writes:
> In article <26qc0u$k0b@louie.udel.edu> carroll@gloin.cis.udel.edu (Mark C. Ca
rroll) writes:
> 
>   > This is made even worse by the way in which Ada documents describe the
>   > language. I got the annotated reference manual for Ada9x, and went to
>   > print it out. How long could it possibly be? I use languages similar
>   > to Ada all the time, and the manuals are between 30 and 100 pages
>   > long. The Ada manual is over *500* pages, the overwhelming majority of
>   > which is bureaucratic twaddle. 
> 
>      How many programming language standards have you read?  The
> Pascal standard is small and readable, but, for example, the Algol 68
> standard probably wins all the prizes for obscurity and
> impenetrability, the size of the PL/1 standard (not PL/1 subset G)
> makes the Ada standard look like light reading, and (not to ignore
> popular languages) the COBOL RM easily surpasses even the AARM in
> bureaucratic twaddle (and size for that matter).

On my desk at the moment I have
 - the current Pascal standard (84 pages)
 - the current ISO C standard (228 pages)
 - the old rationale for the ANSI C standard (119 pages)
 - the ISO version of the POSIX.1 "UNIX system call" standard (352 pages)
I also have
 - the SPARCompiler C Programmers' Guide (406 pages)
If it comes to that,
 - the Turbo Pascal Version 5 Reference Guide (468 pages)
isn't that small either.  And how about
 - Common Lisp, the Language, 2nd Edition (1029 pages)
I haven't _got_ but I have _seen_ a draft of the Modula-2 standard.
I can tell you right now, you may _think_ that Modula-2 is a smaller
language than Ada, but the standard is quite a bit bigger!
I have several times tried to read the 1976 ANSI PL/I standard, which
we have in our library, and failed.  (Is there a more recent PL/I?)

If you compare the Ada LRM with the C standard and the Modula-2 draft,
it actually comes out pretty well.  It's more readable than the C
standard, *and* I was able to pick up a free copy of the machine-
readable text *legally*.

I've loaned my paper copy of the Ada LRM to someone else, but my
recollection is that the great bulk of it is syntax, definitions,
examples, and cross references.  (Maybe the cross references count
as "bureaucratic twaddle"?)  My copy is physically about the same
size as the C standard, and noticeably thinner than the POSIX one.
The "meat to twaddle ratio" for the Ada LRM is at least as good as
that for the C and POSIX standards.  It is so outrageous to claim
that "the overwhelming majority of" the Ada LRM is "bureaucratic
twaddle" that I think we are entitled to ask for either a detailed
justification or a retraction.

For a fair comparison, I suggest looking at the ISO Pascal _Extended_
standard.  I had to read it 5 times before I finally figured out what
"bindable" means.  It's about the same phsyical size as my copy of the
LRM (oh, it does make a difference what _size_ the pages are... the
standards I referred to about are printed on A4 paper) and it is
ever so much less readable.  It's almost all "meat", but it doesn't
_explain_ anything.  At least the LRM explains things.

-- 
Richard A. O'Keefe; ok@goanna.cs.rmit.oz.au; RMIT, Melbourne, Australia.