A farewell to Ada

A farewell to Ada

[Ted Holden]

 
 
 
      I've noticed that much of the present scholastic debate over Ada
involves fine points concerning the letter of the law (was Ada "intended"
to function in embedded systems etc.).  This is the kind of thing I expect
to see associated with losing causes.  Remember, the Apostle said
something like: "The letter of the law killeth, whereas the spirit giveth
life..."  People involved with winning causes are usually too busy making
money to be arguing over the letter of the law.
 
      The spirit of the Ada documents was never in doubt.  What was wanted
was a language which could be used for every kind of software project,
from embedded system to large database, and run on every kind of computer
system, from micro to mainframe.  Reasonable performance was expected on
all computers and for all projects.  Ability to run with minimal OS and
other language support was wanted.  Further, logical clarity and large-
scale re-usability of software was desired.
 
Journal articles indicate a continuing failure of Ada to work for embedded
systems as well as for large scale projects, a continuing failure to run
with acceptable performance on anything other than parallel or special-
purpose, expensive systems, and an actual gain in cross-system complexity
and decrease in the stated goal of reuseability.  In particular, the
ordinary systems which most people will be seeing in front of them for the
next 5 - 15 years, UNIX systems and PCs, will not run Ada accepteably.
 
C began with real machines, real programmers.  The idea seems to have
been:  
 
      "Lets take a hard look at this little PDP-7 and design a language
      which is one-to-one with its logical operations as many ways as
      possible (the plus-plus operator and register increments and so on)
      so that the code is as FAST as can be contrived, maximally easy to
      implement (so that next year when we get our PDP7.5 or whatever,
      we're back rolling in 2 weeks), and, within these constraints, is
      as amenable to human logic as possible in a no-nonsense, point-and-
      shoot kind of way, so that we end up with a kind of high-structured,
      low-level language; a thinking-man's assembler.  And then, let's
      write an operating system (UNIX) in that language so that, when we
      get our PDP-7.5, or the next year's computer, whatever it may be,
      we're REALLY back rolling two weeks later.
 
The maximal ease of implementation was achieved by making the core
language as small as possible, other functionality being left to the
operating system and to libraries, some standard amongst UNIX systems and
others peculiar to various other OSs and hardware bases for which C would
be implemented.  This allowed good and inexpensive C compilers to evolve
rapidly for PCs and other micros and, since the authors of those compilers
maintained the standard libraries as close as possible to the UNIX
implementations, C became the natural bridge between mid-sized and large
computers running UNIX and the micros.  
 
C thus achieved its present position of dominance in the mini-micro world,
and appears to be well poised for the future as well.  C++ appears to be
an entirely rational and intelligent extension of C, superimposing the
entire object-oriented paradigm including the features Ada leaves out.  
In particular, there appears to be no more than a 5% performance
degradation, if that, going from C to C++, at least judging from Turbo C
2.0 and the Zortech C++ compiler, and I assume the same will hold true
when you start seeing good native-mode C++ compilers for UNIX.
 
In fact, C++ appears to BE the very language which Ada was supposed to be
(the spirit of the law) but never can and never will be.  
 
Far from sharing this "real-world" sort of a heritage, Ada appears to have
its beginnings on the other edge of reality or non-reality, dependant on
one's point of view.  Ada appears to have been designed as a physical
embodiment of state-of-the-art principles of "software-engineering",
whatever that's supposed to mean, seemingly by assembling 300 committee
members in a room, having each draw up a maximum possible wish-list of
features for a programming language and/or operating system, and then
adding up all of the lists to a "standard", with any considerations of
real-world computers being regarded as unimportant. 
 
Ada is what you might expect from a programming language designed by
committee;  it is unbelievably slow, an unbelievable resource hog,
involves constant dilemmas over which is the real OS today, Ada or UNIX,
Ada or Dos etc. i.e. do we use Ada tasking, again frighteningly slow, or
ordinary UNIX tasking and inter-process communication, Ada source control
or SCCS, etc.  Naturally, the Ada task manager and the UNIX process
scheduler clash.  As for compiling, my experience has been that, with a
PC and lots of memory to play with, Ada compilers at least will get back
to you on the same DAY;  on a UNIX machine with ten other users doing
various other kinds of things, God forbid other Ada compiles, forget it.
 
The one thing which one might reasonably expect all of this slowness and
clunk to purchase, the one thing which might partially redeem the
situation were Ada to have it, is the object oriented paradigm: 
inheritance of classes and polymorphism.  Ada doesn't have it.
 
Most of the Ada journal articles begin with glowing headlines, and you
have to be able to read between the lines, but this isn't terribly
difficult.  For instance, a large section of articles in the December 88
Journal of Electronic Defense began with the title "Ada:  Maybe Not So Bad
After All". Remember, Ada has been around since 1979.  If that were the
best anybody could say about C after ten years, C compiler salesmen would
be starving and dying like flies.
 
     A senior Intel product marketing engineer is quoted on page 36 of the
same issue:  
 
      "the people who designed the Ada programming language were compiler
      experts, software experts - they weren't necessarily people familiar
      with real-time embedded systems."
 
Another article in the same issue describes the use of Ada in connection
with a real-time embedded digital signal processing application.  Since
Ada tasking could not be made fast enough for such work, the engineers
adapted a commercial run-time system, VRTX, and informed all programmers: 
 
 
     "Thou shalt not use Ada tasking, but rather VRTX tasking.
     "Thou shalt not use Ada dynamic memory allocation...
     "Thou shalt not use Ada generics; too slow...
 
and, when they finished with the "Thou shalt nots", what they had
left of Ada was a subset of Pascal which they had paid many thousands of
dollars for.  A far better Pascal compiler is produced by Borland and can
be had at B Dalton's for around $100.  Needless to say, the Rupe-
Goldbergesque system they ended up with was considerably less maintainable
than they might have gotten just using C.  This seems to be the rule.
 
The September/October 88 issue of Defense Computing carried a similar
article:  "Running in Real Time:  A Problem for Ada".  All other stories
concerning Ada and embedded systems read similarly.
 
     Does Ada work any better for large scale systems?  Another article
in the same Journal of Electronics Defense issue describing use of Ada on
the 1,246,000 line Army AFATDS system claims that:
 
      "Ninety percent of the software requirements were met with no major
      software problems."
 
as if this were good.  The man is claiming that he had major language-
related problems with 124,600 lines of code out of 1,246,000.  Again C
language is not noted for this kind of thing, nor would C be around if it
were.
 
     There was a recent DOD Computing Journal Article titled "Is Ada
Getting Better or Just Older?".  Again you don't read that sort of thing
about C.  There is the August 21 89 issue of Government Computer News
describing the problems which the huge FAA Advanced Automation System is
having due to IBM Ada implementations and tools (or lack thereof).  
 
     The SoftTech notes from the RICIS convention included mention of one
speaker's statement:  "Ada and UNIX doesn't work".  I've heard that a
million times from users, first time that succinctly in print.  Between
UNIX and Ada, UNIX is the real-world standard;  conflicts between it and
Ada will not be resolved in favor of Ada.  Hate to disillusion anybody...
 
     It would appear that the articles written by the real-time people are
saying "well, it isn't doing us any good but it must be working out great
for the mainframe guys, else why would we still be seeing it and be
ordered to use it?" and that the mainframe and database crowd is claiming
just the opposite.  Somebody must be hoping that nobody ever reads all of
these articles and starts putting two and two together.
 
      There are numerous problems associated with the fact that Ada
believes itself to be an OS, aside from the clashes between Ada and real
operating systems.  There is the further obvious problem that somebody
with a large mainframe/Cobol application which he thinks to port to a
UNIX/Ada system will need to redesign and rewrite his entire system from
scratch whereas, using C language, he might have written Cobol-callable
routines incrementally and had his application back up in a matter of days
or weeks instead of years.  There is no real way to call an operating
system from a Cobol program.
 
      The actual use of Ada is further complicated by three considerations
which really amount to theological problems INVOLVING Ada rather than
faults of Ada itself, but which, nonetheless, probably wouldn't exist if
Ada didn't exist.
 
First, the programming style being promulgated by DOD for Ada is anti-
conducive to the stated goal of readability;  it's like looking at a
thousand-page novel such as "War and Peace" with three or four lines of
programming code interspersed every second page or so.  The verbiage hides
the logic.  When every variable name looks like:
 
      "NUMBER_OF_CROWS_SALLY_ANNS_GRANDMOTHER_SHOT_WITH_HER_12_
      GAUGE_-LAST_TUESDAY",
 
then a single subroutine call (involving several such variables) can take
up a whole page.  In my own scheme of things, I try to keep literature and
programming separate.
 
Second, DOD is often insisting on portability via Ada rather than
portability via UNIX, POSIX calls etc.  This amounts to such things as
insisting, for instance, that vendors provide direct Ada hooks to a
database rather than simply writing an Ada -> C -> database hook.  Typical
vendor response is either "F... You" or "Manana".
 
A third is an over-emphasis on design, which often leads to grief in the
real-world.  I believe in designing in the large, nailing down interfaces
at tightly as possible, then rapid prototyping of individual modules,
followed by final design documentation and PDLs at low level.  I know of
numerous horror stories involving design-totally-then-code, but one very
recent one, naturally involving Ada, seems to top all.  
 
A military project involving Sun machines and Ada was abandoned after
something like 4 years and $30 million effort because of unacceptable
performance;  database screens were taking over a minute to come up.  The
design work had all been done according to your formula, the individual
modules had been designed, written, and tested, all according to the
standard military schedules and formulas (2167 etc.).  Everything seemed
hunky dory, only when they put the fricking thing together, it was too
damned slow to use.  And, the remarkable thing is, the very system the
military insists upon for management of software contracts prevented
anybody from knowing they were in trouble until four years and millions
had been blown.  The government people involved were essentially reduced
to the role of actors in a Greek tragedy.
 
Asked for a solution, my firm weighed the choice between offering an Ada-
to-C converter and silence, and opted for silence.
 
It sometimes seems to me that the Soviet military is kept backwards in
computers by a temporary lack of funds, while our military is required by
law to be backwards, and that may not be temporary.  Any rate, my guess
is that the general Russian skill with linguistics would prevent them from
ever being ensnared with Ada;  they would take one look and toss it. 
Slava Bogu.
 
      Ada threatens to leave DoD stranded and technologically backwards;
out of the mainstream of American computer science.  The better class of
programmers coming out of the schools will be used to the 2 second
compiles of Turbo C and Turbo Pascal.  Offer them jobs involving Ada, and
most if not all of them are probably going to give you the finger,
figuring they'd be happier selling used cars for a living.  
 
      There is the further problem of our present micro market being a
completely open system;  a representative of the KGB, the Turkish Empire,
the Green Dragon Tong, the successors to the AssHola Khomeini, Khadaffi,
or anybody else could walk into a B. Dalton's today and buy a copy of
Turbo C 2.0 or Zortech C++ for about $100.  Again, if I were the guy up
there getting into machine gun and rocket fights at 1600 mph, the last
thing I'd want to hear was that my machine guns and rockets were working
slower and/or less reliably than the other guy's because he bought a copy
of Turbo C at B. Dalton's, while my people were spending billions on Ada.
 
 
Ted Holden
HTE

Re: A farewell to Ada

[schmidt]

In article <14033@grebyn.com>, ted@grebyn (Ted Holden) writes:
>Ada is what you might expect from a programming language designed by
>committee;  it is unbelievably slow, an unbelievable resource hog,
>involves constant dilemmas over which is the real OS today, Ada or UNIX,
>Ada or Dos etc. i.e. do we use Ada tasking, again frighteningly slow, or
>ordinary UNIX tasking and inter-process communication, Ada source control
>or SCCS, etc.  Naturally, the Ada task manager and the UNIX process
>scheduler clash.  As for compiling, my experience has been that, with a
>PC and lots of memory to play with, Ada compilers at least will get back
>to you on the same DAY;  on a UNIX machine with ten other users doing
>various other kinds of things, God forbid other Ada compiles, forget it.

Along the same lines, lately I've heard a number of people make the
claim that:

  `There now exist Ada compilers that produce faster code than C/C++
  compilers.'

Naturally, taken out of context this statement doesn't mean very much,
since one can always find a lousy C/C++ compiler and an application
that brings out the worst in the compiler and vice versa for Ada.

Therefore, I'm curious to know what valid empirical studies have been
performed to compare `x' Ada compilers against `y' C/C++ compilers
across a representative set of benchmarks.  Furthermore:

1. Which `top-of-the-line' Ada compilers produce the best code?
2. How long do they take to compile non-contrived programs?
3. What are their resource constraints and requirements?
3. How reliable are they in practice?
4. And how much do they cost compared to `top-of-the-line' C/C++ compilers?

Without evidence of this sort the entire `language imperialism' debate
becomes egregiously religious.

Obviously, ``speed-of-generated-code'' or ``length-of-compile-time''
are not the only criteria by which to judge the success or failure of
a language.  However, since Ada supporters are beginning to make these
claims I'd like to see some supporting evidence!

thanks,

  Doug

Re: Ada

[William Thomas Wolfe, 2847]

From article <14033@grebyn.com>, by ted@grebyn.com (Ted Holden):
> Journal articles indicate a continuing failure of Ada to work for embedded
> systems as well as for large scale projects, a continuing failure to run
> with acceptable performance on anything other than parallel or special-
> purpose, expensive systems, and an actual gain in cross-system complexity
> and decrease in the stated goal of reuseability.  

   This is blatantly false; consider the November 1988 article
   in IEEE Software ("Large Ada projects show productivity gains"):

      After years of development and an initial skeptical reception,
      many people are now using Ada and saying that they like it...
      The growth in Ada's use has been helped by favorable reports
      from early adopters ("Ada Catches on in the Commercial Market,
      Soft News, IEEE Software, November 1986, p. 81) and by the
      growing number of validated compilers... project results show
      that Ada can greatly increase productivity for large systems...
      [in a 1.2-million-line Ada project] reuseable software developed 
      on the project was counted only once.  Roughly 13 percent of the
      delivered software was reuseable.  This reuse saved 190 man-months
      of effort (a 9-percent savings) and reduced the schedule by two
      calender months (a 4-percent savings)... Productivity for the
      execution environment -- including the operating system, data
      management, information management, communications support, and
      communications interface -- was 550 lines per man-month... 
      Productivity for the applications software... was 704 lines per
      man-month... the average productivity of the 1,500 systems in
      productivity consultant Lawrence Putnam's database: 77 lines
      per man-month (at the 1.2-million-line level)... 

   Sounds like a continuing *success* to me... 
   
> In particular, the
> ordinary systems which most people will be seeing in front of them for the
> next 5 - 15 years, UNIX systems and PCs, will not run Ada accepteably.

   Precisely the point of Dr. Charles McKay, head of the Software
   Engineering Research Consortium, in his Tri-Ada '88 presentation,
   "Standards for the Sake of Standards -- A Recipe for Failure".

   A prime example is Unix; the current POSIX effort aims to 
   standardize 1960's technology, thus resulting in a "lowest
   common denominator" which locks users into obsolescence.

   Ada's problem with Unix is that Unix, being 1960's technology,
   does not properly support lightweight processes.  Modernized 
   versions of Unix (e.g., MACH) which are designed to provide
   such support remove the difficulty.  Note that C or C++ programs
   making use of the same "heavyweight" tasking facility will be
   equally slow, since they rely on precisely the same system. 

   If one does not have to struggle with the limitations of *Unix*,
   then there is a wide selection of Ada compilers which run Ada 
   within that environment quite nicely.  Some, like the Telesoft
   TeleGen2 compiler, have global optimization facilities which
   result in better code than that which can be produced by current
   C compilers (as of Tri-Ada '88). 
   
> C began with real machines, real programmers.  The idea seems to have
> been:  [...] end up with a kind of high-structured, low-level language; 
> a thinking-man's assembler.  

   Yes, as one Usenetter's .signature states, "C combines the power
   of assembly language with the flexibility of assembly language".

   Fortunately, the economics of software development are in favor
   of using considerably higher-level languages.

> C++ appears to BE the very language which Ada was supposed to be
> (the spirit of the law) but never can and never will be.  

   Total rubbish; C++ retains all the low-level and dangerous
   facilities of C, which is obsolescent by modern software
   engineering standards.  As stated by Fairley (Software
   Engineering Concepts, page 228),  

      Modern programming languages provide a variety of
      features to support development and maintenance of
      software products.  These features include strong
      type checking, separate compilation, user-defined
      data types, data encapsulation, data abstraction,
      generics, flexible scope rules, user-defined exception
      handling, and concurrency mechanisms.  This chapter
      discusses these concepts...

   Now C++ has one useful feature which Ada does not: inheritance.
   But it is also (as its designer freely admits) lacking in
   generics and exception handling, and also does not provide
   a means of expressing concurrency in a standardized, portable way. 
   Since tools such as Classic Ada permit the use of inheritance with
   Ada (generating *standardized*, compile-it-anywhere code), this is
   something which can be worked around until Ada 9X brings it in directly. 

> Ada is what you might expect from a programming language designed by
> committee;  it is unbelievably slow, an unbelievable resource hog,

   This has been a property of some early Ada *compilers*, but is
   not a property of the Ada *language*.  Fortunately, compiler
   technology is now capable of delivering tight, efficient Ada
   object code, better than that being produced by C compilers.

   Compilation is slower because the Ada compiler is doing much
   more work for you; this reflects again the economics of software
   development in that machine time is cheaper than programmer time.

> [...] There is the August 21 89 issue of Government Computer News
> describing the problems which the huge FAA Advanced Automation System is
> having due to IBM Ada implementations and tools (or lack thereof).  

   Are you saying that this is the fault of the *language*, or of IBM?

> There is no real way to call [Ada] from a Cobol program.

   Ada users can call COBOL or any other language using pragma
   INTERFACE; COBOL needs to have a similar standardized means
   of calling other languages.  Given that it does not, ad hoc
   means of calling other languages have been devised; there is
   no reason why such techniques cannot be used to call Ada just
   as well as C or any other language.  But this is COBOL's problem,
   not Ada's.  
    
> the programming style being promulgated by DOD for Ada [descriptive
> variable names] is anti-conducive to the stated goal of readability;  

   To C hackers, who are accustomed to single-letter variables, yes.

   Software engineering specialists tend to have the opposite perspective.

> Second, DOD is often insisting on portability via Ada rather than
> portability via UNIX, POSIX calls etc.  This amounts to such things as
> insisting, for instance, that vendors provide direct Ada hooks to a
> database rather than simply writing an Ada -> C -> database hook.  Typical
> vendor response is either "F... You" or "Manana".

   And the response of the Ada community is to turn to companies
   such as The Ada Ace Group, Inc., a technical consulting company
   specializing in the development of Ada interface to software
   products and applications.  They provide customized pure Ada
   interfaces to existing commercial software products, such as
   databases, operating systems, and specific applications such 
   as X-Windows.  (Contact information: 4254 Indigo Drive, 
   San Jose, CA  95136; (408) 267-8296)  Do you really think the
   Ada community, with its emphasis on standardization and vendor  
   independence, is going to be stopped by an intransigent vendor?

> A military project involving Sun machines and Ada was abandoned after
> something like 4 years and $30 million effort because of unacceptable
> performance;  database screens were taking over a minute to come up.  The
> design work had all been done according to your formula, the individual
> modules had been designed, written, and tested, all according to the
> standard military schedules and formulas (2167 etc.).  Everything seemed
> hunky dory, only when they put the fricking thing together, it was too
> damned slow to use.  And, the remarkable thing is, the very system the
> military insists upon for management of software contracts prevented
> anybody from knowing they were in trouble until four years and millions
> had been blown.  The government people involved were essentially reduced
> to the role of actors in a Greek tragedy.
>  
> Asked for a solution, my firm weighed the choice between offering an Ada-
> to-C converter and silence, and opted for silence.

   How about applying a profiler and recoding the "hot spots"?
   If the slowness of Unix process handling is a problem, then
   a more modern version of Unix should be used.  Your company
   should have considered more than two options.

   There are problems in the government management process, but
   this pertains to the government and not to Ada.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada & IBM

[William Thomas Wolfe, 2847]

>> [...] There is the August 21 89 issue of Government Computer News
>> describing the problems which the huge FAA Advanced Automation System is
>> having due to IBM Ada implementations and tools (or lack thereof).  

    Apparently IBM has now changed its tune; its recent brochure
    entitled "Ada and IBM... Capability and Committment" states:

      IBM is committed to Ada.  Ada's support for modern software
      engineering concepts, its breadth of application, and its
      support for reuseable software components place it squarely
      in the forefront as a language of choice for both IBM's
      software engineers and for IBM's customers.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada & IBM

[ryer]

Last I heard, Ada is not on the list of _acceptable_ languages for IBM's
SAA (Systems Application Architecture?) applications.  (SAA is IBM's big
new advance in portability and interoperability and a fundamental part
of their strategy for computing in the 90's).  If a program
is coded in Ada, it can't comply with SAA, regardless of any other
compatibility or interfaces.  Has this changed?  It is easy to write
a brochure, but where's the beef?

Mike Ryer
(personal comment, not endorsed by my employer, Intermetrics)

Re: Ada & IBM

[William Thomas Wolfe, 2847]

From ryer@inmet.inmet.com:
> Last I heard, Ada is not on the list of _acceptable_ languages for IBM's
> SAA (Systems Application Architecture?) applications.  

   According to IBMers at Tri-Ada '89, Ada runs on three of the four
   platforms required for SAA-hood, and they're working on the fourth.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

Re: Ada & IBM

[Jerry Callen]

In article <20600018@inmet> ryer@inmet.inmet.com writes:
>
>Last I heard, Ada is not on the list of _acceptable_ languages for IBM's
>SAA (Systems Application Architecture?) applications.  (SAA is IBM's big
>new advance in portability and interoperability and a fundamental part
>of their strategy for computing in the 90's).  If a program
>is coded in Ada, it can't comply with SAA, regardless of any other
>compatibility or interfaces.  Has this changed?  It is easy to write
>a brochure, but where's the beef?
>

>Mike Ryer
>(personal comment, not endorsed by my employer, Intermetrics)

Hi, Mike! Actually, the "SAA Languages" are just the languages
that IBM is promising to keep _compatible_ on all of the SAA "platforms."
(Geez, I hate that psuedo-word.) Just because a language isn't supported
by IBM as an SAA language doesn't mean you can't _use_ the language on
an SAA system. In particular, I think it behooves IBM to come up with a 
standard set of Ada bindings to the various SAA subsystems (communications
and database, especially) that WOULD be portable across the SAA
platforms. After all, Ada is already totally portable, eh? :-)

-- Jerry Callen
   ...!{uunet, gould, maybe others}!encore!jcallen
   jcallen@encore.encore.com

   Do what you want to with my signature, but leave my employer alone!

Re: Ada & IBM

[Dick Dunn]

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,
2847 ) writes in response to Ted Holden's comments about problems...
> >> ...due to IBM Ada implementations and tools (or lack thereof).  

>     Apparently IBM has now changed its tune; its recent brochure
>     entitled "Ada and IBM... Capability and Committment" states:

>       IBM is committed to Ada...

So what?  First, Ted did not address the question of whether IBM is
committed to Ada; he was talking about a report of real-world problems.

Second, "commitment" is not measured by glowing words in a brochure.  Do
you really think IBM would put out a brochure that said "Well, we're not
really keen on Ada, but it looks like we need it..."?

Wanna buy a bridge?  I'm committed to selling you the finest bridge.  It's
got support for modern engineering...hey, it supports lots of things.  It's
got breadth of application...you can apply it to any need as broad as the
bridge is wide...

Sheesh...it's marketing.  Do you believe every piece of advertising you
read?  Find out what's behind it.

What has IBM got for Ada?  Better yet, if you want to measure commitment,
find out how much new software THEY're writing in Ada (as opposed to
assembly language, or PL/S, or C, or...)

Do you really want a bold commitment from the company that gave us PL/I?
(Save the flames...yes, I know a lot of good software was written in PL/I.
It's still uglier than yesterday's roadkill.)
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...`Just say no' to mindless dogma.

Re: Ada & IBM

[William Thomas Wolfe, 2847]

From rcd@ico.isc.com (Dick Dunn):
> What has IBM got for Ada?  How are they using it?

   Compilers, a comprehensive Ada Programming Support Environment, 
   interfaces to IMS/VS, DB2, SAA, and SQL, an Ada equivalent of 
   CICS (called Ada Interactive Services), and so on.  Further info
   can be obtained from the IBM Ada Help Desk (1-800-387-0262). 

   IBM's Systems Integration Division is doing Ada projects in 
   its Colorado, Maryland, Texas, Virginia, and New York locations,
   ranging from embedded and real-time systems to commercial systems.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada & IBM

[Liam R. E. Quin]

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu wrote:
>    [...] "Ada and IBM... Capability and Committment" states:
>      IBM is committed to Ada.  Ada's support for modern software
>      engineering concepts, its breadth of application, and its
>      support for reuseable software components place it squarely
>      in the forefront as a language of choice for both IBM's
>      software engineers and for IBM's customers.

No doubt the simple elegance of Ada appealed to IBM, depite their well-known
dislike of such small languages.

Lee

:-)
-- 
Liam R. Quin, Unixsys (UK) Ltd [note: not an employee of "sq" - a visitor!]
lee@sq.com (Whilst visiting Canada from England)
lee@anduk.co.uk (Upon my return to England at Christmas)

Re: Ada & IBM

[William Thomas Wolfe, 2847]

From lee@sq.sq.com (Liam R. E. Quin):
>>    [...] "Ada and IBM... Capability and Committment" states:
>>      IBM is committed to Ada.  Ada's support for modern software
>>      engineering concepts, its breadth of application, and its
>>      support for reuseable software components place it squarely
>>      in the forefront as a language of choice for both IBM's
>>      software engineers and for IBM's customers.
> 
> No doubt the simple elegance of Ada appealed to IBM

   Actually, it's rather surprising, since their background has
   largely consisted of primitive languages which offer little
   or no support for the software engineering process.  It's good
   to see IBM finally recognizing this major advance in software 
   engineering technology.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada & IBM

[Liam R. E. Quin]

[I wrote]
>> No doubt the simple elegance of Ada appealed to IBM
[Bill Wolf wrote]
>   Actually, it's rather surprising, since their background has
>   largely consisted of primitive languages which offer little
>   or no support for the software engineering process.  It's good
>   to see IBM finally recognizing this major advance in software 
>   engineering technology.

Uh, did I leave off the :-) signs?  I was not being serious. 

Let's not start religious Ada vs. <whatever> quarrels.
[mail me if you absolutely must, I'll try not to take EXCEPTION :-)].

Lee


-- 
Liam R. Quin, Unixsys (UK) Ltd [note: not an employee of "sq" - a visitor!]
lee@sq.com (Whilst visiting Canada from England, until Christmas)
Software engineering is largely a philosophy, a state of mind.

Re: Ada & IBM

[Ken Ritchie]

Recapping: IBM has elected to pursue Ada, surprising some folks(?) :-)

C'mon folks... doesn't anybody KNOW about IBM?
This had to be a MARKET DRIVEN decision, since
IBM (by their own assertion) IS MARKET DRIVEN!
The attractiveness of the smiling Countess ;-)
(dear Ada) can be only a secondary persuasion.

There's going to be a *BOOM* in Ada-based BUSINESS (i.e. $$) and
IBM's obvious intention is to be right where the action is!! 8-)

DISCLAIMER: I'm opinionated, who isn't?  
_______________________________________________________________________________

Ken Ritchie (d/b/a KCR)			Usenet:	...!uunet!netxcom!netxdev!kcr
c/o NetExpress Communications, Inc.	FAX/office:	USA (703) 749-2375

Ada Promises

[Doug Schmidt]

In article <7053@hubcap.clemson.edu>, billwolf%hazel (William Thomas Wolfe, 2847 ) writes:
>   This has been a property of some early Ada *compilers*, but is
>   not a property of the Ada *language*.  

I basically agree with this in principle, though Ganapathi and
Mendal's IEEE Computer article from February 1989 points out several
areas where the Ada's semantics of reordering operations restricts
code motion and strength reduction.  I'd assume that this penalizes
Ada on certain RISC processors since it limits the degree of
instruction scheduling possible.

>   Fortunately, compiler
>   technology is now capable of delivering tight, efficient Ada
>   object code, better than that being produced by C compilers.

Ironically, Ganapathi and Mendal conclude their article by stating
that:
 
  Use of the following Ada capabilities may hinder optimizations currently
  implemented in most Ada compilers:
  
  * exceptions
  * generic units
  * private and limited private types in package definitions
  * naming and modularity of package definitions, and
  * tasking

In other words, just about every major feature that differentiates Ada
from Modula 2 or Pascal exacts a penalty on optimization.  This is a
realistic and understandable phenomenon (C/C++ certainly contain their
share of features that disrupt optimization), but it also makes me
wonder just exactly what you mean with your claim that Ada compilers
produce better code than C compilers.

To avoid misunderstanding, can you please cite *specific* examples
(especially references to publically available literature) to support
your claim?  For example:

1. Precisely which Ada compilers produce better code than which C compilers?
   Not all compilers are created equal...

2. What are the benchmarks and where can they be obtained?  If, in
   order to generate good code, Ada programmers must limit themselves to
   a `Pascal subset' of the language exactly what advantages have
   accrued?

3. What are the hardware/OS platforms and what are the relative costs
   between the Ada and C compilers/environments?  After all, it is
   unfair to compare a $500,000 Rational Ada environment against
   a $120 copy of Turbo C on MS DOS ;-).

Without independently verifiable, empirical evidence it is difficult
to make an informed choice on this issue.  In the words of R. P.
Feynman:

  The fundamental principle of science, the definition almost, is this:
  the sole test of the validity of any idea is experiment.

Additional proof would greatly increase my confidence that Ada is more than
just another `promising' language (pun intended!).

thanks,

  Doug
--
Master Swordsman speak of humility;             | schmidt@ics.uci.edu (ARPA)
Philosophers speak of truth;                    | office: (714) 856-4034
Saints and wisemen speak of the Tao of no doubt;
The moon, sun, and sea speaks for itself. -- Hiroshi Hamada

Re: Ada compilers

[William Thomas Wolfe, 2847]

From schmidt@zola.ics.uci.edu (Doug Schmidt):
>>   Fortunately, compiler
>>   technology is now capable of delivering tight, efficient Ada
>>   object code, better than that being produced by C compilers.
> 
> 1. Precisely which Ada compilers produce better code than 
>    which C compilers? Not all compilers are created equal...

   The Telesoft TeleGen2 compiler, vs. all available C compilers,
   as of circa October 1988; contact Telesoft for details, since 
   the statement was made at the Telesoft User's Group meeting at
   the Tri-Ada '88 conference.  

> 2. What are the benchmarks and where can they be obtained?  If, in
>    order to generate good code, Ada programmers must limit themselves to
>    a `Pascal subset' of the language exactly what advantages have
>    accrued?

   I seem to recall "Dhrystone", among others, being cited.  There 
   were no limitations on the use of the Ada language.
 
> 3. What are the hardware/OS platforms and what are the relative costs
>    between the Ada and C compilers/environments?  After all, it is
>    unfair to compare a $500,000 Rational Ada environment against
>    a $120 copy of Turbo C on MS DOS ;-).

   I think the comparison might have focused on Sun workstations,
   but I'm by no means positive.  In any event, the point of contact is:

      TeleSoft, 5959 Cornerstone Court West, San Diego, CA, 92121-9891

   There were several articles in the Proceedings of Tri-Ada '88
   which considered at length the sophisticated optimization techniques
   which went into the TeleGen2 compiler; that might also be a good source. 
 
   There has been a new release of the TeleGen2 compiler since October 
   1988, and undoubtedly new releases of C compilers as well, so it 
   would probably be best to contact TeleSoft directly at the above 
   address for the most recent competitive statistics.  
    

   Bill Wolfe, wtwolfe@hubcap.clemson.edu

This has gotten stupid!

[Dick Dunn]

> > 1. Precisely which Ada compilers produce better code than 
> >    which C compilers? Not all compilers are created equal...
>    The Telesoft TeleGen2 compiler, vs. all available C compilers,
>    as of circa October 1988; contact Telesoft for details...

Oh, right, Telesoft is the unbiased judge of the universal superiority of
its own compiler!

>    the statement was made at the Telesoft User's Group meeting at
>    the Tri-Ada '88 conference.  

In other words, they made the statement in what amounts to a mutual ad-
miration society meeting.

> > 2. What are the benchmarks and where can they be obtained?...

>    I seem to recall "Dhrystone", among others, being cited.  There 
>    were no limitations on the use of the Ada language.

You "seem to recall"???  Your grandiose boasting is based on something you
don't quite remember?  Even if the one you think you remember is correct,
it's a tiny synthetic benchmark with well-known problems (acknowledged by
the author) and it is NOT suitable for comparisons of compilers.

> > 3. What are the hardware/OS platforms and...

>    I think the comparison might have focused on Sun workstations,
>    but I'm by no means positive...

But soft! 'Tis fair Amnesia come to stay a while.  Isn't it convenient how
little information there is here?  It's probably a comparison against pcc.

Bill told us that, thanks to sophisticated compiler technology, Ada
compilers can now give us better object code than C compilers.  But the
claim apparently applies only to one Ada compiler; the claim is made by
the vendor of that compiler; the claim is reported at a meeting for users
of the compiler; the benchmarks and hardware platforms used for the com-
parison are conveniently forgotten.

Pure vapor.

Bill, you argue best for Ada when you don't post.

Does anyone have any substance about code-generation quality of Ada
compilers?  I think it's a potentially interesting subject.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...`Just say no' to mindless dogma.

Re: Ada

[Walter Rowe]

Ignore that last one ... got trigger happy ...
----------------------------------------------------------------------
>>>>> On 15 Nov 89 16:06:41 GMT, billwolf@hubcap.clemson.edu (Bill Wolfe) said:

billwolf> This is blatantly false; consider the November 1988
billwolf> article in IEEE Software ("Large Ada projects show
billwolf> productivity gains"):

billwolf> [...irrelevant text deleted...]
billwolf> on the project was counted only once.  Roughly 13 percent of
billwolf> the delivered software was reuseable.

Uhmmm ... correct me if I'm wrong here, but if a project is well
designed (ie. module specs are written to be general), I think there
would be a higher degree of re-usability for those modules, regardless
of the language used.  That's the purpose of writing generalized code.
Any good computer scientist/programmer knows that, right?

Imagine having to write sin(), cos(), etc, for every application you
needed them for.  This would of course be ludicrous, so those in the
know wrote good, generic routines to handle these functions and now
you take them for granted.

What I'm trying to say is that re-usability is not necessarily an
attribute of the programming language being used, but more likely it
is the result of using good system design techniques.  Who cares if
its C++, Ada, C, or Pascal?  If you approach the design correctly,
your solution will be general enough so as to apply to the greatest
number of variations of the same problem.  Thats what re-usability is
all about, isn't it?  Not re-inventing the wheel?

billwolf> Sounds like a continuing *success* to me ...

Sure, but so is Pascal (originally designed as a learning tool), but
its not highly used outside of Academia just like Ada is not highly
used outside of DoD.  Ever wonder why?
   
billwolf> A prime example is Unix; the current POSIX effort aims to
billwolf> standardize 1960's technology, thus resulting in a "lowest
billwolf> common denominator" which locks users into obsolescence.

I disagree.  Its not locking into obsolescence.  Its forcing one to
meet only a minimum set of requirements, which allows a maximum amount
of flexibility above and beyond those requirements.  As long as you
meet these minimum requirements, you still have the freedom to enhance
UNIX any way you see fit.  They aren't restricting you to these, but
saying that you must provide at least these things.

billwolf> Modern programming languages provide a variety of features
billwolf> to support development and maintenance of software products.
billwolf> These features include strong type checking, separate
billwolf> compilation, user-defined data types, data encapsulation,
billwolf> data abstraction, generics, flexible scope rules,
billwolf> user-defined exception handling, and concurrency mechanisms.

I have to agree with Bill on this point: more languages ARE beginning
to evolve into useful tools for productivity, rather than learning
tools, or tools intended for specific applications.  However, I think
in order to be most productive and efficient for a given application,
a language still must cater to that application to some extent (ie.
COBOL for record transaction processing, C for systems programming,
etc).

> [...] There is the August 21 89 issue of Government Computer News
> describing the problems which the huge FAA Advanced Automation
> System is having due to IBM Ada implementations and tools (or lack
> thereof).

billwolf> Are you saying that this is the fault of the *language*, or
billwolf> of IBM?

More than likely its IBM, although most of their projects seem to come
out of a committee, and in that respect, draw a striking resemblance
to Ada.  So, possibly both are at fault since Ada was designed by a
committee, too.  I think the basic point being made is that too many
hands in the pot spoil the soup, and I tend to agree with this.  Its
good to get outside opinions so that one can be as objective as
possible, but I still think that fewer people can supply a much more
rational decision.

> the programming style being promulgated by DOD for Ada [descriptive
> variable names] is anti-conducive to the stated goal of readability;  

billwolf> To C hackers, who are accustomed to single-letter variables,
billwolf> yes.  Software engineering specialists tend to have the
billwolf> opposite perspective.

Admittedly, I fall into the C hacker category, but I think Ted makes a
valid point here.  I'd much prefer to shuffle through a few pages of
documentation at the top of a print-out than have to look at unsightly
long variable/procedure/function names.  I support giving variables
meaningful names, just not unsightly long ones.

If the docs are good at the top of a file are good (ie. they clearly
and concisely convey the concept of what this code is suppposed to
do), then you shouldn't have to clutter the code with paragraph long
names.  You're trying to infer the logic being applied, not the
details of the individual statements (for alone they mean nothing
anyway).

billwolf> Bill Wolfe, wtwolfe@hubcap.clemson.edu

Walter Rowe, rowe@cme.nist.gov
---
My opinions are my own, and bare no reflection of the opinions
of the United States Government.

Re: Ada

[William Thomas Wolfe, 2847]

From rowe@cme.nist.gov (Walter Rowe):
> Sure, but so is Pascal (originally designed as a learning tool), but
> its not highly used outside of Academia just like Ada is not highly
> used outside of DoD.  Ever wonder why?

   The fact that good production-quality compilers have only been
   avaliable for the last year or two probably has a lot to do with it...

   Fortunately, as the IEEE Software article I cited demonstrates, 
   commercial use and acceptance of Ada is growing rapidly, both in 
   the US and overseas.  Non-DoD US users include General Electric, 
   Boeing Commercial Airplane, etc.; other companies, such as Arthur 
   Anderson, are considering converting to Ada now that the appropriate 
   compilers and tools are available.  Not because the DoD is using it,
   but as a simple result of business and engineering considerations. 

   Considering that the largest corporation in the WORLD, Nippon 
   Telegraph and Telephone, has maintained a committment to Ada 
   since 1982 (!!!), I'd say that Ada is certainly making excellent 
   progress in the commercial environment.  The fact that the
   DoD is requiring all its information systems work to be done
   in Ada is creating a great deal of infrastructure (e.g., the
   RAPID library of reuseable Ada information systems software
   components), which will further stimulate commercial use.  

   The experience so far has been that "once a team moved to Ada,
   they stayed with Ada.  Once Ada had been successfully used within
   a company, its use proliferated to other projects within the 
   company and to subcontractors and suppliers of that company within
   the industry."  (Ada Letters, Vol. VIII, No. 5, page 15).  Given
   that high-quality compilers have only been available for a relatively
   short period of time, and that the US Ada market was already US $1.25 
   billion as of September 1987, I think the progress so far has been 
   quite substantial.  Watch comp.lang.ada for continued updates.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada

[Pablo Fernicola]

In article <7088@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>
>   Fortunately, as the IEEE Software article I cited demonstrates, 
>   commercial use and acceptance of Ada is growing rapidly, both in 

In IEEE Software, Vol.5 Num. 3 page 26, we read

	"C++ has several advantages over Ada: ..."

>
>   The experience so far has been that "once a team moved to Ada,
>   they stayed with Ada.  Once Ada had been successfully used within
>   a company, its use proliferated to other projects within the 
>   company and to subcontractors and suppliers of that company within
>   the industry."  (Ada Letters, Vol. VIII, No. 5, page 15).  Given
		     ^^^^^^^^^^^^
		     Not a biased opinion, I hope :-)

A common syllogism nowadays is (from the same IEEE Software issue)

	Ada is good; object-oriented is good;
	therefore, Ada is object oriented.


>   Bill Wolfe, wtwolfe@hubcap.clemson.edu

BTW, it is good to hear from Bill again after the misc.jobs.misc debacle ...
--
pff@beach.cis.ufl.edu - Pablo Fernicola - Machine Intelligence Laboratory - UF
		IF YOU CARE ENOUGH TO READ SIGNATURES ...
	I am graduating next year and I am looking for a job.  
MS/BS EE, my graduate work incorporates OO-DBMS/Graphics/Robotics/AI

Re: Ada

[William Thomas Wolfe, 2847]

From pff@beach.cis.ufl.edu (Pablo Fernicola):
> In IEEE Software, Vol.5 Num. 3 page 26, we read
> 
> 	"C++ has several advantages over Ada: ..."

   But unfortunately seems to be missing fundamental features
   such as exceptions, generics, and concurrency...

> A common syllogism nowadays is (from the same IEEE Software issue)
> 
> 	Ada is good; object-oriented is good;
> 	therefore, Ada is object oriented.

   Written by the designer of C++, whose definition of object-oriented
   is "Object-oriented programming is programming using inheritance".

   The definition of "object-oriented" varies widely, but even if we
   accept this definition, we need only obtain Classic Ada (or some 
   equivalent preprocessing product) in order to use inheritance in
   an Ada environment, pending more direct support in Ada 9X.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 
   

Re: Ada

[Andrew Koenig]

In article <7115@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:

>    Written by the designer of C++, whose definition of object-oriented
>    is "Object-oriented programming is programming using inheritance".

Where on earth did you pick up that notion?
-- 
				--Andrew Koenig
				  ark@europa.att.com

Re: Ada

[Mats Luthman]

In article <7115@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:

>    Written by the designer of C++, whose definition of object-oriented
>    is "Object-oriented programming is programming using inheritance".

As far as I recall Bjarne Stroustrup supports the widely accepted definition
of "Object oriented language":

  A language that supports:

*  Data abstraction (encapsulation)
*  Inheritance
*  Dynamic binding

I guess that people who claim that Ada is object oriented don't agree with
this definition, at least not with the third requirement, but saying what
I cited above is (and was probably meant to be) an insult to B.S. and his
intellectual capability.

Mats Luthman

Re: Ada

[William Thomas Wolfe, 2847]

From ark@alice.UUCP (Andrew Koenig):
> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>>    Written by the designer of C++, whose definition of object-oriented
>>    is "Object-oriented programming is programming using inheritance".
> 
> Where on earth did you pick up that notion?

    From his article "What is Object-Oriented Programming", IEEE
    Software, May 1988... it's a direct quote.


    Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada

[Mats Luthman]

In article <7171@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From ark@alice.UUCP (Andrew Koenig):
>> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>>>    Written by the designer of C++, whose definition of object-oriented
>>>    is "Object-oriented programming is programming using inheritance".
>> 
>> Where on earth did you pick up that notion?
>
>    From his article "What is Object-Oriented Programming", IEEE
>    Software, May 1988... it's a direct quote.
>
>
>    Bill Wolfe, wtwolfe@hubcap.clemson.edu


The article is 21 pages long, and is a thorough explanation of what
the author means by 'object oriented programming'. The trick of chosing
one sentence, ripped out of its context, is used again.

Mats Luthman











***

Re: Ada

[Markku Sakkinen]

In article <10171@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes:
-In article <7115@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:
-
->    Written by the designer of C++, whose definition of object-oriented
->    is "Object-oriented programming is programming using inheritance".
-
-Where on earth did you pick up that notion?

I would say that is the main theme of Stroustrup's paper from ECOOP'87
(What is "Object-Oriented Programming), a little simplified.
So, where on earth = in Paris (site of ECOOP'87) :-)
Obviously, it is hard to maintain that languages such as Ada and CLU
are not "object-oriented" in the least, unless one takes inheritance
as the single most important concept of OO.

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland

Re: Ada [and the object oriented metaphor]

[mjl]

In article <7115@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>   The definition of "object-oriented" varies widely, but even if we
>   accept this definition, we need only obtain Classic Ada (or some 
>   equivalent preprocessing product) in order to use inheritance in
>   an Ada environment, pending more direct support in Ada 9X.

The mind boggles: Hoare's Turing Lecture concerns about the safety of
the world have now been compounded by an order of magnitude!  I'm a
proponent of the OO approach, but this instance is all too reminiscent
of the "bag on the side of a bag" system of design so eloquently
described in Kidder's "The Soul of a New Machine." Ada is already a
tarpit of complexity.  While the natural world evolves by selection,
Ada seems destined to "evolve" by accretion.

Mike Lutz

P.S.  I'm can hardly wait for AdaLog and CommonAda, preprocessors
providing all the "benefits" of Ada as well as the logic programming
model of PROLOG and the list processing capabilities of CommonLisp.
[1/2 :-)]
Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{rutgers,cornell}!rochester!rit!mjl
INTERNET:	mjlics@ultb.isc.rit.edu

Hoare, Ada, and safety/complexity

[John Goodenough]

There is a fairly widespread perception that Hoare's Turing Lecture represents
his complete opinion on Ada, as noted in a recent in article, Re: Ada [and the
object oriented metaphor] of 21 Nov 89 14:35:58 GMT mjl@prague.UUCP (Michael
Lutz):

>The mind boggles: Hoare's Turing Lecture concerns about the safety of
>the world have now been compounded by an order of magnitude!  ...

In 1987, Hoare wrote:

    ...an important goal in the design of a new programming language [is] that
    it should be an aid in specification, description, and design of programs
    as well as in the construction of reliable code.

    This was one of the main aims in the design of the language which was
    later given the name Ada.  As a result, the language incorporates many
    excellent structural features which have proved their value in many
    precursor languages such as Pascal and Pascal Plus.

    The combination of many complex features into a single language has led to
    an unfortunate delay in availability of production-quality
    implementations.  But the long wait is coming to an end, and one can now
    look forward to a rapid and widespread improvement in programming
    practice, both from those who use the language and from those who study
    its concepts and structures.

							     C. A. R. Hoare

    [in the Foreword to "Ada, Language and Methodology" by David A Watt, Brian
    A.  Wichmann, and William Findlay, Prentice-Hall, 1987.]

(Of course, the game of "proof by authority" is not all that interesting, but
if you're going to play it, ...)

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391
-- 
John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391

Re: Hoare, Ada, and safety/complexity

[Richard Pattis]

Indeed, Tony Hoare wrote the foreword quoted (the complete foreword is about
twice as long).  Here is the context:  Hoare is a series editor for Prentice-
Hall International, and he writes a foreword for most books in the series,
including the one written by Watt, Wichmann, and Findlay.

In my reading of the foreword, it shows a masterful double meaning in every
sentence.  It looks as if Hoare is praising Ada, but he is really praising
(1) the ideas behind Ada and (2) learning about Ada (without praising using
Ada). Every sentence has a wonderful spin on it.  I advise everyone to read
this foreword skeptically; you'll surely smile a bit.

The authors are much more positive in their praise of language (I vastly
prefer teaching it, compared to Pacsal or Modula-2 in my CS-1/CS-2 classes).
But I don't think Hoare's preface can in any way be construed as being
positive towards Ada, nor as anything contrary to his Turing lecture.

Rich Pattis

Re: Ada vs. C++

[Paul S. R. Chisholm]

From pff@beach.cis.ufl.edu (Pablo Fernicola):
> In IEEE Software, Vol.5 Num. 3 page 26, we read
> 	"C++ has several advantages over Ada: ..."

In article <7115@hubcap.clemson.edu>,
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
(William Thomas Wolfe, 2847) writes:
>    But unfortunately seems to be missing fundamental features
>    such as exceptions, generics, and concurrency...

Exceptions:  Dr. Stroustrup just made a proposal for doing exceptions
in C++.  It looks pretty good.

Generics:  Dr. Stroustrup made a proposal sometime last year on
parametarized types.  His exception handling paper uses the same
syntax, so presumably he's reasonably comfortable with it.

Concurrency:  Most of the time, C++ programs (and programmers) should
use the facilities of the target platform.  Dr. Stroustrup has provided
support for "tasks" in both "C with classes" and C++; the AT&T C++
Language System comes with a Task class.  That's as close to standard
as C++ comes these days.  No, there's no direct support in the language
(special syntax, etc.) for supporting concurrency, for the same reason
there's no direct support for I/O:  it's better done in a library.

To summarize, C++ has the same support for exceptions and generics that
Ada has for inheritance.  (The Ada preprocessor you mention is a red
herring for DOD contractors, unless you propose they submit the
*output* of the preprocessor.)

>    Bill Wolfe, wtwolfe@hubcap.clemson.edu

Paul S. R. Chisholm, AT&T Bell Laboratories
att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.

Re: Ada

[Marco S Hyman]

In article <7088@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
       Non-DoD US users include General Electric, 
       Boeing Commercial Airplane, etc.; other companies, such as Arthur 
       Anderson, are considering converting to Ada now that the appropriate 
       compilers and tools are available.  Not because the DoD is using it,
       but as a simple result of business and engineering considerations. 

Large corporations such ad GE, Boeing, Arthur Anderson, etc., are not known
for state-of-the-art, pushing-the-envelope solutions to their problems.
These are the companies that buy IBM.  Ada is safe, approved by the
government, and, as I once heard Larry Rossler of the HP Language Labs
describe it, doomed to success.  Too many companies are throwing money at it
to fail.

       The experience so far has been that "once a team moved to Ada,
       they stayed with Ada.  Once Ada had been successfully used within
       a company, its use proliferated to other projects within the 
       company and to subcontractors and suppliers of that company within
       the industry."  (Ada Letters, Vol. VIII, No. 5, page 15).

I don't have any facts or figures but I suspect from my own past experience
that this is true of every successful tool/method introduced to a large
corporation.  A manager that tries something new usually goes out on a limb
and therefore works twice as hard to make it succeed.  When it does succeed
that manager makes sure all of his bosses know that he was the hero that
finally brought a software project in on time and within budget.  Since
software projects are not usually on time or within budget the new
tool/method is seen as the solution to all software woes.  Alas, it's
usually just better management plus the productivity increase that comes
with doing something new that really saved the day.

I'm not saying the new tool/method, be it Ada, C++, OOP, or whatever, does
not help.  I just wish that it wasn't seen as a panacea for all that ails
the current problems in software.  (BTW:  the current problems in software
haven't changed, IMHO, in the last 20 years -- there's just a lot more
software.) But I've changed the subject.  Sorry.

C++ and Ada are just tools, folks.  Sometimes they are the correct
tool for the job.  Sometimes they are not.

// marc
-- 
// Marco S. Hyman		{ames,pyramid,sun}!pacbell!dumbcat!marc

interesting statistic

[Dick Dunn]

Wolfe wrote:
[about Ada]
|    The fact that good production-quality compilers have only been
|    avaliable for the last year or two probably has a lot to do with it...
...and later in the same article...
|    Considering that the largest corporation in the WORLD, Nippon 
|    Telegraph and Telephone, has maintained a committment to Ada 
|    since 1982 (!!!), I'd say that Ada is certainly making excellent 
|    progress in the commercial environment...

Considering those two together, I'd say Ada's appeal must be nothing short
of amazing!  Call it two years that production-quality compilers have been
available, i.e., 1987...

I guess we can conclude that NTT maintained a commitment to Ada in spite of
a five-year lack of production-quality compilers???
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...`Just say no' to mindless dogma.

Re: interesting statistic

[William Thomas Wolfe, 2847]

From rcd@ico.isc.com (Dick Dunn):
> I guess we can conclude that NTT maintained a commitment to Ada in spite of
> a five-year lack of production-quality compilers???

    Conclusion correct... they were apparently doing MIS applications 
    in which the quality of the object code was not very important.


    Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

Re: interesting statistic

[Cay Horstmann]

In article <7172@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From rcd@ico.isc.com (Dick Dunn):
>> I guess we can conclude that NTT maintained a commitment to Ada in spite of
>> a five-year lack of production-quality compilers???
>
>    Conclusion correct... they were apparently doing MIS applications 
>    in which the quality of the object code was not very important.
>
>
>    Bill Wolfe, wtwolfe@hubcap.clemson.edu

I guess we therefore can conclude that Ada is perfectly suited for doing
MIS applications in which the quality of the object code is not very important.

If Ada has friends like Bill, does it need enemies?  :-)

Cay
> 

Re: interesting statistic

[William Thomas Wolfe, 2847]

From horstman@sjsumcs.sjsu.edu (Cay Horstmann):
>>> I guess we can conclude that NTT maintained a commitment to Ada in spite of
>>> a five-year lack of production-quality compilers???
>>
>>    Conclusion correct... they were apparently doing MIS applications 
>>    in which the quality of the object code was not very important.
% 
% I guess we therefore can conclude that Ada is perfectly suited for doing
% MIS applications in which the quality of the object code is not very 
% important.

    Quite correct.  Now that production-quality compilers are widely
    available, it is also perfectly suited for an extremely wide range
    of applications, and is being used accordingly.


    Bill Wolfe, wtwolfe@hubcap.clemson.edu

Ada allows one-char names (was Re: Ada)

[Steve Frysinger of Blue Feather Farm]

From article <ROWE.89Nov16140835@stella.cme.nist.gov>, by rowe@cme.nist.gov (Walter Rowe):
> billwolf> To C hackers, who are accustomed to single-letter variables,
 
> long variable/procedure/function names.  I support giving variables
> meaningful names, just not unsightly long ones.

I've been enjoying this debate, but for the sake of clarification I must
point out that Ada permits one-character variable names, and that most
C compilers I know allow variable names as long as Ada allows.  So I
submit that variable name length is irrelevant to this discussion.

Just wanted to keep folks who don't know Ada (or C) from misunderstanding!

Steve Frysinger

Forward into the past

[Dick Dunn]

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,
2847 ) writes about UNIX and the Ada<->UNIX conflict that Ted Holden had
commented on:

>    A prime example is Unix; the current POSIX effort aims to 
>    standardize 1960's technology, thus resulting in a "lowest
>    common denominator" which locks users into obsolescence.

I picked this out of the latter half of an article where Bill was objec-
ting to Ted saying things that were "blatantly false" (Bill's words).  Bill
ought to be a little more careful about his own blatant falsehoods.

The POSIX work does, in fact, standardize some things which existed in the
'60's.  But it also covers mechanisms introduced in the '70's (e.g., job
control) and even into the latter part of the '80's (such as the "session"
mechanism).  Wouldn't it be rather disturbing to have a standard which
*excluded* technology older than 1970?!?

Standards are developed in two ways--either they codify existing practice,
or they attempt to constrain future practice.  Most standards in computing
are of the former sort.  The danger of a "codification" standard is, as
Bill obliquely points out, that it doesn't provide any guidance for the
future.  However, it does NOT lock people in; they are free to experiment
with extensions to this type of standard.  As new practice emerges beyond
the old standard, a basis for a successor standard is built.  Defining a
standard _a_priori_ without the benefit of existing practice is much harder
to get right.  You have to use the best research available to you, and hope
it's right.  It's sometimes necessary; sometimes an industry can't hope to
move forward without a standard.  (Consider TV, CDs, etc.)  Ada is in this
second class of standardization (unlike almost all other programming
languages).  It would help a lot if people who advocate either approach to
standardization would be less parochial and realize the tradeoffs.

>    Ada's problem with Unix is that Unix, being 1960's technology,...

Careful there!  People who live in glass houses...

To the extent that UNIX is 1960's technology, Ada is 1950's technology
and UNIX is the more modern of the two by a decade!  I'm serious...the
basic control structures, not to mention the "look and feel" of algorithmic
languages, was pinned down by the end of the 50's; it took another two years
to get it canonized in Algol 60 (with the "real" report out in '62).  Sure,
if I'm going to characterize Ada as a "'50's language" I have to ignore a
lot of important characteristics--but no more than are ignored by charac-
terizing UNIX as "1960's technology".

>    [UNIX] does not properly support lightweight processes...Modernized 
>    versions of Unix (e.g., MACH) which are designed to provide
>    such support remove the difficulty...

Bill is one of the people who has been arguing (over in comp.software-eng)
against the value of having a heavy operating systems course in a CS
curriculum...yet here we find that he thinks Mach is a "modernized version
of UNIX"???  I've seen trade rags muddle it that way, but it's wrong...
UNIX and Mach are not even the same type of animal.  But the more signifi-
cant misunderstanding is the idea that somehow lightweight processes should
have been in UNIX long ago.

The reason we have only recently seen a more widespread implementation of
lightweight processes is that it's only recently (meaning within the last
few years) become reasonably well understood just what the abstraction of a
"lightweight process" should be.  The understanding has been evolving along
with various experiments in hardware parallelism of various granularity.
The problem was not a matter of finding a workable abstraction, but of
choosing the right one(s).  The approach, in the UNIX community in
particular, is to try things first in research work, then let them gain
some wider experience in the more avant-garde places in industry, bring
them into the mainstream, and finally standardize them.  This cannot help
but look strange in the Ada world where standardization comes first and is
followed by trial.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...`Just say no' to mindless dogma.

Re: Ada vs. Posix -- the battle continues

[mjl]

In article <7053@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>> In particular, the
>> ordinary systems which most people will be seeing in front of them for the
>> next 5 - 15 years, UNIX systems and PCs, will not run Ada accepteably.
>
>
>   A prime example is Unix; the current POSIX effort aims to 
>   standardize 1960's technology, thus resulting in a "lowest
>   common denominator" which locks users into obsolescence.

Actually, both Unix and Ada are products of the 1970's.  The difference
is that Unix, being primarily of commercial interest, has been able to
evolve, whereas Ada, a government sponsored thing-a-ma-bob, has
stagnated.  It's a shrine to the ideas of 1975, both good and bad.  The
fact that Unix has evolved in ways incompatible with Ada says as at
least as much about Ada as it does about Unix.

I followed the development of Ada from its inception as Strawman, and
became increasingly more depressed as the work proceeded.  The good
concepts Ada embodies are overwhelmed by its complexity (see Hoare's
excellent discussion of this in his Turing Lecture -- all of his
comments still apply).

Ada is the PL/I of the 70's, unusable until the mid-80's; is it destined
to be the choke-collar of DoD software development in the 90's?

Mike Lutz
Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{rutgers,cornell}!rochester!rit!mjl
INTERNET:	mjlics@ultb.isc.rit.edu

Re: Ada & Posix

[William Thomas Wolfe, 2847]

From mjl@cs.rit.edu:
> Actually, both Unix and Ada are products of the 1970's.  The difference
> is that Unix, being primarily of commercial interest, has been able to
> evolve, 

   Thus generating the need for the POSIX effort.  Ada, on the 
   other hand, standardized itself to start with.  Furthermore, 
   its definition was frozen for ten years precisely in order to
   provide vendors with the ability to amortize their investments
   over that period of time.  Ada has always had its portability,
   whereas Unix is just now struggling to achieve it.

   Now that Unix is finally standardizing, work is also in progress
   (in the IEEE 1003.5 committee) to develop a standardized Ada binding
   to the IEEE 1003.1 POSIX standard.  From AlsyNews, September 1989:

      Ada applications will have a major portability advantage
      over C applications because Ada's strong typing will assure
      that an application accesses only the services that are in
      the POSIX packages.  A C application might inadvertently mix
      portable POSIX services with non-portable services provided
      by the local operating system.

   A full IEEE ballot on the Ada binding to POSIX is expected by year-end.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada & Posix

[William Thomas Wolfe, 2847]

From billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu:
>    Ada has always had its portability,
>    whereas Unix is just now struggling to achieve it.

   Consider also this quote from last Wednesday's Wall Street Journal:

      Currently, about 9% of the world's computers run Unix.
      It was feared that the computer industry's inability to
      agree on a single version of Unix would slow its spread.
      But because there is now a potential standard version of
      Unix, the operating system's popularity is expected to
      surge.  Analysts estimate that more than a quarter of the
      computer systems will run Unix by 1993.  "Having a clear
      common [standard] will encourage the perception that Unix
      is a mainstream product," said Eric Schmidt, vice president 
      of Sun Microsystems Inc.'s general systems group.

   Contrary to what some Usenetters seem to think, Unix is by no
   means universal; it is only recently discovering the need to
   impose the discipline of standardization, so that it might seek 
   more than its present single-digit level of market share.
 

   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: A farewell to Ada

[Richard S D'Ippolito]

Painful as it was, I read your whole article, Ted.


When you say (in article <14033@grebyn.com>, Ted Holden):

>     Does Ada work any better for large scale systems?  Another article
>in the same Journal of Electronics Defense issue describing use of Ada on
>the 1,246,000 line Army AFATDS system claims that:
> 
>      "Ninety percent of the software requirements were met with no major
>      software problems."
> 
>as if this were good.  The man is claiming that he had major language-
>related problems with 124,600 lines of code out of 1,246,000.

how can you expect to be taken seriously?  Do you really believe the math
and premises behind your statement?  Wow!


Rich
-- 
We use kill ratios to measure how the war is going.
We use SLOC ratios to measure how our software is coming.
(Idea from Gary Seath)                                        rsd@sei.cmu.edu
-----------------------------------------------------------------------------

Re: A farewell to Ada

[Michael Schwartz]

OK.  You win. I have to put in my 2 cents' worth.  It's hard, because I
agree with many things that everybody has said.

Ada has been getting a bum rap.  Ada was not designed by committee, it
was designed by competition.  C, on the other hand, has been judged by
its applications.

Ada had no substantial applications to benchmark its design against.
The software engineering requirements imposed on Ada were for
programming in the large.  Precisely what Ada has been shown to be good
at.  Not surprisingly, Ada has not been found perfect for every
application area.  Where it has failed, Ada-9X proposals have been
submitted to change it.

C was developed for systems programming.  The worth of a compiler was
judged by the ability to build a good, modular, maintainable operating
system.  Where C failed, the language was changed.  And changed.  And
changed.

It has surprised no one that C is more responsive to change requests
than Ada.  Nor is it surprising that inexperienced software engineers
write better code in Ada than in C.  It has not escaped anyone's
attention that there are more inexperienced software engineers than
experienced software engineers.

Sorry for belaboring the obvious, but let's start somewhere.  Now let's
talk about Ada and Unix.  

Areas where Ada and Unix have problems:  a) System-dependent features
accessed from Ada b) Scheduler conflicts--Ada tasks vs Unix tasks c)
Ada image sizes and startup times

Of these areas, (c) is the most readily addressed.  I have heard a
number of Ada 9X proposals amounting to a mechanism to freeze the Ada
image after elaboration, but before execution.  So much for startup
times.  I have also heard several vendors tout smarter link-editors
which will help resolve image size problems.  I also hold hope for
shared library implementations; the Ada runtime can be shared among all
processes needing it.

Area (a) is one that requires Ada vendor support.  It is difficult to
think of a non-trivial software system without some system-dependent
feature.  After all, we buy different hardware precisely because of
these features.  In my mind, a major difference between a good Ada
compiler and a marginal one can be found in the support for operating
system signals, pragma interfaces, and representation specifications.
It is no anathema to me to have an Ada system contain bodies which are
Pragma Interface (C,...) EVEN IF I DON'T HAVE TO.  Maintenance costs
must be kept foremost.  Reducing maintenance costs is, after all, one
of the major considerations in developing Ada.  Let's not spoil this by
insisting that every Unix guru learn Ada.

Scheduler conflicts (b) remain a problem because Unix processes are not
the same as Ada tasks.  Several have pointed out that Ada tasks are
'lightweight'; they mean that Ada tasks are represented by different
execution threads (instruction pointers and stack frames) but the same
data space.  At least one Unix vendor has implemented a lightweight
process type in the Unix kernel.  It is possible that a good solution
will be to build an Ada compiler which maps its tasks to lightweight
Unix processes, letting the Ada scheduler be either eliminated or
vastly reduced.

In the absence of this solution, a multi-tasking Ada program must build
a monitor to mediate all operating system calls which may 'use up' its
most vital resource -- the Unix operating system process.  The
efficiency with which this may be done is directly related to both the
Ada compilation system's (ACS) ability to interface with Unix (see
(a)), and the 'goodness' of the Unix in question.

Since 'signals' are to Unix more or less what 'rendezvous' are to Ada,
the more events which can be propogated to the Ada monitor from Unix
via signals, the more efficient the implementation.  Broad support for
SIGIO seems to particularly help.

With current compiler technology, one published result we have obtained
is multi-tasking access through sockets within 20% of the performance
of a C program using standard fork() and exec() calls.  Both
applications were able to exchange over 5000 tcp/ip messages per
second with a cheap 68020 box.  Turning off the time-sliced tasking in
the Ada program helped significantly.

One other result is that using our Ada abstraction, new employees were
able to contribute to our project within one to two days, even with no
prior Unix experience.  Of course, a C abstraction is possible--but why
doesn't anyone use one?

A 'today' note: Dennis Ritchie spoke to the FRUUG (Front Range Unix
Users Group) last night about 9th Edition IPC.  He has developed a
different IPC abstraction for his research.  In syntax, it is similar
to our Ada (and C) abstractions.  Of course, it has kernel support :-).

There.  I feel better now ('thar she blows!)

Michael
-----------------------
schwartz@pogo.den.mmc.com  "Expect everything ... 
mschwartz@mmc.com                   and the unexpected never happens." 
ncar!dinl!schwartz                               --the phantom tollbooth

DISCLAIMER:  The opinions expressesed are not necessarily those of my 
	     employer or myself.

-- 
-----------------------
schwartz@pogo.den.mmc.com "Expect everything ... 
mschwartz@mmc.com                   and the unexpected never happens." 
ncar!dinl!schwartz                               --the phantom tollbooth

DISCLAIMER:  The opinions expressesed are not necessarily those of my 
	     employer or myself.

Re: A farewell to Ada

[Ted Holden]

Lots of good replies....
 
 
From: Richard S D'Ippolito, Software Engineering Institute, Pittsburgh, PA
 
>>     Does Ada work any better for large scale systems?  Another article
>>in the same Journal of Electronics Defense issue describing use of Ada on
>>the 1,246,000 line Army AFATDS system claims that:
>>
>>      "Ninety percent of the software requirements were met with no major
>>      software problems."
>>
>>as if this were good.  The man is claiming that he had major language-
>>related problems with 124,600 lines of code out of 1,246,000.
 
>how can you expect to be taken seriously?  Do you really believe the math
>and premises behind your statement?  Wow!
 
The journal should be in your library or in that of Carnegie Mellon.  I'm
sure as hell not making any of this stuff up.  Get serious.  I'm quoting
one of your own journals which was necessarily written in such a way as
to paint Ada in as FAVORABLE a light as possible, and the most favorable
thing the one gentleman could say was that he ONLY had major problems
with 10% of his code.  Pretty sad.
 
 
From: Bill Wolf, Clemson
 
>>From article <14033@grebyn.com>, by ted@grebyn.com (Ted Holden):
>> Journal articles indicate a continuing failure of Ada to work for embedded
>> systems as well as for large scale projects, a continuing failure to run
>> with acceptable performance on anything other than parallel or special-
>> purpose, expensive systems, and an actual gain in cross-system complexity
>> and decrease in the stated goal of reuseability.
 
>   This is blatantly false; consider the November 1988 article
>   in IEEE Software ("Large Ada projects show productivity gains"):
 
>      After years of development and an initial skeptical reception,
>      many people are now using Ada and saying that they like it...
>      The growth in Ada's use has been helped by favorable reports
>      from early adopters ("Ada Catches on in the Commercial Market,
>      Soft News, IEEE Software, November 1986, p. 81) and by the
>      growing number of validated compilers... project results show
>      that Ada can greatly increase productivity for large systems...
>      [in a 1.2-million-line Ada project] reuseable software developed
>      on the project was counted only once.  Roughly 13 percent of the
>      delivered software was reuseable.  This reuse saved 190 man-months
>      of effort (a 9-percent savings) and reduced the schedule by two
>      calender months (a 4-percent savings)... Productivity for the
>      execution environment -- including the operating system, data
>      management, information management, communications support, and
>      communications interface -- was 550 lines per man-month...
>      Productivity for the applications software... was 704 lines per
>      man-month... the average productivity of the 1,500 systems in
>      productivity consultant Lawrence Putnam's database: 77 lines
>      per man-month (at the 1.2-million-line level)...
 
>   Sounds like a continuing *success* to me...
   
 
Sounds very subjective to me and it sounds like a lot of factors are
being left out.  The funny thing is, that this subjective argument
concerning productivity is the only technical or quasi-technical
argument I have ever heard in favor of Ada.  Every other argument in
favor of Ada which I have ever heard was a variant of:
                          
        "We will cut your ____ie off if you do not use Ada on your
        project..."
 
That's not much to have to say to the world.
 
>> In particular, the
>> ordinary systems which most people will be seeing in front of them for the
>> next 5 - 15 years, UNIX systems and PCs, will not run Ada accepteably.
 
>   Precisely the point of Dr. Charles McKay, head of the Software
>   Engineering Research Consortium, in his Tri-Ada '88 presentation,
>   "Standards for the Sake of Standards -- A Recipe for Failure".
 
>   A prime example is Unix; the current POSIX effort aims to
>   standardize 1960's technology, thus resulting in a "lowest
>   common denominator" which locks users into obsolescence.
 
Proprietary OSs lock users into obsolescence;  UNIX frees them.
Until Dr. McKay publishes HIS portable OS and large numbers of people
begin using it, UNIX will remain the only answer.
 
>   Ada's problem with Unix is that Unix, being 1960's technology,
>   does not properly support lightweight processes.  Modernized
>   versions of Unix (e.g., MACH) which are designed to provide
>   such support remove the difficulty.  Note that C or C++ programs
>   making use of the same "heavyweight" tasking facility will be
>   equally slow, since they rely on precisely the same system.
 
>   If one does not have to struggle with the limitations of *Unix*,
>   then there is a wide selection of Ada compilers which run Ada
>   within that environment quite nicely.  Some, like the Telesoft
>   TeleGen2 compiler, have global optimization facilities which
>   result in better code than that which can be produced by current
>   C compilers (as of Tri-Ada '88).
 
I have personally watched the Telesoft Telegen Ada compiler take over 20
minutes to compile a 35 line program into a 300 KB executable on a 68020
based machine with almost nothing else happening on it.  Knowing the Ada
community's idea of progress, I'd expect the Telegen2 to take about 15
minutes to do the same job.
 
Mach is five years away from anything approaching large scale use in
America;  right now, it is a student's hobbyshop project, albeit a hell
of an interesting one.  Mach-like or Mach-derived products such as the
Sequent OS are beginning to be seen and, if your name is John
Rockafeller, you should have no difficulty coming up with such a system
to run Ada on.  Ada does, in fact, run accepteably on a Sequent.
Remember, however, the difficulties of building semetric parallellism
into an imbedded system;  that aileron controller won't be a Sequent.
Remember also that the primary customer for Ada is supposed to be
the U.S. military.  Do you have any idea what the state of the art for
computer hardware is in the U.S. military?  We're talking about
Unisys/Arrete 5000/80's, 5000/90's, 8186-based devices running Zenix on
top of BTOS.....  The 5000/95's are just now being installed.  Get
the idea?
 
As for struggling with the "limitations" of UNIX, you'd better either
get used to it or move to Mars.  There is no other easily portable,
mature operating system.  Without it, you'll always be using
ten-year-old hardware, because developing an OS the old way (like IBM
and Microsoft seem intent on doing with BS/2) takes ten years.  They
paint themselves into some funny corners with it, like trying to tell
the world that the N-10 chip is actually a graphics coprocessor for the
486.  That's like having Theodore Roosavelt serve as Jimmy Carter's
secretary of agriculture;  it's driven by the obvious accessment of the
chances of running BS/2 on an N-10, which is about like the chance of
hell freezing over tommorrow morning.
 
 
>> C began with real machines, real programmers.  The idea seems to have
>> been:  [...] end up with a kind of high-structured, low-level language;
>> a thinking-man's assembler.
 
>   Fortunately, the economics of software development are in favor
>   of using considerably higher-level languages.
 
Then perhaps you could explain the total dominance of C in the
mini/micro world, the only completely healthy segment of the computer
market?  The last figures I've read indicated that 65 percent of all
software development in this world was being done in C, and the next
highest figure for any other language was around six percent.  Are
Borland, MicroSoft, Lotus, Ashton-Tate, WordPerfect, and all of
those companies just that stupid?
 
>> C++ appears to BE the very language which Ada was supposed to be
>> (the spirit of the law) but never can and never will be.
 
>   Total rubbish; C++ retains all the low-level and dangerous
>   facilities of C, which is obsolescent by modern software
>   engineering standards.  As stated by Fairley (Software
 
Those features are there because they are necessary for real world
programming.  Tacking those features onto or into an Ada program (which
is meant for real-world use) is not a superior solution;  it makes
for non-portable code.
 
>> There is no real way to call [Ada] from a Cobol program.
 
>   Ada users can call COBOL or any other language using pragma
>   INTERFACE; COBOL needs to have a similar standardized means
>   of calling other languages.  Given that it does not, ad hoc
>   means of calling other languages have been devised; there is
>   no reason why such techniques cannot be used to call Ada just
>   as well as C or any other language.  But this is COBOL's problem,
>   not Ada's.
 
Dead wrong.  This is a grey area, but Ada tasking basically requires
that the starting point be an Ada program i.e. predictable results/full
Ada functionality are not possible from an Ada module called from a
routine written in another language.  The requirements to link
low-level kinds of routines into Cobol programs are very real.  Every
Ada manual I've seen says that results from such code are unpredictable.
 
>> A military project involving Sun machines and Ada was abandoned after
>> something like 4 years and $30 million effort because of unacceptable
>> performance;  database screens were taking over a minute to come up.  The
>> design work had all been done according to your formula, the individual
>> modules had been designed, written, and tested, all according to the
>> standard military schedules and formulas (2167 etc.).  Everything seemed
>> hunky dory, only when they put the fricking thing together, it was too
>> damned slow to use.  And, the remarkable thing is, the very system the
>> military insists upon for management of software contracts prevented
>> anybody from knowing they were in trouble until four years and millions
>> had been blown.  The government people involved were essentially reduced
>> to the role of actors in a Greek tragedy.
>>
>> Asked for a solution, my firm weighed the choice between offering an Ada-
>> to-C converter and silence, and opted for silence.
 
>   How about applying a profiler and recoding the "hot spots"?
 
        There weren't any "cold" spots
 
>   If the slowness of Unix process handling is a problem, then
>   a more modern version of Unix should be used.  Your company
>   should have considered more than two options.
 
First, the problem with performance didn't involve UNIX.  Second, to my
knowledge, the vender only offers the one version for the machine.
Again, the customer was not John Rockafeller.
 
 
>> [...] There is the August 21 89 issue of Government Computer News
>> describing the problems which the huge FAA Advanced Automation System is
>> having due to IBM Ada implementations and tools (or lack thereof).  
 
>    Apparently IBM has now changed its tune; its recent brochure
>    entitled "Ada and IBM... Capability and Committment" states:
 
>      IBM is committed to Ada.  Ada's support for modern software
>      engineering concepts, its breadth of application, and its
>      support for reuseable software components place it squarely
>      in the forefront as a language of choice for both IBM's
>      software engineers and for IBM's customers.
 
 
IBM was and is committed to PL/1, the PC-Jr, OS/2, MCA...  Apparently,
they have simply added Ada to their list of big-time losers with which
(temporarily) there is a profit to be made.
 
 
 
 
From: CAROZZONI: The Internet
 
>>in particular, the
>>ordinary systems which most people will be seeing in front of them for the
>>next 5 - 15 years, UNIX systems and PCs, will not run Ada acceptably.
 
>        And the technical reason is ?
 
Inferior design of the programming language.
 
>        Standardization among C compilers can best be shown by the Billions
>        and Billions of "ifndef"'s and "ifdef"'s in any C program such as
>        the Emacs Editor source code.
 
 
You actually USE Emacs?  Did it come bundled with Ada?  Does the
Internet have any kind of a rule regarding picking three losers, like
the old New York three-time-loser law?  How about Emacs, Ada, and Oracle?
 
>>.....PC and lots of memory to play with, Ada compilers at least will get
>>back to you on the same DAY; ...................................
 
 
>        I use Ada on a PC/AT (as do others here) and also use MS C 5.1!
>        We can't agree with you on this. Try reading the Ada compiler
>        installation manual.
 
The best compile times I've ever heard of either on a VAX class machine
or a 386 is around 1000/2000 lines/minute;  Turbo C is around 15000 on a
fast 286, Zortech C++ about the same, Turbo Pascal around 40000 on a fast
286;  God knows what they run at on a 386.  We're talking about at least
a two-order-of-magnitude differential.
 
>>......After All". Remember, Ada has been around since 1979.  If that were
>>the best anybody could say about C after ten years, C compiler salesmen would
>>be starving and dying like flies.
 
>        Your facts are consistently confused. The availability of validated Ada
>        compilers covering a reasonable selection of machines have only
>        been around for 4-5 years.
  
 
Ada started in 79;  taking 6 years to write a validated compiler doesn't
speak favorably of your efforts.  World War II was fought in less time.
 
 
>>.................... "Ada and UNIX doesn't work".  I've heard that a
>>million times from users, first time that succinctly in print.  Between
>>UNIX and Ada, UNIX is the real-world standard..................
 
>        The UNIX standard? (BDS, System 5, Xenix, OSF, UI, Mach etc)?
 
Pick one.
 
>>      Ada threatens to leave DoD stranded and technologically backwards;
>>out of the mainstream of American computer science..............
 
>        A recent article indicated that Ada and Ada like (Pascal, Modula 2)
>        languages are the primary choice for Software Engineering Curriculums.
>        May be you should enroll in one.
 
Sorry, I live in the real world;  I can't afford the brain damage that
might do.
 
 
....................
 
 
Am I missing something by citing 1988 and 1987 journals?  Is it possible
that in the year since the articles I have mentioned were printed that
Ada has come of age?  Consider the article concerning the Rational
machine in this week's (Nov 13 89) issue of Government Computer News,
page 47.  It claims the price of the latest Rational Ada development
machine has "come down" to around $100,000.  It also claims that the
machine will be used as a network resource in conjunction with Sun, DEC,
and IBM file servers.
 
The obvious implication is that these other machines, which are quite
powerful, yet lack the capability for serious Ada development.  Why is
that?  IBM, DEC, and Sun computers can easily be used to develope
software in C, Fortran, Pascal, C++, Cobol...
 
My own most recent machine is a Primus 386 which runs at 25 mh with no
wait states, has 4 meg main memory and a 104 mh Conner disk which I paid
around $2300 for.  This system could easily be used to develope almost
any kind of software with any reasonable language.  What are you people
getting for the other $97,700 with the Rational?
 
Consider the possibility of an analogy from the world of medicine.  In
the medical world, the Rational might be referred to as a "heroic
measure", possibly an iron lung.  The patient (in this case, Ada), would
be referred to either as "a terminally ill patient" or "the deceased".
 
Aside from myself, who is saying that the end is near for Ada?
Possibly, a certain Mr. Gorbachov in the CCCP, who is basically
declaring the cold war to be over, and a Mr. Cheney in Washington D.C.
who is talking about cutting 180 Billion from the U.S. defense budget
over the next five years (Wash. Post, A1, Nov 18, 89).  Anybody care to
bet that Ada doesn't become one of the first casualties of all this?
 
Ted Holden
HTE
 
 

Re: Ada

[William Thomas Wolfe, 2847]

From ted@grebyn.com (Ted Holden):
>>   Total rubbish; C++ retains all the low-level and dangerous
>>   facilities of C, which is obsolescent by modern software
>>   engineering standards.  As stated by Fairley (Software
>  
> Those features are there because they are necessary for real world
> programming. 

   Would you care to try to prove this, for the benefit of 
   those of us who could really use a few good laughs?  (But
   do us a favor and read a few SOFTWARE ENGINEERING texts
   before you try, so we won't have to waste too much effort
   giving you references...)

>>> There is no real way to call [Ada] from a Cobol program.
>  
>>   Ada users can call COBOL or any other language using pragma
>>   INTERFACE; COBOL needs to have a similar standardized means
>>   of calling other languages.  Given that it does not, ad hoc
>>   means of calling other languages have been devised; there is
>>   no reason why such techniques cannot be used to call Ada just
>>   as well as C or any other language.  But this is COBOL's problem,
>>   not Ada's.
>  
> Dead wrong.  This is a grey area, but Ada tasking basically requires
> that the starting point be an Ada program i.e. predictable results/full
> Ada functionality are not possible from an Ada module called from a
> routine written in another language.  The requirements to link
> low-level kinds of routines into Cobol programs are very real.  Every
> Ada manual I've seen says that results from such code are unpredictable.

   Is this the Ada Reference Manual (and thus pertaining to Ada),
   or specific manuals for specific compilers?  If the latter, then
   this may be a property of particular compilers, but is NOT an
   inherent property of Ada.  Thus, it becomes the user's responsibility
   to find a vendor which will provide a compiler which will satisfy the
   user's requirements relative to SOME OTHER LANGUAGE in addition to 
   the requirements of the Ada LRM.  
 
> First, the problem with performance didn't involve UNIX.  Second, to my
> knowledge, the vender only offers the one version for the machine.
> Again, the customer was not John Rockafeller.

   Oh, I see.  It is somehow Ada's fault that compilers are not available
   for pennies (if that) which will do everything imaginable on all possible
   machines, particularly when management failed to do a good job of compiler
   evaluation before starting the project and now needs to find a better 
   compiler than the one MANAGEMENT selected in order to save the project. 

   C'mon, Ted, admit it!!!  You're trying to blame Ada for everything
   under the sun, REGARDLESS of whose fault it really was.  Get a life... 
 
> The obvious implication is that these other machines, which are quite
> powerful, yet lack the capability for serious Ada development.  Why is
> that?  IBM, DEC, and Sun computers can easily be used to develope
> software in C, Fortran, Pascal, C++, Cobol...
   
   And Ada.  Rational offers a very powerful CASE environment which
   far surpasses anything being used by the C, Fortran, Pascal, etc.
   crowd.  One major reason for this is that users of those languages
   generally operate as programmers, whereas Ada users generally operate
   as software engineers.  This results in Ada users having much higher
   standards, both for their language and for their CASE environments.

   Competition is arising for Rational in the form of the TeleArcs
   CASE environment for the Suns and VAXen; given Telesoft's association
   with IBM, it will probably soon be available there as well.  And of
   course there are other vendors playing the game as well.  So although
   Ada software has long been developed on all of the above platforms
   without advanced CASE environments, that era is quickly departing.
 
% Aside from myself, who is saying that the end is near for Ada?
% Possibly, a certain Mr. Gorbachov in the CCCP, who is basically
% declaring the cold war to be over, and a Mr. Cheney in Washington D.C.
% who is talking about cutting 180 Billion from the U.S. defense budget
% over the next five years (Wash. Post, A1, Nov 18, 89).  Anybody care to
% bet that Ada doesn't become one of the first casualties of all this?

   Yep.

% The last figures I've read indicated that 65 percent of all
% software development in this world was being done in C, and the next
% highest figure for any other language was around six percent.  Are
% Borland, MicroSoft, Lotus, Ashton-Tate, WordPerfect, and all of
% those companies just that stupid?

   Considering the number of articles I've read recently in the 
   Wall Street Journal about the software crisis at Microsoft,
   et al., this would seem to be a rather reasonable conclusion.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

ADA

[jj]

PLEASE YOU WILL PARDON ME BECAUSE I AM A
NEW USER AND THIS IS MY FIRST POST.  

FROM WHAT I HAVE READ IN THIS BBS IF
YOU USE ADA YOUR PROGRAMS WILL NOT
HAVE ANY BUGS.  I THINK THAT
WOULD BE A VERY GOOD THING.  I 
THINK EVERYONE SHOULD USE ADA SO
THEIR WILL NOT BE ANY MORE BUGS.

PLEASE TELL ME HOW TO GET ADA FOR
MY RADIO SHACK COLOR COMPUTER (I 
USED IT AS A TERMINAL TO TYPE THIS IN).  

A Poor Man's Ada Library

[Ted Holden]

 
 
     I have come to believe that a good Ada Language library can be
had with very little expense;  everything you need to know about
Ada can be found in three books, if you know how to pick the three. 
Here is my impression of the three books you'll need:
 
 
1.   Ada advocates talk a great deal about "software engineering",
often as if Ada and software engineering were near synonyms. 
Hence, the first book which should be on your shelf should be a
REAL software engineering book.  I recommend Bertrand Meyer's
"Object-Oriented Software Construction", Prentice-Hall
International Series in Computer Science.  Meyer mentions Ada
several times, but only as a bad example, e.g. page 60:
 
     "Because the term 'Object-Oriented' has been used to describe
     various techniques - even Ada has been claimed to be an
     object-oriented language! - it is useful to distinguish the
     various steps that lead to true object-orientedness."
 
Object-oriented programming is the only thing which could possibly
help some of the giant projects which are now mandated to be done
in Ada.  Ada doesn't have it now.  Ada probably won't have it with
the 9x version, which will likely include mostly fixes for some of
the present bugs and woes, and given the speed of the process
involved, the 9x standard will probably be out in about a year, a
first compiler in four years, and first near-reasonable compilers
in seven or ten years.  This probably says 14+ years for object-
oriented Ada.
 
 
2.   Another term which software engineers, particularly of the Ada
variant, are constantly blathering about is "software reusability". 
Hence, the second book in your Ada library should be a "software
reusability" book.  This, I figure, just has to be the Programmers'
Connection catalogue, which can be had free for a phone call to
(800 336-1166).  This catalogue has everything under the sun in it,
at least for the mini-micro/UNIX world, and that about says it all
these days, or at least says most of it.  A programmer with this
catalogue at his disposal can regard his C compiler as a tube of
glue with which to simply glue things from the catalogue together; 
that makes for a kind of an easy life.  The catalogue also contains
a few Ada items for perverts, but you will notice that it contains
three indices, one by company, one by product name, and one by
function, and that the function index contains about a fifth of a
column on Ada and several pages on C products.  Hence, in the book
on software reusability, Ada is basically a footnote, and C is the
body of the book.
 
 
3.   Of course, I've been saving the good part for last.  The third
book you will need for your Ada library is a real, honest-to-God
Ada book, and here we delve into the realm of humor.  All Ada books
are funny to some extent or other, but my choice will have to be
one pointed out to my by my buddy Harris Reavin:  "Software
Development With Ada", Addison Wesley International Computer
Science Series, by Ian Sommerville and Ron Morrison.  The back
cover reads:
 
     "The effective use of the Ada programming language will make
     a dramatic difference to the cost and quality of real-time
     software systems.  The aim of this book is to promote an
     understanding of the concepts which underlie the language
     facilities of Ada."
 
Sounds good, so far, but reading between the covers quickly leads
to high humor:
 
Page 21
 
     "Ada programmers have to be more highty skilled than
     programmers in FORTRAN or assembly code because they must
     understand the concepts underlying Ada to use the langnage
     properly. This means that they probably expect to be paid more
     for their sewices, thus increasing implementation costs."
 
Ada "gurus" are constantly talking about the advantage of Ada for
team projects, but here Sommerville/Morrison are making the point
that the do-everything language is so complex that the only team
likely to succeed at doing anything at all with it is the local
chapter of Mensa.
 
 
Again, on pages 22 - 23
 
     "There is no question whatsoever that the biggest problem in
     changing from Pascal, FORTRAN, or assembly langnage
     programming to Ada is posed by the sheer size of the Ada
     language. Indeed, it has been argued by Hoare (1981) that Ada
     is so large and so complex a language that it will be
     impossible ever to have confidence in its implementation.
 
     Therefore, the use of Ada might actually reduce software
     reliability.  Hoare's argument is flawed as, whatever its
     faults, Ada is better than assembly language, which is often
     the only altemative. However, we accept that Ada is a large
     and complex language which could and should be trimmed in some
     areas...
 
     Furthermore, the effective use of Ada constructs, such as
     packages, to implement abstract data types, requires an
     understanding of the concepts that underlie these constructs.
     This implies that the effective use of Ada requires some
     formal training in computer science, and this will pose
     immense problems Ior those organizations whose software
     engineers do not have such a background. This is a fairly
     common situation, and very large training costs must be
     budgeted for in the management of a transition to Ada as the
     principal programming language for systems development."
 
 
What do Sommerville/Morrison have to say about the likelihood of
ever actually hiring the local Mensa chapter as your programming
team out on some military base in Muskogee Oklahoma?
 
On page 37
 
     "The lnterLisp system is an excellent example of a tightly
     integrated programming environment, but it is unlikely that
     environments to support the development of programs in other
     languages, such as Ada, can be integrated in the same way. Not
     only is language extension forbidden in Ada, but the Ada
     programming community will exhibit a wider range of abilities
     than the InterLisp community who are all highly skilled
     programmers.  Less skilled and motivated workers are not
     likely to be willing to expend the time required to learn
     about a complex, extensible programming environment.  Nor are
     they able to produce powerful tools to extend that
     encironment.  So, although Ada-oriented programming
     environments may be built, they are unlikely to be as tightly
     integrated as InterLisp"
 
Does this contradiction sound a little bit more serious than the
problem concerning the inner meaning of "break" in C?
 
Sommerville/Morrison have more to say about Ada:
 
Page 43
 
     "Although it is to the credit of the planners of Ada that the
     need for a support environment was recognized, less time and
     effort were expended in establishing the requirements for that
     environment than were spent in the formulation of the langnage
     requirements. This was probably a mistake as sofarare
     engineering tools are as important a part of the soltware
     development process as the programming language used. In fact,
     had the APSE and Ada been designed as an integrated system,
     some of the complexity inherent in Ada might have been
     factored out into the APSE."
 
 
Page 69
 
 
     "A particular problem with using Ada as a design description
     language is that all dependencies (with clauses) must be
     specified before the program can be compiled. This conflicts
     with top-down design where high-level decisions are made and
     dependencies sorted out at a later stage.
 
 
Page 177
 
     Ada has limited facilities for inheritance and it has been
     argued that it is not a true object oriented programming
     language because of this lack.  However, as we shall see
     later, derived types and packages together do give some form
     of inheritance.
 
 
Page 204
 
     ...As we have said before, the subroutine is the main
     abstraction facility in Ada.
 
 
Page 219
 
     "...For example, if a package specification is recompiled,
     then so must be the package body, even though it is not
     altered.  The same is true for all sub units of library units,
     and may cause considerable recompilation.
 
Which makes for lots of slow, given what everybody knows to be the
case concerning Ada compile times. 
 
 
 
Ted Holden
HTE
 
 
 
 
 
 
 
 
 
 
 

Re: Ada

[William Thomas Wolfe, 2847]

From article <19452@grebyn.com>, by ted@grebyn.com (Ted Holden):
> Object-oriented programming is the only thing which could possibly
> help some of the giant projects which are now mandated to be done
> in Ada.  Ada doesn't have it now.  Ada probably won't have it with
> the 9x version, which will likely include mostly fixes for some of
> the present bugs and woes, and given the speed of the process
> involved, the 9x standard will probably be out in about a year, a
> first compiler in four years, and first near-reasonable compilers
> in seven or ten years.  This probably says 14+ years for object-
> oriented Ada.

   Regrettably for Mr. Holden, object-oriented Ada is available right
   now.  Software Productivity Solutions has a product called Classic
   Ada which serves as a Smalltalk-based object-oriented preprocessor 
   for Ada-language software developers.  Another object-oriented approach
   along the lines of Zetalisp's Flavors (InnovAda) will soon be on the 
   market as well.  But Ted Holden will never let reality interfere with 
   his point of view, as he has so repeatedly demonstrated. 

> Ada "gurus" are constantly talking about the advantage of Ada for
> team projects, but here Sommerville/Morrison are making the point
> that the do-everything language is so complex that the only team
> likely to succeed at doing anything at all with it is the local
> chapter of Mensa.

   Well, Ted, if you aren't bright enough to handle Ada, I suggest that
   you stay away from it.  However, you should keep in mind that STANFINS-R
   has recently demonstrated that even COBOL programmers can be turned into
   effective Ada software engineers.  Perhaps you should therefore see to it
   that you refrain from using any language more sophisticated than COBOL!
 

   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada

[William B. Tyler]

In article <8322@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>
>   Regrettably for Mr. Holden, object-oriented Ada is available right
>   now.  Software Productivity Solutions has a product called Classic
>   Ada which serves as a Smalltalk-based object-oriented preprocessor 
>   for Ada-language software developers.  Another object-oriented approach
>   along the lines of Zetalisp's Flavors (InnovAda) will soon be on the 
>   market as well.  But Ted Holden will never let reality interfere with 
>   his point of view, as he has so repeatedly demonstrated. 
>

Wolfe's response serves to reinforce Holden's point.  Ada, the language,
has no capability for object oriented programming.  Use of these 
extensions amounts to use of a different language, especially since 
Ada admits no extensions by definition.

>   Well, Ted, if you aren't bright enough to handle Ada, I suggest that
>   you stay away from it.  

This seems to be an admission that Ada has failed in a very important
area of language design.  If it requires brilliance for proper use,
it is certainly inappropriate as a vehicle for implementing large
projects with many programmers, some at least of whom will be of
average intelligence.

Why don't you give it a rest, Wolfie?  At least try keeping out of
the C newsgroup.
-- 
Bill Tyler				...(tolerant|hpda)!procase!tyler

Re: Ada

[Dennis M. O'Connor]

"[...*...]" below means I've deleted something I consider an ad-hominem,
that IMHO added nothing constructive to the conversation. My apologies
if I offend anyone.

tyler@procase (William B. Tyler) writes:
] In article <...> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
] > [...*...]
] >   Software Productivity Solutions has a product called Classic Ada
] >    which serves as a Smalltalk-based object-oriented preprocessor 
] >   for Ada-language software developers.  Another object-oriented approach
] >   along the lines of Zetalisp's Flavors (InnovAda) will soon be on the 
] >   market as well. 
] > [...*...]
] 
] [...*...]  Ada ... has no capability for object oriented programming.

My understanding is that "support for OOP" is not a YES-NO question.
IMHO, Ada does support objects, if not OOP : does not a package represent
a passive object, and a task represent an active one ? Doesn't a
"task type" has all the characteristics of a class (and even more) ?
What Ada doesn't support is inheritance. So, Ada's support for OOP
is limited, not non-existant. It's support for Object-Oriented Design
(OOD) is a different issue.

] Use of these extensions amounts to use of a different language, especially
] since Ada admits no extensions by definition.

However, if you believe that the primary benefit of OOP is found in
the design stage (OOD), then using something like Classic Ada for design,
and then automatically translating it into Ada (which is, I believe,
how these products work) is probably an option even in an "Ada-only"
project. (Any DoD project participants care to comment ?) It is certainly
an option for those who use Ada because they like the features of the
language, not because of a DoD mandate. Yes, such people exist. ;-)

] >  [...*...] if you aren't bright enough to handle Ada, I suggest that
] >   you stay away from it.  
] 
] This seems to be an admission that Ada has failed in a very important
] area of language design.  If it requires brilliance for proper use,
] it is certainly inappropriate as a vehicle for implementing large
] projects with many programmers, some at least of whom will be of
] average intelligence.

What is this "you gotta be smart to use Ada" stuff anyway ? Let's
face it : if you are using the complex features of any language, it
should be because the design is complex, not because of the the
language you are implementing in. And if the design is complex,
you'd better be smart no matter what language you use.

If a language forces you to implement a simple design in
a complex way, I`d say it's flawed. Feel free to point
out such flaws in Ada to the Ada-9X commitee, please !

In a large project with programmers of varying degrees of talent,
"average" (yuck I hate that word) programmers should be assigned
tasks of "average" difficulty, and the tough stuff should be
done by the most talented people. This, like many other issues,
is language-independant.

It has to be admitted, of course, that many languages wind up associated 
with a particular design methodology and project management philosophy.
But "correlation is not causation", eh ?

] Why don't you give it a rest [...] try keeping out of the C newsgroup.

I don't really understand the emnity between some of the C and Ada
proponents. Why the emotions ? What are people afraid of ? So
one or both languages doesn't take over the world, so what ?
Eventually (I hope) both will be obsolete in their present forms.
Hopefully, both can learn form each other, and evolve into
something better.

Nobody should mind constructive criticism, eh ?
--
  Dennis O'Connor      OCONNORDM@CRD.GE.COM      UUNET!CRD.GE.COM!OCONNOR
  "Let's take a little off the top ... a bit off the sides ...
    trim the back a bit ... Surprise ! You've been bald-ed !"

ADA

[Robert Adams]

Need some useful packages for ADA programming.  Please leave 
email at RAdams9348@gnn.com.

Thanks,
Robert

ada

[BCummi6553]

I just started and I haveing trouble with trying to get my program to
calulate scores
entered that our unlimited and displaying how to show how many were
entered. Can you help me or tell me where to get help.

BCummin6553.aol.com

Ada

[Jeffrey D. Iverson]

At http://www.iversonsoftware.com/ada.html we've created a FREE online
directory of professional consultants and developers for Ada. We
currently have 22 entries.

You'll also find a job board where you can see opportunities for work, a
discussion board where you can post questions or find answers, and a
bookstore.

I hope you'll visit soon!
-- 

 Jeffrey D. Iverson         j5rson@iversonsoftware.com
 Iverson Software Co.       http://iversonsoftware.com/

Ada

[N6101233]

I realise that this group is about Ada the language, but I'm desperately
try to find out some stuff about obstacles she had as a female scientist
and why here work has only recently been acknowledged.  If any one
knows, or knows of a group that might - I'd really appreciate!

Robin

Ada

[Brijesh]

I am fairly new to Ada programming and have a rather trivial question I
was hoping the group could help answer.

I understand Ada is a very powerful language but is not used much
outside the defence industry, I was woderign if this is a correct
assumption and if so why is this the case - and if not where else is it
used.

Thanks,

Brij

Re: Ada

[Greg Martin]

On Thu, 23 Dec 1999 11:11:12 +0000, Brijesh <brijesh.malkan@gecm.com>
wrote:

>I am fairly new to Ada programming and have a rather trivial question I
>was hoping the group could help answer.
>
>I understand Ada is a very powerful language but is not used much
>outside the defence industry, I was woderign if this is a correct
>assumption and if so why is this the case - and if not where else is it
>used.
>
Hi Brij.
I'm new to Ada as well but I can tell you it is used in other areas
where software might be considered mission critical. I'm Canadian and
know it to be used for air traffic control here (and elsewhere I
suspect) and software our space agency uses. In general it's used for
on board aircraft applications. It seems to be a small part of the
market but it's definately there. You might try searching on Ada jobs
or something similiar.
Regards,
Greg Martin.

Re: Ada

[Robert Dewar]

In article <38620350.48F8FC08@gecm.com>,
  Brijesh <brijesh.malkan@gecm.com> wrote:
> I understand Ada is a very powerful language but is not used
much
> outside the defence industry, I was woderign if this is a
correct
> assumption and if so why is this the case - and if not where
else is it
> used.
>
> Thanks,


Never believe such rumours, they are almost always wrong. It
is interesting that there is a whole series of technologies that
has important current applications, but which conventional
wisdom pronounces dead (examples, APL, OS/2, Pascal, PL/1, and
yes, Ada :-)

Ada has many non-DoD applications, go to www.adapower.com to
follow up on more information, but here are some examples:

Train switching systems (soon to be adopted by the NY subway)
Internet switches
Medical equipment
Commercial airplaces (ever flown on a 777 - it's an all Ada
plane)
Cable TV (Canal Plus in Europe)
Air Traffic Control Systems
Eurospace
Banking applications
etc.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[tmoran]

>Ada has many non-DoD applications, go to www.adapower.com to
>follow up on more information, but here are some examples:
>...
>etc.
  One etc I know about is stocks and commodities databases for
speculators, er, investors.  All databases, and the daily data,
have errors, which show up as oddballs on graphs, or, worse,
screw up technical analysis algorithms.  A system I worked on
used Ada to help cleaning and merging data.  It was useful as a
good language to help avoid introducing new errors, the
run-time error checking helped catch unexpected errors, and
tasking let it easily display questionable data to a human
asynchronously with scanning the data.  This was about 5 years
ago, at the beginning of the present on-line trading craze.

Re: Ada

[Roger Racine]

On Thu, 23 Dec 1999 11:11:12 +0000, Brijesh <brijesh.malkan@gecm.com>
wrote:

>I am fairly new to Ada programming and have a rather trivial question I
>was hoping the group could help answer.
>
>I understand Ada is a very powerful language but is not used much
>outside the defence industry, I was woderign if this is a correct
>assumption and if so why is this the case - and if not where else is it
>used.
>
>Thanks,
>
>Brij
>

You actually have 2 questions, only 1 of which is trivial:

1) Is Ada used much outside the defence industry?

2) If not, why not; if so where?

1) Ada is not used "much" anywhere, inside or outside the military, if
you compare it with C.  It is, however, being used by "many"
organizations both within and outside the military.  This should be a
trivial question since the number is some finite countable positive
integer.  Unfortunately, I do not think anyone knows the exact number.

2) Ada is being used in communication systems (TopLayer is one
example), airplanes (Boeing), space systems (NASA), teaching,
compilers (ACT), etc.  The list is not small unless it is compared
with the equivalent list of C projects.

The hard part of your second question is "why not?"  There are so many
reasons, none of which are very "good" (which is why those of us who
still advocate its use are still doing so).  At the risk of getting
into another language war, here goes:

1) Control theory.  C is in a positive control loop; Ada is in a
negative loop.  C is popular.  Therefore people want C on their
resumes.  Therefore people want to do projects in C.  Therefore
companies provide tools for C development.  Therefore libraries for C
are written.  Ada is not popular.  Therefore people do not want Ada on
their resumes.  I know of people who have threatened to quit if they
were forced to use Ada, since they thought they were becoming
unwanted. 

2) Time to Market.  Ada is a readable language.  C is a writeable
language.  People think they are more productive using C because they
get to integration faster, and they might get a software system to
market sooner than with Ada.  Ada will allow people to find certain
errors more easily, but this is not perceived to be a significant
enough improvement, and for most commercial software, getting all the
bugs out is not necessary to getting a product out.

3) Philosophy.  I am treading on thin ice here, but there is possibly
an innate human trait to need recognition.  With C, you need gurus who
are great at finding the subtle problems.  These people are less
important in Ada projects, and therefore are less happy.  I will admit
that one of my current projects is being done in C, and we had a code
peer review the other day.  I found some very significant defects,
that probably would not have been found until very late in the
testing.  Everyone praised me for finding these defects, and I felt
very good.  The defects could not have existed in Ada.  Special
recognition in Ada projects has to come in other ways, and will
generally come to a different group of people, and possibly fewer.

4) First impressions last a long time.  The first impression many
people had with Ada was that the language had shortcomings for
real-time systems.  In fact, the Ada conferences and publications had
many articles on what was wrong with the language.  The compiler
vendors tried to provide ways to get around the problems, but then
code was not portable.  This left a very bad feeling in people who
used Ada 83.  They are not interested in even looking at Ada 95.

5) Tools.  Books, compilers, development environments, are all more
available and cheaper for C than for Ada.  I can go into a local
computer store and find Visual C++ for some small amount of money (I
have seen it, but have not bought it, so I do not remember the exact
amount).  To get an equivalent Ada development environment
(supported), I have to go to a vendor, and the cost will probably be
at least an order of magnitude more.  This brings one into economics.
If Visual C++ costs the same to produce as some Ada compiler, but 100
times more copies of Visual C++ are sold, what is the difference in
profit for Microsoft if they sell theirs for 1/10 the price?  It is
not trivial to answer this (since it depends on the cost of initial
development, the value of stock options, the cost of distribution, the
cost of lawyers, etc.), but it can be more profitable.

Does this help explain the current situation?  This is probably way
too simplistic.  I forgot to even mention the DoD mandate.

Roger Racine

Re: Ada

[Marin D. Condic]

Roger Racine wrote:
> 2) Time to Market.  Ada is a readable language.  C is a writeable
> language.  People think they are more productive using C because they
> get to integration faster, and they might get a software system to
> market sooner than with Ada.  Ada will allow people to find certain
> errors more easily, but this is not perceived to be a significant
> enough improvement, and for most commercial software, getting all the
> bugs out is not necessary to getting a product out.
> 
I beg to differ - sort of. In many systems Ada gets you to market sooner
with fewer problems. Assuming skilled programmers in each case. Where
C/C++ has an edge is in areas where you get tons of reusable libraries
with it, such as in Visual C++. But this is just one type of system
development. I've been playing with the CLAW GUI builder demo and found
that it will build Ada GUI programs quite easily, so it isn't as if Ada
*can't* do it - just that it isn't as easily marketed. If you got CLAW,
a compiler, a bunch of utilities (Similar to MFC? Where is the ACLWG
these days anyway?) manuals, tutorials, a book, a configuration
management system, etc. all in one package it might compete well in the
"Time To Market" field. All these things exist, but not as a single, one
stop shopping, package. (Maybe a teaming effort is needed?)


> 5) Tools.  Books, compilers, development environments, are all more
> available and cheaper for C than for Ada.  I can go into a local

Definitely. I was recently at a big electronics store in San Jose and
looked through their stacks of books relating to programming &
languages. Hundreds of books available on C, C++, Perl, Cobol, etc. Not
a single text on Ada, even though many good ones exist. It is sort of a
deadlock situation - The store doesn't want to stock something for which
there won't be a reasonable level of sales. The potential vendors don't
want to subsidize it because revenues are too thin to do so. The
potential users have little interest because it isn't just sitting right
there waiting for them to pick it up. The deadlock continues.

Now potentially, it would be possible for some of the vendors to get
together to produce an integrated package with each supplying some part
of the end product. A joint venture would spread the risk and might
bring sufficient resources to bear to actually put up a shrink-wrapped
package on a display rack on the floor of a few computer stores. Done
right with a sufficiently narrow focus, it could succeed and make
everyone a few bucks while making Ada a bit more prevalent. I'd
certainly be interested in discussing it... ;-)

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Ada

[Richard D Riehle]

In article <38690E47.7DBDC2D1@quadruscorp.com>,
	"Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:

>> 5) Tools.  Books, compilers, development environments, are all more
>> available and cheaper for C than for Ada.  I can go into a local
>
>Definitely. I was recently at a big electronics store in San Jose and
>looked through their stacks of books relating to programming &
>languages. Hundreds of books available on C, C++, Perl, Cobol, etc. Not
>a single text on Ada, even though many good ones exist. It is sort of a
>deadlock situation - The store doesn't want to stock something for which
>there won't be a reasonable level of sales. The potential vendors don't
>want to subsidize it because revenues are too thin to do so. The
>potential users have little interest because it isn't just sitting right
>there waiting for them to pick it up. The deadlock continues.

Marin,

Sounds as if you were visiting Fry's Electronics, our local Silicon
Valley Computer Circus.  For serious literature on anything related
to computers, Fry's is not a good choice.  Instead, we have a local
bookstore, Computer Literacy Bookshops  (www.fatbran.com), which has
a representative selection of Ada books.  Next time you are looking
for computer books in Silicon Valley, don't go to Fry's.  Go to 
Computer Literacy Bookshops.  

BTW, many of us who buy computers and computer gear stay away from
Fry's.  I have had such bad experiences with their service that I will
not buy anything from them unless there is no choice.  There
are lots of good alternatives here is SV.  Next time you are in 
SV, give me a call and I will direct you to some better options. 

Richard Riehle

Re: Ada

[Marin D. Condic]

Richard D Riehle wrote:
> Marin,
> 
> Sounds as if you were visiting Fry's Electronics, our local Silicon
> Valley Computer Circus.  For serious literature on anything related
> to computers, Fry's is not a good choice.  Instead, we have a local
> bookstore, Computer Literacy Bookshops  (www.fatbran.com), which has
> a representative selection of Ada books.  Next time you are looking
> for computer books in Silicon Valley, don't go to Fry's.  Go to
> Computer Literacy Bookshops.
> 
Yes, that's where I was looking. They gave off the impression of being
sort of the "Home Depot" of electronics stores. Maybe their selection is
not the best, but they seemed to be sort of "Computer Stuff For The
Masses". The books may not have beem the "serious" computer literature
you have in mind, but they did have lots of shelves of stuff aimed at
helping folks at a variety of levels to learn different languages/tools.

My only point was that for Ada to improve its market position, it needs
to be presented to "The Masses" in a way that makes it easy to adopt and
use. That's why I think a whole shrink-wrapped kit for the PC/Windows
environment would be a good idea.

MDC

-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Ada

[Robert Dewar]

In article <386F7856.26134B3E@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:
> My only point was that for Ada to improve its market position,
> it needs to be presented to "The Masses" in a way that makes
> it easy to adopt and use. That's why I think a whole
> shrink-wrapped kit for the PC/Windows
> environment would be a good idea.

So .. don't stop at making the suggestion that "someone" (*)
do this, instead take the initiative to do it yourself. All
the ingrediants are there. You can certainly build what you
want from the public version of GNAT. Of course getting shelf
space at Fry's is a totally different kettle of fish :-)

(*) someone -- that elusive person to whom many tasks are
assigned, but who seldom follows through, and in fact is
rather hard to track down :-) :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[Marin D. Condic]

Robert Dewar wrote:
> So .. don't stop at making the suggestion that "someone" (*)
> do this, instead take the initiative to do it yourself. All
> the ingrediants are there. You can certainly build what you
> want from the public version of GNAT. Of course getting shelf
> space at Fry's is a totally different kettle of fish :-)

Yup. Shelf space at Fry's (or COMPUSA, etc.) might be an issue - but it
might be resolvable fairly easily with a few phone calls if the "right"
product is available, or at least planned. The notion I had in mind
would involve more than a version of GNAT - there would need to be a
bunch of other things in the kit, some of which might not be so readily
available. Thats why I think it would take a coordinated effort of a few
vendors to put together a comprehensive package and a marketing
strategy. What I might be able to bring to the table at this juncture is
TBD.

> 
> (*) someone -- that elusive person to whom many tasks are
> assigned, but who seldom follows through, and in fact is
> rather hard to track down :-) :-)

I'm very familiar with "someone" and frequently get frustrated with his
inability to keep to my schedule. ;-) Perhaps if I were to get him that
very expensive and rare device known as A Round Tuit he might be able to
make faster progress :-)

MDC
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Ada

[Ted Dennison]

"Marin D. Condic" wrote:

> Yup. Shelf space at Fry's (or COMPUSA, etc.) might be an issue - but it
> might be resolvable fairly easily with a few phone calls if the "right"

My understanding was that stores like that tend to have sort of a
supermarket-style approach to shelf space. That means you aren't going to
get them to give you shelf space for free.

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: Ada

[Robert Dewar]

In article <386F9D7E.B6DD06B9@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:

> Thats why I think it would take a coordinated effort of a few
> vendors to put together a comprehensive package and a
> marketing strategy.

This won't happen if you wait for vendors to do it, because they
won't be convinced it makes any marketing sense (I am certainly
dubious).

But on the other hand, all the tools and components you need
are out there in open source form, so you or someone else can
certainly put everything together without needing to wait for
the vendors to move.

Part of the reason I think this makes less sense than you
think is that these days students and other likely consumers
of such a package expect to pay $0 for it, and are not about
to go and plunk down a credit card at Fry's or anywhere else
to buy a package of this kind!

Note also that there are some attempts to do something like
what you suggest, for example, the University of Brighton
CD ROM.

But if you do want to create something, I think the delivery
HAS to be free and electronic. I don't think you will get
anywhere
with a shrink wrapped box at Fry's.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[Marin D. Condic]

Robert Dewar wrote:
> Part of the reason I think this makes less sense than you
> think is that these days students and other likely consumers
> of such a package expect to pay $0 for it, and are not about
> to go and plunk down a credit card at Fry's or anywhere else
> to buy a package of this kind!
> 
You may be right. The only way to really settle the question is to
attempt to do it and see if it sells. That can be pretty expensive. But
do keep in mind that Micro$oft is out there selling shrink-wrapped
versions of Visual C++, etc. and people *do* plunk down credit cards to
buy that.

One can debate how profitable this might be - MS may be subsidizing
their development environment in order to keep development for Windows
going on. Its hard to say without a look at the books and I wouldn't
trust rumors or corporate statements on the subject. But certainly
people do buy VC++ so why might they not buy a *better* environment that
was wrapped around an Ada compiler?


> But if you do want to create something, I think the delivery
> HAS to be free and electronic. I don't think you will get
> anywhere
> with a shrink wrapped box at Fry's.
> 
I wouldn't write off electronic delivery - e-commerce is certainly
booming in growth right now. Fry's may have to go that route themselves
just to stay in business. But remember that when you go into Fry's you
will see development kits for other languages there on the shelves.
Somebody must be making a buck doing that - is there a reason that Ada
can't be one of those players? And a big advantage to being on a shelf
in a computer store is that people who may never have had any knowlege
or interest in Ada might happen to see it and be intrigued enough to try
it out.

My desire is to see that Ada experiences growth in its application for
commercial efforts. I think that is a goal most of us in this newsgroup
would agree on. I think that a weakness Ada has when compared to some
other languages is that there isn't a one-stop source where you can pick
up everything you need for serious development. There are lots of things
you can gather from all over the net and possibly cobble together a
development environment with everything you need. If your garden variety
developer were able to get the whole ball of wax in one location with
everything glued together in a consistent manner, it might encourage
more use.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Ada

[Larry Kilgallen]

In article <3870DEED.4744AE18@quadruscorp.com>, "Marin D. Condic" <mcondic-nospam@quadruscorp.com> writes:
> Robert Dewar wrote:
>> Part of the reason I think this makes less sense than you
>> think is that these days students and other likely consumers
>> of such a package expect to pay $0 for it, and are not about
>> to go and plunk down a credit card at Fry's or anywhere else
>> to buy a package of this kind!
>> 
> You may be right. The only way to really settle the question is to
> attempt to do it and see if it sells. That can be pretty expensive. But
> do keep in mind that Micro$oft is out there selling shrink-wrapped
> versions of Visual C++, etc. and people *do* plunk down credit cards to
> buy that.

For a point of reference, the per-copy cost of commercial CD
pressing is about $1 from a big vendor to a small customer.
That is after a setup charge of about $500.

> Somebody must be making a buck doing that - is there a reason that Ada
> can't be one of those players? And a big advantage to being on a shelf
> in a computer store is that people who may never have had any knowlege
> or interest in Ada might happen to see it and be intrigued enough to try
> it out.

Do not underestimate the value of attractive packaging at generating
sales. Lots of trash gets sold in various fields through the use of
attractive packaging -- there is no reason to skimp just because the
contents happen to be worthwhile.

If it is a boxed product, be sure to include a printed manual.
When I examine sealed boxes wondering about documentation, I
often judge by weight :-)

This does seem to be the sort of opportunity open-source software
was designed for -- the add-on value provided by promoting retail
sales is just way outside the sphere of developing software in the
first place.  If the retail package should become so overpriced as
to be offensive, competitors will enter the market.

Larry Kilgallen

Re: Ada

[Charles Hixson]

OTOH, on-line distributors, such as, e.g., Cheap-Bytes , PC-Connection, or EggHead sell items that don't
require the same concerns as the open store front.  Perhaps the packaging should be designed to look good from
a face-forward perspective, and to sell via on-line distribution, but with the ability to take advantage of
any store-front access that becomes available (without drastically raising the cost of distribution!)

Larry Kilgallen wrote:

> In article <3870DEED.4744AE18@quadruscorp.com>, "Marin D. Condic" <mcondic-nospam@quadruscorp.com> writes:
> > Robert Dewar wrote:
> ......

> > or interest in Ada might happen to see it and be intrigued enough to try
> > it out.
>
> Do not underestimate the value of attractive packaging at generating
> sales. Lots of trash gets sold in various fields through the use of
> attractive packaging -- there is no reason to skimp just because the
> contents happen to be worthwhile.
>
> If it is a boxed product, be sure to include a printed manual.
> When I examine sealed boxes wondering about documentation, I
> often judge by weight :-)
>
> This does seem to be the sort of opportunity open-source software
> was designed for -- the add-on value provided by promoting retail
> sales is just way outside the sphere of developing software in the
> first place.  If the retail package should become so overpriced as
> to be offensive, competitors will enter the market.
>
> Larry Kilgallen

Re: Ada

[Roger Racine]

On Mon, 03 Jan 2000 09:39:57 -0800, "Marin D. Condic"
<mcondic-nospam@quadruscorp.com> wrote:

>Robert Dewar wrote:
>> Part of the reason I think this makes less sense than you
>> think is that these days students and other likely consumers
>> of such a package expect to pay $0 for it, and are not about
>> to go and plunk down a credit card at Fry's or anywhere else
>> to buy a package of this kind!
>> 
>You may be right. The only way to really settle the question is to
>attempt to do it and see if it sells. That can be pretty expensive. But
>do keep in mind that Micro$oft is out there selling shrink-wrapped
>versions of Visual C++, etc. and people *do* plunk down credit cards to
>buy that.
>
>
>My desire is to see that Ada experiences growth in its application for
>commercial efforts. I think that is a goal most of us in this newsgroup
>would agree on. I think that a weakness Ada has when compared to some
>other languages is that there isn't a one-stop source where you can pick
>up everything you need for serious development. There are lots of things
>you can gather from all over the net and possibly cobble together a
>development environment with everything you need. If your garden variety
>developer were able to get the whole ball of wax in one location with
>everything glued together in a consistent manner, it might encourage
>more use.
>

I went to the local CompUSA store over the weekend and noticed that
Corel is now selling WordPerfect in a box that includes Linux.
Perhaps an Ada development environment combined with the operating
system might be popular enough to create a profit?

Maybe a cross-development system for the Palm Pilot included?

Roger Racine

Re: Ada

[Magnus Alexandersson]

"Marin D. Condic" wrote:
 
> Definitely. I was recently at a big electronics store in San Jose and
> looked through their stacks of books relating to programming &
> languages. Hundreds of books available on C, C++, Perl, Cobol, etc. Not
> a single text on Ada, even though many good ones exist. 

My school is dropping Ada for Java since the Ada books are hiedously
expensive here in Sweden and Javabooks come by the tenfold...

Reality bites, huh?

- 
///Magnus

http://www.mdtsud.chalmers.se/~md8maal

Re: Ada

[Tarjei T. Jensen]

Magnus Alexandersson wrote:
>My school is dropping Ada for Java since the Ada books are hiedously
>expensive here in Sweden and Javabooks come by the tenfold...


Are the students time worthless? 


Greetings,

Re: Ada

[Larry Kilgallen]

In article <85mpvr$mm42@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes:
> 
> Magnus Alexandersson wrote:
>>My school is dropping Ada for Java since the Ada books are hiedously
>>expensive here in Sweden and Javabooks come by the tenfold...
> 
> 
> Are the students time worthless? 

Perhaps even more money could be saved by changing the course to teach
them how to program Excel spreadsheets.

Larry Kilgallen

Re: Ada

[Marin D. Condic]

Larry Kilgallen wrote:
> 
> In article <85mpvr$mm42@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes:
> >
> > Magnus Alexandersson wrote:
> >>My school is dropping Ada for Java since the Ada books are hiedously
> >>expensive here in Sweden and Javabooks come by the tenfold...
> >
> >
> > Are the students time worthless?
> 
> Perhaps even more money could be saved by changing the course to teach
> them how to program Excel spreadsheets.
> 
Or let's just teach them how to use Notepad because it comes free with
Windows, has on-line documentation and is so simple that the students
wouldn't need to waste time even reading it. (Tongue firmly planted in
cheek)

Seriously: From what I've seen of Ada books, they aren't hugely out of
line with respect to price from books on other computer topics. College
level texts I've seen in the last couple of years on other topics have
been even more spendy than any of the Ada books I've purchased. The
largest cost of college is tuition. Why structure college courses around
the cost of books? (Maybe they could hire less expensive instructors?)

If I were Dean of the Computer Science department, I'd be more
interested in building a curriculum that presented important concepts in
the subject rather than picking topics because of current industry fads
or the cost of texts. But that's just me.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Ada

[Magnus Alexandersson]

"Marin D. Condic" wrote:

> Seriously: From what I've seen of Ada books, they aren't hugely out of
> line with respect to price from books on other computer topics. College
> level texts I've seen in the last couple of years on other topics have
> been even more spendy than any of the Ada books I've purchased. The
> largest cost of college is tuition. Why structure college courses around
> the cost of books? (Maybe they could hire less expensive instructors?)

Our dean says that there aren't many books out there that meets the
desired content of the
courses... Well, I believe that it's programming as a general thing to
study, not the language. On the other hand, since I learnt Ada, I've now
noticed how easy (;p) C became.
 
> If I were Dean of the Computer Science department, I'd be more
> interested in building a curriculum that presented important concepts in
> the subject rather than picking topics because of current industry fads
> or the cost of texts. But that's just me.

We are doing that now, learning the way of programming... Not just the
languagepart, se above.

-- 
///Magnus

http://www.mdtsud.chalmers.se/~md8maal

Re: Ada

[Marin D. Condic]

Magnus Alexandersson wrote:
> 
> Our dean says that there aren't many books out there that meets the
> desired content of the
> courses... Well, I believe that it's programming as a general thing to
> study, not the language. On the other hand, since I learnt Ada, I've now
> noticed how easy (;p) C became.
> 
I'm presuming that language may be an issue in the texts selected, so
that may be a limiting factor. There are a number of books available in
English at least which will address Ada itself as well as Ada in
specific application domains. You might look at the "books" section of
http://www.AdaPower.com/ for a few references.

If you've learned how to program better C code from having studied Ada,
then you have definitely learned something valuable. One reason for
studying languages like Ada is to understand concepts which may be
possible in other languages, but are not as directly supported.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Ada

[Magnus Alexandersson]

"Marin D. Condic" wrote:
 
> Definitely. I was recently at a big electronics store in San Jose and
> looked through their stacks of books relating to programming &
> languages. Hundreds of books available on C, C++, Perl, Cobol, etc. Not
> a single text on Ada, even though many good ones exist. 

My school is dropping Ada for Java since the Ada books are hiedously
expensive here in Sweden and Javabooks come by the tenfold...

Reality bites, huh?"Marin D. Condic" wrote:
> 
> Roger Racine wrote:
> > 2) Time to Market.  Ada is a readable language.  C is a writeable
> > language.  People think they are more productive using C because they
> > get to integration faster, and they might get a software system to
> > market sooner than with Ada.  Ada will allow people to find certain
> > errors more easily, but this is not perceived to be a significant
> > enough improvement, and for most commercial software, getting all the
> > bugs out is not necessary to getting a product out.
> >
> I beg to differ - sort of. In many systems Ada gets you to market sooner
> with fewer problems. Assuming skilled programmers in each case. Where
> C/C++ has an edge is in areas where you get tons of reusable libraries
> with it, such as in Visual C++. But this is just one type of system
> development. I've been playing with the CLAW GUI builder demo and found
> that it will build Ada GUI programs quite easily, so it isn't as if Ada
> *can't* do it - just that it isn't as easily marketed. If you got CLAW,
> a compiler, a bunch of utilities (Similar to MFC? Where is the ACLWG
> these days anyway?) manuals, tutorials, a book, a configuration
> management system, etc. all in one package it might compete well in the
> "Time To Market" field. All these things exist, but not as a single, one
> stop shopping, package. (Maybe a teaming effort is needed?)
> 
> > 5) Tools.  Books, compilers, development environments, are all more
> > available and cheaper for C than for Ada.  I can go into a local
> 
> Definitely. I was recently at a big electronics store in San Jose and
> looked through their stacks of books relating to programming &
> languages. Hundreds of books available on C, C++, Perl, Cobol, etc. Not
> a single text on Ada, even though many good ones exist. It is sort of a
> deadlock situation - The store doesn't want to stock something for which
> there won't be a reasonable level of sales. The potential vendors don't
> want to subsidize it because revenues are too thin to do so. The
> potential users have little interest because it isn't just sitting right
> there waiting for them to pick it up. The deadlock continues.
> 
> Now potentially, it would be possible for some of the vendors to get
> together to produce an integrated package with each supplying some part
> of the end product. A joint venture would spread the risk and might
> bring sufficient resources to bear to actually put up a shrink-wrapped
> package on a display rack on the floor of a few computer stores. Done
> right with a sufficiently narrow focus, it could succeed and make
> everyone a few bucks while making Ada a bit more prevalent. I'd
> certainly be interested in discussing it... ;-)
> 
> MDC
> --
> =============================================================
> Marin David Condic   - Quadrus Corporation -   1.800.555.3393
> 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
> http://www.quadruscorp.com/
> m c o n d i c @ q u a d r u s c o r p . c o m
> 
> Visit my web site at:  http://www.mcondic.com/
> 
> "Capitalism without failure is like religion without sin."
>         --  Allan Meltzer, Economist
> =============================================================


-- 
///Magnus

http://www.mdtsud.chalmers.se/~md8maal

Re: Ada

[Jon Jensen]

As someone who started doing Ada programming in 1987 I think the answer to
your question is simple:

The PC and Windows

In the 80's when Ada was first introduced, it was overshadowed by the
introduction of the PC and the drastic change the PC brought into industry.
This was compounded by the lack of inexpensive, high quality Ada compilers,
debuggers and tools on the PC.  As developers migrated from mainframe and
minicomputer development to PC development they didn't see Ada as a viable
alternative to the Pascal and C compilers that were available.

A similar change happened in the early 90's when developers migrated from
MS-DOS programming to Windows programming on the PC.  Again Ada was late to
the game in coming up with competitive compilers for Windows.  Again Ada was
ignored by most Windows developers.

Could it have been different?  I don't think so.  Any time any language is
mandated by law as opposed to being adopted as a defacto industry standard,
it is going to have an uphill struggle.

There seems to be a perception in this news group and in the Ada industry
that programming in Ada somehow makes your programs error proof.  Ada
certainly has features that make it less likely to program certain kind of
errors but you can certainly write bad code in Ada just as in any other
language.  Java purists would say that because Ada (and other languages)
allow pointers, programs developed with those languages are error prone.

There are still a lot of opportunities for Ada development out there.  I am
sure there is a lot of embedded systems work that is being done with it and
some commercial applications.  In these narrow areas you can certainly make
a living programming in Ada.  Ada development (done right) can also teach
you some wonderful things about resuability and modularity.  It isn't a
silver bullet.


Brijesh <brijesh.malkan@gecm.com> wrote in message
news:38620350.48F8FC08@gecm.com...
> I am fairly new to Ada programming and have a rather trivial question I
> was hoping the group could help answer.
>
> I understand Ada is a very powerful language but is not used much
> outside the defence industry, I was woderign if this is a correct
> assumption and if so why is this the case - and if not where else is it
> used.
>
> Thanks,
>
> Brij
>

Re: Ada

[reason67]

In article <38620350.48F8FC08@gecm.com>,
  Brijesh <brijesh.malkan@gecm.com> wrote:
> I am fairly new to Ada programming and have a rather trivial question
I
> was hoping the group could help answer.
>
> I understand Ada is a very powerful language but is not used much
> outside the defence industry, I was woderign if this is a correct
> assumption and if so why is this the case - and if not where else is
it
> used.

In the USA around 1% of comercial software was written in Ada. So, your
assumption is correct.

I don't think anyone knows the reasons for sure. My personal speculation
is economic. Until fairly recently Ada compilers were very expensive
compared to C. When you buya Unix platform you got C for free with it.
(This is also why FORTRAN was so popular as it was free on old IBM
Mainfraims).

I do not have a crystal ball, but Ada could pick up. From the recent
expansion of Parallel Virtual Machine architectures, I think parallel
computing is going to be really big in a few years. The Ada runtime
could be modified to support PVM or other methods, so you could easily
port code from a 1000 machine cluster to a 5 machine cluster.

I do not know if anyone is working on this currently. After the
Holidays, I planned on looking at writing a binding to PVM for gnat 3.12
on Linux. If successful I wanted to look into using PVM as the tasking
model (instead of pthreads), but I have done almost no research at this
time.

IF Ada can be successfully merged with this new clusters, then Ada has a
real shot at being much bigger in the USA. Esp. if people
start writing parallel virtual machine libraries in Ada as
well.

Unfortunately, if I was just starting out, I would not look into Ada for
a long term career in the USA. I think I would look much more heavily
into C++.
---
Jeffrey Blatt


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[Robert Dewar]

In article <83tohh$q2s$1@nnrp1.deja.com>,
  reason67@my-deja.com wrote:
> In article <38620350.48F8FC08@gecm.com>,
>   Brijesh <brijesh.malkan@gecm.com> wrote:
> > I am fairly new to Ada programming and have a rather trivial
question
> I
> > was hoping the group could help answer.
> >
> > I understand Ada is a very powerful language but is not used
much
> > outside the defence industry, I was woderign if this is a
correct
> > assumption and if so why is this the case - and if not where
else is
> it
> > used.
>
> In the USA around 1% of comercial software was written in Ada.
So, your
> assumption is correct.


I wonder where that figure of 1% comes from. If true, it means
that Ada is widely used, since this is 1% of an absolutely HUGE
market (1% is much higher than you think, once you have
subtracted out the really popular languages like COBOL and
Visual Basic, the latter accounting for the lion's share of
all software development).

In fact I suspect the figure is below 1%, but again, we are
talking percentages of a huge market, so even a sliver of this
can be highly significant. After all what percentage of the
over all automobile market does Ferrari have or Rolls Royce,
yet we still consider these technologies significant :-)

Certainly we all know lots of examples of successful commercial
use of Ada.

There seems to be a general tendency to write off technologies
that do not dominate the market. I can't tell you how many
people I meet who think OS/2 is dead, when in fact it is being
very successful in many contexts (and has exceeded sales
expectations every quarter for the last 5 or 6 quarters). Sure
it does not have the market share of Windows, but this again is
a huge market, and OS/2 has a significant share.

A similar situation exists with Ada. Of course it is not
numerically as successful as C++ for example, but that really
does not mean much. If you need the most reliable and best
technology around, you do not take a poll to see what is the
most commonly used technology!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[Terry Sikes]

In article <83u8l0$5i5$1@nnrp1.deja.com>,
Robert Dewar  <robert_dewar@my-deja.com> wrote:
>In article <83tohh$q2s$1@nnrp1.deja.com>,
>  reason67@my-deja.com wrote:
>> In article <38620350.48F8FC08@gecm.com>,
>>   Brijesh <brijesh.malkan@gecm.com> wrote:
>>> I am fairly new to Ada programming and have a rather trivial
>>> question I was hoping the group could help answer.
>>>
>>> I understand Ada is a very powerful language but is not
>>> used much outside the defence industry, I was woderign if
>>> this is a correct assumption and if so why is this the
>>> case - and if not where else is it used.
>>
>> In the USA around 1% of comercial software was written in Ada.
>> So, your assumption is correct.
>
>I wonder where that figure of 1% comes from. If true, it means
>that Ada is widely used, since this is 1% of an absolutely HUGE
>market (1% is much higher than you think, once you have
>subtracted out the really popular languages like COBOL and
>Visual Basic, the latter accounting for the lion's share of
>all software development).

I'm curious as to the source of your assertion regarding Visual Basic.
For one look at "per language" programmer demand, see
www.lmarkets.com, which seems to show both C++ and Java considerably
ahead of VB (of course this is programmer demand, not programmer body
count).  Perhaps someone should lobby the site maintainer to include
Ada on the chart, even if it is a low scorer today - perhaps a
positive trend will start at some point.

>In fact I suspect the figure is below 1%, but again, we are
>talking percentages of a huge market, so even a sliver of this
>can be highly significant. After all what percentage of the
>over all automobile market does Ferrari have or Rolls Royce,
>yet we still consider these technologies significant :-)
>
>Certainly we all know lots of examples of successful commercial
>use of Ada.

True.

>There seems to be a general tendency to write off technologies
>that do not dominate the market. I can't tell you how many
>people I meet who think OS/2 is dead, when in fact it is being
>very successful in many contexts (and has exceeded sales
>expectations every quarter for the last 5 or 6 quarters). Sure
>it does not have the market share of Windows, but this again is
>a huge market, and OS/2 has a significant share.

Yes, I think this is a quite unfortunate effect of the amount of
information the average programmer intellect can absorb over time.
Personally, I decided to pursue other languages years ago when Ada
compilers were all really expensive, and its use appeared to be
declining even in the DoD.  Now, with free compilers available, an OO
programming model available (Ada95), and an upcoming RT control
application in my future, Ada is looking very interesting all of a
sudden.  ;-)

>A similar situation exists with Ada. Of course it is not
>numerically as successful as C++ for example, but that really
>does not mean much. If you need the most reliable and best
>technology around, you do not take a poll to see what is the
>most commonly used technology!

Again true, but I can't help but think that wider adoption would be a
very good thing for the language.  Many projects may have gone with
other technologies simply based on the available Ada talent pool.

I've been involved with Java for a while, and it appears to me that
with suitable library support Ada could be a great alternative for (at
least) server side programming.  (IIRC there is an Ada=>JVM solution,
but I don't know much about it.)

There's a lot of discussion on the Java advocacy newsgroup about the
desirability (or lack thereof;) of generics, operator overloading and
so on.  From what I can tell, Ada provides good implementations of
these things as opposed to C++.  Also, the scientific community has
shown significant interest in a modified Java for numerical
programming (www.javagrande.org), that also seems potentially a
fertile ground for Ada advocacy.  Heck, Ada is even an ISO standard...
;-)

Looking at Ada95, it seems to me to be close to a "sweet spot" in
terms of features, efficiency, language safety, and
performance...perhaps its time for an Ada renaissance!

Terry
--
tsikes@netcom.com

Re: Ada

[Hyman Rosen]

tsikes@netcom.com (Terry Sikes) writes:
> There's a lot of discussion on the Java advocacy newsgroup about the
> desirability (or lack thereof;) of generics, operator overloading and
> so on.  From what I can tell, Ada provides good implementations of
> these things as opposed to C++.

C++ provides excellent implementation of generics,
and good implementation of overloading, except that
one cannot overload on return type as in Ada.

Is there something specific you believe you can not
do in C++ with regard to these abilities?

Re: Ada

[Richard D Riehle]

In article <t7aemmtz3b.fsf@calumny.jyacc.com>,
	Hyman Rosen <hymie@prolifics.com> wrote:

>C++ provides excellent implementation of generics,
>and good implementation of overloading, except that
>one cannot overload on return type as in Ada.
>
>Is there something specific you believe you can not
>do in C++ with regard to these abilities?

There are some differences in Ada and C++. The issue is not
"can not do" but rather how it is done and whether the Ada
way is any improvement.   Also, it is never a matter of
whether something can or cannot be done in a particular 
language.  Rather, the issue is whether a given language
is more expressive of a desired capability.  In many ways,
Ada is more expressive.  In other ways, C++ is more expressive.

Ada generics (templates)are always compiled before they are 
"included" by the client.  This is a function of the Ada library
model.  The instantiation is permitted only after the successful
compilation of the generic unit.  This puts type checking a little
closer to the origination of the generic.  

If I read the C++ literature correctly, C++ templates are expected
to be "full expansion" units.  Ada permits a template to be instantiated
in other forms to conserve memory. Some compilers support this.

Ada has more formats for generic formal parameters.  This has its
advantages and may sometimes have disadvantages.  The designer needs
to learn more idioms of the language.  Once having learned those idioms,
more options for template design are available.

Ada permits but does not require as much overloading of operators
as one needs in a C++.  This is useful when one is creating templates
for simple scalar and numeric types.  It does simplify the templates
for those types.  Actually, in this case, the Ada model is somewhat
an improvement over C++.  Of course, a C++ advocate may answer that
the word "class" may be used for a built-in type, but this still falls
short of the Ada model for range constraints and other rules of
scalar types.

Ada is more complicated when creating templates in which an entire
package is a generic formal parameter.  C++ is very straightfoward
in this regard.  The consequence is that this powerful feature of
Ada is often ignored by component designers.  In time, as Ada 
practitioners become more comfortable with its capabilities, we should
see more use of it.  Meanwhile, C++ seems much easier when one needs
one of more classes as generic formal parameters.

On the other hand, a generic formal package parameter provides the
equivalent of a namespace parameter, something I suspect cannot be
expressed easily in C++.  It also enables one to design reusable 
signatures for simplifying the parameter lists of application frameworks
components. Moreover, these signatures are subjected to all the 
checks of the compiler before they may ever be used.

Implementation of Ada generics can take advantage of child
library units, including private child library units to create,
as private child package specifications, a whole subsystem of reusable
package bodies.  This is not widely used, in practice, but has 
substantial power once it is understood by Ada component designers.

There are lots of other issues where Ada is more expressive of 
the component design problem.  I am sure others who frequent this
forum will note some of the more obvious ones I have overlooked.

Richard Riehle

Re: Ada

[Hyman Rosen]

Richard D Riehle <laoXhai@ix.netcom.com> writes:
> Ada generics (templates)are always compiled before they are 
> "included" by the client.  This is a function of the Ada library
> model.  The instantiation is permitted only after the successful
> compilation of the generic unit.  This puts type checking a little
> closer to the origination of the generic.  
> 
> If I read the C++ literature correctly, C++ templates are expected
> to be "full expansion" units.  Ada permits a template to be instantiated
> in other forms to conserve memory. Some compilers support this.

You have not read the literature correctly, or you have not read the
correct literature :-) C++ templates can be (according to the standard,
but not yet in reality) separately compiled, and many errors within the
template can be caught before instantiation. You are correct in that it
is unlikely that a C++ will offer anything but the full-expansion style
of template instantiation.

> Ada has more formats for generic formal parameters.  This has its
> advantages and may sometimes have disadvantages.  The designer needs
> to learn more idioms of the language.  Once having learned those idioms,
> more options for template design are available.

C++ has essentially *no* format for its generic formals, which are
types, templates, or constants. I think that allows C++ to achieve
the same things with its templates that Ada can.

> Ada permits but does not require as much overloading of operators
> as one needs in a C++.  This is useful when one is creating templates
> for simple scalar and numeric types.  It does simplify the templates
> for those types.  Actually, in this case, the Ada model is somewhat
> an improvement over C++.  Of course, a C++ advocate may answer that
> the word "class" may be used for a built-in type, but this still falls
> short of the Ada model for range constraints and other rules of
> scalar types.

Well, C++ doesn't have range constraints and subtypes (which is
too bad), so it can hardly overload on them. But it does have
enumerations, and those are fully overloadable. But C++ doesn't
have attributes, so one can't write a generic wrap-around successor
function, for example, so there, I've found an example for you :-)

> Ada is more complicated when creating templates in which an entire
> package is a generic formal parameter.  C++ is very straightfoward
> in this regard.  The consequence is that this powerful feature of
> Ada is often ignored by component designers.  In time, as Ada 
> practitioners become more comfortable with its capabilities, we should
> see more use of it.  Meanwhile, C++ seems much easier when one needs
> one of more classes as generic formal parameters.

I hold that a C++ class is more-or-less equivalent to an Ada package,
so a generic formal package in Ada would simply correspond to a generic
formal class in C++.

Re: Ada

[Richard D Riehle]

In article <t77lhpuc8o.fsf@calumny.jyacc.com>,
	Hyman Rosen <hymie@prolifics.com> wrote:

>Richard D Riehle <laoXhai@ix.netcom.com> writes:
>
>You have not read the literature correctly, or you have not read the
>correct literature :-) C++ templates can be (according to the standard,
>but not yet in reality) separately compiled, 

I guess it is not just my reading of the compiler publishers manuals
that prevent me from doing the same thing I can do in Ada.  Also, I
am not sure that, once this is implemented in C++, it will correspond
to the same level of error checking possible in Ada generics.  One
of the essential points in Ada is that error checking is not just a
function of type-safety.   Often overlooked is the extensive set of
rules on Scope and Visibility in Chapted 8 of the ALRM.  C++ does not
seem to be quite as comprehensive on this point.

Meanwhile, my C++ programs must correspond to what the compiler 
publishers allow rather than the theoretical permissions of the
standard.  

>> Ada has more formats for generic formal parameters.  This has its
>> advantages and may sometimes have disadvantages.  The designer needs
>> to learn more idioms of the language.  Once having learned those idioms,
>> more options for template design are available.
>
>C++ has essentially *no* format for its generic formals, which are
>types, templates, or constants. I think that allows C++ to achieve
>the same things with its templates that Ada can.

As mentioned in my earlier post, I agree that when using the word "can"
nearly every language _can_ accomplish whatever any other language _can_.
The issue, when comparing languages, should never be whether something
_can_ be expressed in this or that language.  Rather, the issue is how
easily that something can be expressed.  It is the difference between
expressibility (can express) and expressiveness (designed to express).  

A caution is in order.  An earlier critique of Ada in this forum 
suggested that Ada is not as _intuitive_ as C++.  The author of that
criticism confused the notion of _intuitive_ with the notion of
_superficial_.  Expressive does not necessarily mean _intuitive_. 
Also, I do not mean to imply that you, Hyman, are superficial.  It
is clear that you think carefully and deeply about these issues.
There are many programming constructs for which COBOL is more
expressive, others for which Smalltalk is more expressive, and some
for which Ada is not as expressive as C++ or Eiffel.  We simply have
not yet achieved perfection in the design of programming languages.
However, as you noted in you post, Ada does have some advantages of
expressiveness, as does C++.  I continue to prefer the Ada approach,
even though I am currently spending more time coding C++ than I would
want. 

>I hold that a C++ class is more-or-less equivalent to an Ada package,
>so a generic formal package in Ada would simply correspond to a generic
>formal class in C++.

I will agree with this.  I suspect that, if templates had been designed
into C++ from the beginning, they might be a little better than they
are.  I find the Ada generic slightly more expressive, for my taste,
than the C++ template.  Fortunately, not all of us on this planet are
identical so there is room for more than one viewpoint on this subject.

Richard Riehle
 

Re: Ada

[Robert A Duff]

Hyman Rosen <hymie@prolifics.com> writes:

> You have not read the literature correctly, or you have not read the
> correct literature :-) C++ templates can be (according to the standard,
> but not yet in reality) separately compiled, and many errors within the
> template can be caught before instantiation. You are correct in that it
> is unlikely that a C++ will offer anything but the full-expansion style
> of template instantiation.

The C++ standard allows templates to be separately compiled.
And the Ada standard allows garbage collection.
And the C standard allows array-bounds checking.
;-)

- Bob

Re: Ada

[Terry Sikes]

In article <t7aemmtz3b.fsf@calumny.jyacc.com>,
Hyman Rosen  <hymie@prolifics.com> wrote:
>tsikes@netcom.com (Terry Sikes) writes:

>> There's a lot of discussion on the Java advocacy newsgroup about the
>> desirability (or lack thereof;) of generics, operator overloading and
>> so on.  From what I can tell, Ada provides good implementations of
>> these things as opposed to C++.
>
>C++ provides excellent implementation of generics,
>and good implementation of overloading, except that
>one cannot overload on return type as in Ada.

I've perused the other responses to this so I won't touch on some
points raised by others.  In working fairly extensively with C++
generics (mainly STL, VC 6.0) I've come to the conclusion that at this
time they are still totally pushing the envelope for the compiler
writers.  In my current project, for instance, fairly simple things
like map<int, string> generate identifiers in excess of 255
characters, which the compiler warns about truncating.  There is a
pragma to disable this warning for the current file, but often this
warning occurs in system headers, which I'm reluctant to modify.  ;-)
I also find it troublesome that such simple cases introduce possible
software defects, which I'm being warned about, with no way of fixing
the problem other than abandoning generics.

Further the error messages generated for template errors are quite
bad.  In one case I tested an iterator using "<" rather than "!=" and
was greeted with a cascade of seemingly unrelated messages.  Careful
code inspection was the only way to find the problem.

Finally, I find the syntax of C++ templates rather illegible, but
perhaps that's just me.

>Is there something specific you believe you can not
>do in C++ with regard to these abilities?

Its not so much a matter of "can not do" as "can not do quickly", "can
not identify the error" and/or "can not read later".  ;-)

On the latter point, between operator overloading and templates, it is
quite easy to (unintentionally) generate very obtuse C++.

One thing I'd like to see in both languages is the ability to use a
set of non-reserved Unicode symbols for operator overloading, to
disambiguate with the normal operator symbols.

Terry
--
tsikes@netcom.com

Re: Ada

[Robert Dewar]

In article <t7aemmtz3b.fsf@calumny.jyacc.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:

> C++ provides excellent implementation of generics,

The trouble with templates is that there is no equivalent of
the generic contract model, and also it is very difficult to
implement generic sharing of code. These are both issues
which the Ada model regards as essential, so certainly
by Ada standards, the above statement is controversial.


> and good implementation of overloading

OUCH! The rules for overloading in C++ are fiersomely complex,
far more so than in Ada, due to the interaction with implicit
conversions (something that Ada avoids), and the consequent
need for complex preference rules. In my experience, almost
no C++ programmers can tell you what the rules are, and many
people run into trouble with these rules.

> except that
> one cannot overload on return type as in Ada.

A pretty big gap! It means for example that if you have
multiple implementations of sets, that you cannot have
a parameterless function Empty that returns the (appropriate)
empty set.

> Is there something specific you believe you can not
> do in C++ with regard to these abilities?

Yes, see the above, in particular, to summarize:

1. Share generic code at the object level
2. Be sure your template is correct *before* you use it
3. Understand the overloading rules
4. Overload on return type


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[Hyman Rosen]

Robert Dewar <robert_dewar@my-deja.com> writes:
> A pretty big gap! It means for example that if you have
> multiple implementations of sets, that you cannot have
> a parameterless function Empty that returns the (appropriate)
> empty set.

Incorrect as far as equivalent behavior is concerned,
as the following program demonstrates.

enum SetType { A, B, C };
template <SetType T> struct Set
{
	static Set Empty() { return Set(); }
};
struct EmptySet
{
	template <SetType T> operator Set<T>() { return Set<T>::Empty(); }
};
void f(Set<A>) { }
void g(Set<B>) { }
int main()
{
	f(EmptySet());
	g(EmptySet());
}

Re: Ada

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> A pretty big gap! 

Yes.

>...It means for example that if you have
> multiple implementations of sets, that you cannot have
> a parameterless function Empty that returns the (appropriate)
> empty set.

Even worse, it means that literals can't be overloaded.  Of course, C++
doesn't even *have* enumeration literals of different enumeration types,
anyway.  And for numeric literals, the C++ rule requires that each
literal be marked with a character that indicates its type, which is a
kludge (and certainly wouldn't work in Ada with tits capability of
having many numeric types).

- Bob

Re: Ada

[Hyman Rosen]

Robert A Duff <bobduff@world.std.com> writes:
> Even worse, it means that literals can't be overloaded.  Of course, C++
> doesn't even *have* enumeration literals of different enumeration types,
> anyway.

It certainly does. The problematic part is that enumeration literals
are entered into the scope in which the enumeration type is declared,
because of backward compatibility with C. As a result, one normally
declares enumerated types inside a class or namespace, so that literals
won't conflict.

If you really need enumerator literal overloading, you can play the
same game as for empty sets, on a case-by-case basis:

struct Direction { enum E { Left, Right, Up, Down }; };
struct Politics  { enum E { Left, Center, Right }; };

static struct
{
	operator Direction::E() { return Direction::Left; }
	operator Politics ::E() { return Politics ::Left; }
} Left;

static struct
{
	operator Direction::E() { return Direction::Right; }
	operator Politics ::E() { return Politics ::Right; }
} Right;

void f(Direction::E) { }
void g(Politics ::E) { }

int main()
{
	f(Left);
	f(Right);
	g(Left);
	g(Right);
}

Re: Ada

[Florian Weimer]

Hyman Rosen <hymie@prolifics.com> writes:

[Ada generics vs. C++ templates]

> Is there something specific you believe you can not
> do in C++ with regard to these abilities?

I can't imagine anything which can't be done with C++ templates which
you can do using Ada generics.  (The opposite case is different, though,
because of Ada's strong typing.)  However, there are some shortcomings
of C++ templates (at least that's my impression):

You won't get reasonable error messages.  For example, try instantiating
a STL container with a reference type; most compilers will give you
several kilobytes of error messages.  The situation gets worse if you
nest templates more deeply.

Writing reusable templates in C++ is hard, because you have to be very
careful not to use operations on the parametric types which aren't
available in general.  These restrictions are not enforced by the
compiler unless you provide suitable instantiations.

Re: Ada

[Hyman Rosen]

Florian Weimer <usenet@deneb.cygnus.argh.org> writes:
> You won't get reasonable error messages.  For example, try instantiating
> a STL container with a reference type; most compilers will give you
> several kilobytes of error messages.  The situation gets worse if you
> nest templates more deeply.

This is a quality-of-implementation issue. I think vendors are
concentrating first on compiling correct code. One hopes that
in the future, error messages will get better.

> Writing reusable templates in C++ is hard, because you have to be very
> careful not to use operations on the parametric types which aren't
> available in general.  These restrictions are not enforced by the
> compiler unless you provide suitable instantiations.

"If the type will fit, you must acquit" :-) The C++ template model
allows legal instantiations to compile, without specifying
restrictions on the types in advance, only through the operations
performed on the objects of the type. This requires attention in
writing the template if you want to minimize the number of things
required of the type, but that's fine.

Re: Ada

[Brian Rogoff]

On 4 Jan 2000, Florian Weimer wrote:
> Hyman Rosen <hymie@prolifics.com> writes:
> 
> [Ada generics vs. C++ templates]
> 
> > Is there something specific you believe you can not
> > do in C++ with regard to these abilities?
> 
> I can't imagine anything which can't be done with C++ templates which
> you can do using Ada generics. 

In some theoretical sense, yes, since you can express computations with 
C++ templates they can do just about anything. C++ type checking is also 
undecidable thanks to this. 

In the world of the practical programmer, Ada allows subprograms as
generic parameters and since Ada has nesting you can use them to 
clumsily simulate many uses of downward closures. C++ forces you to use 
classes and overload "()", and that is IMO *way* more clumsy than the 
Ada workaround. 

Others have discussed strong typing and separate compilation, so I'll
leave those points alone. What I like most about Ada is the confidence 
I have that a small compiled program is close to correct in my experience.

I like some aspects of the C++ template systems ability to automatically 
instantiate, and would love to see an Ada-like language with this ability. 
I suspect that this might also not have a decidable type system. 

-- Brian

Re: Ada

[Robert Dewar]

In article <84rd2f$snm$1@nntp3.atl.mindspring.net>,
  tsikes@netcom.com (Terry Sikes) wrote:
> For one look at "per language" programmer demand, see
> www.lmarkets.com, which seems to show both C++ and Java
considerably
> ahead of VB (of course this is programmer demand, not
programmer body
> count).


Nope, this is does not reflect programmer demand. It simply
reflects the number of jobs that are being offered in this
particular forum. Even if it did reflect programmer demand,
that would say nothing about the supply (ads tend to reflect
the surplus of demand over supply, which has nothing to do
with total market).

There are many sources for this information. One for example,
was a keynote address from Bill Gates at a big conference
(perhaps Comdex?) last year. There he also stated that Delphi
was at 5%, and Java at 9% (he said he did not really believe
the Java figure, that it probably reflected a lot of
experimentation, and given the failure of Java to get a
real foothold in client side programming that sounds right
to me. This same talk put Visual basic at about 50% of
PC development, and that also sounds about right to me,
with C/C++ being about 15%.

Ada did not get mentioned, but even if it was at what
(for me) would seem a very high level of 1% of all PC
development, it would have been under Bill's radar screen :-)

To get a feel for the Visual Basic market, have a look at the
catalogs of Active-X (now COM) components. Yes, these components
can be used in Visual C++ (and for that matter in Ada programs
written with GNAT :-) but the primary use of these components
is in the visual basic world.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[Terry Sikes]

In article <84sudm$33s$1@nnrp1.deja.com>,
Robert Dewar  <robert_dewar@my-deja.com> wrote:
>In article <84rd2f$snm$1@nntp3.atl.mindspring.net>,
>  tsikes@netcom.com (Terry Sikes) wrote:
>> For one look at "per language" programmer demand, see
>> www.lmarkets.com, which seems to show both C++ and Java
>considerably
>> ahead of VB (of course this is programmer demand, not
>programmer body
>> count).
>
>Nope, this is does not reflect programmer demand. It simply
>reflects the number of jobs that are being offered in this
>particular forum. Even if it did reflect programmer demand,
>that would say nothing about the supply (ads tend to reflect
>the surplus of demand over supply, which has nothing to do
>with total market).

You're right about the site reflecting surplus of demand over supply.
However, I find it hard to understand how the demand for VB
programmers is being filled, given that VB programming isn't in the
curriculum of most universities (also I know a couple of VB
consultants who're making good money, which doesn't indicate excessive
supply).

I'm going to contact Ted Shieh for more details about his methodology,
I thought there was more on the site, but couldn't find it.

>There are many sources for this information. One for example,
>was a keynote address from Bill Gates at a big conference
>(perhaps Comdex?) last year. There he also stated that Delphi
>was at 5%, and Java at 9% (he said he did not really believe
>the Java figure, that it probably reflected a lot of
>experimentation, and given the failure of Java to get a
>real foothold in client side programming that sounds right
>to me. This same talk put Visual basic at about 50% of
>PC development, and that also sounds about right to me,
>with C/C++ being about 15%.

50% of Windows (not PC) development, even if true, ignores major
market segments:

o  embedded systems
o  Unix/mainframe server-side  (this has picked up recently;)
o  Mac
o  Linux

I think you're underestimating the amount of C/C++ even on the Windows
side, also.  Bill has some level of vested interest in promoting VB,
after all.

>Ada did not get mentioned, but even if it was at what
>(for me) would seem a very high level of 1% of all PC
>development, it would have been under Bill's radar screen :-)

Probably.

>To get a feel for the Visual Basic market, have a look at the
>catalogs of Active-X (now COM) components. Yes, these components
>can be used in Visual C++ (and for that matter in Ada programs
>written with GNAT :-) but the primary use of these components
>is in the visual basic world.

As you say, they are compiler-neutral.  I think that the Windows
component marketplace has been VBs biggest success...  :-)   Linux
would benefit from a similar feature - or if Java ever gets efficient
enough, Java Beans are an alternative.

Terry
--
tsikes@netcom.com

Re: Ada

[Robert Dewar]

In article <84tj1p$r2g$1@nntp3.atl.mindspring.net>,
  tsikes@netcom.com (Terry Sikes) wrote:

> o  embedded systems

This is a very small sliver of the total development market

> o  Unix/mainframe server-side  (this has picked up recently;)

Still a small player development wise compared to PC's

> o  Mac

This is a VERY small fraction of the total PC development
effort.

> o  Linux

Getting larger, but still dwarfed by PC's

> I think you're underestimating the amount of C/C++ even on the
> Windows side, also.

Most university trained people *over* estimate the amount of
C and C++, precisely because they don't know the widely
used languages (COBOL and Visual Basic).


> Bill has some level of vested interest in promoting VB,
> after all.

Well I don't think he cares too much if people use VB or
visual C++. What is interesting about his figures is the
Delphi and Java figures, which he *does* care about :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada

[Terry Sikes]

In article <84uk54$6jl$1@nnrp1.deja.com>,
Robert Dewar  <robert_dewar@my-deja.com> wrote:
>In article <84tj1p$r2g$1@nntp3.atl.mindspring.net>,
>  tsikes@netcom.com (Terry Sikes) wrote:
>
>> o  embedded systems
>
>This is a very small sliver of the total development market

I'd be interested in knowing how "small" - there are a ton of
products with embedded microprocessors.

>> o  Unix/mainframe server-side  (this has picked up recently;)
>
>Still a small player development wise compared to PC's

Really?  You think the total number of development dollars spent on
server-side software is "small" compared to client side?  Even with
the Internet taking off?

>> o  Mac
>
>This is a VERY small fraction of the total PC development
>effort.

Macs are sitting at around 5% market share right now, and I'd guess
more development is done on them, percentage-wise, than is done on
Windows.

>> o  Linux
>
>Getting larger, but still dwarfed by PC's

Well, Linux installs are hard to measure, but I'd heard a figure of
10,000,000+ over a year ago.  The thing is though, that a very high
percentage of Linux boxes are development boxes.

>> I think you're underestimating the amount of C/C++ even on the
>> Windows side, also.
>
>Most university trained people *over* estimate the amount of
>C and C++, precisely because they don't know the widely
>used languages (COBOL and Visual Basic).

Although there are some, I think you'll find the numbers of PC COBOL
programmers to be quite small...  ;-)

As to VB, I agree its widely used...but I still think that C/C++
account for more than 15% of Windows development dollars.

>> Bill has some level of vested interest in promoting VB,
>> after all.
>
>Well I don't think he cares too much if people use VB or
>visual C++. What is interesting about his figures is the
>Delphi and Java figures, which he *does* care about :-)

C'mon, Bill has a soft spot for BASIC.  ;-)

Delphi has its good points, but just think if it had been implemented
in Ada95 instead of Object Pascal...

At any rate, its fairly pointless to discuss language marketshare
without better figures - anyone have any?

Terry
--
tsikes@netcom.com

Re: Ada

[Al Christians]

Terry Sikes wrote:
> 
> >This same talk put Visual basic at about 50% of
> >PC development, and that also sounds about right to me,
> >with C/C++ being about 15%.
> 
> 50% of Windows (not PC) development, even if true, ignores major
> market segments:
> 

In one of Capers Jones's books, he mentions many millions of workers
whose job description is not 'software developer' who spend some part 
of their work week developing software anyway.  VB might have a very 
large market share among that group of informal developers.    

Should the developers of Ada language products address the needs of 
that group?


Al

Re: Ada

[Terry Sikes]

In article <3874CB8B.2613A67F@easystreet.com>,
Al Christians  <achrist@easystreet.com> wrote:
>Terry Sikes wrote:

>> 50% of Windows (not PC) development, even if true, ignores major
>> market segments:
>
>In one of Capers Jones's books, he mentions many millions of workers
>whose job description is not 'software developer' who spend some part 
>of their work week developing software anyway.  VB might have a very 
>large market share among that group of informal developers.    
>
>Should the developers of Ada language products address the needs of 
>that group?

Right, I personally wouldn't count someone who writes some Excel
(VBScript) macros for an accounting spreadsheet as a "software
developer".  I think VBScript isn't too bad for that level of
development, and that something (even 1/2;) as complex as Ada would
drive those users away.

At any rate, its pretty academic since probably 90%+ of those folk are
using MS Office, and its unlikely the scripting language there will
change anytime soon...  (I wonder what the equivalent is for Star
Office...?)

I'd guess there's a large group of self-taught web developers as well,
that might be a more fertile ground for Unix/Linux based tools.

Terry
--
tsikes@netcom.com

Re: Ada

[Robert Dewar]

In article <3874CB8B.2613A67F@easystreet.com>,
  Al Christians <achrist@easystreet.com> wrote:
> Should the developers of Ada language products address the
> needs of that group?

One way to do this is to make sure that Ada is a first class
citizen when it comes to the COM interface, so it can play in
the same playground as VB. We have worked hard in the case of
GNAT to make GNAT fully compatible with COM/DCOM, and you can
do some VERY neat things with GNAT in this arena. I am sure
David Botton will be happy to elaborate :-)

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.

Ada

[Andy Glew]

> > If you can get C and Unix for free why do you need Ada and Ada-OS?

Just for my own knowledge: does GNU Ada (GNATS) support a full
Ada-OS, including the real-time and multithreading constructs like
rendezvous?  Do these run on stock hardware? On LINUX?

I have often thought that one of the big barriers to Ada's acceptance
was the multithreading and real time control - or, at least the perception
that they were required.

If the OS constructs had been optional, Ada would be a quite nice
language to program in. Variant records, if nothing else... explicit control
over memory layout, etc.

Re: Ada

[Marin D. Condic]

Andy Glew wrote:
> 
> > > If you can get C and Unix for free why do you need Ada and Ada-OS?
> 
> Just for my own knowledge: does GNU Ada (GNATS) support a full
> Ada-OS, including the real-time and multithreading constructs like
> rendezvous?  Do these run on stock hardware? On LINUX?
> 
There are others on this group who can provide much more detailed and
authoritative answere, but the short form is this: Yes, GNAT supports
Ada's tasking features and does a pretty good job of it. On a platform
that has an OS of its own, (WindowsNT, Flavors of Unix, etc.) GNAT maps
to operating system primitives to support tasks. On a bare machine, you
need to provide a RTOS such as RTEMS to provide the tasking primitives.

This is generally the case for all modern implementations of Ada, so
tasking is widely available. It works quite well, provided that the
application implementors understand tasks and know when they should or
should not be used.

BTW: I don't see how this could be perceived as a handicap to Ada. It
provides a facility most other languages do not, yet if your application
has no need of it, there is no real penalty. How do you see it as a
barrier to using Ada?

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Ada

[Andy Glew]

> BTW: I don't see how this could be perceived as a handicap to Ada. It
> provides a facility most other languages do not, yet if your application
> has no need of it, there is no real penalty. How do you see it as a
> barrier to using Ada?

(1) It was a barrier to ports.

(2) A long as there is absolutely no real penalty.

Re: Ada

[Marin D. Condic]

Andy Glew wrote:
> 
> > BTW: I don't see how this could be perceived as a handicap to Ada. It
> > provides a facility most other languages do not, yet if your application
> > has no need of it, there is no real penalty. How do you see it as a
> > barrier to using Ada?
> 
> (1) It was a barrier to ports.
> 
> (2) A long as there is absolutely no real penalty.

O.K., I can see #1 to a point. Ports to small microprocessors still
don't exist in any real numbers and some of this may be due to perceived
difficulties in getting tasking to work there.

#2 has the conditional: "It Depends" attached to it. Certainly for
compilers that target a capable OS with tasking primitives should not
exhibit any penalties for tasking when it is not used, since it is the
OS that holds all (most) of the code. For embedded targets where you
have to supply some sort of RTK, the question becomes "how good is the
compiler/linker at removing dead code?" Many modern linkers are pretty
good at eliminating subroutines that are never called. And of course, it
still comes down to the specific implementation. A poor quality compiler
for any language is going to create penalties and WRT Ada, there are
more opportunities to do so than in less sophisticated language.
However, there isn't anything inherent in the language design which
makes it impossible to generate efficient, tight code. There are many
Ada compilers which do so.

The trick is to do a good evaluation of the compilers available for the
application at hand and see what sort of code generation you really get.
Some are overall better than others. Each does some things well and
other things poorly. You always want to build some sample code similar
to the intended application and see what you get with a specific
compiler. This is true for any language.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Ada

[Chris Morgan]

"Andy Glew" <glew@cs.wisc.edu> writes:

> > BTW: I don't see how this could be perceived as a handicap to Ada. It
> > provides a facility most other languages do not, yet if your application
> > has no need of it, there is no real penalty. How do you see it as a
> > barrier to using Ada?
> 
> (1) It was a barrier to ports.
> 
> (2) A long as there is absolutely no real penalty.

There is a setup of GNAT called GNORT (GNAT with absolutely No
RunTime). No penalty there.
-- 
Chris Morgan <cm at mihalis.net>                  http://mihalis.net

Re: Ada

[Chris Morgan]

"Andy Glew" <glew@cs.wisc.edu> writes:

> > > If you can get C and Unix for free why do you need Ada and Ada-OS?
> 
> Just for my own knowledge: does GNU Ada (GNATS) support a full
> Ada-OS, including the real-time and multithreading constructs like
> rendezvous?  Do these run on stock hardware? On LINUX?

Full (i.e. strict) compliance with Ada semantics needs root privilege
on some OSs (e.g. Solaris last time I checked) so that your threads
can get true pre-emptive multi-threading (e.g. by running in the
real-time rather than time-sharing scheduling priority
class). Otherwise (again on Solaris, last time I checked) there are
things like threads going to the back of their queue after being
pre-empted by a higher priority thread, which is incorrect for true
pre-emption (it looks to the thread like it got preempted by a
"sibling"). On the other hand you can even chose user-space or kernel
threads. There is some advanced work on this stuff going on at FSU
e.g. to make user-space threads more useful by letting another thread
work when one blocks on I/O.

Additionally the GNAT compiler has lots of other goodies. Check out
www.gnat.com and www.gnuada.org for some nice starting points. Markus
Kuhn at Cambridge has implemented a candidate Serpent (some crypto
scheme) implementation in Ada, don't know how it did.

The above is probably garbled (long day) hope it give you some idea.

Chris
-- 
Chris Morgan <cm at mihalis.net>                  http://mihalis.net

Ada

[mcf501]

I was just wondering if it is possible to change the colour of a string
in ada 95?

Re: Ada

[Larry Kilgallen]

In article <1106770009.493447.308200@c13g2000cwb.googlegroups.com>, mcf501@york.ac.uk writes:
> I was just wondering if it is possible to change the colour of a string
> in ada 95?

Ada strings have no attribute called "color".

If you mean to change the color in which a string is displayed,
that depends on your operating system and display hardware.  On
an older terminal, for instance, the only two color choices are
Black and White.

Re: Ada

[Stephen Leake]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <1106770009.493447.308200@c13g2000cwb.googlegroups.com>, mcf501@york.ac.uk writes:
> > I was just wondering if it is possible to change the colour of a string
> > in ada 95?
> 
> Ada strings have no attribute called "color".
> 
> If you mean to change the color in which a string is displayed,
> that depends on your operating system and display hardware.  On
> an older terminal, for instance, the only two color choices are
> Black and White.

Or Black and Green. Or Orange, on my first home computer. That was a
fun little Apple II clone; I wrote my first Pascal on that machine.
That was fun, too :).

-- 
-- Stephe

Re: Ada

[Frank J. Lhota]

<mcf501@york.ac.uk> wrote in message 
news:1106770009.493447.308200@c13g2000cwb.googlegroups.com...
>I was just wondering if it is possible to change the colour of a string
> in ada 95?

If by string you mean an array of characters, then no, you cannot change its 
colour, if for no other reason than the fact that an array of characters 
does not have a colour component.

Most likely, you meant "How can I change the color of text displayed on a 
Window?". To answer the question, we would need to know the OS. It's really 
more of an OS issue than a language issue.

Re: Ada

[Stephen Leake]

"Frank J. Lhota" <NOSPAM.Lhota.adarose@verizon.net> writes:

> <mcf501@york.ac.uk> wrote in message 
> news:1106770009.493447.308200@c13g2000cwb.googlegroups.com...
> >I was just wondering if it is possible to change the colour of a string
> > in ada 95?
> 
> Most likely, you meant "How can I change the color of text displayed on a 
> Window?". To answer the question, we would need to know the OS. It's really 
> more of an OS issue than a language issue.

more precisely, it's a GUI library/display issue. VMS and Unix don't
care what display you are using; X Windows, Gtk, Qt do. Only on
Windows is the GUI tightly tied to the OS, and that is changing as Gtk
and X Windows become easier to use on Windows.

Best thread in a while :).

-- 
-- Stephe

Re: Ada

[Ludovic Brenta]

> I was just wondering if it is possible to change the colour of a string
> in ada 95?

It reminds me of an old joke, "what colour do you want your database?"

:)

-- 
Ludovic Brenta.

Re: Ada

[Stephen Leake]

mcf501@york.ac.uk writes:

> I was just wondering if it is possible to change the colour of a string
> in ada 95?

This is just too tempting :).

<bogus comments>

I edit Ada 95 code with Emacs, which provides colorization of strings
(among other things). The variable that sets the color of these
strings is font-lock-string-face.

Here is the definition of font-lock-string-face:

(defface font-lock-string-face
  '((((type tty) (class color)) (:foreground "green"))
    (((class grayscale) (background light)) (:foreground "DimGray" :italic t))
    (((class grayscale) (background dark)) (:foreground "LightGray" :italic t))
    (((class color) (background light)) (:foreground "RosyBrown"))
    (((class color) (background dark)) (:foreground "LightSalmon"))
    (t (:italic t)))
  "Font Lock mode face used to highlight strings."
  :group 'font-lock-highlighting-faces)


So, to change the color of a string in Ada 95, I would change one of
the colors listed above.

</bogus comments>

That was fun :).

I assume you are really asking about the color of a string displayed
in a particular graphical user interface. You'll have to tell us which
GUI toolkit you are using, on which operating system, to get anything
like a helpful answer.

-- 
-- Stephe

Re: Ada

[Jeffrey Carter]

mcf501@york.ac.uk wrote:

> I was just wondering if it is possible to change the colour of a string
> in ada 95?

Can you change the color in some other language? If so, then you can 
change it in Ada.

-- 
Jeff Carter
"We use a large, vibrating egg."
Annie Hall
44

Re: Ada

[Larry Kilgallen]

In article <WNWJd.7145$r27.4742@newsread1.news.pas.earthlink.net>, Jeffrey Carter <spam@spam.com> writes:

> Can you change the color in some other language?

Only if the color wants to change :-)

Re: Ada

[u_int32_t]

On Wed, 26 Jan 2005 19:17:34 -0600, Larry Kilgallen wrote:

> In article <WNWJd.7145$r27.4742@newsread1.news.pas.earthlink.net>,
> Jeffrey Carter <spam@spam.com> writes:
> 
>> Can you change the color in some other language?
> 
> Only if the color wants to change :-)

I've heard that even if the colour wants to change, the system sometimes
doesn't want it to change and it shows a blue screen to protest

Re: Ada

[Larry Kilgallen]

In article <pan.2005.01.27.04.43.28.350331@aol.com>, u_int32_t <u_int32_t@aol.com> writes:
> On Wed, 26 Jan 2005 19:17:34 -0600, Larry Kilgallen wrote:
> 
>> In article <WNWJd.7145$r27.4742@newsread1.news.pas.earthlink.net>,
>> Jeffrey Carter <spam@spam.com> writes:
>> 
>>> Can you change the color in some other language?
>> 
>> Only if the color wants to change :-)
> 
> I've heard that even if the colour wants to change, the system sometimes
> doesn't want it to change and it shows a blue screen to protest

	1. If anyone notices the screen going blue, it was other than
	   blue before, no matter how briefly.

	2. Therefore the color changed !

Re: Ada

[Björn Lundin]

torsdag 27 januari 2005 05:43 skrev u_int32_t:
> On Wed, 26 Jan 2005 19:17:34 -0600, Larry Kilgallen wrote:
> > In article <WNWJd.7145$r27.4742@newsread1.news.pas.earthlink.net>,
> >
> > Jeffrey Carter <spam@spam.com> writes:
> >> Can you change the color in some other language?
> >
> > Only if the color wants to change :-)
>
> I've heard that even if the colour wants to change, the system sometimes
> doesn't want it to change and it shows a blue screen to protest

Then let's hope that the OP wanted to change the string to the color blue :)
/Björn

> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada-france.org
> http://www.ada-france.org/mailman/listinfo/comp.lang.ada

Re: Ada

[Frank Piron]

Am 26 Jan 2005 12:06:49 -0800 schrieb <mcf501@york.ac.uk>:

> I was just wondering if it is possible to change the colour of a string
> in ada 95?
>
If you want coloured text output without GUI then
you may use ANSI sequences on UNIX/Linux and e.g. this
http://users.ncrvnet.nl/gmvdijk/packages.html#CONSOLE
package (Jerry van Dijk) for win32.
-- 
Frank Piron,
defrankatkonaddot
(leftrotate two)

Re: Ada

[Larry Kilgallen]

In article <opsk84dswem0et4w@news.online.de>, Frank Piron <empty@zero.nil> writes:
> Am 26 Jan 2005 12:06:49 -0800 schrieb <mcf501@york.ac.uk>:
> 
>> I was just wondering if it is possible to change the colour of a string
>> in ada 95?
>>
> If you want coloured text output without GUI then
> you may use ANSI sequences on UNIX/Linux

ANSI sequences are related to the terminal or terminal emulator,
independent of the operating system.  They work fine on VMS also.

Re: Ada

[Frank Piron]

Am 27 Jan 2005 04:53:25 -0600 schrieb Larry Kilgallen 
<Kilgallen@SpamCop.net>:

> In article <opsk84dswem0et4w@news.online.de>, Frank Piron 
> <empty@zero.nil> writes:
>> Am 26 Jan 2005 12:06:49 -0800 schrieb <mcf501@york.ac.uk>:
>>
>>> I was just wondering if it is possible to change the colour of a string
>>> in ada 95?
>>>
>> If you want coloured text output without GUI then
>> you may use ANSI sequences on UNIX/Linux
>
> ANSI sequences are related to the terminal or terminal emulator,
> independent of the operating system.  They work fine on VMS also.

Of course you are right.

-- 
Frank Piron,
defrankatkonaddot
(leftrotate two)

Re: Ada

[Adrien Plisson]

Larry Kilgallen wrote:
> ANSI sequences are related to the terminal or terminal emulator,
> independent of the operating system.  They work fine on VMS also.

they may also work in some particular situations under DOS/Windows.
you have to use command.com (not cmd.exe) with the ansi.sys driver 
loaded. refer to microsoft documentation for how to do this.

note: on recents versions of Windows (NT/2000/XP) it could be tricky 
to make it work...

-- 
rien

Re: Ada

[Stephen Leake]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <opsk84dswem0et4w@news.online.de>, Frank Piron <empty@zero.nil> writes:
> > Am 26 Jan 2005 12:06:49 -0800 schrieb <mcf501@york.ac.uk>:
> > 
> >> I was just wondering if it is possible to change the colour of a string
> >> in ada 95?
> >>
> > If you want coloured text output without GUI then
> > you may use ANSI sequences on UNIX/Linux
> 
> ANSI sequences are related to the terminal or terminal emulator,
> independent of the operating system.  They work fine on VMS also.

And just to be pedantic, any device that outputs (or reflects) photons
(that are visible to humans) is a "graphical user interface". We just
didn't know enough to call "terminals" "GUIs" back then.

:).

-- 
-- Stephe

Re: Ada

[Martin Krischik]

mcf501@york.ac.uk wrote:

> I was just wondering if it is possible to change the colour of a string
> in ada 95?

If your Colour Monitor, a Colour Graphic-Card and a TUI or GUI installed
which supports Colour then: Yes.

Alternative: you have a Colour Printer attached. That would work as well.

If you want more help you have to specify your question in more detail.

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com