Re: Open Systems closed to Ada?

Re: Open Systems closed to Ada?

[mcsun!uknet!yorkohm!minster!mjl-b]

In article <1992Nov26.015455.8009@fcom.cc.utah.edu> val@news.ccutah.edu (Val Ka
rtchner) writes:
>alex@cs.umd.edu (Alex Blakemore) writes:
>: In article <EMERY.92Nov24173553@Dr_No.mitre.org> emery@Dr_No.mitre.org (Davi
d Emery) writes:
>: > My experience with the POSIX/C community is that they don't understand
>: > why anyone would program in anything other than C/C++, and they have
>: > no interest (bordering on active hostility) in anyone who does not toe
>: > their line.   (Think of it as "Software Fundamentalism" of the
>: > Ayatollah variety, and you won't be far wrong...)
>: 
>: This attitude runs rampant in Universities as well.
>: I hope we Ada advocates will be more tolerant when we rule the world.
>
>Which language is the "state religion" that bans all other religions from
>its state?

I guess you're trying to implicate Ada here and contrast it with C (or
perhaps C++). Ada doesn't ban other languages -- there is still a lot of
effort going on to interface Ada to other systems and lnaguages. In general,
the problems don't actually come from Ada, but from poor specification in
other languages, notably C.

>Which language is simply the majority "religion" while not
>being intolerant of others?

As someone else pointed out, many C interfaces use char * for everything and
then typecast to the type they really mean later on. This makes for a poor
and error prone interface spec. -- as I found out when writing an Ada
binding to Berkeley sockets. Is this an example of C's great tolerance?

>Which one would you compare to the USA and
>which would you compare to Iran?  Which one rules by choice and which one
>will only rule by fiat?

Unfortunately, the motivations for choice are not as altruistic as you
perceive. Choice of computer languages, as in many other areas, has very
little to do with how good the language is technically. It has far more to
do with exposure, marketing and education.

Most of the choices are made at a superficial level -- after all, properly
evaluating the alternatives takes time, money and thought and making a
change from your current system takes a paradigm shift, retraining and
different and/or new ways of thinking.

How many companies properly perform this evaluation and are prepared to make
the changes for long term goals?

-- val@csulx.weber.edu ==\///= Ogden UT USA =|

Mat

| Mathew Lodge                      | "I don't care how many times they go    |
| mjl-b@minster.york.ac.uk          |  up-tiddly-up-up. They're still gits."  |
| Langwith College, Uni of York, UK |  -- Blackadder Goes Forth               |

Re: Open Systems closed to Ada?

[dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!wupost!cs.utexas.edu!m]

In article <1992Nov30.215944.17819@fcom.cc.utah.edu> val@news.ccutah.edu (Val K
artchner) writes:
>emery@dr_no.aries.mitre.org (David Emery) writes:
>: 
>: >Which language is the "state religion" that bans all other religions from
>: >its state?  
>: 
>: C
>
>In case you were unaware of it, there is a mandate in the DoD that "all new
>software development shall be done in Ada" unless there is a compelling cost
>justifiable reason...

Unfair apples and oranges here, to me it seemed David was pointing out the
difficulties with or flat out lack of support provided within a language's
semantics for cooperative interfacing/binding to another foreign language.
This does not correlate with a customer mandating use of a particular
language such as Ada (or Jovial, or FORTRAN, or C, or Lisp, or Smalltalk...)

>: >Which language is simply the majority "religion" while not being 
>: >intolerant of others?  
>: 
>: none
>
>Are you aware of something called "The Ada Mandate"?

Make it plums and limes here, but see above...same point.  Key word in
the question is "language".

>: >Which one would you compare to the USA and which would you compare to Iran?
  
>: 
>: I've compare the C community to Iran.  
>
>Which community legislates compliance?

Now here we have a subtle shift because David introduces the C "community".
I feel there isn't much room for either the C or Ada communities to point
fingers, since both strive mightily to prove they can solve the world's
problems within their own realm.  Much contention is made by Ada proponents
that the Open Systems standards predominantly favor C applications.  A
simple reason for that...the C community discovered their increasingly
chaotic universe required some form of cooperative structure fast to
retain customer base.  Because of the Ada language's enforced structure
and coherency, the Ada community enjoyed the luxury of a somewhat more
ordered perspective.  What is NOT needed is an exponentially growing
pool of crybabies.  What IS needed is a colloborative effort from both
sides to capitalize on the advantages of _both_ language paradigms.

>: >Which one rules by choice and which one will only rule by fiat?
>: 
>: Many people choose to program in C.  Unfortunately for those of us who
>: don't, the C community has shown a significant intolerance for other
>: language paradigms.  One wonders how many people are now programming
>: in C because they have no other choice.
>
>I have spent my professional career in the defense community.  Of the other
>programmers that I personally know, only 25% prefer Ada over any other
>language.  I know of no programmers in the commercial sector who would
>prefer to program in Ada.

Think of C as a language which attracts free-wheeling, loosely-bound
developers.  Think of Ada as a language which attracts programmers who
prefer structure, discipline, order, and consistency.  Those traits
most dominant in a _human_ will drive them toward the language of their
personal choice.  As for statistics, I usually pay no attention to them
if they lack the backup of a quantifiable, definitive study.  Commercial
sector programmers may not even known what Ada can do because of the
industry's dismal record in spreading the word.

Mark A. Breland - Microelectronics and Computer Technology Corporation (MCC)
Ada Fault Tolerance                               | voice:    (512) 338-3509
3500 West Balcones Center Drive                   | FAX:      (512) 338-3900
Austin, Texas 78759-6509   USA                    | internet: breland@mcc.com

Re: Open Systems closed to Ada?

[mcsun!uknet!yorkohm!minster!mjl-b]

In article <1992Dec1.021017.23228@fcom.cc.utah.edu> val@news.ccutah.edu (Val Ka
rtchner) writes:
>: In article <1992Nov30.215944.17819@fcom.cc.utah.edu> I wrote:
>: I have spent my professional career in the defense community.  Of the other
>: programmers that I personally know, only 25% prefer Ada over any other
>: language.  I know of no programmers in the commercial sector who would
>: prefer to program in Ada.
>
>Perhaps I should have phrased it as "Personally, I know of no programmers...."
>By "personally" I mean people that I have met face-to-face, and by "know" I
>mean that I know what they are doing now (as in current employment) as far
>as languages and their programming preferences.

The trouble with personal experiences is that they're all different. I know
of some C++ programmers who used Ada for a project and are now "Ada
converts". You know some C++ programmers who don't like Ada. I know some who
do. My example is just as valid as yours, and just as meaningless.

>|== "I think, therefore I AMiga" -- val@csulx.weber.edu ==\///= Ogden UT USA =
|

Mat

| Mathew Lodge                      | "I don't care how many times they go    |
| mjl-b@minster.york.ac.uk          |  up-tiddly-up-up. They're still gits."  |
| Langwith College, Uni of York, UK |  -- Blackadder Goes Forth               |

Re: Open Systems closed to Ada?

[dog.ee.lbl.gov!overload.lbl.gov!agate!biosci!uwm.edu!zaphod.mps.ohio-stat]

emery@dr_no.mitre.org (David Emery) writes:
: The U.S. DoD has chosen Ada as a matter of policy.  Its rationale for
: its decision is well-known (and you can disagree with it if you wish.)
: But there's a big difference between the DoD policy on the use of Ada
: and the mantra that I've experienced in the C community.  
: 
: Governments are *supposed* to make policy.  What I consider completely
: objectionable are the people within a technical community who take on
: the role of government/management and make the policy for them.  

As a counterpoint, I offer the following:

  The Chinese government has chosen Communism (or more correctly,
  totalitarian socialist oligarchy) as a matter of policy.  Its rationale
  for its decision is well-known (and you can disagree with it if you
  wish.)  But there is a big difference between the Chinese policy on
  the use of Communism and the chaos that I've experienced in a free-market
  economy.

  Governments are *supposed* to make policy.  What I consider completely
  objectionable are the people within that community who take on the role of
  government/management and try to make policy for them by public demonstration
  in a public square.

While Communism may be desireable in many respects (government provided
housing, health care, jobs, etc..), I do not like the additional baggage
(government mandate among others) that is carried along with it.  While
Ada is (personally) less objectionable than certain forms of government,
it does carry additional baggage that I do not want.

While I agree that it is within the U.S. government's rights to make
certain policy decisions, it doesn't mean that whatever decisions are
made are automatically Good Things.

: Maybe my experience in POSIX is different than the "real workd".  But
: I tell you this:  I've met very few C programmers who have any
: experience with languages significantly different than C (FORTRAN is,
: after all, a similar language.  Lisp, Smalltalk, SNOBOL, COBOL and Ada
: represent different paradigms.)  Even those who profess to like C++
: think its greatest feature is backwards compatability with C.
: Conversly, most Ada programmers (that I've met, and i know a LOT of
: Ada people) are familiar with several languages (almost all of them
: know C), and are able to understand the various features of different
: languages.  

It is truely a shame that there are programmers who only know one computer
language.  (I've also brought up this point in this group.)  For the sake
of comparison, how many natural languages have you bothered to learn?
(This is a rhetorical question.)

My opinion is that the first language that a programmer should learn is
some form of assembler.  Without this basic knowledge it is like learning
algebra without knowing how to do the four basic operations because you've
used a calculator all of your school days.  To forstall the obvious response,
learning electronics would be equivalent to knowing the three-page proof
that "1 = 1".  (I have more than necessary knowledge of the subject, but
others can just take it for granted that it "works as documented".)

: The "State religion" metaphor is interesting.  You can well consider
: Ada to be the 'state religion' for the U.S. DoD, but there's no
: requirement to use Ada outside of the DoD (which is the span of the
: Congressional mandate. No one has told HHS, or Agriculture or Commerce
: or Justice to use Ada...)
: ...
: If Ada represents the state religion, it does so in a general society
: of religions tolerance.  I prefer this to the "fundamentalism" that
: runs rampant in the C community.  It's easy to leave the state church
: and pray to other languages, WHEN YOU HAVE THE CHOICE.

Leaving the organizations of origin of the two major contenders (DoD and
AT&T), how is the devotions to the languages (Ada and C/C++)?  This needn't
be hashed out here but can be discussed in the Usenet thread "Financial
Statistics for Ada and C/C++" started by an Ada devotee.

: p.s.  There are several people who attended Tri-Ada who are under no
: compunction to use Ada.  One that comes to mind is the guy from Cutler
: Medical Instruments ....
: 
: Also, how do people explain Boeing's decision to use Ada for the 777
: and other commercial avionics programs?  If Ada is so dangerous or
: inefficienty, Boeing, which has a reputation for quality commercial
: airliners, could have chosen C or some other such language.  ...

I've never seen any claims that Ada is dangerous.  I do agree that it is
less efficient than C/C++.  However, this is also a point on which we will
never agree.

Nevertheless, you have been, inadvertantly, making my point for dropping The
Mandate.  (I know, we won't agree on this either.)  However, you have made
my point for freedom in language choice.  There are those outside the DoD
that use Ada without The Mandate, and those inside the DoD which don't use
Ada despite The Mandate.  Any opinions to the contrary don't face reality.

And breland@cobweb.mcc.com (Mark Breland) writes:
: Unfair apples and oranges here, to me it seemed David was pointing out the
: difficulties with or flat out lack of support provided within a language's
: semantics for cooperative interfacing/binding to another foreign language.
: This does not correlate with a customer mandating use of a particular
: language such as Ada (or Jovial, or FORTRAN, or C, or Lisp, or Smalltalk...)

If you can claim "unfair" for me misunderstanding his answer, then I can
certainly claim "unfair" for him misunderstanding my question.  :-)
However, you should not make unsubstantiated conjecture on subjects like
this.  "Lack of support within a language's semantics" is mostly an
excuse for "lack of knowledge".  I have personally interfaced several foreign
languages with C as the caller and the callee.

The type of obvious support that you want is available in C++.

: ....  What is NOT needed is an exponentially growing
: pool of crybabies.  What IS needed is a colloborative effort from both
: sides to capitalize on the advantages of _both_ language paradigms.

Agreed.  But Ada and C++ have been growing together in capabilities
Remember when the Ada community thought that "object orientedness" was a
Bad Thing?  Now that it will be available in Ada 9X, it is a Good Thing
and the previously held opinion will forever be denied.  Similar behavior
will also be evident in other communities as well.  However, I have always
liked a few things about Ada, but I don't like the baggage that comes
along with it.

Ada and C/C++ are different philosophies that will not grow together.

: Think of C as a language which attracts free-wheeling, loosely-bound
: developers.  Think of Ada as a language which attracts programmers who
: prefer structure, discipline, order, and consistency.  Those traits
: most dominant in a _human_ will drive them toward the language of their
: personal choice.  As for statistics, I usually pay no attention to them
: if they lack the backup of a quantifiable, definitive study.  Commercial
: sector programmers may not even known what Ada can do because of the
: industry's dismal record in spreading the word.

Be careful about stereotypes.  I and the person sitting right next to me now
both happen to be government contractors who have programmed together before
(in C).  We both "prefer structure, discipline, order, and consistency", but
our prefered language happens to be C++.  (I happen to be using Ada in this
current project, but he uses C++.)  This is therefore not a valid
generalization.

As for statistics: There are lies, statistics, and studies.  I happen to
have a study in front of me right now titled "Ada and C++ Business Case
Analysis, July 1991".  (This is the actual study and not the summary.)
I have read it.  The best way to summarize this study is to use a quote
from "Dinosaurs", "What would you like this study to conclude Sir?"

			-=:[ VAL ]:=-
--
|================== #include <disclaimer.h> ==================///=============|
| "AMIGA: The computer for the creative mind" (tm) Commodore /// Weber State  |
| "Macintosh: The computer for the rest of us"(tm) Apple \\\///   University  |
|== "I think, therefore I AMiga" -- val@csulx.weber.edu ==\///= Ogden UT USA =|

Re: Open Systems closed to Ada?

[Gregory Aharonian]

>I know of no other program language that has the equivalent of Ada's
>pragma interface.  Ada may be Ada-centric, but it has *ALWAYS*
>recognized and supported the notion not all software would be written
>in Ada.

There is an excellent file that floats over the Internet, cfortran.h, that
makes it easy to call Fortran and C routines from each other on a wide
variety of machines. 
The PC families of languages (Microsoft, Borland) have always had good
interlanguage calling features, as does the DEC's VMS operating system.

Greg Aharonian
-- 
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178

Re: Open Systems closed to Ada?

[Gregory Aharonian]

[.....................]
>Even those who profess to like C++ think its greatest feature is backwards
>compatibility with C.

Backwards compatibility is a concept that translates poorly into the defense
world.  In the real world, companies can't afford to write off the investment
it has in existing software and programmers (companies don't have the tax
dollar till to constantly dip into), nor can companies ignore the supply of
programmers and software tools in the marketplace that it draws from (again
unlike the DoD, which has tax dollars to develop tools (like STARS) and
programmers whenever it feels like it).

In fact, the very "backwards compatibility" which you seem to be making
fun of is what will probably prevent Ada from establishing any significant
role in the commercial marketplace. C++ and Object Oriented Cobol (which
even I think is strange) aren't as nice as Ada, but they are backward
compatible.

Greg Aharonian
-- 
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178

Re: Open Systems closed to Ada?

[Alex Blakemore]

In article <1992Dec1.230732.13822@fcom.cc.utah.edu> val@news.ccutah.edu (Val Ka
rtchner) writes:
> Ada and C++ have been growing together in capabilities
> Remember when the Ada community thought that "object orientedness" was a
> Bad Thing?  Now that it will be available in Ada 9X, it is a Good Thing

many Ada advocates never claimed OO to be bad - and wished Ada supported it.
To be fair, when Ada was designed OOP was not as well understood as today, and
including it in Ada83 may have been the straw that broke the compilers back
(or in the case of many Unix compilers, 

It is interesting to see so much of Ada's good ideas show up in languages
like C++, Eiffel and others (.e.g NeXT's extension to ObjC includes exceptions 
that
act just like Ada exceptions except they can carry arguments too)
On the surface, it seems that C++ added a lot more from Ada to C than
Ada9x will add to Ada83 from C++.

> I have always liked a few things about Ada, but I don't like
> the baggage that comes along with it.

in an attempt to resurrect something interesting from this thread,
what baggage do you refer to (and what do you like)?

is the baggage something wrong in the language, available compilers/tools,
or something sociological?  please try to be specific so we Ada advocates
can better understand why people resist the one true way :) :) :)

I agree that the mandate may seem draconian but remember the Dod's original
goal with Ada was and is to eliminate the tower of Babbel.  Even the C communit
y
has found standardization critical.  I wish Dod would put alot more emphasis on
the carrot though.
-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted

Re: Open Systems closed to Ada?

[Robert I. Eachus]

In article <1992Dec1.230732.13822@fcom.cc.utah.edu> val@news.ccutah.edu (Val Ka
rtchner) writes:

   Nevertheless, you have been, inadvertantly, making my point for dropping The
   Mandate.  (I know, we won't agree on this either.)  However, you have made
   my point for freedom in language choice.  There are those outside the DoD
   that use Ada without The Mandate, and those inside the DoD which don't use
   Ada despite The Mandate.  Any opinions to the contrary don't face reality.

   Face reality.  The goevernment spent a lot of money developing Ada
because it NEEDED a language which would significantly reduce
maintenance costs on long-lived embedded computer systems.  This was
the primary goal of the HOLWG, and there is overwhelming evidence that
Ada more than meets this goal.  In 1976 or thereabouts the DoD spent
only 8% of the money spent on software on development and most of the
rest on maintenance.  Tripling the amount spent on development to cut
the maintenance cost by 50% would have been a good thing.  Ada comes
closer to a factor of ten drop in maintenance costs while also
decreasing development costs.

   Now you come along and say that, yes Ada reduces development costs
over CMS-2 and JOVIAL, but we can reduce them further with C++.  The
DoD of course responds that the don't give a flying #$%&, in their
environment maintenance costs dominate, and there is NO evidence that
maintenance costs would be lower with C++.  In fact, right out of the
gate, you are asking them to support at least two languages, because
there are applications for which C++ is totally unsuited.  The DoD
knew and knows that it pays a penalty by insisting on a single
language that can be used for both flight guidance systems and payroll
applications.  The advantages--to the DoD--of having a single language
for both outweigh the costs--to them.

   So stop bitching aobut "the MANDATE" for the wrong reasons.  If you
can show that--for a given system--the cost of using some other
language is less over the ENTIRE life of the system, any branch of the
DoD is willing to listen.  But to save a million dollars up front by
spending an extra 20 million over the next 20 or 30 years is just not
cost effective.

   I have already seen both sides of the coin.  I've seen cases where
the use of Ada allowed major changes to the hardware to be
accomplished at little or no cost after software development was
complete.  I've seen Ada systems where the biggest maintenance concern
was that since all the work could be done by one person, there would
be a lack of continuity.  I've also seen systems which got waivers not
to use Ada and which either failed to very get fielded because the
computer hardware was obsolete by the time the system was finished and
the cost of modifying the software to fit new hardware was too high,
or where the DoD is evaluating the cost of completely rewriting the
system in Ada to reduce maintenance costs.  (C-17 is an example of
this--see the GAO report...)

   Now if the DoD already knows of--literally--billions of dollars
that went down the tubes because Ada was not used, I think you can
start to understand their position.  Given my position, I'm not going
to put together a list of the top ten DoD software disasters for the
last decade--you can if you want.  However, if I put together a list
of the top ten reasons why DoD software projects failed, I think that
inappropriate Ada waivers (or ignoring the mandate) would be about
third or forth.  The first is going out for bid with an inadequate set
of requirements (RFP and/or A-spec).  The second is probably allowing
software PDR (preliminary design review) completion to drag out and
allowing coding to start before the design is approved.  Where
unrealistic schedule falls on the list depends on whether you regard
it as mostly a problem or a symptom.

--

					Robert I. Eachus

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

Re: Open Systems closed to Ada?

[david.c.willett]

>From article <SRCTRAN.92Dec1230203@world.std.com>, by srctran@world.std.com (G
regory Aharonian):
> [.....................]
>>Even those who profess to like C++ think its greatest feature is backwards
>>compatibility with C.
> 
> Backwards compatibility is a concept that translates poorly into the defense
> world.  In the real world, companies can't afford to write off the investment
> it has in existing software and programmers (companies don't have the tax
> dollar till to constantly dip into), nor can companies ignore the supply of
> programmers and software tools in the marketplace that it draws from (again
> unlike the DoD, which has tax dollars to develop tools (like STARS) and
> programmers whenever it feels like it).
>
	{remainder of Greg's Comments deleted}

Backwards compatibility is used and normal throughout the DoD world.  The
Services (in particular the USN) are notorious for "retrofitting" existing
systems with enhanced technology.
 

DAVE

-- 
Dave Willett          AT&T Federal Systems Advanced Technologies
attmail!dwillett      (AT&T FSAT)
If you think it's so !#$%^& easy, You try it!

Re: Open Systems closed to Ada?

[mcsun!uknet!yorkohm!minster!mjl-b]

In article <SRCTRAN.92Dec1230203@world.std.com> srctran@world.std.com (Gregory 
Aharonian) writes:
>[.....................]
>>Even those who profess to like C++ think its greatest feature is backwards
>>compatibility with C.
>
>Backwards compatibility is a concept that translates poorly into the defense
>world.  In the real world, companies can't afford to write off the investment
>it has in existing software and programmers (companies don't have the tax
>dollar till to constantly dip into), nor can companies ignore the supply of
>programmers and software tools in the marketplace that it draws from (again
>unlike the DoD, which has tax dollars to develop tools (like STARS) and
>programmers whenever it feels like it).

>In fact, the very "backwards compatibility" which you seem to be making
>fun of is what will probably prevent Ada from establishing any significant
>role in the commercial marketplace. C++ and Object Oriented Cobol (which
>even I think is strange) aren't as nice as Ada, but they are backward
>compatible.

I would argue that the industry cannot afford to continue to develop
software the way it does at the moment. It all just costs too much, which is
what the High Order Language Working Group was all about, way back in the
1970s. Ada is useful as *one part* of the way forward, but we need also need
tools and *better educated* engineers.

The cost in the short term will be high -- calling it "writing off the
investment" is exaggerating. It's not as if everyone has to start from
scratch. But the long term savings are worth it.

Apologies if this all sounds a bit like The Journey To The Promised Land --
it's not meant to be as grandiose or pretentious as that!

>Greg Aharonian

Mat

| Mathew Lodge                      | "I don't care how many times they go    |
| mjl-b@minster.york.ac.uk          |  up-tiddly-up-up. They're still gits."  |
| Langwith College, Uni of York, UK |  -- Blackadder Goes Forth               |

Re: Open Systems closed to ADA?

[Alvin Starr]

Back to the original point. Are "OPEN SYSTEMS" closed to ADA.  From
my perspective it would seem that ADA is closed to Open Systems. ADA
compilers tend to be part of an integrated development environment(some more
than others) that will help you take source files and generate a binary for
a given target system. If you are not on that exact target then you are beat.

Example.
We have a OS that has support for a number of the real-time/multi-tasking
features that make ADA a good real-time language. We can execute IBCS2(386V.2)
code but to use the features of our OS you would have to use a different
set of system calls. the problems that we found are:
        - everybody system call libraries are custom/proprietary and will not
          be released to anybody or for an amount of money that I cannot
          obtain.
        - The ADA compilers all contain custom linkers and assemblers so each
          one is different and any work that is done will have to be redone
          for each new compiler.
        - The ADA compiler vendors were not interested in supporting another
          OS(unless of course we moved a dumpster full of cash up to the front
          door). They also were not interested in letting us do the original
          porting work.

We explored the possibility of providing a POSIX compatible OS that would be
compiled in ADA and could have new device drivers written and debugged in ADA.
Much to our surprise we found that there was very little interest.

I can go out and get half a dozen C/C++ compilers for the SUN and each of them
will generate assembler and object code that I can use with the others. Can
any 2 ADA compiler vendors claim the same. IMHO this is the crux of the problem
.
As a software developer I do not want a swiss army knife, I want a tool box
that I can add new tools to and replace the worn out old tools. The answer is
not a bigger knife with more tools half of which are no use to me but I still
have to pay for.

--
Alvin Starr                   ||   voice: (416)513-6717
Eyepoint Inc.                 ||   fax:   (416)513-6718
alvin@eyepoint.com            ||
-- 
Alvin Starr                   ||   voice: (416)513-6717
Eyepoint Inc.                 ||   fax:   (416)513-6718
alvin@eyepoint.com            ||

Re: Open Systems closed to Ada?

[Jim Lonjers]

It may come as a surprise to many folks that yes, even when people have a
choice, many choose Ada, and it is not limited to the more highly
publicized cases of Boeing (777) and Motorola (the Cellular Telephone
system).

My company sells to many non U.S. DoD customers (FAA in the U.S. and
several foreign customers).  When we have a choice, we pick Ada.  In many
cases, we have to sell our decision to the customers.  One rather
interesting one was to an organization that had passed an "Ada mandate,"
but the folks who actually had to carry out the mandate did not want to be
bothered with it.  We ended up having to convince them that their
organization's mandate was the right decision.

Yes, rational people do pick Ada, even if it takes more work to convince
the customer that it is the right way to do business.

[Just a few words of support for Dave Emery who seems to be under attack
 for his views -- I too have observed the same pro-C militant attitudes.
 Shall I say it?  Yes, it seems to be pretty much out of ignorance.  Most
 of those who are militantly in favor or against any particular thing
 are not all that well versed in the alternatives.

 About the only thing that C has going for it is that it has a large
 trained base of programmers (how well trained, I do not know).  This
 is because most of the schools now teach C as part of the curriculum,
 or when a curriculum does not teach a particular language, C is
 encouraged.  It is also easier to write little C programs than it is to
 write little Ada programs.  However, when it comes to portability, reuse,
 large scale programming of any sort, C really does come up short.  I agree
 with the commentor that it is such social factors that will be the true
 determiner of who comes out the winner in the "language wars."  Lets not
 forget that COBOL and FORTRAN are still winning by a large margin.
 
 It is interesting that C++ has invented an inter-language
 calling mechanism.  Also that the C community is now re-inventing
 tasking (threads), but doing it differently, but not better than,
 Ada.  There is no doubt that C++ was heavily influenced by Ada --
 the C++ langauge developers admit that they were intelligent enough
 to borrow many good things from many sources.]

Jim Lonjers

Re: Open Systems closed to Ada?

[Jim Lonjers]

In article <1992Dec1.230732.13822@fcom.cc.utah.edu> val@news.ccutah.edu (Val Ka
rtchner) writes:
>While I agree that it is within the U.S. government's rights to make
>certain policy decisions, it doesn't mean that whatever decisions are
>made are automatically Good Things.

. . . and there is the counter problem that some people think that when the
   government makes a decision it must be a Bad Thing, especially when it
   is the DoD.

Can we clear one item up?  The "government decision" is not a mandate, nor
is it a policy which extends outside of the government.  It is pure and
simple a financial/business decision, much like those made by our various
commercial ventures.  And, like most decisions that affect a large
organization, it can be picked apart from many different angles.  As a
business decision, however, it was probably one of the best the DoD has
made in terms of software procurement.

>My opinion is that the first language that a programmer should learn is
>some form of assembler.

I sure agree with this.  I cannot count the number of times I have had to
explain the costs of various programming paradigms by dropping it to this
level.  Without this knowledge (and some concept of what today's
compiler optimization is capable of), the ability to write code which is
both, highly abstract and highly efficient to execute is impossible.

>I do agree that it is
>less efficient than C/C++.

This is absolutely and totally false.  References available on request.
You can add me to the folks who will never agree with you on this point.

>Remember when the Ada community thought that "object orientedness" was a
>Bad Thing?

No, I have never heard this opinion in the Ada community.  You will have to
remind us of when that was.

>Ada and C/C++ are different philosophies that will not grow together.

But, above (in a part that I prematurely pruned out), you said they were
definitely growing together.

Re: Open Systems closed to Ada?

[Jim Lonjers]

In article <SRCTRAN.92Dec1230203@world.std.com> srctran@world.std.com (Gregory 
Aharonian) writes:
>Backwards compatibility is a concept that translates poorly into the defense
>world.  In the real world, companies can't afford to write off the investment
>it has in existing software and programmers (companies don't have the tax
>dollar till to constantly dip into), nor can companies ignore the supply of
>programmers and software tools in the marketplace that it draws from (again
>unlike the DoD, which has tax dollars to develop tools (like STARS) and
>programmers whenever it feels like it).

You had better get educated.  There are very few new DoD procurements.  You
see a few large ticket items debated over and over, but the general trend
in the military is to revise, refit and extend existing systems.  As those
in the Navy's NGCR program put it -- "there is no more engineering from
clean sheets of paper."

If you take a good look at STARS (as I know you profess to have done), you
will recognize much of the truly innovative work that has gone on there.

>In fact, the very "backwards compatibility" which you seem to be making
>fun of is what will probably prevent Ada from establishing any significant
>role in the commercial marketplace. C++ and Object Oriented Cobol (which
>even I think is strange) aren't as nice as Ada, but they are backward
>compatible.

Yes, backwards compatibility has doomed many a good thing.  How many
mainframe manufacturers are going to survive "backwards compatibilty"
requirements?  It is a good thing, but it will doom all those who practice
it.  The world moves on.

Re: Open Systems closed to Ada?

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!csc.ti.com!til]

In <1992Dec4.074834.24047@gvl.unisys.com> lonjers@prc.unisys.com (Jim Lonjers) 
writes:

>It may come as a surprise to many folks that yes, even when people have a
>choice, many choose Ada, and it is not limited to the more highly
>publicized cases of Boeing (777) and Motorola (the Cellular Telephone
>system).

I think the question is not whether many do or not, but relatively how
many when compared to other choices, and what are the jobs it is
chosen for.

>My company sells to many non U.S. DoD customers (FAA in the U.S. and
>several foreign customers).  When we have a choice, we pick Ada.  In many
>cases, we have to sell our decision to the customers.  One rather
>interesting one was to an organization that had passed an "Ada mandate,"
>but the folks who actually had to carry out the mandate did not want to be
>bothered with it.  We ended up having to convince them that their
>organization's mandate was the right decision.

A blanket mandate is, practically by definition, almost NEVER the
'right decision'.

>Yes, rational people do pick Ada, even if it takes more work to convince
>the customer that it is the right way to do business.

>[Just a few words of support for Dave Emery who seems to be under attack
> for his views -- I too have observed the same pro-C militant attitudes.
> Shall I say it?  Yes, it seems to be pretty much out of ignorance.  Most
> of those who are militantly in favor or against any particular thing
> are not all that well versed in the alternatives.

And here we see the militant Ada attitude; if you don't agree with
them that Ada is superior to everything, it must be because you're
ignorant. 

> About the only thing that C has going for it is that it has a large
> trained base of programmers (how well trained, I do not know).  This
> is because most of the schools now teach C as part of the curriculum,
> or when a curriculum does not teach a particular language, C is
> encouraged.  It is also easier to write little C programs than it is to
> write little Ada programs.  

The only thing?  Gee, that sort of begs the question of how it got
started, then, doesn't it?  I mean, why did all those schools start
teaching C and how did it get so popular?

[My school, at the time I went through it, didn't teach either C *or*
Ada.] 

>  However, when it comes to portability, reuse,
> large scale programming of any sort, C really does come up short.  

This does seem to leave a few facts requiring explanation, like how
all those large systems in C got implemented, where the large body of
fairly portable C code miraculously was created and how, etc.

> I agree
> with the commentor that it is such social factors that will be the true
> determiner of who comes out the winner in the "language wars."  Lets not
> forget that COBOL and FORTRAN are still winning by a large margin.

Reminds me of the response someone (Djikstra?  Knuth?) made a number
of years ago when asked what programming languages would be like in
the future.  The response ran something like, "I don't know what
features it will have, but I can tell you what it will be called.
FORTRAN." 

> 
> It is interesting that C++ has invented an inter-language
> calling mechanism.  

Why 'interesting'?  Any language that does name mangling (as C++ does)
is going to need an inter-language calling mechanism to tell the
compiler NOT to mangle certain identifiers so that the linker can find
them, particularly if backward compatibility and the ability to link
to modules of a language that does not do such mangling (C) is one of
the design goals.  This was hardly 'borrowed' from Ada.

> Also that the C community is now re-inventing
> tasking (threads), but doing it differently, but not better than,
> Ada.  

I wasn't aware that Ada 'invented' threads -- I don't believe that
putting them into C++ was borrowed from Ada, either, but rather driven
by the POSIX 'lightweight process' concept.

> There is no doubt that C++ was heavily influenced by Ada --

Well, I don't know about *heavily* -- Bjarne Stroustrup has publicly
stated which ideas were borrowed from where, including those which
were borrowed from Ada (the most useful of which is Exceptions, in my
opinion). 

> the C++ langauge developers admit that they were intelligent enough
> to borrow many good things from many sources.]

This is called 'evolution'.  One would HOPE that any good language was
designed by doing this.

-- 
"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: Open Systems closed to Ada?

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!csc.ti.com!til]

In <EMERY.92Nov30210601@dr_no.mitre.org> emery@dr_no.mitre.org (David Emery) wr
ites:

>The U.S. DoD has chosen Ada as a matter of policy.  Its rationale for
>its decision is well-known (and you can disagree with it if you wish.)
>But there's a big difference between the DoD policy on the use of Ada
>and the mantra that I've experienced in the C community.  

>Governments are *supposed* to make policy.  What I consider completely
>objectionable are the people within a technical community who take on
>the role of government/management and make the policy for them.  

Would you rather that government/management 'made policy' with no
input from the technical community?

>Maybe my experience in POSIX is different than the "real workd".  But
>I tell you this:  I've met very few C programmers who have any
>experience with languages significantly different than C (FORTRAN is,
>after all, a similar language.  

NOT!  Or at least no more similar than one procedural language is with
another. 

>Lisp, Smalltalk, SNOBOL, COBOL and Ada
>represent different paradigms.)  

I'm rather curious who these people in the 'C Community' are.  I
prefer (personally) both C++ and C to Ada; my language exerience (in
order) is: FORTRAN IV, BASIC, Pascal, FORTRAN 77, COMPASS, C, Ada,
C++; with brief exposures to SNOBOL, LISP, ALGOL, and a few others.
You insist that my preference must be due to ignorance, but then go on
to accuse the *C COMMUNITY* of being closed-minded and bigotted?

>Even those who profess to like C++
>think its greatest feature is backwards compatability with C.

Say WHAT?  Certainly that's one of many, but "its greatest feature"?
All I can say to that is that you really need to meet more people.

>Conversly, most Ada programmers (that I've met, and i know a LOT of
>Ada people) are familiar with several languages (almost all of them
>know C), and are able to understand the various features of different
>languages.  

Maybe this is your problem.  All the people you know are in the Ada
Community, so when your attitude toward people who aren't becomes
evident, you wind up seeing what you expect to see?

>The C community that I object to has as its primary characteristic
>"Narrow-Mindedness".  

Sounds like the Ada Community that I object to -- what with its rules
and 'Mandates' and accusations of "agree with us or you are ignorant
scum".  Of course, what I've described isn't the Ada Community at all,
but rather some vociferous minority within it.  And what you've
described isn't the "C Community", either.

>The "State religion" metaphor is interesting.  You can well consider
>Ada to be the 'state religion' for the U.S. DoD, but there's no
>requirement to use Ada outside of the DoD (which is the span of the
>Congressional mandate. No one has told HHS, or Agriculture or Commerce
>or Justice to use Ada...)  This can be compared to requiring devotion
>to the state religion while within church.  But, there's no
>requirement to pray to the state religion when outside of the
>state-run church.

>The Ayatollahs of the C community that I've dealt with have a
>different view.  Their view is that "everyone should obey the C
>faith".  People with different views are treated as blasphemers and
>heretics.  

Were you frightened by Dennis Ritchie when you were very young, or
what?  All I can say is that if you came at me with the attitude you
show here, you would probably get exactly the reception that your
attitude seems to lead you to expect.  

Is anyone, no matter who they are, surprised that the sort of abusive
attitude shown here is greeted with something less than love and
kindness from the other side?  

Whatever happened to simply using the best tools to get the job done,
whatever that job might be?  Why so many people who insist that one
tool MUST fit all?  And contrary to what David Emory claims, the
attitude seems to run the other way; there seem to be a lot of Ada
'proponents' who will tell you that if you didn't select Ada for any
important job that it can only be because you are an ignorant idiot or
a "C ayatollah".  More than I have ever encountered among C advocates,
in point of fact (although there are certainly some present in that
group, as well).

So, how about we get back to discussing *Ada* now?

-- 
"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: Open Systems closed to Ada?

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!li]

I promised myself I wasn't going to post any more on this topic.  But
I can't let this assertion by mccall@mksol.dseg.ti.com (fred j mccall
575-3539) go unanswered.

>Maybe this is your problem.  All the people you know are in the Ada
>Community, so when your attitude toward people who aren't becomes
>evident, you wind up seeing what you expect to see?

I have spent the last 5 years working on IEEE Standard P1003.5 Ada
Binding to POSIX.  During this time, I have attended more POSIX
meetings (3 or 4 annually) than Ada conferences.  It's my observation
that the great majority of people attending POSIX meetings are C
people.  I certainly don't think they would call themselves Ada
people.  

When I got started in the P1003.5 effort, I was hoping that we would
be welcomed by the rest of POSIX.  What I expected was disinterest.
What I found was hostility.  

So, I explicitly reject this statement by Fred McCall.  My comments on
the two communities are are explictly based with my experience working
in the POSIX community, which I believe to be dominated by C people.

And, Fred, please try to spell my last name right the next time you
flame me.  It's E-M-E-R-Y.  You wouldn't want people to be confused
about who you are attacking, would you?

				dave

Re: Open Systems closed to Ada?

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!wupost!cs.ut]

In <EMERY.92Dec4135828@dr_no.mitre.org> emery@dr_no.mitre.org (David Emery) wri
tes:

>I promised myself I wasn't going to post any more on this topic.  But
>I can't let this assertion by mccall@mksol.dseg.ti.com (fred j mccall
>575-3539) go unanswered.

>>Maybe this is your problem.  All the people you know are in the Ada
>>Community, so when your attitude toward people who aren't becomes
>>evident, you wind up seeing what you expect to see?

>I have spent the last 5 years working on IEEE Standard P1003.5 Ada
>Binding to POSIX.  During this time, I have attended more POSIX
>meetings (3 or 4 annually) than Ada conferences.  It's my observation
>that the great majority of people attending POSIX meetings are C
>people.  I certainly don't think they would call themselves Ada
>people.  

Well, there's certainly an unnexpected phenomenon, wouldn't you say?
NOT.  If you acted toward them with the same attitude you show here, I
can understand why you had problems.

>When I got started in the P1003.5 effort, I was hoping that we would
>be welcomed by the rest of POSIX.  What I expected was disinterest.
>What I found was hostility.  

Manifested how?  Surely they didn't just act hostile because you were
doing the Ada binding.  There had to be just a bit more to it than
that, wouldn't you say?

>So, I explicitly reject this statement by Fred McCall.  My comments on
>the two communities are are explictly based with my experience working
>in the POSIX community, which I believe to be dominated by C people.

Reject as you like.  There is a BIG difference between going to
meetings and KNOWING the people at those meetings.  From your attitude
here, I would guess that you couldn't be bothered to do the latter,
them only being C scum and all.  If you were anything like as
antagonistic there as you sound here, I can't express much surprise at
WHATEVER reception you got. 

>And, Fred, please try to spell my last name right the next time you
>flame me.  It's E-M-E-R-Y.  You wouldn't want people to be confused
>about who you are attacking, would you?

Flame you?  Attacking you?  After the things you've been posting, you
categorize my response as 'flaming' you?  No *wonder* you're having
problems.  Somebody at POSIX probably said 'hello' and you took it as
hostility, given the thin skin you seem to have here.

Oh, and just by the by, you might want to read through the netiquette
stuff on criticism regarding typing, spelling, grammar, etc.
Generally considered bad form, and all that.

Rave on, Dave.  Rant about the Evil C Conspiracy all you
want.  Just don't be surprised if people decline to see the world
through your ever-so-biased viewpoint.

Me, I prefer reality to raves.

[This one you can call a flame if you like.]

-- 
"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: Open Systems closed to Ada?

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!eff!wor]

>If you take a good look at STARS (as I know you profess to have done), you
>will recognize much of the truly innovative work that has gone on there.

If this stuff is so great, why don't I see any of the STARS vendors at
CASE shows and conferences marketing and publicizing their truly innovative
work?  Because, no one would buy the junk the the DoD willingly accepts.

Take IBM, the grand masters of hypocrisy in truly innovative technology.
They have a commercial line, AD/CYCLE, which addresses the same exact
problem in the real world that STARS addresses in the defense world.  Not
once in the past five years has IBM made any mention of Ada or STARS in
any of their AD/CYCLE material, presentations or products.  Why?  Because
IBM doesn't waste time on things no one wants to spend their money own.

Remember that "metaprogramming" doesn't mean "bettaprogramming".

Greg Aharonian
-- 
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178

Re: Open Systems closed to Ada?

[mcsun!uknet!yorkohm!minster!mjl-b]

In article <1992Dec4.163301.1791@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (f
red j mccall 575-3539) writes:
>In <1992Dec4.074834.24047@gvl.unisys.com> lonjers@prc.unisys.com (Jim Lonjers)
 writes:
>
>>It may come as a surprise to many folks that yes, even when people have a
>>choice, many choose Ada, and it is not limited to the more highly
>>publicized cases of Boeing (777) and Motorola (the Cellular Telephone
>>system).
>
>I think the question is not whether many do or not, but relatively how
>many when compared to other choices, and what are the jobs it is
>chosen for.

No, I think the quesion is _why_ did they made their choices.

My reasoning: Suppose many people may make a bad choice. Does this make the
choice any better?

>>[Just a few words of support for Dave Emery who seems to be under attack
>> for his views -- I too have observed the same pro-C militant attitudes.
>> Shall I say it?  Yes, it seems to be pretty much out of ignorance.  Most
>> of those who are militantly in favor or against any particular thing
>> are not all that well versed in the alternatives.
>
>And here we see the militant Ada attitude; if you don't agree with
>them that Ada is superior to everything, it must be because you're
>ignorant. 

This is an extreme response to Jim's statement of his experience.

>> About the only thing that C has going for it is that it has a large
>> trained base of programmers (how well trained, I do not know).  This
>> is because most of the schools now teach C as part of the curriculum,
>> or when a curriculum does not teach a particular language, C is
>> encouraged.  It is also easier to write little C programs than it is to
>> write little Ada programs.  
>
>The only thing?  Gee, that sort of begs the question of how it got
>started, then, doesn't it?  I mean, why did all those schools start
>teaching C and how did it get so popular?

It would indeed be interesting to find out why, as this sort of question is
the crux of why Ada is not more widespread. Again, you seem to be equating
"popular" with "good". My favourite refutation analogue follows:

From: rlk@VisiCom.COM
Date: 22 Apr 92 17:23:18 GMT

I've always wondered at the argument of of "programming language X must be
great because so many programmers write in it".  Hurrumph.  A similar
argument can be made for eating at McDonalds -- it must be the world's best
food, because more people eat at McDonalds than any other restaraunt.

But for mission-critical dining experiences, such as a two-year anniversary,
only a fool would go to McDonalds.  The added expense of a four-star
restaraunt is worth it, even though it may take longer.

	.Bob.

p.s. I hope McDonalds' lawyers don't read comp.lang.ada! ;-)

>> It is interesting that C++ has invented an inter-language
>> calling mechanism.  
>
>Why 'interesting'?  Any language that does name mangling (as C++ does)
>is going to need an inter-language calling mechanism to tell the
>compiler NOT to mangle certain identifiers so that the linker can find
>them, particularly if backward compatibility and the ability to link
>to modules of a language that does not do such mangling (C) is one of
>the design goals.  This was hardly 'borrowed' from Ada.

You've missed Jim's point about inter-operability of langauges. Yours is an
implementation issue and very specific to Unix-style linkers. With a simple
language like C, you only need a simple linker. But for more advanced
langauges, you're going to need a more advanced linker, or more "mangling".

>> Also that the C community is now re-inventing
>> tasking (threads), but doing it differently, but not better than,
>> Ada.  
>
>I wasn't aware that Ada 'invented' threads -- I don't believe that
>putting them into C++ was borrowed from Ada, either, but rather driven
>by the POSIX 'lightweight process' concept.

I wasn't aware that anyone was claiming that Ada invented threads.

Ada was one of the first languages to include a tasking model. All the
tasking stuff was pretty new and untried back in the early 80s. The POSIX
lightweight threads effort was driven by broadly similar goals to the Ada83
language team, and it's no surprise that they ended up with a very similar
model.

>Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me
.

Mat

| Mathew Lodge                      | "I don't care how many times they go    |
| mjl-b@minster.york.ac.uk          |  up-tiddly-up-up. They're still gits."  |
| Langwith College, Uni of York, UK |  -- Blackadder Goes Forth               |

Re: Open Systems closed to Ada?

[Michael Feldman]

In article <723246251.26591@minster.york.ac.uk> mjl-b@minster.york.ac.uk (Mathe
w Lodge) writes:
>
>The trouble with personal experiences is that they're all different. I know
>of some C++ programmers who used Ada for a project and are now "Ada
>converts". You know some C++ programmers who don't like Ada. I know some who
>do. My example is just as valid as yours, and just as meaningless.
>
Finally, a breath of fresh air in this stifling flame war. Can I suggest -
yet again - a moratorium on the "I like Ada" "I like C++" "So's your old
man" stuff, at least for a while?

This is a group on Ada. The personal experiences and preferences mentioned
by Mathew can be characterized as "religious preferences." The analogy to
religions is pretty decent: in this sense a religion is a _belief system_, 
based on axioms whose truth can be neither proved nor refuted. Adherents to
the religion _believe_ that their axioms are revealed from On High;
adherents to other religions believe the same of _their_ axioms. The
key point is that we are talking about faith, and rational arguments
are not usually helpful in shaking faith.

Let's all do each other a favor: stop proselytizing. The missionary zeal
that seems to flare up every few weeks on this group really gets in the
way of informed - hopefully technical - discussion. If you are a C++
adherent, interested not in understanding my religion but in proselytizing
for your own, please go back to your own church and get your bod out of mine.

If you work for DoD or its contractors, and are therefore subject to the
Mandate - admittedly a state-sponsored religion that applies ONLY to
the DoD software community - either relax and try to understand Ada,
which I assert is the purpose of the group, or go flame somewhere else.

I did not create the mandate, nor did anyone else who reads this group.
Regular readers of this group know I think it was a stupid blunder, but 
it exists and you're stuck with it. I am not; I am here by choice. Spare 
us your constant complaints; go lobby Congress to drop the mandate - they 
put it there in the first place. You're wasting your time here.

Give me and my co-religionists a break. OK? I am quite game to study
comparative religions, as an intellectual exercise. But the crusades have 
gone on too long for me. Stick to the subject or take your shouting
elsewhere.

Thanks much.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans want the fruits of patience -- and they want them now."
------------------------------------------------------------------------

Re: Open Systems closed to Ada?

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!sdd.hp.com!apo]

Thank You, Thank You, Thank You Michael...

I share your opinion in this matter, and I'd like to thank you for putting it
forth much more eloquently than I would have been able to.  :)

Cheers...

Thomas Vachuska
------------------------------------------------------------------------------
tom@mothra.rose.hp.com                   (916)-785-4983  (Telnet & Voice Mail)
------------------------------------------------------------------------------

Re: Open Systems closed to Ada?

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.go]

In <723739755.28314@minster.york.ac.uk> mjl-b@minster.york.ac.uk writes:

>In article <1992Dec4.163301.1791@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (
fred j mccall 575-3539) writes:
>>In <1992Dec4.074834.24047@gvl.unisys.com> lonjers@prc.unisys.com (Jim Lonjers
) writes:
>>
>>>It may come as a surprise to many folks that yes, even when people have a
>>>choice, many choose Ada, and it is not limited to the more highly
>>>publicized cases of Boeing (777) and Motorola (the Cellular Telephone
>>>system).
>>
>>I think the question is not whether many do or not, but relatively how
>>many when compared to other choices, and what are the jobs it is
>>chosen for.

>No, I think the quesion is _why_ did they made their choices.

>My reasoning: Suppose many people may make a bad choice. Does this make the
>choice any better?

Suppose many people made their choices based on unfouced assertions
about language superiority for this or that purpose?  You're just as
lost here, and probably will here "because it's better" a lot from
everyone.  I think looking at the TASKS to be performed and the
success or failure at those tasks makes for a less biased measure, if
there is any pattern to the choices at all.

>>>[Just a few words of support for Dave Emery who seems to be under attack
>>> for his views -- I too have observed the same pro-C militant attitudes.
>>> Shall I say it?  Yes, it seems to be pretty much out of ignorance.  Most
>>> of those who are militantly in favor or against any particular thing
>>> are not all that well versed in the alternatives.
>>
>>And here we see the militant Ada attitude; if you don't agree with
>>them that Ada is superior to everything, it must be because you're
>>ignorant. 

>This is an extreme response to Jim's statement of his experience.

How so?  Let's take a look at what we've seen asserted in this thread.

1) People who favor C over Ada only know C.
2) People who favor Ada over C have a knowledge of a multitude of
languages. 
3) People who favor C over Ada do so pretty much out of ignorance, and
the C community are the American Ayatollahs of computer language.

Now then, where was my remark such an 'extreme response', except
perhaps that the 'target' was people favoring Ada instead of people
favoring C/C++?

>>> About the only thing that C has going for it is that it has a large
>>> trained base of programmers (how well trained, I do not know).  This
>>> is because most of the schools now teach C as part of the curriculum,
>>> or when a curriculum does not teach a particular language, C is
>>> encouraged.  It is also easier to write little C programs than it is to
>>> write little Ada programs.  
>>
>>The only thing?  Gee, that sort of begs the question of how it got
>>started, then, doesn't it?  I mean, why did all those schools start
>>teaching C and how did it get so popular?

>It would indeed be interesting to find out why, as this sort of question is
>the crux of why Ada is not more widespread. Again, you seem to be equating
>"popular" with "good". My favourite refutation analogue follows:

No, I'm not equating popular with good.  The assertion was made that
the only thing C has going for it is a large trained base of
programmers and that schools teach it.  Well, extrapolating back into
the past, that can't have always been the case, so C must have, or at
least had in the past, SOMETHING else going for it.  This is a
question that isn't addressed in the ex-cathedra pronouncement that
the only thing C has going for it is a large trained base of
programmers, coupled with the backhand slap about "how well trained, I
do not know".  In point of fact, this pronouncement is falsified
simply by the fact that there must have been a time in the past when C
DIDN'T have a large trained base of programmers and WASN'T taught in
school.  If that were ALL it had going for it, those things would
never have come about.

>>> It is interesting that C++ has invented an inter-language
>>> calling mechanism.  
>>
>>Why 'interesting'?  Any language that does name mangling (as C++ does)
>>is going to need an inter-language calling mechanism to tell the
>>compiler NOT to mangle certain identifiers so that the linker can find
>>them, particularly if backward compatibility and the ability to link
>>to modules of a language that does not do such mangling (C) is one of
>>the design goals.  This was hardly 'borrowed' from Ada.

>You've missed Jim's point about inter-operability of langauges. Yours is an
>implementation issue and very specific to Unix-style linkers. With a simple
>language like C, you only need a simple linker. But for more advanced
>langauges, you're going to need a more advanced linker, or more "mangling".

Well, no, I didn't miss it at all.  The implication is all through
there that C++ is borrowing this or that from Ada, as a demonstration
of Ada's ostensible superiority.  I simply pointed out that this was
neither borrowed from Ada nor particularly surprising.  

>>> Also that the C community is now re-inventing
>>> tasking (threads), but doing it differently, but not better than,
>>> Ada.  
>>
>>I wasn't aware that Ada 'invented' threads -- I don't believe that
>>putting them into C++ was borrowed from Ada, either, but rather driven
>>by the POSIX 'lightweight process' concept.

>I wasn't aware that anyone was claiming that Ada invented threads.

Read the implications of the statement I'm replying to.  "Gee, Ada had
tasking already, and now C++ is 'reinventing' it."

>Ada was one of the first languages to include a tasking model. All the
>tasking stuff was pretty new and untried back in the early 80s. The POSIX
>lightweight threads effort was driven by broadly similar goals to the Ada83
>language team, and it's no surprise that they ended up with a very similar
>model.

Actually, I understood that there was a certain amount of friction
between the Ada Working Group, who wanted Lightweight Processes to
reflect the Ada tasking model, and a number of other interests who had
other concerns that they didn't feel the Ada tasking model met
sufficiently.  Of course, this is hearsay, since I wasn't there, but I
certainly don't find it particularly incredible.

-- 
"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: Open Systems closed to Ada?

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.go]

In <723740056.28422@minster.york.ac.uk> mjl-b@minster.york.ac.uk writes:

>In article <1992Dec4.165905.2316@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (
fred j mccall 575-3539) writes:
>>In <EMERY.92Nov30210601@dr_no.mitre.org> emery@dr_no.mitre.org (David Emery) 
writes:
>>>The U.S. DoD has chosen Ada as a matter of policy.  Its rationale for
>>>its decision is well-known (and you can disagree with it if you wish.)
>>>But there's a big difference between the DoD policy on the use of Ada
>>>and the mantra that I've experienced in the C community.  
>>
>>>Governments are *supposed* to make policy.  What I consider completely
>>>objectionable are the people within a technical community who take on
>>>the role of government/management and make the policy for them.  
>>
>>Would you rather that government/management 'made policy' with no
>>input from the technical community?

>No, I'd rather they form a higher order language group full of people from
>the technical community, review the languages in use to see if there's one
>good enough for what they want, and go on from there.

>Sure I've heard that somewhere before...

Ah, but there's a bit of difference between doing that periodically
and selecting the best tool for the job and going off to design your
own and then 'freezing' the state of the art and never looking again
(or only looking every dozen years or so).

>>Whatever happened to simply using the best tools to get the job done,
>>whatever that job might be?

>What, indeed, happened to that?

Governments started mandating things.  :-)

-- 
"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: Open Systems closed to Ada?

[Robert I. Eachus]

     I don't know why I bother, other than to lower my blood pressure...

In article <1992Dec5.231243.1533@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (f
red j mccall 575-3539) writes:

   In <EMERY.92Dec4135828@dr_no.mitre.org> emery@dr_no.mitre.org (David Emery) 
writes:

   >>I have spent the last 5 years working on IEEE Standard P1003.5 Ada
   >>Binding to POSIX...

   >>When I got started in the P1003.5 effort, I was hoping that we would
   >>be welcomed by the rest of POSIX.  What I expected was disinterest.
   >>What I found was hostility.  

   >Manifested how?  Surely they didn't just act hostile because you were
   >doing the Ada binding.  There had to be just a bit more to it than
   >that, wouldn't you say?

   >Reject as you like.  There is a BIG difference between going to
   >meetings and KNOWING the people at those meetings.  From your attitude
   >here, I would guess that you couldn't be bothered to do the latter,
   >them only being C scum and all...

     Fred, pay attention!  Dave did not say, I went to a few POSIX
meetings and made a lot of noise.  He said he spent five years working
on the P1003.5 Ada binding.  Dave didn't do ALL the work, but from
watching the process there were only a few people who did the work of
making the binding happen.  There is a big difference between
attending a conference or six and doing the work.

   >>And, Fred, please try to spell my last name right the next time you
   >>flame me.  It's E-M-E-R-Y.  You wouldn't want people to be confused
   >>about who you are attacking, would you?

   >Oh, and just by the by, you might want to read through the netiquette
   >stuff on criticism regarding typing, spelling, grammar, etc.
   >Generally considered bad form, and all that.

      Generally considered bad form to correct spelling errors, means
don't be one of a hundred idiots who post to point out a typing error.
It does NOT apply to correcting the misspelling of your own name,
especially as part of another post.

   >Rave on, Dave.  Rant about the Evil C Conspiracy all you
   >want.  Just don't be surprised if people decline to see the world
   >through your ever-so-biased viewpoint.

   >Me, I prefer reality to raves.

    Try reality then.  The ISO POSIX working group ISO/IEC
JTC1/SC22/WG15 refuses to submit any POSIX bindings, OTHER THAN C
BINDINGS, for standardization until the language independent binding
is complete.  Language independent bindings may be a good idea, but
this one has been going no where for years, and is delaying the
international approval of both Ada and FORTRAN bindings.  There is an
IEEE standard POSIX binding to Ada (P1003.5) which does not use the LI
binding, the IEEE POSIX Ada group has agreed to use the LI binding for
an Ada 9X binding, so why is there a problem.  Earlier this year, WG9
asked WG15 to expedite the Ada binding.  The action they took was
worse than delay...

--

					Robert I. Eachus

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

Re: Open Systems closed to Ada?

[dog.ee.lbl.gov!hellgate.utah.edu!caen!uwm.edu!linac!pacific.mps.ohio-stat]

I don't intend to fan the flames, but I'd like to shed a little light if I
can do so.  The first thing to realize is that the "C community" and the
"UNIX community" are closely tied together.  The language and the operating
system bootstrapped each other.

emery@dr_no.mitre.org (David Emery) writes:
>Maybe my experience in POSIX is different than the "real workd".  But
>I tell you this:  I've met very few C programmers who have any
>experience with languages significantly different than C (FORTRAN is,
>after all, a similar language.  Lisp, Smalltalk, SNOBOL, COBOL and Ada
>represent different paradigms.)...

While the classification of FORTRAN makes sense, COBOL belongs in the same
class.  (It differs most strongly in superficial matters.)  Ada isn't very
far out from C, FORTRAN, COBOL, (and you could add the extended Algol
family out through Pascal, too).  But this disagreement is less than our
agreement that Lisp, Smalltalk, and SNOBOL are truly different.

SNOBOL is unarguably different...it's definitely a different way of think-
ing.  Now, where is SNOBOL today?  Mostly history...it evolved through SL5
(which was mainly an experiment) to Icon.  Icon is alive and well; it's
being used for serious programming...in the UNIX community, where there was
a niche and it could find acceptance.  Most Icon programmers are also
competent C programmers--and the superficial appearance and syntax of Icon
bear a useful resemblance to that of C, although the programming paradigms
are very different.

Lisp?  Alive and well, obviously...and many mutations exist.  Interesting
that so many C programmers use emacs, an editor whose extensibility is
based on a Lisp programming model.

Or have a look at tcl, a tool-language that's emerged in the past few years
and met resounding success...in the C/UNIX community, because that's where
it could find people flexible enough to try something new.

You can even look at PostScript...and beneath the obvious strong influence
of Forth, you can see style obviously influenced by crossover C programmers.
There's "Display PostScript" and pswrap and its inverse and a pile of C /
PostScript interaction.  I suspect most PostScript programmers (an odd
breed) are also C programmers.

Beyond that, the C/UNIX community has achieved some of its most notable
results through the use of many little languages.  Any significant category
of tasks is a candidate for a new language.  If anything, people are TOO
ready to try new languages.  Various perceptions of the community's atti-
tudes can vary widely, but there are too many real polyglot examples to
maintain an honest belief that they have a one-language view.  C is the
Swiss-army-knife (and perl is the Swiss-army-chainsaw), or the Vise-
Grips(R)...but there are many other language tools.

>...Even those who profess to like C++
>think its greatest feature is backwards compatability with C.

(...iwillnotflameiwillnotflameIWILLNOTFLAMEokmaybejustalittlebit...)
This really is absurd on the face of it...nobody who can tell a keyboard
from a mouse would accept the size and complexity of C++ (and it IS too
large and too complex) just for a list of features whose top item is
backward compatibility.  Anyone who feels that way just writes in C.

>The C community that I object to has as its primary characteristic
>"Narrow-Mindedness".  

I've really never found this C community that you speak of...in spite of
having been in what is apparently "the C community" for about 12 years.
Since by long background I'm a "language person" I think I'd have noticed.
I've certainly played around with enough different languages in C-land.

>The Ayatollahs of the C community...[worst of the diatribe deleted]

I think you need to read Mike Feldman's recent article, have a beer, and
relax.  A string of epithets only adds to the arguments against your
position.
-- 
Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
	...Straight, but not narrow.

Re: Open Systems closed to Ada?

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!csn!raven!rcd]

I think I can suggest why David Emery has found some substantial hostility
towards Ada.

emery@dr_no.mitre.org (David Emery) writes:
>I have spent the last 5 years working on IEEE Standard P1003.5 Ada
>Binding to POSIX ... It's my observation
>that the great majority of people attending POSIX meetings are C
>people...

That's hardly surprising, is it?  To be succinct, POSIX is an effort to
standardize UNIX; UNIX and C are intimately tied together and owe their
successes to one another.  For better or worse, that's incontrovertible
history.

Now, realize that UNIX was being seriously used long before Ada started to
emerge...yet UNIX was (by virtue of heavy use in developmental situations)
late to come 'round to standardization.  By the time the POSIX effort
started, it was long overdue.

>When I got started in the P1003.5 effort, I was hoping that we would
>be welcomed by the rest of POSIX.  What I expected was disinterest.
>What I found was hostility.  

Why is this surprising?  Here are these folks who have been cookin' along
with UNIX for, say, eight years or so.  They know they need a standard;
they're getting desperate.  It is academically, intellectually, and most
important, commercially imperative that they get a standard they can use.
The definition of the system interface is cast, as it has been for many
years, in terms of C.  They're ready to do it; they know what they need;
they've finally hashed out most of their differences...and all of a sudden,
along comes the kid brother saying "hey, wait for me!  You gotta let me
play too!  Mom said so!"

Why should they be patient with someone joining the game late, trying to
get a share of the action?  Why *shouldn't* they be hostile?  They've got
work to do too.  The attempt to shift to language-independent definitions
of interfaces late in the game was a major obstacle to the work.

I'm not saying that the Ada folks are wrong in wanting to be part of the
POSIX effort.  I'm saying they came late to a game already under way.
-- 
Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
	...Straight, but not narrow.

Re: Open Systems closed to Ada?

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!enterpoop.mit.edu!linus!]

<well, I'm breaking my promise again to not post on this, but here goes.>

The goals of the P1003.5 effort was to provide Ada with access to the
facilities provided by a POSIX-compliant operating system.  A similar
group, P1003.9, worked on a FORTRAN binding to POSIX.  It's worth
noting that Unix has been multi-lingual for years, starting with
FORTRAN, and continuing through lots of other languages.  There is
substantial experience in the Unix community with providing access to
Unix services from languages other than C.  

>>When I got started in the P1003.5 effort, I was hoping that we would
>>be welcomed by the rest of POSIX.  What I expected was disinterest.
>>What I found was hostility.  

>Why is this surprising?  Here are these folks who have been cookin' along
>with UNIX for, say, eight years or so.  They know they need a standard;
>they're getting desperate.  It is academically, intellectually, and most
>important, commercially imperative that they get a standard they can use.
>The definition of the system interface is cast, as it has been for many
>years, in terms of C.  They're ready to do it; they know what they need;
>they've finally hashed out most of their differences...and all of a sudden,
>along comes the kid brother saying "hey, wait for me!  You gotta let me
>play too!  Mom said so!"

>Why should they be patient with someone joining the game late, trying to
>get a share of the action?  Why *shouldn't* they be hostile?  They've got
>work to do too.  The attempt to shift to language-independent definitions
>of interfaces late in the game was a major obstacle to the work.

I strongly suspect that you have not been a participant in the POSIX
standardization efforts.  Ada (and FORTRAN) binding efforts have had
little or no negative effect on the development of the C
standards/bindings.  During the balloting of POSIX P1003.1, a couple
of us sent in ballots commenting on some specific areas from an Ada
perspective.  In some cases, these ballots were used to decide between
two otherwise equal approaches.  During the development of the P1003.4
and P1003.4a real-time and threads standards, the Ada balloters have
been much more involved, but in this case there is not the base of
experience that existed for P1003.1, and the Ada community has
substantial experience implementing concurrency both on top of
traditional Unix systems, and also for real-time applications.

What the P1003.5 working group wanted from the POSIX standardization
effort was a reasonable forum to work in.  In particular, we wanted to
make sure that the Ada binding was technically correct from the POSIX
side, and also that it was usable from the Ada side.  During the
development and balloting of the standard, we received some really
outstanding ballots from balloters with little or no knowledge of Ada,
but substantial experience with C and POSIX.  It's probably worth
noting that P1003.5 had the _largest_ balloting group of any POSIX
standard to date, and achieved 91% consensus within that group, well
above the average approval rating for a POSIX standard.  

My problem comes with the conduct of the standardization committees.
As has been noted previously, ISO WG15, and also the IEEE TCOS SEC,
have been adept at developing bureaucratic roadblocks for language
bindings other than C.  Ada is not alone in this respect; the FORTRAN
group (P1003.9) has been similarly obstructed.  Much of this is
centered around the call for "language independence".  ISO has ruled
(for better or worse, mostly worse, in my opinion) that POSIX
standards should be developed using a language-independent notation,
with "thin" language bindings.  This has been used as justification to
prevent the FORTRAN and Ada bindings from achieving standardization,
but the same line of reasoning has NOT been applied to equivalent C
bindings.  

The net effect of these procedures has been to permit work on C
bindings to go forward, while holding back other language bindings
from full standarization.  I find this objectionable.  If a
requirement like language-independence is established, it should be
applied equally.  If language-independence and thin bindings are a
good thing for Ada and FORTRAN, then they are a good thing for C, too.
If they're not a good idea for C, why does anyone think they are good
for other languages?  

I don't want to see _any_ language binding prevented from achieving
standarization.  But, as an Ada advocate and Ada bindings developer, I
have a personal stake in the standardization of Ada bindings to open
systems standards such as POSIX, PHIGS, and X Windows.  

				dave

Re: Open Systems closed to Ada?

[Mark Breland]

Since my original post started this free for all, I suppose I should 
collaborate with Mike Feldman to help bring it to a close.  My intent in the
original post was to assess the community's feelings about the Ada/Open
Systems relationship.  The thread's descent into a fiery flame-off between
opposing language proponents both disturbs and angers me.  There is no
need whatsoever for distortion and vindictiveness between professionals
attempting to determine a reasonable means of making all of our jobs more
effective.  Every language has its own philosophical roots, some being
more closely related than others.  However, there must be some acceptable
middle ground to support interoperability.

Regardless of personal preferences, regardless of mandates, regardless of
OO, regardless of whose model came first, regardless of performance/efficiency,
this all boils down to a cold, hard, business fact.  Re-use will be a
pre-eminent requirement as all customers strive to cut development costs
to the absolute bone.  An application may very well be more appropriately
implemented in language X, yet end up employing language Y because there
already existed a preponderance of EXISTING language Y components which
addressed the application's problem domain.

So pick your analogous metaphor (religion, caste, race, gender)  and call
me altruistic, but the entire computing community must plot a path to
common ground (to at least shake hands and pass info), or we're doomed to
an infinite recursive standoff.

Mark A. Breland - Microelectronics and Computer Technology Corporation (MCC)
Ada Fault Tolerance                               | voice:    (512) 338-3509
3500 West Balcones Center Drive                   | FAX:      (512) 338-3900
Austin, Texas 78759-6509   USA                    | internet: breland@mcc.com

Re: Open Systems closed to Ada?

[Michael Feldman]

In article <1992Dec7.215946.18972@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (
fred j mccall 575-3539) writes:
>
[stuff deleted all over the place]

>>No, I'd rather they form a higher order language group full of people from
>>the technical community, review the languages in use to see if there's one
>>good enough for what they want, and go on from there.
>
>>Sure I've heard that somewhere before...
>
>Ah, but there's a bit of difference between doing that periodically
>and selecting the best tool for the job and going off to design your
>own and then 'freezing' the state of the art and never looking again
>(or only looking every dozen years or so).
>
Let's set out a few facts. The Ada standard was adopted in 1983 as an
ANSI standard. Following ANSI rules, the standard revisiting process
was begun in 1988, five years after adoption. That the revision seems to
be taking so long is a commentary on the social process of creating a
standard in the usual way, i.e. by a committee of many people - users,
vendors, Uncle Sam - each with their own agenda.

Consider the following other standards:

  ANSI C was adopted in (I think) 1990; the language was first published
  in 1975. It took 15 years to agree on a standard.

  Fortran 90 (!) was adopted only in 1992. The previous standard was
  Fortran 77, so the process started in 1982. So it took ten years.
  The standard prior to Fortran 77 was Fortran 66, 11 years before.

  ANSI Pascal was adopted in 1983; Pascal was first published in 1971,
  12 years before. Moreover, ANSI Pascal and ISO Pascal are slightly
  different (conformant array parameters are the only difference -
  ISO has 'em; the US faction didn't want 'em). So after laboring
  mightily, the Pascal work brought forth TWO mice. Ever look at the
  Pascal standard? Not worth the effort, if you ask me. MUCH too minimal,
  which only perpetuated the Pascal "feature wars." Ever try porting a
  Turbo Pascal program to Microsoft Pascal? They are DIFFERENT
  languages.

What's the point? The Ada9X project is doing NOTHING but following the
traditional ANSI process. If X=3 or X=4, as is likely, the revision
will set a new record for expeditiousness. Building a standard
after the fact, when everyone has vested interests ranging from
serious desire for change to strong desire for no change, is simply
not easy. C, Fortran, and Pascal are ample evidence of the social 
problems. (Cobol's even better, but I've lost track of that process.)

Ada83 was frozen, and 1815-A enforced with a mighty hand, because DoD was
simply not about to keep working with constantly moving targets. And,
by the way, the ISO standard is the same as the ANSI one. So there is a
single worldwide standard. This is bad?

The copyright and trademark lapsed in 1988. People who complained about
DoD not allowing experimentation could EASILY have done as they wished
from 1988 on. Validation is required ONLY for DoD contract compilers;
there is no reason why Ada-like supersets could not have been built
and marketed after 1988, to the rest of the world. I am constantly
amazed at the number of people who don't even know that Ada has not
been a trademark for 4 years. People who beef about features they'd
like in Ada could simply have gotten together and produced a compiler
that implemented their wish list.

Ada9X will not even be a MIL standard, if I understand correctly. It
will simply be an ANSI standard like all the others. Presumably DoD
will freeze it for their own work - why shouldn't they? For the rest
of us, the sky is the limit, just as it is for all the other languages.
Grab GNAT when it comes out, add features to your heart's delight,
experiment, run it up the flagpole and see who salutes.

C++ is reasonably common across compilers, but not as much so as Ada,
although I am told it's catching up. When will we see a C++ standard?
If your answer is "over my dead body - who wants it to stagnate?"
then you are precisely missing the point about why DoD wants a 
language standard. One man's stagnation is another man's stability.

I hear lots of sob stories from teachers and students of C++ whose
code will compile under g++ but not under Turbo, and vice versa.
And NOT because the class libraries are different (which they are),
but because the languages differ just enough to cause madness.
This is good? It's 1992, folks. How long will we fight the feature wars?

Well, it's deja vu again. This is another round of the ancient debate
between free choice and predestination. The nice thing about standards
is that they achieve stability. The rotten thing about standards is
that they achieve stability. Take your choice.

IMHO, DoD is doing the right thing by opting for a strong and enforceable
standard. Shooting at a moving target is no fun. I don't often defend
Defense, but dammit, I think they are right on target here. Contractors
who want to experiment with a moving state of the art with MY tax money
are just outta luck.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans want the fruits of patience -- and they want them now."
------------------------------------------------------------------------

Re: Open Systems closed to Ada?

[Michael Feldman]

In article <1992Dec7.232157.3816@ennews.eas.asu.edu> koehnema@enuxha.eas.asu.ed
u (Harry Koehnemann) writes:
>
>It does - free compilers.  Universities are poor.  C compilers are free
>on Unix platforms.  In contrast, Ada compilers are absurdly expensive.
>Since our US industry is so reluctant to spend money on anything that
>might take more than 3 months to start showing a return on their
>investment (like training), they'll use the language dictated to them
>by the current masses.

Now, now. $1500. for a server license is absurdly expensive? Gimme a break.
Even if only 50 students a year use it, that's 30 bucks a seat.
We just purchased Alsys for the HP900-800 for $1800. We will have at
least 200 students a year on it. $9.00 a student is too much?

Ever look at the price of Sabre C? I have fought as hard as anyone else
in the industry for free Ada compilers, but not so that we can kill off
the commercial ones - not at current university pricing. I want GNAT
because I get sources with it, so I and my students can tinker.

More and more current masses are learning Ada. (Details on request.)

BTW - I'll agree wholeheartedly that the _commercial_ compiler prices 
are still way too high. The response, in general, is that the price of
a compiler, even if it's high, is marginal as a fraction of the cost of
a serious industry project.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans want the fruits of patience -- and they want them now."
------------------------------------------------------------------------

Re: Open Systems closed to Ada?

[Michael Feldman]

In article <1992Dec8.093525@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) wr
ites:

[lots of great stuff deleted]
>
>I think you need to read Mike Feldman's recent article, have a beer, and
>relax.  A string of epithets only adds to the arguments against your
>position.

I couldn't agree more :-)

Seriously, thanks for the support, Dick.

Mike Feldman

Re: Open Systems closed to Ada?

[Rob Spray]

In <1992Dec9.205207.4722@ennews.eas.asu.edu> koehnema@enuxha.eas.asu.edu (Harry
 Koehnemann) writes:

>The context of the question was "What did C have going for it in the
>past that makes it popular today".  The first I became aware of "cheap"
>Ada compilers was ~1989 with Meridians $150 compiler for the PC (site
>licenses too).  However, 1989 isn't soon enough to see Ada intergrated
>into CS programs (although that is now starting to happen) or to produce
>the same volume of Ada programmers we currently see available for C.
>If cheap compilers came out earlier, then maybe I'm wrong.

They were there, you just had to hustle!  In 1985, I got a deep 
discount on a Verdix compiler for Southern Methodist University's
VAX running 4.2bsd.  It wasn't advertised, but a few phone calls
made it happen.  It was good too.  My graduate students were using
the debugger to debug tasking programs based solely on info they
gleened from the man pages (I had the only set of manuals, so they 
wouldn't go for a walk.)

--Rob    spray@convex.com
--former Visiting Industrial Professor, SMU

Disclaimer: my present employer uses Verdix technology, but I had
no relation with Verdix other than as a happy academic customer in 1985.

Re: Open Systems closed to Ada?

[agate!spool.mu.edu!uwm.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mkso]

In <1992Dec7.232157.3816@ennews.eas.asu.edu> koehnema@enuxha.eas.asu.edu (Harry
 Koehnemann) writes:

>In article <1992Dec7.215753.18846@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com 
(fred j mccall 575-3539) writes:
>>
>>No, I'm not equating popular with good.  The assertion was made that
>>the only thing C has going for it is a large trained base of
>>programmers and that schools teach it.  Well, extrapolating back into
>>the past, that can't have always been the case, so C must have, or at
>>least had in the past, SOMETHING else going for it.

>It does - free compilers.  Universities are poor.  C compilers are free
>on Unix platforms.  In contrast, Ada compilers are absurdly expensive.
>Since our US industry is so reluctant to spend money on anything that
>might take more than 3 months to start showing a return on their
>investment (like training), they'll use the language dictated to them
>by the current masses.

While this is certainly one factor that may have contributed to the
popularity of C, I don't see it as a full explanation.  After all, it
was also used rather heavily in some areas of industry before that
pupularity was ever achieved.  Why would people LIKE such a language
and prefer to work in it?  We did this a while back; most of us don't
appear to have been locked into the languages we learned first, so
this can't be a full explanation.

-- 
"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: Open Systems closed to Ada?

[agate!spool.mu.edu!uwm.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mkso]

In <EACHUS.92Dec7182950@oddjob.mitre.org> eachus@oddjob.mitre.org (Robert I. Ea
chus) writes:


>     I don't know why I bother, other than to lower my blood pressure...

Well, I'm not sure why you bothered, either, but if it makes you feel
better, why go for it.  :-)

>In article <1992Dec5.231243.1533@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (
fred j mccall 575-3539) writes:

>   In <EMERY.92Dec4135828@dr_no.mitre.org> emery@dr_no.mitre.org (David Emery)
 writes:

>   >>I have spent the last 5 years working on IEEE Standard P1003.5 Ada
>   >>Binding to POSIX...

>   >>When I got started in the P1003.5 effort, I was hoping that we would
>   >>be welcomed by the rest of POSIX.  What I expected was disinterest.
>   >>What I found was hostility.  

>   >Manifested how?  Surely they didn't just act hostile because you were
>   >doing the Ada binding.  There had to be just a bit more to it than
>   >that, wouldn't you say?

>   >Reject as you like.  There is a BIG difference between going to
>   >meetings and KNOWING the people at those meetings.  From your attitude
>   >here, I would guess that you couldn't be bothered to do the latter,
>   >them only being C scum and all...

>     Fred, pay attention!  Dave did not say, I went to a few POSIX
>meetings and made a lot of noise.  He said he spent five years working
>on the P1003.5 Ada binding.  Dave didn't do ALL the work, but from
>watching the process there were only a few people who did the work of
>making the binding happen.  There is a big difference between
>attending a conference or six and doing the work.

Robert, pay attention!  Fred did not say that Dave said that.
However, what Dave DID say was that they were "greeted with animosity"
or something very similar.  Now, that hardly sounds like the closest
working relationship in the world, now does it?

>   >>And, Fred, please try to spell my last name right the next time you
>   >>flame me.  It's E-M-E-R-Y.  You wouldn't want people to be confused
>   >>about who you are attacking, would you?

>   >Oh, and just by the by, you might want to read through the netiquette
>   >stuff on criticism regarding typing, spelling, grammar, etc.
>   >Generally considered bad form, and all that.

>      Generally considered bad form to correct spelling errors, means
>don't be one of a hundred idiots who post to point out a typing error.
>It does NOT apply to correcting the misspelling of your own name,
>especially as part of another post.

Certainly it does, unless it is done repeatedly.  Criticizing typos is
one of the commonest obfuscatory tactics used on Usenet.  That's part
of the reason why that bit is in the netiquette.

>   >Rave on, Dave.  Rant about the Evil C Conspiracy all you
>   >want.  Just don't be surprised if people decline to see the world
>   >through your ever-so-biased viewpoint.

>   >Me, I prefer reality to raves.

>    Try reality then.  The ISO POSIX working group ISO/IEC
>JTC1/SC22/WG15 refuses to submit any POSIX bindings, OTHER THAN C
>BINDINGS, for standardization until the language independent binding
>is complete.  Language independent bindings may be a good idea, but
>this one has been going no where for years, and is delaying the
>international approval of both Ada and FORTRAN bindings.  There is an
>IEEE standard POSIX binding to Ada (P1003.5) which does not use the LI
>binding, the IEEE POSIX Ada group has agreed to use the LI binding for
>an Ada 9X binding, so why is there a problem.  Earlier this year, WG9
>asked WG15 to expedite the Ada binding.  The action they took was
>worse than delay...

Well, there's just a bit more to this, from what I understand about
what is going on.  As I understand it, ISO didn't just 'make up' this
rule; there is something in their setup that REQUIRES that anything
not based on a specific language be written in language-independent
terms.  Now, as long as POSIX and C were treated alone, everything was
fine.  Once other language bindings started to turn up, they have to
be done in a language-independent fashion.  I understood that this was
initially a problem with more than just the two language bindings --
that it was a problem with all of POSIX.  However, I also understand
that ISO wound up basically getting told something like, "We'll fix it
later, but if you think that the U.S. is going to wait on a Standard
and that all these people are going to go back and redo all that work
just to comply with your rules, you're kidding yourself."  They were
basically offered the choice of taking it with a C spec or of going
their own way.  Economics rather forced the former course, predicated
by the promise to migrate things to a more language-independent form.
They sort of have to buy the C bindings, since without them there is
no POSIX right now.

Completer facts are better.  Anyway, this hardly sounds like some vast
conspiracy against Ada, once it's looked at in context.

-- 
"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: Open Systems closed to Ada?

[agate!spool.mu.edu!uwm.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mkso]

In <EMERY.92Dec8095856@dr_no.mitre.org> emery@dr_no.mitre.org (David Emery) wri
tes:

>My problem comes with the conduct of the standardization committees.
>As has been noted previously, ISO WG15, and also the IEEE TCOS SEC,
>have been adept at developing bureaucratic roadblocks for language
>bindings other than C.  Ada is not alone in this respect; the FORTRAN
>group (P1003.9) has been similarly obstructed.  Much of this is
>centered around the call for "language independence".  ISO has ruled
>(for better or worse, mostly worse, in my opinion) that POSIX
>standards should be developed using a language-independent notation,
>with "thin" language bindings.  This has been used as justification to
>prevent the FORTRAN and Ada bindings from achieving standardization,
>but the same line of reasoning has NOT been applied to equivalent C
>bindings.  

Well, as I understand it, the attempt was made to apply it to the
equivalent C bindings, and it was pointed out that trying to do that
would practically require redoing all of POSIX and that the people
doing the work simply weren't going to stand for that right now.  I
also understand that this isn't exactly a 'new rule' pulled out by ISO
just to obstruct Ada as a sop to the 'Great C Conspiracy'.  I agree
with you that it's a crock, but it's the price we pay for trying to
play with ISO.

>The net effect of these procedures has been to permit work on C
>bindings to go forward, while holding back other language bindings
>from full standarization.  I find this objectionable.  If a
>requirement like language-independence is established, it should be
>applied equally.  If language-independence and thin bindings are a
>good thing for Ada and FORTRAN, then they are a good thing for C, too.
>If they're not a good idea for C, why does anyone think they are good
>for other languages?  

Well, actually, I gather that they don't.  The C folks would just as
soon let you bind to C instead of some language-independent form.  ISO
is the roadblock, and from what I hear they also wanted to try to
force C Language to do this -- but right now it's so embedded in the
POSIX spec that it can't really be done without major rework of POSIX.
ISO was (once again, rumor based knowledge) basically told that if
they wanted to play in POSIX they would simply have to accept things
the way they were right now, with a promise to address language
independence on the next pass.  Personally, I think this approach
should have been followed for ALL the language specs, but that isn't
how it came down.  Personally, I also feel that painting this as some
'conspiracy' or 'antagonism to Ada' by the 'C community' is both
untrue and somewhat less than productive.

>I don't want to see _any_ language binding prevented from achieving
>standarization.  But, as an Ada advocate and Ada bindings developer, I
>have a personal stake in the standardization of Ada bindings to open
>systems standards such as POSIX, PHIGS, and X Windows.  

Gee, Dave, we agreed about something!  Now if you could have just
avoided this 'in your face' approach in the first place . . . 

Probably too much to ask for, though.

-- 
"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: Open Systems closed to Ada?

[agate!spool.mu.edu!uwm.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mkso]

In <1992Dec9.052624.23020@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman)
 writes:

>In article <1992Dec7.215946.18972@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com 
(fred j mccall 575-3539) writes:
>>
>[stuff deleted all over the place]

>>>No, I'd rather they form a higher order language group full of people from
>>>the technical community, review the languages in use to see if there's one
>>>good enough for what they want, and go on from there.
>>
>>>Sure I've heard that somewhere before...
>>
>>Ah, but there's a bit of difference between doing that periodically
>>and selecting the best tool for the job and going off to design your
>>own and then 'freezing' the state of the art and never looking again
>>(or only looking every dozen years or so).
>>
>Let's set out a few facts. The Ada standard was adopted in 1983 as an
>ANSI standard. Following ANSI rules, the standard revisiting process
>was begun in 1988, five years after adoption. That the revision seems to
>be taking so long is a commentary on the social process of creating a
>standard in the usual way, i.e. by a committee of many people - users,
>vendors, Uncle Sam - each with their own agenda.

Facts are always good, but I'm not sure what your point is.

>Consider the following other standards:

>  ANSI C was adopted in (I think) 1990; the language was first published
>  in 1975. It took 15 years to agree on a standard.

Yes, but no one is 'mandating' that I must freeze technology and use
ANSI C if I have something that will do the job better.

>  Fortran 90 (!) was adopted only in 1992. The previous standard was
>  Fortran 77, so the process started in 1982. So it took ten years.
>  The standard prior to Fortran 77 was Fortran 66, 11 years before.

Yes, and FORTRAN 90 (originally intended to be FORTRAN 88) was a
pretty contentious thing.  Once again, so what?  No one is 'mandating'
that I must freeze technology and use FORTRAN 90 if I have something
that will do the job better.

>  ANSI Pascal was adopted in 1983; Pascal was first published in 1971,
>  12 years before. Moreover, ANSI Pascal and ISO Pascal are slightly
>  different (conformant array parameters are the only difference -
>  ISO has 'em; the US faction didn't want 'em). So after laboring
>  mightily, the Pascal work brought forth TWO mice. Ever look at the
>  Pascal standard? Not worth the effort, if you ask me. MUCH too minimal,
>  which only perpetuated the Pascal "feature wars." Ever try porting a
>  Turbo Pascal program to Microsoft Pascal? They are DIFFERENT
>  languages.

I'm aware.  However, once again, no one is 'mandating' that I must
freeze technology and use ANSI-standard Pascal if I have something
that will do the job better.

>What's the point? The Ada9X project is doing NOTHING but following the
>traditional ANSI process. If X=3 or X=4, as is likely, the revision
>will set a new record for expeditiousness. Building a standard
>after the fact, when everyone has vested interests ranging from
>serious desire for change to strong desire for no change, is simply
>not easy. C, Fortran, and Pascal are ample evidence of the social 
>problems. (Cobol's even better, but I've lost track of that process.)

Yes, but there is an 'Ada Mandate' that basically forces people to
freeze technology in between standard revisions.  Where are the 'C
Mandate', the 'FORTRAN Mandate', or the 'Pascal Mandate' which would
force me to freeze technology?

>Ada83 was frozen, and 1815-A enforced with a mighty hand, because DoD was
>simply not about to keep working with constantly moving targets. And,
>by the way, the ISO standard is the same as the ANSI one. So there is a
>single worldwide standard. This is bad?

It's bad if there's a 'mandate' requiring the freezing of technology
for eleven years.

>The copyright and trademark lapsed in 1988. People who complained about
>DoD not allowing experimentation could EASILY have done as they wished
>from 1988 on. 

Yes, but you can't USE the results of that 'experimenation' for
anything.  'Ada Mandate', you know.

>Validation is required ONLY for DoD contract compilers;
>there is no reason why Ada-like supersets could not have been built
>and marketed after 1988, to the rest of the world. 

Yes, but why would they?  The biggest market was and is for Defense
stuff.  Why expend the effort to make something that most people using
the language simply couldn't use?

>I am constantly
>amazed at the number of people who don't even know that Ada has not
>been a trademark for 4 years. People who beef about features they'd
>like in Ada could simply have gotten together and produced a compiler
>that implemented their wish list.

Well I knew that.  Yes, people could have done that, but why?  You
couldn't use such a compiler for anything.  First there has to be a
market for it.

>Ada9X will not even be a MIL standard, if I understand correctly. It
>will simply be an ANSI standard like all the others. Presumably DoD
>will freeze it for their own work - why shouldn't they? For the rest
>of us, the sky is the limit, just as it is for all the other languages.
>Grab GNAT when it comes out, add features to your heart's delight,
>experiment, run it up the flagpole and see who salutes.

This may actually be the first real step for Ada.  Most babies walk
when they're a bit younger, but it's never too late.  

>C++ is reasonably common across compilers, but not as much so as Ada,
>although I am told it's catching up. When will we see a C++ standard?
>If your answer is "over my dead body - who wants it to stagnate?"
>then you are precisely missing the point about why DoD wants a 
>language standard. One man's stagnation is another man's stability.

The problem isn't "having a standard"; the problem is "having a
Mandate".  It's the Mandate that puts the incentive to stagnate in
(because it closes the main market for improvements).

>I hear lots of sob stories from teachers and students of C++ whose
>code will compile under g++ but not under Turbo, and vice versa.
>And NOT because the class libraries are different (which they are),
>but because the languages differ just enough to cause madness.
>This is good? It's 1992, folks. How long will we fight the feature wars?

Well, there's also the problem that the hardware and operating systems
are radically different, but hey, let's ignore that.  The problem is
that people are writing non-portable code, not that the language
allows you to do it.

>Well, it's deja vu again. This is another round of the ancient debate
>between free choice and predestination. The nice thing about standards
>is that they achieve stability. The rotten thing about standards is
>that they achieve stability. Take your choice.

No, the nice thing about standards is that you can pick the ones you
like; there are so many of them, and all conflicting.  :-)

Anyway, the problem isn't with standards -- the problem is with
Mandates. 

>IMHO, DoD is doing the right thing by opting for a strong and enforceable
>standard. Shooting at a moving target is no fun. I don't often defend
>Defense, but dammit, I think they are right on target here. Contractors
>who want to experiment with a moving state of the art with MY tax money
>are just outta luck.

Can we actually document any savings, or are we still working on
guesswork and theory in this area?  Anyway, wouldn't it make more
sense to freeze on a per-contract basis rather than to Mandate frozen
technology for a dozen years at a time?

-- 
"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: Open Systems closed to Ada?

[Robert I. Eachus]

    I'm not going to quote any of Fred McCall's broken record,
especially since most of it just ain't so.  The DoD mandate says use
a validated Ada compiler.  The validation rules go on to say what
validation of an Ada compiler means.  It has never meant, and never
will mean strict conformance to a particular standard.  (Godel proved
that impossible quite a while ago.)  Validation sets a standard of
quality, and provides a process for determining whether a particular
deviation from the ACVC tests can be justified.

    In particular if a compiler vendor has an Ada compiler which
includes some Ada 9X features, or adds support for rate-monotonic
scheduling or what have you, it is not automatically rejected.
Instead, any deviations are evaluated to determine if the vendor's
justification is in fact acceptable.

    In practice the ARG acts as a court of last resort in such cases.
If the fast reaction team (FRT) or the ARG feels that an issue needs
further discussion, the validation certificate in question is issued,
and the test in question is withdrawn if necessary until the issue is
resolved.  Starting with ACVC 2.0, this process will be further
streamlined to encourage vendors to offer such (legitimate)
extensions, and also to allow vendors to release new technology
sooner.

    There have been cases where some members felt this was used by one
vendor or another as a sort of sneaky loophole, but others didn't.  In
this case the rule is effectively innocent unless unanimously found
guilty.  In other cases--even though the test was correct and the
compiler was wrong--a test was withdrawn because the ARG felt it was
counterproductive.  We even have a class of AI called pathology,
informally defined as "we'll tell the vendors what they should do, but
no user, and especially no ACVC test, should expect it to work that
way."

     So validation and the Ada mandate are NOT intended to stiffle
innovation or limit creativity.  They are intended to insure that long
lived source code is still useable ten years from now, without a lot
of support costs.  You don't like that, play in another sandbox.  I
can find you companies which mandate FORTRAN, C, C++, COBOL, and LISP,
but you probably wouldn't be happy with any of them.  The company
policy is there for the same reason as the DoD policy, and your
difficulty seems to involve having rules to enforce software
engineering standards.

--

					Robert I. Eachus

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

Re: Open Systems closed to Ada?

[agate!stanford.edu!kronos.arc.nasa.gov!butch!iscnvx!news]

   Fred, I lost count of the number of times you used the word "mandate" in
your last post, but I gather that this is a pet peeve of yours.

   In all seriousness, your implication that no one would use a non-validated
Ada compiler, and therefore such a compiler has no value, seems suspect to me.
If you would briefly grant me the assumption that the mandate was being
successfully enforced, would you agree with the statement that "No one can use
any 'C' compiler, therefore 'C' compilers are useless"?  I doubt it.

   I disagree with the Ada mandate; however, when all is said and done, the DoD
is just one software customer.  I doubt there's a large market for Macintosh
software at IBM.  It hasn't kept Mac programmers from peddling their wares
elsewhere.  If the DoD chooses to freeze THEIR technology for eleven
years at a pop, IT'S THEIR CHOICE (and, IMHO, one whose wisdom has yet to be
established).

Re: Open Systems closed to Ada?

[Michael Feldman]

In article <1992Dec11.131655.23725@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com 
(fred j mccall 575-3539) writes:
>
>>IMHO, DoD is doing the right thing by opting for a strong and enforceable
>>standard. Shooting at a moving target is no fun. I don't often defend
>>Defense, but dammit, I think they are right on target here. Contractors
>>who want to experiment with a moving state of the art with MY tax money
>>are just outta luck.
>
>Can we actually document any savings, or are we still working on
>guesswork and theory in this area?  Anyway, wouldn't it make more
>sense to freeze on a per-contract basis rather than to Mandate frozen
>technology for a dozen years at a time?
>
My experience is that the projects are sufficiently complex that the numbers
can be cooked to show savings or lack of savings according to the motive
of the writer. Lots of people are trying to show that Ada saves money,
and because they want these numbers to come out right, they do. Others
want just as desperately to show no savings, and I'm sure the numbers
would come out their way too. Maybe I'm too cynical, but I don't put
all that much faith in these arguments, one way or the other.

The Mandate give a starting date (June 1, 1991), but no end date. What
makes you think that DoD will NECESSARILY "freeze technology" for the
next eleven years? If the technology changes such as to make it
manifestly obvious that the Mandate should go away, I'm sure that
it can be made to do so. Lots of clever people at DoD and on the Hill.

In the meantime, in effect the decision IS being made project by project.
How else? Each project is contracted for individually. If the manager
can make the case that Ada is manifestly not cost-effective, (s)he
can get that waiver or exception. The practical effect of the mandate
is to make the nay-sayers defend their case, instead of making the yea-sayers
defend _their_ case. I see nothing wrong with that. 

The _psychological_ effect of the 1990 Mandate is why I think it was a dumb
idea. The rest of the world says "how good could Ada be if DoD has to
force it on its own contractors?" and shuts off discussion, figuring
it's not worth investigating further. 

I happen to believe that the jury is still out on cost-effectiveness _on 
a single project_ - that one can cook the numbers any way one likes, 
because the differences are not well-understood and probably at the margins 
of the project, and also because the language/OS field is very fluid
these days and compiler version K running on system version P could
give VERY different numbers from K+1 and P+1. It comes down to a 
question of will. People who wish to operate in good faith and give
Ada their best shot without endlessly nay-saying will, in my idealistic
view of the world, manage to come up with a good and cost-effective
project. Those who wish to keep sabotaging an effort will, I'm sure,
find endlessly creative ways to do so.

The _global_ cost-effectiveness of doing a large number of 
projects with a small number of languages seems obvious to me.
Frankly, I really wish people would settle down, accept the Mandate
as given for the time being, shut up and get the work done.
That is, IMHO, the best way to spend my tax dollars.

Reminds me of a saying I learned in Holland: "Niet kakelen,
eieren leggen." Stop cackling and lay eggs.

Mike Feldman

Re: Open Systems closed to Ada?

[Michael Feldman]

In article <92346.46129.LJ10891@LMSC5.IS.LMSC.LOCKHEED.COM> LJ10891@LMSC5.IS.LM
SC.LOCKHEED.COM writes:
>
>   I disagree with the Ada mandate; however, when all is said and done, the Do
D
>is just one software customer.  I doubt there's a large market for Macintosh
>software at IBM.  It hasn't kept Mac programmers from peddling their wares
>elsewhere.  If the DoD chooses to freeze THEIR technology for eleven
>years at a pop, IT'S THEIR CHOICE (and, IMHO, one whose wisdom has yet to be
>established).

I agree entirely with your statement about the Mac. 

The wisdom of the mandate has yet to be established; on the other hand,
nobody has yet established its foolishness either. I have no problem
with DoD mandating Ada. My problem arise when someone in Congress figured
it was a good idea to write it into the law. There's a difference. I
guess it's just another example of us Americans trying to fix with laws
what we've lost the ability to fix with common sense.

Mike
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans want the fruits of patience -- and they want them now."
------------------------------------------------------------------------

Re: Open Systems closed to Ada?

[Arthur Evans]

mfeldman@seas.gwu.edu (Michael Feldman) says:
>> My experience is that the projects are sufficiently complex that the
>> numbers can be cooked to show savings or lack of savings according to
>> the motive of the writer. Lots of people are trying to show that Ada
>> saves money, and because they want these numbers to come out right,
>> they do. Others want just as desperately to show no savings, and I'm
>> sure the numbers would come out their way too. Maybe I'm too cynical,
>> but I don't put all that much faith in these arguments, one way or
>> the other.

True, of course.  Nonetheless, the paper "Ada Outperforms Assembly: A
Case Study" (citation below) given at TRI-Ada '92 last month is surely
relevant.  I quote the abstract in its entirety:

    With the intent of getting an Ada waiver, a defense contractor wrote
    a portion of its software in Ada to prove that Ada could not produce
    real-time code.  The expectation was that the resultant machine code
    would be too large and too slow to be effective for a communications
    application.  However, the opposite was verified.  With only minor
    source code variations, one version of the compiled Ada code was
    much smaller while executing at the same speed, and a second version
    was approximately the same speed but much faster than the
    corresponding assembly code.

What was interesting here is that they intended to prove Ada inadequate
and ended up proving just the opposite, somewhat to their initial
dismay.  Details are in the paper, which I commend to your attention.

Here are two quotes from the paper, both being paragraphs quoted in
their entirety:

    How can a compiler for a high-order language beat assembly code in
    both size and performance?  It is because of a reasonably high level
    of maturity on the part of compiler development in general and the
    compiler vendor in specific.  When a vendor brings a wealth of
    experience to bear on optimization, it goes beyond the capabilities
    of any one individual, no matter how experienced.

    QRS [the pseudonym for the defense contractor, which is not
    identified] is convinced.  It has now decided to use Ada extensively
    because it believes the use of Ada will provide the company with a
    competitive edge in the market place.

The paper is by Patricia K Lawlis and Terance W Elem and appears on
pages 334-337 of the Conference Proceedings.  I suspect that you can get
a reprint from Tartan, which is rather proud of the fact that their
compiler was used.

Art Evans
----------------------------------------------
Arthur Evans, Jr, PhD           Ada Consultant
461 Fairview Road
Pittsburgh PA  15238-1933
412-963-0839
ae@sei.cmu.edu

Re: Open Systems closed to Ada?

[agate!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall]

In <92346.46129.LJ10891@LMSC5.IS.LMSC.LOCKHEED.COM> LJ10891@LMSC5.IS.LMSC.LOCKH
EED.COM writes:

>   Fred, I lost count of the number of times you used the word "mandate" in
>your last post, but I gather that this is a pet peeve of yours.

>   In all seriousness, your implication that no one would use a non-validated
>Ada compiler, and therefore such a compiler has no value, seems suspect to me.

It may seem suspect, but take a look at who the major Ada customers
are, at least in this country.  If the government won't buy off on it,
companies probably aren't going to go to the effort of producing it.

>If you would briefly grant me the assumption that the mandate was being
>successfully enforced, would you agree with the statement that "No one can use
>any 'C' compiler, therefore 'C' compilers are useless"?  I doubt it.

No, because the major customer for C has no such 'mandate'.

>   I disagree with the Ada mandate; however, when all is said and done, the Do
D
>is just one software customer.  I doubt there's a large market for Macintosh
>software at IBM.  It hasn't kept Mac programmers from peddling their wares
>elsewhere.  If the DoD chooses to freeze THEIR technology for eleven
>years at a pop, IT'S THEIR CHOICE (and, IMHO, one whose wisdom has yet to be
>established).

Yes, it's their choice.  And it stultifies the Ada market.


-- 
"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: Open Systems closed to Ada?

[agate!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall]

In <EACHUS.92Dec11133546@oddjob.mitre.org> eachus@oddjob.mitre.org (Robert I. E
achus) writes:


>    I'm not going to quote any of Fred McCall's broken record,
>especially since most of it just ain't so.  

Disproof by assertion.  Lovely.

>The DoD mandate says use
>a validated Ada compiler.  The validation rules go on to say what
>validation of an Ada compiler means.  It has never meant, and never
>will mean strict conformance to a particular standard.  (Godel proved
>that impossible quite a while ago.)  Validation sets a standard of
>quality, and provides a process for determining whether a particular
>deviation from the ACVC tests can be justified.

No, what it means is that you have to pass the validation suite.  This
means, in essence, no significant extensions to the language.

>    In particular if a compiler vendor has an Ada compiler which
>includes some Ada 9X features, or adds support for rate-monotonic
>scheduling or what have you, it is not automatically rejected.
>Instead, any deviations are evaluated to determine if the vendor's
>justification is in fact acceptable.

Then it's rejected. ;-)

Seriously, do you honestly believe that if someone had come up with an
Ada compiler that allowed multiple inheritance, etc., in 1986, that it
would have been validate?  *I* don't.

>    In practice the ARG acts as a court of last resort in such cases.
>If the fast reaction team (FRT) or the ARG feels that an issue needs
>further discussion, the validation certificate in question is issued,
>and the test in question is withdrawn if necessary until the issue is
>resolved.  Starting with ACVC 2.0, this process will be further
>streamlined to encourage vendors to offer such (legitimate)
>extensions, and also to allow vendors to release new technology
>sooner.

And just what constitutes an 'illegitimate' extension and how do you
decide?  What about a compiler whose default behaviour matches the
standard (and passes the validation suite) but which has switches that
turn on and off various features.  Would you validate it or not?

>    There have been cases where some members felt this was used by one
>vendor or another as a sort of sneaky loophole, but others didn't.  In
>this case the rule is effectively innocent unless unanimously found
>guilty.  In other cases--even though the test was correct and the
>compiler was wrong--a test was withdrawn because the ARG felt it was
>counterproductive.  We even have a class of AI called pathology,
>informally defined as "we'll tell the vendors what they should do, but
>no user, and especially no ACVC test, should expect it to work that
>way."

>     So validation and the Ada mandate are NOT intended to stiffle
>innovation or limit creativity.  

Of course they're not INTENDED to do that.  Hell, nobody sets out to
DELIBERATELY prevent progress.

>They are intended to insure that long
>lived source code is still useable ten years from now, without a lot
>of support costs.  

It is one thing to say what the language should do and test for that
insofar as comiling working code.  The problem is that in a lot of
cases extensions to the compiler that permit it to accept certain
constructs that are 'not Ada' is enough to prevent validation (unless
they've changed the rules considerably).  That's hardly necessary to
keep working code working, now is it?  After all, if the code wasn't
'broken' originally, it won't be broken in the future.  Of course,
USING one of those extensions can lead to code that breaks on a
compiler that doesn't support them (presumably the reason why getting
compilers with extensions through validation is tough), but what about
pragmas?  One compiler could offer a pragma that another doesn't
support, and when you change compilers code is going to break.  So
just what have you accomplished, other than discouraging innovation? 

>You don't like that, play in another sandbox.  

I don't like it.  I think it's a bad idea.  I will continue to say
that I think it's a bad idea.  If you don't like that, go to a country
where the government is allowed to prevent people from saying what
they think.

>I
>can find you companies which mandate FORTRAN, C, C++, COBOL, and LISP,
>but you probably wouldn't be happy with any of them.  

Well, goody goody for you.  I certainly hope those companies are
working in a field for which that mandated language is well suited;
otherwise they're doing the same silly thing that the govenrment does. 

>The company
>policy is there for the same reason as the DoD policy, and your
>difficulty seems to involve having rules to enforce software
>engineering standards.

Well, I don't feel particularly responsible for how things "SEEM" to
you.  The problem would appear to be with your perceptions.

-- 
"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: Open Systems closed to Ada?

[agate!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall]

In <1992Dec11.212550.23767@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman
) writes:

>In article <1992Dec11.131655.23725@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com
 (fred j mccall 575-3539) writes:
>>
>>>IMHO, DoD is doing the right thing by opting for a strong and enforceable
>>>standard. Shooting at a moving target is no fun. I don't often defend
>>>Defense, but dammit, I think they are right on target here. Contractors
>>>who want to experiment with a moving state of the art with MY tax money
>>>are just outta luck.
>>
>>Can we actually document any savings, or are we still working on
>>guesswork and theory in this area?  Anyway, wouldn't it make more
>>sense to freeze on a per-contract basis rather than to Mandate frozen
>>technology for a dozen years at a time?
>>
>My experience is that the projects are sufficiently complex that the numbers
>can be cooked to show savings or lack of savings according to the motive
>of the writer. Lots of people are trying to show that Ada saves money,
>and because they want these numbers to come out right, they do. Others
>want just as desperately to show no savings, and I'm sure the numbers
>would come out their way too. Maybe I'm too cynical, but I don't put
>all that much faith in these arguments, one way or the other.

Probably quite true.  I just think that appeals to all the savings
that Ada provides when we don't seem to have a lot of proof over the
long term that it's providing such savings are just slightly less than
convincing. 

>The Mandate give a starting date (June 1, 1991), but no end date. What
>makes you think that DoD will NECESSARILY "freeze technology" for the
>next eleven years? If the technology changes such as to make it
>manifestly obvious that the Mandate should go away, I'm sure that
>it can be made to do so. Lots of clever people at DoD and on the Hill.

Because I expect that once it is in effect, it will remain in effect.
Bureaucratic inertia, if nothing else, which means the technology can
only change when the language definition is changed; about every 10-12
years. 

>In the meantime, in effect the decision IS being made project by project.
>How else? Each project is contracted for individually. If the manager
>can make the case that Ada is manifestly not cost-effective, (s)he
>can get that waiver or exception. The practical effect of the mandate
>is to make the nay-sayers defend their case, instead of making the yea-sayers
>defend _their_ case. I see nothing wrong with that. 

I think it makes more sense to simply do the thing in the best
language for the job, and make EVERYBODY defend their case.  The idea
that there's a 'default' language that you have to make a case AGAINST
strikes me as a problem.

>The _psychological_ effect of the 1990 Mandate is why I think it was a dumb
>idea. The rest of the world says "how good could Ada be if DoD has to
>force it on its own contractors?" and shuts off discussion, figuring
>it's not worth investigating further. 

>I happen to believe that the jury is still out on cost-effectiveness _on 
>a single project_ - that one can cook the numbers any way one likes, 
>because the differences are not well-understood and probably at the margins 
>of the project, and also because the language/OS field is very fluid
>these days and compiler version K running on system version P could
>give VERY different numbers from K+1 and P+1. It comes down to a 
>question of will. People who wish to operate in good faith and give
>Ada their best shot without endlessly nay-saying will, in my idealistic
>view of the world, manage to come up with a good and cost-effective
>project. Those who wish to keep sabotaging an effort will, I'm sure,
>find endlessly creative ways to do so.

Quite true.  However, the fact that something can be made into a "good
and cost-effective project" using Ada still doesn't say that Ada was
the best choice.  It's almost a "well, you may as well lay back and
enjoy it" attitude.  You can't do anything about the weather, so you
may as well just deal with it.  The same kind of thinking gets applied
to the Mandate, I suspect.

>The _global_ cost-effectiveness of doing a large number of 
>projects with a small number of languages seems obvious to me.
>Frankly, I really wish people would settle down, accept the Mandate
>as given for the time being, shut up and get the work done.
>That is, IMHO, the best way to spend my tax dollars.

I think we'd all be better served by OPEN discussion, rather than a
Mandate.  The "soldier, shut up and soldier" argument is one with
which I'm quite familiar; I'm just not convinced that it's the best
approach to producing the best products for the tax money we spend
doing it. 

-- 
"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: Open Systems closed to Ada?

[Pete Carah]

In article <1992Dec13.151515.27646@sei.cmu.edu> ae@sei.cmu.edu (Arthur Evans) w
rites (quotes...):
>    QRS [the pseudonym for the defense contractor, which is not
>    identified] is convinced.  It has now decided to use Ada extensively
>    because it believes the use of Ada will provide the company with a
>    competitive edge in the market place.
Or when the compiler isn't better for particular cases (e.g. device drivers
and, say, specialized display drivers for which you want to unroll large
loops, etc), one can prototype in ada and hand-convert to assembly when
the program is debugged.  Of course, assembly optimizations and the
related ada source optimizations may not exactly correspond.  However,
this may make the assembly development both faster and more reliable.
I have done this several times in 286-based systems using the Meridian
compiler (whose optimizer wouldn't handle programs as big as ours at the
time, and which wasn't as good at PARTICULAR optimizations specific to
the task as we were).  Ada's package isolation makes this easy to
manage.

Ada is certainly not a bad language; it wasn't nearly as well supported
as C for its first 5 or more years, but that is finally getting better.

I have objections to the mandate being used to force, say, 20-30 (or even
several hundred) line snobol (or awk, for example; there are related
problems in non-text situations too) programs to be developed in ada
where the result (because of lack of associative array packages, for
an example from awk) would require thousands of lines of ada to be
written.  The symbol table packages in the repository are in general
not very portable - we DID try to use several of them (in other
situations) and ran into problems with compile-time symbol-table size,
and generated-code segment size (remember this was on a 286).

If the program volume in the repository ever gets up to even
comp.sources.unix (which has been a very low-volume group lately) it
may start to be useful.  Note too that the only program from the
unix sources groups which I've had problems with on a 286 was pathalias
(for the hash table for system names).  (compress has similar problems
but since the hash table is fixed size, someone solved that problem
long ago.  The result runs even in MSDOS real-mode.)

-- Pete

Re: Open Systems closed to Ada?

[David Emery]

>Ada is certainly not a bad language; it wasn't nearly as well supported
>as C for its first 5 or more years, but that is finally getting better.

Huh?  How many C compilers were there during the first 5 years of C,
back around 1972 or so...
				dave

Re: Open Systems closed to Ada?

[agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!pa]

In <EMERY.92Dec16101016@dr_no.mitre.org> emery@dr_no.mitre.org (David Emery) wr
ites:

>>Ada is certainly not a bad language; it wasn't nearly as well supported
>>as C for its first 5 or more years, but that is finally getting better.

>Huh?  How many C compilers were there during the first 5 years of C,
>back around 1972 or so...

Well, I don't think C was five years old until 1977-78.  The B compiler
was written by Ken Thompson in 1970 (1).  Unix was re-written in C in 1973.
(2).

However, in 1978, apart from the PDP-11, "C compilers run on a wide
variety of machines, including the Honeywell 6000, the IBM System/360,
and the Interdata 8/32."(3)

Sounds like about where Ada was ten years later, no?  In terms of 
compiler availability, that is.

I surmise that the original poster meant that during the first five
of Ada compiler availability, C was a better supported language in
terms of compiler availability and tool support. Hardly a revelation,
since it's a smaller language and roughly a decade older.

--Rob  spray@convex.com

(1) Bell System Technical Journal July-August 1978 Vol 57, No 6, Part 2
    p1992
(2) ibid, p1907
(3) ibid, p1991