ted@grebyn.com (Ted Holden) (05/20/91)
From: jls@netcom.COM (Jim Showalter)
Subject: Re: Socioeconomics, Ada, C++
Message-ID: <1991May18.194618.10112@netcom.COM>
Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest}
References: <SRCTRAN.91May6233619@world.std.com> <ENAG.91May12230018@maud.ifi.uio.no> <1991May18.022831.20653@grebyn.com>
Date: Sat, 18 May 1991 19:46:18 GMT
>Ah, Ted's back. For those of you who missed it, a few months ago he posted
>some nonsense about Ada and, after I pressed him on it, he admitted that
>he actually knows NOTHING about Ada--he has no experience using it, he has
>never read a text on it, etc. His opinions are based entirely on hearsay
>and gossip. But that doesn't keep him from parading his ignorance in a
>worldwide forum. So now he's back...
That's an utterly amazing interpretation of anything I might ever have
posted to any of the language groups, but coming from an Ada zealot, it
does not surprise me.
It is my policy to refrain from accusing other posters on usenet of
lying, since I have observed a number of people accusing anybody who
disagrees with them of lying, and since it is my impression that terms
such as "liar", "ignorance" etc. get too much use on usenet. I
therefore shall not comment on Showalter's claim of my having admitted to
never having read an Ada text, never having used Ada etc... other than
accuse the guy of lying, there's no other comment I'd know how to make.
My own personal experience with Ada involved
writing various Ada/C interfaces (to get functionality which didn't
exist with Ada). God knows what people in similar straits are going to
do when that option lapses. Beyond that, my experiences with Ada mostly
involve listening to horror stories from friends and compatriots
involved in large Ada projects. I've never heard so many people cry
so much over any one topic in my life.
>Anybody who doesn't want to use Ada has the freedom not to bid
>on any of the DoD's contracts. But do, please, stop WHINING about it.
I prefer to try to "whine" about it BEFORE any American soldiers get
killed on account of it.
>as for Mr. Holden's claim that "there are several FAR better answers out
>there in common usage, the most obvious of which is C++", this betrays
>is brute ignorance concerning Ada I warned you about at the start of
>his post.
That's twice Showalter has accused me of ignorance within just a few
paragraphs. I've had one article concerning the Ada/C++ question
published in the C++ Journal; apparently, they took some of what I had
to say seriously.
>>Reality dictates that DOD cannot afford to proceed with Ada any further
>>than it has. Aside from the multitude of unbelievable problems which
>>are involved with Ada itself,
>Note the cute rhetorical tactic: Mr. Holden raises the specter of Ada
>bogeymen but never actually commits to NAMING any of them. WHAT unbelievable
>problems?
How could I not answer that?
Surely no reasonable person could begrudge me the opportunity to reply
to such a direct question. The man (Showalter) quite obviously has never
seen any of the following and certainly deserves to.
I and a number of my associates, as well as a number of the most
prominent computer scientists of our age, most notably Charles Anthony
Richard Hoare, the inventor of the quick-sort process (Turing Award
Lecture, 1980), believe the Ada programming language to be not only a
major source of frustration and unnecessary cost to everybody involved
with it, but an actual threat to the security of the United States and
of any other nation which might become involved with it.
About a year ago, I put together a sort of a compendium on user reaction
to Ada which I still figure tells the whole story, or easily as much as
any rational person would ever need to know. Readers be the judge.
..........................................................................
..........................................................................
The Final Word on Ada
From: Nigel Tzeng, NASA
>Oh yes...on the other front...executable size...we are sometimes space limited
>on the size of the programs we can have in the on-board systems...how do the
>C vs ADA sizes compare?
>This information is important to know...otherwise we cannot make an intelligent
>decision on which language to use in the future. NASA is trying to figure out
>if they should adopt ADA as the single official language. Developers at NASA
>need to know the hard data in order to decide whether to support such a stand.
Good thinking. With enough work and most Ada features turned off, Ada speeds
for some tasks should approach those of C. This has little or nothing to do
with the BIG problems of Ada, which are philosophical/economic in nature
and not easily amenable to technical solution. Executable size is a
symptom of one such problem.
From: Jim Harkins, Scientific Atlanta, San Diego, CA
>(Bill Wolfe) writes:
>> There is a great need for a single production programming language
>> which supports good software and code engineering practices.
>Yep, and there is great need for a single type of automobile. Any idiot can
>see that not only is it extremely dangerous for a person to go from driving
>a Hyndai Excel to a Ford Aerostar, as a nation we are wasting an awful lot
>of time both in learning new skills and in designing automobiles that differ
>in several respects. I think a good compromise would be the Ford Escort...
This is a REAL good analogy, but I'm afraid Jim doesn't carry it far
enough, simply because he can't conceive of it actually happening.
Problem is, the Ada crew CAN. You have to put yourself in their
shoes; they want to control the two extremes of programming, embedded
systems and mainframe/database work, and everything in between and,
hence, they need every feature in the world in their CORE LANGUAGE.
Letting people make up their own libraries for applications (as per C/UNIX)
would be too much like a free system. Logical consequence:
From a recent comp.lang.ada posting.
"My only problem with Ada at this point is the cost ($ and hardware
resources) of a compiler for my XT clone. Both IntegrAda and Janus require
more memory than DOS 4.01 leaves available. This is BAD DESIGN. There
is no excuse for a 551K executable in a PC (pass 2 of Integrada). Janus
Ada requires > 580K available to run, and rumor has it that the Integrada
compiler is a repackaged Janus compiler."
Everybody begins to realize: "Hey!, looks like Ada's the only
thing I'm ever gonna have, so I'd better see to it that everything I
ever plan on doing is part of Ada...", and we get Ada-9x, the language
which will include all the great features that Ada left out. Kind of like
quick-sand or one of those old Chinese finger traps... the more you
struggle, the worse it gets.
The good news is that, given the speed at which these things happen,
Ada-9x is probably 10 years away. The bad news is two-fold: first,
Ada-9x will probably break all existing Ada code and, second, the clunk
factor will likely be so great (1,000,000+ bytes for "HELLO WORLD" might
actually be achieveable), that no more working Ada code will ever be written
afterwards. Total paralysis.
Several times recently, Ada affectionados have posted articles
concerning the national information clearinghouse for Ada-9x, including
the phone-modem number (301) 459-8939 for Ada-9x concerns. This BBS
contains 744 recent user comments on Ada in it's present state; true life
experiences of actual Ada sufferers. These are grouped in bunches of 50
in self-extracting zip files (e.g. 101-150.exe) and may be downloaded.
For instance:
complaint #0300
PROBLEM:
Currently, to create and mature an Ada compiler, it takes from
3..5 years. For the new architectures of the future and rapid
compiler development, the language needs to be expressed in terms
that are easy to parse and to generate code.
The definition should be revamped so that the grammar in Ada to
conform to LR(m,n) for consistent/complete parsing rules -- the
most efficient and accurate compiler techniques. Move more
semantics to the grammar specification to rid the language
definition of so many special cases.
The solution proposed, unless I'm missing something, would break nearly
all existing Ada code, hence it isn't likely to happen. Doesn't say
much for the basic design of Ada either, does it?
Add the time to finish the 9x standard and the 2 - 3 year time between
first-compiler <--> compiler-which-anybody-can-stand-to-use, and you get
my ten year figure for 9x. Sort of; there may never actually be a 9x
compiler which anybody can stand to use.
Here's the rub: a casual reading of the 744 little "problems" would
lead one to believe that 1 out of every ten or so was a show-stopper, and
that nine of ten are just people whining for new features. This would
be a misinterpretation. In fact, it's probably all of those new
features which are the big serious problem, given past history. The ten
year problem, however, says that anybody figuring to use Ada starting
now had best get used to the more minor problems (the 1 out of 10).
These include:
complaint #0237
We cannot adequately configure large systems as the language now
stands. There are no standard means of performing the kind of
operations on library units generally considered desirable. These
include:
- creating a new variant or version of a compilation unit;
- mixed language working, particularly the use of Ada units by
other languages;
- access control, visibility of units to other programmers;
- change control and the general history of the system.
The inability to do these things arises out of a few loosely worded
paragraphs in the LRM (in 10.1 and 10.4), which imply the existence
of a single Ada program library, whose state is updated solely by
the compiler. This can be an inconvenient foundation on which to
build. The relationships between compilations in a project will be
determined by the problem and the organization of work, and any
automatic enforcement of a configuration control regime must come
from a locally chosen PSE. Ada especially, as a language with large
and diverse application, must have a separate compilation system
which gives the greatest freedom possible in this area.
IMPORTANCE:
ESSENTIAL
Ada was intended for use in large projects, involving many people,
possibly at different centers. These are precisely the projects
which will collapse if the programming support technology is
inadequate.
That is, Ada can't realistically be used for large systems.
complaint #0150
Due to the availability of virtual memory, most minicomputer
and mainframe programmers rarely consider the size of main memory
as a limiting factor when creating their programs. In contrast,
th size of main memory is a major concern of microcomputer
programmers. The most widely used microcomputer operating
systems, MS-DOS, does not have virtual memory capabilities.
Without the availability of special programming techniques to get
around this limitation, microcomputer programmers would have to
severely limit the functionality of their programs, and, it would
be impossible to create large, integrated information systems for
microcomputers. One of most widely used of these programming
techniques is the "chaining" capability provided in many
programming languages. "Chaining" gives a programmer the ability
to break down large integrated information systems into separate
executable programs, and, then, when the system is operated, swap
these programs in and out of main memory as the need arises.
"Chaining", in effect, simulates virtual memory. Ada does not
have the capability to chain programs. As a result,
microcomputer programmers who use Ada must severely limit the
functionality of their programs.
Importance (1-10)
1 - Microcomputer programmers who use Ada will have to
continue limiting the functionality of their programs.
Current Workarounds
Programmers must either limit the functionality of their Ada
programs or use a proprietary CHAIN command supplied by the
compiler manufacturer - which hurts portability.
I.e., Ada can't be used for small systems... klunk factor's too high.
Consider the one feature which might come remotely close to justifying
this giant klunk factor: object-oriented capabilities.
complaint #0599
PROBLEM:
Inheritance has become one of the standard attributes of
modern object-oriented programming languages (such as C++
and Smalltalk-80). Unfortunately, Ada is quite deficient in
its support for inheritance ( it is based primarily on
derived types, and then not particularly well), and this is
a valid criticism leveled at the language by critics (and C
bigots who, if forced to learn a new language, simply prefer
to learn C++). There are currently many proposals to add
full-blown inheritance (and other standard object-oriented
attributes, such as polymorphism) to Ada; the scope of this
revision request is much more modest, intended only to make
the derived type mechanisms that already exist work better.
IMPORTANCE: ESSENTIAL
If the lack of modern object-oriented attributes is not
addressed in Ada 9X, Ada will almost certainly become the
FORTRAN of the '90's.
CURRENT WORKAROUNDS:
Be thankful for what limited object-oriented support is
offered by the current language.
Consider Ada's original primary mandate: embedded systems:
complaint #0021
PROBLEM:
A high priority task may be suspended because it needs to rendezvous with
a low priority task. That low priority task does not get scheduled
promptly because of its priority. However this causes the high priority
task to be suspended also.
IMPORTANCE: (7)
This problem makes the use of task priorities extremely difficult to apply
correctly in a large system. It limits the ability to use task priorities
to improve throughput in a system.
complaint #0072
PROBLEM:
The Ada priority system has proved quite inadequate for the
needs of certain classes of hard realtime embedded systems.
These are applications where a high degree of responsiveness
is required.
For example, there is a major conflict between the fifo
mechanism prescribed for the entry queue and the need for the
highest priority task to proceed wherever possible.
complaint #0084
problem
Ada tasking involves too much run-time overhead for some high-performance
applications, including many embedded systems applications for which the
language was designed. This overhead not only slows down the program in
general, but may also occur at unpredictable times, thus delaying response at
critical times. To avoid the overhead, real-time programmers frequently
circumvent Ada tasking.
The problem is exacerbated by Ada's lack of support for those who do try to use
tasking in an efficient manner. There is no standard set of guidelines to
programmers for writing optimizable tasking code, or to language implementors,
for deciding which optimizations to perform. Also, there is no simple way for a
programmer who is concerned with writing portable high-performance code to
check that optimizations applied under one implementation will be applied under
different implementations.
The consequences of Ada tasking overhead have not gone unnoticed in higher
circles of government. A recent General Accounting Office report [1] noted that
Ada has limitations in real-time applications that require fast processing
speed, compact computer programs, and accurate timing control. All three of
these requirements are directly and adversely affected by Ada's current
tasking overhead.
complaint #0278
PROBLEM:
In the last 5 years, tomes have been written on the Ada tasking
model. It is too complex and has too much overhead for embedded
systems to utilize effectively. It also does not fit well with
architectures found in embedded systems, e.g., multiprogramming/
distributed processing. The control mechanisms are not
responsive to realtime needs. Applications programs are
responsible for housekeeping on context switches where the
process will not return to the previously selected context. The
model does not support the well-known basic scheduling
disciplines, e.g., preempt or nonpreempt and resume or nonresume,
see Conway's Theory of Scheduling. The problems with tasking
efficiency is not the maturity of the compilers, but in the
underlying model defined in the language and the validation
requirements for the compilers.
importance: very high, one of the major goals for the Ada 9x
current workarounds: Programming standards to avoid tasking or
only initiate a single task and to not use rendezvous of any kind
as they are too unpredictable and require too much overhead.
Allow the ACVC not to test this section so that the application
does not have to absorb a runtime system from a compiler vendor
that has little experience with the applications.
Or, write in a language like Modula-2 or object oriented C++ that
does not interfere in the target architecture.
i.e. Ada can't really be used for embedded systems, its original mandate.
People unfortunate enough to HAVE to use Ada for imbedded systems are
spending ten hours working around Ada and one hour trying to solve their
problem. The problem is that someday, somewhere along the line, one of
our pilots might have to actually fly something programmed like this against
something which has been programmed using real software tools.
How about something simple like string handling?
complaint #0163
Problem:
Strings are inadequate in Ada. It is very frequently the case that
the length of a string is not known until it is formed...after it
has been declared. This leads to ugly, clumsy constructions (blank
pad everything, keep track of length separately, play tricks with
DECLARE's and constant strings, etc.). The obvious solution of
writing a variable-length string package (see LRM, section 7.6) is
unsatisfactory: you are lead to a limited private type because
neither the standard equality test nor assignment are appropriate.
(you want the both to ignore everything beyond the actual length of
the strings) For limited private types, however, you have no
assignment statement at all. We implemented such a package and
found that using a procedure (SET) for assignment was error-prone
and hard-to-read. This even for experienced programmers and even
after getting beyond the initial learning curve for the package.
How about something REAL SIMPLE, like argc/argv?
complaint #355
PROBLEM:
It is difficult, in a standard manner, to get at the operating
system command line arguments supplied when the program is invoked.
IMPORTANCE:
(Scale of 1 - 10, with 10 being most important):
<<8>>
CURRENT WORKAROUNDS:
Look up in vendor-specific manuals the method of accessing the
command line parameters and access them differently on different
operating systems.
What about writing an OS in Ada (so that real "software engineers" won't have
to screw around with UNIX anymore)?
complaint #0186
It is difficult, if not impossible, to use Ada to write an operating
system. For example, a multiprocessor naval command and control
system might need basic software, comparable in complexity to a
minicomputer network operating system, to support fault tolerance,
load sharing, change of system operating mode etc. It is highly
desirable that such important software be written in Ada, and be
portable, i.e. be quite independent of the compiler supplier's Ada
run time system. Currently, it would be very difficult to do this
in Ada, because of the difficulty of manipulating tasks of arbitrary
type and parentage.
IMPORTANCE: 7.
CURRENT WORKAROUNDS:
Use operating systems written in C or assembler.
Write the operating system as an extension of the Ada run time
system - this is undesirable because it is non-portable and
unvalidated.
At a recent question and answer session for vendors involving a Navy
RFP for a project for which a POSIX compliant OS written in Ada was to
be required, the vendors informed the contract officer that the R would
draw no Ps with that requirement. This was in one of the Govt. computer
tabloids.
What about basic portability?
complaint #0365
Problem:
Implementation Options Lead to Non-Portability and
Non-Reusability.
Discussion: The LRM allows many implementation
options and this freedom has lead to numerous
"dialects" of Ada. As programs are written to rely on
the characteristics of a given implementation,
non-portable Ada code results. Often, the programmer
is not even aware that the code is non-portable,
because implementation differences amy even exist for
the predefined language features. Further, it is
sometimes not impossible to compile an Ada program with
two different implementations of the same vendor's
compiler.
Another kind of non-portability is that of the programmer's
skills, The user interfaces to Ada compilers have become so
varied that programmers find it very difficult to move from
one Ada implementation to another, Not only does the
command line syntax vary, but so do program library
structures, library sharability between users, compiler
capabilities, capacity limits. etc.
Importance: ESSENTIAL
Current Workarounds:
Significant amounts of code rewriting, recompilation, and
testing must be done to get a given Ada program to compile
and to run successfully using another compiler, if at all
possible, even on the same host-target configuration. It
is very difficult to write a truly portable Ada program.
Another possible solution to porting an Ada program is for
a customer to carefully choose a compiler to suit the given
Ada program, or perhaps collaborate with a vendor to tailor
the compiler to suit these needs.
Significant amounts of programmer retraining must occur
when a different Ada compiler is used.
...................................................................
Quite aside from all of the above grief, a recent post to usenet
mentioned the fact that the Ada LRM quote regarding tasking reads
something like <...it shall not be the case that a lower priority task
shall be running and a higher priority task not...>, and that a totally
legit interpretation of this would involve simply running the higher
priority task to completion (or trying to) and then worrying about the
lower priority task. The fun would start when you tried to port an
application from that system to a "normal" one, whatever that might be
in the case of Ada. This is the Laurel and Hardy school of "software
engineering": powerful evidence that Strustrup and others who figure
tasking belongs in an OS and not in a language are correct.
Ted Holden
HTE
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/20/91)
In article <1991May20.015647.4051@grebyn.com>, ted@grebyn.com (Ted Holden) writes: > I and a number of my associates, as well as a number of the most > prominent computer scientists of our age, most notably Charles Anthony > Richard Hoare, the inventor of the quick-sort process (Turing Award > Lecture, 1980), believe the Ada programming language to be not only a > major source of frustration and unnecessary cost to everybody involved > with it, but an actual threat to the security of the United States and > of any other nation which might become involved with it. > About a year ago, I put together a sort of a compendium on user reaction > to Ada which I still figure tells the whole story, or easily as much as > any rational person would ever need to know. Readers be the judge. I am not an Ada bigot, and I think the horror stories Ted Holden posted are illuminating and worrying. However, I'd like to make a few comments: (1) Ted Holden drags in C.A.R.Hoare ("innocence by association"). However, many of Hoare's criticisms of Ada apply with equal or greater force to C++. I for one would be extremely interested to learn what Hoare _now_ thinks of Ada in comparison with C++. (2) I myself used to think that Ada was far too complex to use in good conscience, until I read the Annotated C++ Reference Manual, and learned what "complex" really meant. (3) Things like generics and exceptions are there in the C++ ARM, but they can't yet be used in portable programs, because most C++ compilers (including cfront) don't support them and the standard may change them. On comp.std.c++ they are still arguing about whether something like 'packages' needs to be added to C++ and if so what they should look like. The language keeps changing. I strongly suspect that once there is a standard for C++ we will have no shortage of similar horror stories concerning C++. -- There is no such thing as a balanced ecology; ecosystems are chaotic.
jls@netcom.COM (Jim Showalter) (05/20/91)
>My own personal experience with Ada involved >writing various Ada/C interfaces (to get functionality which didn't >exist with Ada). More precisely, "to get functionality not available in either the Ada or C language definitions, but available via access to standard libraries". Of course, with this precision your statement loses its sting, don't you agree? >God knows what people in similar straits are going to >do when that option lapses. Not only is this option not going to "lapse", the Ada 9x language revision process is considering even more flexible and well-defined interface capabilities to other languages. For a language to actually define the method for interface to other languages is really quite rare: do you know of any similar features in C to accomodate a call to, say, a FORTRAN routine?--remember, your answer has to be a LANGUAGE feature, not some vendor-specific portable linker extension. >Beyond that, my experiences with Ada mostly >involve listening to horror stories from friends and compatriots >involved in large Ada projects. I've never heard so many people cry >so much over any one topic in my life. You need to qualify this in order for it to have much content. Were they complaining about Ada, the available tools, the problems inherent in any large project, or what? When were they doing this complaining?--if it was more than 5 years ago it is almost certainly all moot by now: the tools are industrial strength now, excellent books and training courses are available, key mappings (e.g. Ada/OO, Ada/2167A, Ada/SQL) have been established, there are considerably more talented Ada practitioners available now than there were, etc. Furthermore, it has been my experience that Ada winds up being the whipping boy on a lot of projects because it serves to underscore the wretched state of software engineering practice on so many projects. For example, because it is strongly and statically type-checked, constant change to package specs leads to incessant rebuilds of the system. It is easy to blame this on Ada, when in fact what is being highlighted is the need for a better architecture with a more stable set of interface definitions: clearly a software engineering problem, not a language problem. Besides, you act like there haven't been any horror stories in other languages, and yet here I have a large stockpile of them for C, C++, and Pascal. >>Anybody who doesn't want to use Ada has the freedom not to bid >>on any of the DoD's contracts. But do, please, stop WHINING about it. > >I prefer to try to "whine" about it BEFORE any American soldiers get >killed on account of it. Could you tell me, please, how a language with strong typing, direct support for abstraction, automatic constraint checking, built-in exception handling, a stable and international language definition, compiler validation, and some of the most powerful development tools in the world would be dangerous to American (and NATO, by the way) soldiers, particularly in comparison to C, which is weakly typed, performs no constraint checking, has no built-in error handling mechanism, and encourages bit-fiddling and address arithmetic? Ada is so well suited to life-critical problems with hard real-time constraints that it is the language of choice for the FAA's rewrite/upgrade of all air traffic control software in the U.S., and for the Space Station. It is also the language of choice in a number of process control applications (including nuclear power plants). It has consistently been chosen for applications where a mistake could be fatal...I guess when people's lives are on the line untyped pointer hacking seems a bit too risque. >>as for Mr. Holden's claim that "there are several FAR better answers out >>there in common usage, the most obvious of which is C++", this betrays >>is brute ignorance concerning Ada I warned you about at the start of >>his post. > >That's twice Showalter has accused me of ignorance within just a few >paragraphs. I've had one article concerning the Ada/C++ question >published in the C++ Journal; apparently, they took some of what I had >to say seriously. Yeah, and I published a scathing rebuttal of that article. I wasn't shocked that you wrote it, but I WAS shocked that they stooped to printing it. Apparently it is not a refereed journal. For those who were spared his article, Ted basically betrayed the same ignorance (there, I said it again!) of the facts he continues to display to this day. He quoted hearsay and gossip pulled from BBS's, he ignored all evidence supporting Ada (including success stories such as STANFINS-R), he indicated a complete lack of understanding of the challenges of large complex projects, and he ignored a number of significant issues related to the adoption of C++ by a development organization (e.g. tool maturity, lack of trained personnel, etc--basically the same things people complained about ten years ago with Ada). >>>Reality dictates that DOD cannot afford to proceed with Ada any further >>>than it has. Aside from the multitude of unbelievable problems which >>>are involved with Ada itself, > >>Note the cute rhetorical tactic: Mr. Holden raises the specter of Ada >>bogeymen but never actually commits to NAMING any of them. WHAT unbelievable >>problems? > >How could I not answer that? >Surely no reasonable person could begrudge me the opportunity to reply >to such a direct question. The man (Showalter) quite obviously has never >seen any of the following and certainly deserves to. >About a year ago, I put together a sort of a compendium on user reaction >to Ada which I still figure tells the whole story, or easily as much as >any rational person would ever need to know. Readers be the judge. > >.......................................................................... >.......................................................................... > > The Final Word on Ada > > > > From: Nigel Tzeng, NASA > >>Oh yes...on the other front...executable size...we are sometimes space limited >>on the size of the programs we can have in the on-board systems...how do the >>C vs ADA sizes compare? > >>This information is important to know...otherwise we cannot make an intelligent >>decision on which language to use in the future. NASA is trying to figure out >>if they should adopt ADA as the single official language. Developers at NASA >>need to know the hard data in order to decide whether to support such a stand. > >Good thinking. With enough work and most Ada features turned off, Ada speeds >for some tasks should approach those of C. This has little or nothing to do >with the BIG problems of Ada, which are philosophical/economic in nature >and not easily amenable to technical solution. Executable size is a >symptom of one such problem. Uh, Ted? Your ignorance and zealotry are showing again. Those Ada features you want to turn off are little things like constraint checking, which are kind of important if you don't want to walk off the end of an array and start writing data where program should be, thereby causing your satellite to spiral slowly into the sun. You can certainly disable the checks, thereby making your Ada code a little more dangerous and, hence, a little more like C--but this is probably not a very bright idea in most cases. Damning something for running slower because it is running safer reminds me of the joke that ends "I could get the answer faster too, if I didn't have to be right". I'll sacrifice a little speed to keep from erroneous execution. I realize this may be an alien concept to a dyed-in-the-wool hacker, but even Hoare agrees that safety is important, so work with me, okay? Incidentally, your misinformation notwithstanding, NASA decided on Ada for the Space Station. >From: Jim Harkins, Scientific Atlanta, San Diego, CA > >>(Bill Wolfe) writes: >>> There is a great need for a single production programming language >>> which supports good software and code engineering practices. > >>Yep, and there is great need for a single type of automobile. Any idiot can >>see that not only is it extremely dangerous for a person to go from driving >>a Hyndai Excel to a Ford Aerostar, as a nation we are wasting an awful lot >>of time both in learning new skills and in designing automobiles that differ >>in several respects. I think a good compromise would be the Ford Escort... > >This is a REAL good analogy, but I'm afraid Jim doesn't carry it far >enough, simply because he can't conceive of it actually happening. >Problem is, the Ada crew CAN. You have to put yourself in their >shoes; they want to control the two extremes of programming, embedded >systems and mainframe/database work, and everything in between and, >hence, they need every feature in the world in their CORE LANGUAGE. >Letting people make up their own libraries for applications (as per C/UNIX) >would be too much like a free system. Letting people make up their own libraries for 40 years--with attendant loss of portability across applications--was part of the motivation for creating Ada in the first place. Whenever someone tells me they write in C/UNIX, the first question I ask is "Which one?". But more importantly, the claim that Ada is a big language is largely unfounded. Ada has two complex features not available in other languages, generics and tasking, but these are extremely powerful features with no clean workaround in other languages (generics by code copying and tasking by operating system calls leave a lot to be desired). Leaving aside generics and tasking, the remainder of the language is not really all that much more complex than Modula-2: basically a superset of Pascal with separation of specification and implementation, namespace control, and a better type model. Ada has about the same number of keywords and control structures as C++. True, the reference manual for the language is big, but that is because it is a precise definition of the language, something absent from most languages. >Logical consequence: > >From a recent comp.lang.ada posting. > "My only problem with Ada at this point is the cost ($ and hardware > resources) of a compiler for my XT clone. Both IntegrAda and Janus require > more memory than DOS 4.01 leaves available. This is BAD DESIGN. There > is no excuse for a 551K executable in a PC (pass 2 of Integrada). Janus > Ada requires > 580K available to run, and rumor has it that the Integrada > compiler is a repackaged Janus compiler." This is a tools issue, not a language issue. If tool immaturity is sufficient reason to damn a language, then can I expect you to be fair and damn C++ as well? >Everybody begins to realize: "Hey!, looks like Ada's the only >thing I'm ever gonna have, so I'd better see to it that everything I >ever plan on doing is part of Ada...", and we get Ada-9x, the language >which will include all the great features that Ada left out. Kind of like >quick-sand or one of those old Chinese finger traps... the more you >struggle, the worse it gets. You mean like C++ includes all the great features that C left out? Ted, would it be too much for me to at least insist on logical consistency and honesty in your arguments? So far you've attacked Ada for (obsolete) issues of tool maturity and for its planned evolution into the more complex language Ada 9x, and yet you fall strangely silent when those same issues could be just as equally applied to C++. Or are you just a bigot? >The good news is that, given the speed at which these things happen, >Ada-9x is probably 10 years away. The bad news is two-fold: first, >Ada-9x will probably break all existing Ada code Actually, upward compatibility is sort of a Holy Grail for the 9x folks. >and, second, the clunk >factor will likely be so great (1,000,000+ bytes for "HELLO WORLD" might >actually be achieveable), that no more working Ada code will ever be written >afterwards. Total paralysis. Ah. "Hello world." Funny you should mention that: I left a job at a large successful UNIX workstation vendor several years ago partly due to an argument over Ada and "Hello world". A developer dismissed Ada with a wave of his hand, saying "I don't want to take 20 minutes to write 'Hello world'.". I pointed out that 1) it didn't take 20 minutes to do that in Ada and 2) the issue wasn't small one line programs in the first place--the issue was large-scale software engineering on complex projects like, for example, maintaining and augmenting an operating system and attendant utilities, a process that was in a constant state of chaos using the existing methodology, tools, and language (whenever they succeeded in shipping a new build, it was more a testament to the power of the human will than to software engineering). Sadly (but not unexpectedly), the developer in question just didn't get it and went off to do another all-nighter in yet another battle to meet some deadline. I left for saner pastures. >Several times recently, Ada affectionados have posted articles >concerning the national information clearinghouse for Ada-9x, including >the phone-modem number (301) 459-8939 for Ada-9x concerns. This BBS >contains 744 recent user comments on Ada in it's present state; true life >experiences of actual Ada sufferers. These are grouped in bunches of 50 >in self-extracting zip files (e.g. 101-150.exe) and may be downloaded. >For instance: > >complaint #0300 > > > PROBLEM: > > Currently, to create and mature an Ada compiler, it takes from > 3..5 years. For the new architectures of the future and rapid > compiler development, the language needs to be expressed in terms > that are easy to parse and to generate code. > > The definition should be revamped so that the grammar in Ada to > conform to LR(m,n) for consistent/complete parsing rules -- the > most efficient and accurate compiler techniques. Move more > semantics to the grammar specification to rid the language > definition of so many special cases. > >The solution proposed, unless I'm missing something, would break nearly >all existing Ada code, hence it isn't likely to happen. You're missing something (why am I not surprised?). The removal of special cases should be largely upward-compatible, since all this means is that code that compiled previously under a more restrictive set of rules will compile now under a less restrictive set of rules. >anybody figuring to use Ada starting >now had best get used to the more minor problems (the 1 out of 10). >These include: > >complaint #0237 > > We cannot adequately configure large systems as the language now > stands. There are no standard means of performing the kind of > operations on library units generally considered desirable. These > include: > - creating a new variant or version of a compilation unit; > - mixed language working, particularly the use of Ada units by > other languages; > - access control, visibility of units to other programmers; > - change control and the general history of the system. > The inability to do these things arises out of a few loosely worded > paragraphs in the LRM (in 10.1 and 10.4), which imply the existence > of a single Ada program library, whose state is updated solely by > the compiler. This can be an inconvenient foundation on which to > build. The relationships between compilations in a project will be > determined by the problem and the organization of work, and any > automatic enforcement of a configuration control regime must come > from a locally chosen PSE. Ada especially, as a language with large > and diverse application, must have a separate compilation system > which gives the greatest freedom possible in this area. > > > IMPORTANCE: > > ESSENTIAL > > Ada was intended for use in large projects, involving many people, > possibly at different centers. These are precisely the projects > which will collapse if the programming support technology is > inadequate. Again, tools. You can buy a Rational Environment that solves all of the above problems, with no need to change the language at all. Sophisticated languages require sophisticated tools. This should not come as a surprise: C++ requires a browser to keep from going nuts locating classes, and yet C requires no such beast. Ada requires better support than is available from just an editor, batch compiler, and debugger. (Note: I no longer work for Rational and receive no money for plugging their stuff--their stuff is simply the best and deserves as much exposure as possible.) >That is, Ada can't realistically be used for large systems. Uh huh. You know, Ted--sometimes you say something so INCREDIBLY dumb I wonder if you're just pulling our collective leg. Ada has successfully been used on some of the largest and most complex software projects ever attempted, many of them over 1MSLOC in size. These succesful projects have ranged all over the spectrum of application domains, including MIS and AI. Or are you so completely ignorant of the facts that you truly believe that no projects have ever been successfully completed in Ada? >complaint #0150 > > Due to the availability of virtual memory, most minicomputer > and mainframe programmers rarely consider the size of main memory > as a limiting factor when creating their programs. In contrast, > th size of main memory is a major concern of microcomputer > programmers. The most widely used microcomputer operating > systems, MS-DOS, does not have virtual memory capabilities. > Without the availability of special programming techniques to get > around this limitation, microcomputer programmers would have to > severely limit the functionality of their programs, and, it would > be impossible to create large, integrated information systems for > microcomputers. One of most widely used of these programming > techniques is the "chaining" capability provided in many > programming languages. "Chaining" gives a programmer the ability > to break down large integrated information systems into separate > executable programs, and, then, when the system is operated, swap > these programs in and out of main memory as the need arises. > "Chaining", in effect, simulates virtual memory. Ada does not > have the capability to chain programs. As a result, > microcomputer programmers who use Ada must severely limit the > functionality of their programs. > > Importance (1-10) > > 1 - Microcomputer programmers who use Ada will have to > continue limiting the functionality of their programs. > Current Workarounds > > Programmers must either limit the functionality of their Ada > programs or use a proprietary CHAIN command supplied by the > compiler manufacturer - which hurts portability. > > >I.e., Ada can't be used for small systems... klunk factor's too high. Chaining is not defined as part of the C ANSI standard, to the best of my knowledge. Is it? If not, then any chaining that is done for C programs is not an inherent part of C, is probably ALSO a proprietary and non-portable vendor-specific directive, and is therefore no better or worse than the equivalent support offered for Ada on PCs. Isn't it fairly standard for PC compiler vendors to kludge in this capability in some way? Turbo Pascal, for example, offers a chaining capability, but that certainly isn't part of any Pascal standard I'm aware of. Again, a tools issue. >Consider the one feature which might come remotely close to justifying >this giant klunk factor: object-oriented capabilities. > >complaint #0599 > > > PROBLEM: > > Inheritance has become one of the standard attributes of > modern object-oriented programming languages (such as C++ > and Smalltalk-80). Unfortunately, Ada is quite deficient in > its support for inheritance ( it is based primarily on > derived types, and then not particularly well), and this is > a valid criticism leveled at the language by critics (and C > bigots who, if forced to learn a new language, simply prefer > to learn C++). There are currently many proposals to add > full-blown inheritance (and other standard object-oriented > attributes, such as polymorphism) to Ada; the scope of this > revision request is much more modest, intended only to make > the derived type mechanisms that already exist work better. > > IMPORTANCE: ESSENTIAL > > If the lack of modern object-oriented attributes is not > addressed in Ada 9X, Ada will almost certainly become the > FORTRAN of the '90's. > > CURRENT WORKAROUNDS: > > Be thankful for what limited object-oriented support is > offered by the current language. I've addressed the issue of the relative importance of inheritance (particularly as supported by C++) to software engineering elsewhere. Suffice it to say that I think it represents about 5% of the true value of C++ over C. The remaining 95% is in the realm of additional features I term "software engineering oriented", such as strong typing, specification/implementation separation, opaque types, exceptions, data abstraction, and genericity--features already present in Ada for a decade. To damn Ada for the lack of inheritance is fair only if I can similarly damn C++ for the lack of concurrency. Incidentally, I'd be quite happy if Ada became the FORTRAN of the 90's. Indeed, I'd be overjoyed, since FORTRAN is by all measures an extremely successful language, far more so than C and C++ combined. Of course, I'm REALLY hoping it will be the COBOL of the 90's, in which case it would constitute 70% of all the software in the world. >Consider Ada's original primary mandate: embedded systems: > > >complaint #0021 > > > PROBLEM: > > A high priority task may be suspended because it needs to rendezvous with > a low priority task. That low priority task does not get scheduled > promptly because of its priority. However this causes the high priority > task to be suspended also. > > IMPORTANCE: (7) > > This problem makes the use of task priorities extremely difficult to apply > correctly in a large system. It limits the ability to use task priorities > to improve throughput in a system. > > >complaint #0072 > > > > PROBLEM: > > The Ada priority system has proved quite inadequate for the > needs of certain classes of hard realtime embedded systems. > These are applications where a high degree of responsiveness > is required. > > For example, there is a major conflict between the fifo > mechanism prescribed for the entry queue and the need for the > highest priority task to proceed wherever possible. Yep, this is a known problem, and it will be fixed. Gee, they made a mistake the first time around. Guess the language is a failure. >complaint #0084 > > problem > > Ada tasking involves too much run-time overhead for some high-performance > applications, including many embedded systems applications for which the > language was designed. This overhead not only slows down the program in > general, but may also occur at unpredictable times, thus delaying response at > critical times. To avoid the overhead, real-time programmers frequently > circumvent Ada tasking. > > The problem is exacerbated by Ada's lack of support for those who do try to use > tasking in an efficient manner. There is no standard set of guidelines to > programmers for writing optimizable tasking code, or to language implementors, > for deciding which optimizations to perform. Also, there is no simple way for a > programmer who is concerned with writing portable high-performance code to > check that optimizations applied under one implementation will be applied under > different implementations. > > The consequences of Ada tasking overhead have not gone unnoticed in higher > circles of government. A recent General Accounting Office report [1] noted that > Ada has limitations in real-time applications that require fast processing > speed, compact computer programs, and accurate timing control. All three of > these requirements are directly and adversely affected by Ada's current > tasking overhead. > > >complaint #0278 > > > PROBLEM: > > In the last 5 years, tomes have been written on the Ada tasking > model. It is too complex and has too much overhead for embedded > systems to utilize effectively. It also does not fit well with > architectures found in embedded systems, e.g., multiprogramming/ > distributed processing. The control mechanisms are not > responsive to realtime needs. Applications programs are > responsible for housekeeping on context switches where the > process will not return to the previously selected context. The > model does not support the well-known basic scheduling > disciplines, e.g., preempt or nonpreempt and resume or nonresume, > see Conway's Theory of Scheduling. The problems with tasking > efficiency is not the maturity of the compilers, but in the > underlying model defined in the language and the validation > requirements for the compilers. > > importance: very high, one of the major goals for the Ada 9x > > current workarounds: Programming standards to avoid tasking or > only initiate a single task and to not use rendezvous of any kind > as they are too unpredictable and require too much overhead. > Allow the ACVC not to test this section so that the application > does not have to absorb a runtime system from a compiler vendor > that has little experience with the applications. > > Or, write in a language like Modula-2 or object oriented C++ that > does not interfere in the target architecture. > >i.e. Ada can't really be used for embedded systems, its original mandate. >People unfortunate enough to HAVE to use Ada for imbedded systems are >spending ten hours working around Ada and one hour trying to solve their >problem. The problem is that someday, somewhere along the line, one of >our pilots might have to actually fly something programmed like this against >something which has been programmed using real software tools. The complaints about tasking overhead and usability are largely unfounded. I know of many very successful projects with hard real-time constraints that have used tasking extensively and met all their performance goals (your claim that Ada "can't really be used for embedded systems" notwithstanding). Most complaints about tasking, on closer investigation, turn out to be due to lack of training and/or immature tools. The few issues that are real issues are being resolved. At least Ada provides a clear path toward such resolution, which is more than can be said for most languages. By the way, do you have any idea how insulting it is when you say something about Ada that implies it will kill soldiers? There are a lot of people committed to Ada precisely because they believe that it offers the BEST chance of AVOIDING such tragedies, and for you to mock them is rude and shocking in the extreme, particularly given your generally nonexistent grasp of the facts. One of the reasons I'm so adamant about Ada and so down on C is because I regard Ada as inherently safer than C, and I see that as a good thing. And I'm not alone. >How about something simple like string handling? > > >complaint #0163 > >Problem: > Strings are inadequate in Ada. It is very frequently the case that > the length of a string is not known until it is formed...after it > has been declared. This leads to ugly, clumsy constructions (blank > pad everything, keep track of length separately, play tricks with > DECLARE's and constant strings, etc.). The obvious solution of > writing a variable-length string package (see LRM, section 7.6) is > unsatisfactory: you are lead to a limited private type because > neither the standard equality test nor assignment are appropriate. > (you want the both to ignore everything beyond the actual length of > the strings) For limited private types, however, you have no > assignment statement at all. We implemented such a package and > found that using a procedure (SET) for assignment was error-prone > and hard-to-read. This even for experienced programmers and even > after getting beyond the initial learning curve for the package. > > >How about something REAL SIMPLE, like argc/argv? Which, being heap allocated, work just EVER so well in embedded systems with tight memory constraints, right? Ada doesn't support variable length strings for the same reason it doesn't support variable length arrays--memory usage in embedded systems has to be determinable at compile time to the maximum extent possible. Besides, the "tricks" with declare blocks and constant strings are actually quite simple idioms I recommend to anybody using strings in Ada. >complaint #355 > > > PROBLEM: > > It is difficult, in a standard manner, to get at the operating > system command line arguments supplied when the program is invoked. > > IMPORTANCE: > > (Scale of 1 - 10, with 10 being most important): > <<8>> > > CURRENT WORKAROUNDS: > > Look up in vendor-specific manuals the method of accessing the > command line parameters and access them differently on different > operating systems. > > >What about writing an OS in Ada (so that real "software engineers" won't have >to screw around with UNIX anymore)? Not a bad idea, actually--IBM didn't use Ada, but they DID rewrite UNIX from the ground up for their RS6000 because they deemed the existing implementation too erroneous to live with... But I digress. The real issue is that command line arguments are outside the language, just as they are in C. The only reason you THINK they're defined in C is that you're so used to arcg/argv that you don't realize that those are just conventions obeyed in UNIX. Write a C program on UNIX and try to port it to MS-DOS, and you'll see what I mean (unless the MS-DOS vender has been kind enough to already supply a workaround for you that acts like argv/argc). This complaint is silly and well outside the scope of the Ada language--if the complaint is that operating systems are not consistent across different platforms, I certainly agree that this is a problem, but what does that have to do with Ada? >complaint #0186 > > > It is difficult, if not impossible, to use Ada to write an operating > system. For example, a multiprocessor naval command and control > system might need basic software, comparable in complexity to a > minicomputer network operating system, to support fault tolerance, > load sharing, change of system operating mode etc. It is highly > desirable that such important software be written in Ada, and be > portable, i.e. be quite independent of the compiler supplier's Ada > run time system. Currently, it would be very difficult to do this > in Ada, because of the difficulty of manipulating tasks of arbitrary > type and parentage. > > IMPORTANCE: 7. > > > CURRENT WORKAROUNDS: > > Use operating systems written in C or assembler. > > Write the operating system as an extension of the Ada run time > system - this is undesirable because it is non-portable and > unvalidated. Well, Rational did it, so it must be possible. >At a recent question and answer session for vendors involving a Navy >RFP for a project for which a POSIX compliant OS written in Ada was to >be required, the vendors informed the contract officer that the R would >draw no Ps with that requirement. This was in one of the Govt. computer >tabloids. Oh, to have been in on the bidding in this case! >What about basic portability? > > >complaint #0365 > > > Problem: > Implementation Options Lead to Non-Portability and > Non-Reusability. > > Discussion: The LRM allows many implementation > options and this freedom has lead to numerous > "dialects" of Ada. As programs are written to rely on > the characteristics of a given implementation, > non-portable Ada code results. Often, the programmer > is not even aware that the code is non-portable, > because implementation differences amy even exist for > the predefined language features. Further, it is > sometimes not impossible to compile an Ada program with > two different implementations of the same vendor's > compiler. Ada is not a 100% solution to this particular issue, and there are certainly a few issues (such as implementation-defined attributes) being addressed by Ada 9x, but try to remember your objective here: to beat Ada in comparison to other languages, not to find fault wherever you can with Ada. If you just want to find fault with Ada, I can trump you each time by saying "Yes, but it's far far worse in <language of choice...I suggest C>." Try me: you claim that Ada is not 100% portable...I respond "Yes, but it's far far more portable than C". Your move. > Another kind of non-portability is that of the programmer's > skills, The user interfaces to Ada compilers have become so > varied that programmers find it very difficult to move from > one Ada implementation to another, Not only does the > command line syntax vary, but so do program library > structures, library sharability between users, compiler > capabilities, capacity limits. etc. > > Importance: ESSENTIAL > > Current Workarounds: > > Significant amounts of code rewriting, recompilation, and > testing must be done to get a given Ada program to compile > and to run successfully using another compiler, if at all > possible, even on the same host-target configuration. It > is very difficult to write a truly portable Ada program. > > Another possible solution to porting an Ada program is for > a customer to carefully choose a compiler to suit the given > Ada program, or perhaps collaborate with a vendor to tailor > the compiler to suit these needs. > > Significant amounts of programmer retraining must occur > when a different Ada compiler is used. > >................................................................... Tools tools tools. Again all outside the scope of the language. Are all C compilers the same across platforms? Are the C compilers from the same VENDOR even the same across platforms? Not in my experience, and even in those rare cases where compiler consistency is maintained, you've now stuck yourself with one vendor (the very thing objected to above). Do I think it would be nice if tools were the same from platform to platform? Yes--but what does that have to do with Ada? >Quite aside from all of the above grief, a recent post to usenet >mentioned the fact that the Ada LRM quote regarding tasking reads >something like <...it shall not be the case that a lower priority task >shall be running and a higher priority task not...>, and that a totally >legit interpretation of this would involve simply running the higher >priority task to completion (or trying to) and then worrying about the >lower priority task. The fun would start when you tried to port an >application from that system to a "normal" one, whatever that might be >in the case of Ada. This is the Laurel and Hardy school of "software >engineering": powerful evidence that Strustrup and others who figure >tasking belongs in an OS and not in a language are correct. Uh huh--WHICH OS? See, in all of your atacks on tasking you've been beating up on Ada for failing to be totally portable across platforms, and yet I don't for the life of me see how you'd achieve this if you were writing code in C that was dependent on operating system calls to achieve its concurrency. Say you write it on Sun UNIX. Now you want it to run on DEC UNIX. Can you just copy it over, compile it, and run it? Doubtful--if all UNIX's are the same, what's the point of POSIX? But the problem is even worse--what if you want it to run on an MS-DOS platform? Are UNIX and MS-DOS the same? Don't think so. So what do you do? You rewrite at least some of your code (and, given the state of software engineering practice when it comes to architecture, layers, subsystems, and interfaces, you probably rewrite a LOT of your code because you sprinkled UNIX dependencies throughout its closure instead of confining them to a single layer exporting a virtual machine). So, Ada may not be 100% portable when it comes to supporting concurrency, but it is considerably better at it than languages that must call the underlying operating system to achieve concurrency. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
jls@netcom.COM (Jim Showalter) (05/20/91)
>I strongly suspect that once there is a standard for C++ we will have >no shortage of similar horror stories concerning C++. Why wait? I've got horror stories NOW (I've also got success stories, but I have both for Ada, too, so what does that prove?). -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
enag@ifi.uio.no (Erik Naggum) (05/21/91)
Jim Showalter responds to Ted Holden:
Chaining is not defined as part of the C ANSI standard, to the
best of my knowledge. Is it? If not, then any chaining that is
done for C programs is not an inherent part of C, is probably ALSO
a proprietary and non-portable vendor-specific directive, and is
therefore no better or worse than the equivalent support offered
for Ada on PCs. Isn't it fairly standard for PC compiler vendors
to kludge in this capability in some way? Turbo Pascal, for
example, offers a chaining capability, but that certainly isn't
part of any Pascal standard I'm aware of.
Assuming that "chain" means that one program can start another in its
place, this is an operating system (dependent) facility. C is tied to
UNIX in this manner, and the library and system calls exist for this
purpose, among others. Look for the exec family of functions. Most
implementations of C have these functions.
POSIX addresses this issue. The Ada bindings is what you're looking
for.
By the way, do you have any idea how insulting it is when you say
something about Ada that implies it will kill soldiers?
I was tempted to comment on the previous remark, but find it more
appropriate now:
Programming languages don't kill people. People kill people.
(Sorry, couldn't resist.)
Are all C compilers the same across platforms? Are the C
compilers from the same VENDOR even the same across platforms?
If we're going to make comparisons, let's make them between ANSI C
X3.159-1989 and MIL-STD-1814A Ada, not between Microsoft C, Turbo C,
QuickC, etc, and MIL-STD-1814A Ada. The various toy C implementations
are not exactly known for consistency or adherence to standards.
Doubtful -- if all UNIX's are the same, what's the point of POSIX?
POSIX also pushes the state of the art.
Jim, this was, all in all, an excellent reply to Ted Holden. Thanks.
</Erik>
--
Erik Naggum Professional Programmer +47-2-836-863
Naggum Software Electronic Text <enag@ifi.uio.no>
0118 OSLO, NORWAY Computer Communications <erik@naggum.uu.no>khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (05/21/91)
In article <1991May20.015647.4051@grebyn.com> ted@grebyn.com (Ted Holden) writes: .... Currently, to create and mature an Ada compiler, it takes from 3..5 years. For the new architectures of the future and rapid compiler development, the language needs to be expressed in terms that are easy to parse and to generate code. The definition should be revamped so that the grammar in Ada to conform to LR(m,n) for consistent/complete parsing rules -- the most efficient and accurate compiler techniques. Move more semantics to the grammar specification to rid the language definition of so many special cases. This is a silly compliant. Very few people rewrite front ends for new machines. We typically have compilers (for all languages) structured along the following lines: front end | optimizer | code generator Sometimes it is more complex. the optimizer is nominally optional; or can be stuck in the front or back end. When moving to a new machine the code generator must be changed. For exotic machines perhaps the optimizer may need work. For truly deranged machines, you may need a new front end (to accomodate a totally new language). I am not an Ada fan, but I don't oppose it either. Why must we rant against all that we don't like, as if its continued existance is a plague sure to doom us all ? -- ---------------------------------------------------------------- Keith H. Bierman keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM SMI 2550 Garcia 12-33 | (415 336 2648) Mountain View, CA 94043
jls@netcom.COM (Jim Showalter) (05/21/91)
>If we're going to make comparisons, let's make them between ANSI C >X3.159-1989 and MIL-STD-1814A Ada, not between Microsoft C, Turbo C, >QuickC, etc, and MIL-STD-1814A Ada. The various toy C implementations >are not exactly known for consistency or adherence to standards. This lets C off the hook too easily. The point I was making here was that Ada is a standard and that Ada compilers are validated. I grant that ANSI C is a standard, but with no compiler validation, anyone can claim to sell an ANSI C compiler. Furthermore, with no "C mandate" in place, the "toy C" implementations you list above (e.g. Turbo C, Microsoft C) are quite popular (Borland sold 500,000 C => C++ upgrades last year). So you wind up with an industry speaking multiple dialects of C, using vendor-specific extensions, and generallyperpetuating the very sorts of problems Ada addresses. The irony of this is that the commercial sector in THEORY should be better at understanding the business downside to such chaos than the government, and yet it was the government that dreamed up Ada. I keep hoping at least a few technical managers in some forward-looking companies will wake up one day, realize how much money they're squandering on COBOL maintenance and C hacking, and convert. But I'm not holding my breath. >Jim, this was, all in all, an excellent reply to Ted Holden. Thanks. Thank you! It wasn't easy to keep from just foaming at the mouth and flaming. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
rharwood@east.pima.edu (05/25/91)
In article <1991May25.024120.8263@grebyn.com>, ted@grebyn.com (Ted Holden) writes: > My article in the C++ journal mentioned a few of these successes, for > instance the 1.25 M sloc AFATDS project which was declared a success because > only 10% of the code (123,600 sloc) had major language-related software > problems. Communism could be declared a success that way. This is about where I gave up wading through the 1016-line post (around line 500). I was working with Teledyne Brown Engineering at Fort Sill, OK when the AFATDS project was underway -- BACK IN 1985!!!! I think we all admit that the compilers were "dogs" back then... Anyone with a grain of Ada experience knows that TODAY's compilers are orders of magnitudes better than what was available 5 or 6 years ago.
ted@grebyn.com (Ted Holden) (05/25/91)
I've counted the word "ignorant/ignorance" at least four times in Showalter's reply to my recent large post. Before proceeding to debunk that reply, I'd like to express my opinion on the subject of vocabulary, Showalter's in particular. A late uncle of mine raised and sold birds; he had several thousand parakeets and a couple of hundred big birds on hand at any one time, some brighter, others not so bright. One of the later finally learned to talk at age five or six, after my uncle had totally given up on him. Friends had asked about that one at times and my uncle would reply "That's a retarded bird... he'll never talk...", and, sure enough, the bird's first words were "Wraaark! Retarded Bird, Retarded Bird...". Similarly, I have to assume that Showalter's fondness for the word "ignorance/ignorant" dates to some similar longterm childhood trauma, and has little or nothing to do with either myself, the Ada programming language, or comp.lang.ada. >From: Jim Showalter, Netcom >>My own personal experience with Ada involved >>writing various Ada/C interfaces (to get functionality which didn't >>exist with Ada). >More precisely, "to get functionality not available in either the >Ada or C language definitions, but available via access to standard >libraries". Of course, with this precision your statement loses its >sting, don't you agree? More precisely, the low-level data handling routines I was writing at the time had to meet three criteria: fast, small, and callable from various other software (Cobol, Informix 4-GL, Ada, and a couple of others), with roughly the same look from all points. Ada fails all three criteria. 0 For 3 is a strikeout in baseball... not much different here. >>God knows what people in similar straits are going to >>do when that option lapses. >Not only is this option not going to "lapse", the Ada 9x language >revision process is considering even more flexible and well-defined >interface capabilities to other languages. For a language to actually >define the method for interface to other languages is really quite >rare: do you know of any similar features in C to accomodate a call >to, say, a FORTRAN routine?--remember, your answer has to be a >LANGUAGE feature, not some vendor-specific portable linker extension. You're wrong on all counts and worse. The option lapses in June. Ada is supposed to be the last and only programming language in DOD. This means by definition, as the law states, that after this June, ALL DOD programming must be done in Ada, period. The interface you mention is not only an admission of failure (i.e. the language can't function unaided), but it guarantees unportable code since such multi-language efforts are guaranteed non-standard accross platforms. Finally, making such an interface a language feature is 180 degrees wrong, and symptomatic of everything else which is wrong with Ada. The Borland C++ interface to assembler is the best thought out example of such an interface I've seen yet, and I can't picture making such a thing a language feature. Borland wouldn't have been able to do it; the law from ten years ago would have prevented it. The minimalist aspects of C/C++ are precisely what make them the answer to today's problems. The following is from Hoare's famous article: "You include only those features which you know to be needed for EVERY single application of the language and which you know to be appropriate for EVERY single hardware configuration on which the language is to be implemented. Then, extensions can be specially designed where necessary for particular hardware devices and for particular applications. That is the great strength of Pascal, that there are so few unnecessary features, and almost no need for subsets. That is why the language is strong enough to support specialized extensions - Concurrent Pascal for real-time work, Pascal Plus for discrete event simulation, UCSD Pascal for microcomputer applications. If only we could learn the right lessons from our successes of the past, we would not need to learn from our failures." The whole import of Hoare's speech was that the basic underlying design philosophy of Ada was entirely wrong, and that this would guarantee multitudes of major-league troubles, as the user comments adequately document. Life does not offer us technological cures for philosophical problems. There is, for instance, no technological solution for somebody wishing to be a communist, a pervert, an Ada guru etc. Think of it this way; if I was a masochist like you are and wanted to link in the inline assembler libraries (as well as every other feature available in Borland C++) to every application I ever wrote, then all of my executables would be 600,000+ bytes just like yours are, they'd be slower than hell, just like yours are, they'd take me forever to develope, just like yours do... in short, I'd be using Ada, no matter that the package said C++, wouldn't I? If the law FORCED me to program like that, then I'd REALLY be hurting. >>Beyond that, my experiences with Ada mostly >>involve listening to horror stories from friends and compatriots >>involved in large Ada projects. I've never heard so many people cry >>so much over any one topic in my life. >You need to qualify this in order for it to have much content. Were >they complaining about Ada, the available tools, the problems inherent >in any large project, or what? The language. >When were they doing this complaining?--if >it was more than 5 years ago it is almost certainly all moot by now: No it isn't. The language is identically the same, guaranteed by law, and will remain so for some time. None of the problems detailed in my article have gone away, guaranteed by law. Problems with C, C++, Pascal, Smalltalk etc. do go away, guaranteed by the laws of the free market. >>>Anybody who doesn't want to use Ada has the freedom not to bid >>>on any of the DoD's contracts. But do, please, stop WHINING about it. >>I prefer to try to "whine" about it BEFORE any American soldiers get >>killed on account of it. >Could you tell me, please, how a language with strong typing, direct >support for abstraction, automatic constraint checking, built-in >exception handling, a stable and international language definition, >compiler validation, and some of the most powerful development tools >in the world would be dangerous to American (and NATO, by the way) >soldiers, particularly in comparison to C, which is weakly typed, >performs no constraint checking, has no built-in error handling mechanism, >and encourages bit-fiddling and address arithmetic? Every software project gets done with finite quantities of time, money, talent, psychic energy etc. Make a language or software development system but so slow, ponderous, clunky to use, and the software developed with that system is sooner or later going to suffer. When programmers spend four hours working around a language and one solving their problem, the end product suffers. When systems become concatenated and jerry-rigged because the law insists that a goof language be used, and programmers end up trying to stuff the goof language in in some harmless way and then branch to something which works, and then two years later the whole jerry-rigged system needs to be ported to another platform but it can't because the new platform doesn't jerry-rig the same way, the end product suffers. The original idea of using one language for everything was basically good. Only one minor detail; that one language needs to be C++. C++ and ANSI C do not have the weak-typing you mention, or any software-engineering weaknesses. The only place you'll find a C compiler like that will be on something in the dipsy-dumpster behind the Smithsonian tech-history museum. As per safety, a C++ compiler in the hands of a modern practitioner is basically a tube of glue with which to join together pre-packaged items from professional libraries. That's VERY safe; it's made possible because C/C++ are the mainstream, the standard. Live out in left field with Ada, and you won't have this. What you WILL have will be an overly complex language, with multitudes of Joe Redneck computer programmer out there on every Army base in every little podong town in the USA all trying to use it WITHOUT the benefit of all the pre-packaged stuff. That's real safe, isn't it? >Ada is so well >suited to life-critical problems with hard real-time constraints that >it is the language of choice for the FAA's rewrite/upgrade of all >air traffic control software in the U.S., and for the Space Station. >It is also the language of choice in a number of process control >applications (including nuclear power plants). Our father, who art in heaven... >>>as for Mr. Holden's claim that "there are several FAR better answers out >>>there in common usage, the most obvious of which is C++", this betrays >>>is brute >>>ignorance Don't start counting here, this is quote from a previous article... >>>concerning Ada I warned you about at the start of his post. >>That's twice Showalter has accused me of ignorance within just a few >>paragraphs. I've had one article concerning the Ada/C++ question >>published in the C++ Journal; apparently, they took some of what I had >>to say seriously. >Yeah, and I published a scathing rebuttal of that article. I wasn't shocked >that you wrote it, but I WAS shocked that they stooped to printing it. >Apparently it is not a refereed journal. Or such referees as there are do not share your opinions. But you say you like refereed journals? Almost all communist literature over the last 70 years or so has been refereed. In the CCCP, they have an enforced paper recycling program; you turn in old magazines, books, journals etc. at recycling points (punkti vtoroy syerii, I believe) for coupons to buy new with. The people in fact buy wheelbarrows full of the refereed communist literature, which is dirt cheap, and wheel it straight to the recycling points unread, and get their coupons to buy real literature with. The commy literature is then converted into more commy literature, toilet paper (essentially the same thing), and other useful goods. The analogy between Ada and communism is a good one in fact; Ada serves about as much useful purpose as communism, its journals are refereed by bigoted idiots as are those of communism, it is about as well loved by those forced to deal with it... Global recycling programs... if Mike Gorbachov could be talked into it, this might in fact be the best use anybody could possibly come up with for everything which has ever been written concerning Ada. You could just toss it in with the commy lit and nobody would ever be able to tell the difference. I'd even be happy to donate my own Ada articles, even THIS one... AFTER Ada is dead and buried of course. >For those who were spared his article, Ted basically betrayed the same >ignorance (there, I said it again!) #1 Proud of that big new vocabulary, huh? So was my uncle's parrot... >of the facts he continues to display to this day. >He quoted hearsay and gossip pulled from BBS's, Those quotes, as is clearly evident, are complaints regarding major failures of the Ada language, from some very serious people involved in attempts to use Ada on technologically sophisticated projects. These aren't from local BBS's. They are from the Ada 9x BBS, specifically set up for the purpose. Readers should have no diffficulty discerning between those people and Showalter as to who is serious. >He ignored #2 >all evidence supporting Ada (including success stories such as STANFINS-R), Amongst projects in the federal government generally, and especially in DOD, there are successes, failures, and then a third kind of animal: abject failures which are simply declared to be successes and signed off on. Anybody who has seen it knows what I'm talking about; I personally have seen a couple of things declared to be successes which, were they to take place in either private industry or local governments, would have resulted in lawsuits and/or prison sentences for fraud. STANFINS-R, to the best of my knowledge, falls into category three, Ada being the chief culprit. >>>Oh yes...on the other front...executable size...we are sometimes space limited >>>on the size of the programs we can have in the on-board systems...how do the >>>C vs ADA sizes compare? >>>This information is important to know...otherwise we cannot make an intelligent >>>decision on which language to use in the future. NASA is trying to figure out >>>if they should adopt ADA as the single official language. Developers at NASA >>>need to know the hard data in order to decide whether to support such a stand. >>Good thinking. With enough work and most Ada features turned off, Ada speeds >>for some tasks should approach those of C. This has little or nothing to do >>with the BIG problems of Ada, which are philosophical/economic in nature >>and not easily amenable to technical solution. Executable size is a >>symptom of one such problem. >Uh, Ted? Your >ignorance #3 >and zealotry are showing again. >>This is a REAL good analogy, but I'm afraid Jim doesn't carry it far >>enough, simply because he can't conceive of it actually happening. >>Problem is, the Ada crew CAN. You have to put yourself in their >>shoes; they want to control the two extremes of programming, embedded >>systems and mainframe/database work, and everything in between and, >>hence, they need every feature in the world in their CORE LANGUAGE. >>Letting people make up their own libraries for applications (as per C/UNIX) >>would be too much like a free system. >Letting people make up their own libraries for 40 years--with attendant >loss of portability across applications--was part of the motivation for >creating Ada in the first place. Whenever someone tells me they write >in C/UNIX, the first question I ask is "Which one?". Right. Which Ada/C, Ada/Cobol, Ada/C/Cobol, Ada/Cobol/4GL combo are YOU using this time, Showalter? The only thing beyond C++ which I would ever need would be the aforementioned link to assembler, rarely. No Ada user could say that. Again, those Ada/other combos are real portable, aren't they. >But more importantly, the claim that Ada is a big language is largely >unfounded. Ada has two complex features not available in other languages, >generics and tasking, but these are extremely powerful features with no >clean workaround in other languages (generics by code copying and tasking >by operating system calls leave a lot to be desired). Every serious organization I've ever heard of using Ada has had to entirely bypass Ada tasking and generics, and work around them. The penalties in performance, reliability, flakey behavior etc. were intolerable. POSIX/UNIX-V interprocess communications are guaranteed to be the same all over the world. Similarly for any given real-time exec. Far better to build around these; the benefits of the Ada tasking model are self-evident from the various quotes in my article. The people quoted, unlike Mr. Showalter, are quite serious. >Leaving aside >generics and tasking, the remainder of the language is not really all >that much more complex than Modula-2: basically a superset of Pascal >with separation of specification and implementation, namespace control, >and a better type model. Ada has about the same number of keywords and >control structures as C++. True, the reference manual for the language is >big, but that is because it is a precise definition of the language, >something absent from most languages. Ada, as is well known, is an ill-defined language, the last item in my post (...it shall not be the case...) being but one example. That is why Hoare wrote the essay he did regarding it. Again: "And so, the best of my advice to the originators and designers of Ada has been ignored. In this last resort, I appeal to you, representatives of the programming profession in the United States, and citizens concerned with the welfare and safety of your own country and of mankind. Do not allow this language in its present state to be used in applications where reliability is critical, i.e. nuclear power stations, cruise missiles, early warning systems, antiballistic missile defense systems. The next rocket to go astray as a result of a programming language error may not be an exploratory space rocket on a harmless trip to Venus: it may be a nuclear warhead exploding over one of our own cities." A statement like that, once made, is made forever. There is no changing one's mind on something like that. It is not the case that Hoare was 12 years old when he said that (the Touring award speech isn't commonly given by 12 year olds), and the language is the same now as it was then. Guaranteed by law. The problems he spoke of were deep philosophical problems, and all are still there. The user comments in this article are symptoms of the deep underlying problems. No solution other than tossing Ada exists. >>Logical consequence: >>From a recent comp.lang.ada posting. >> "My only problem with Ada at this point is the cost ($ and hardware >> resources) of a compiler for my XT clone. Both IntegrAda and Janus require >> more memory than DOS 4.01 leaves available. This is BAD DESIGN. There >> is no excuse for a 551K executable in a PC (pass 2 of Integrada). Janus >> Ada requires > 580K available to run, and rumor has it that the Integrada >> compiler is a repackaged Janus compiler." >This is a tools issue, not a language issue. Bullshit. >If tool immaturity is sufficient >reason to damn a language, then can I expect you to be fair and damn C++ as >well? At present I am nearly finished with a program which will be used in language labs, which uses a Sound-Blaster card and VGA text-mode fonts, and a number of other things, and the whole program including debug code is around 50K bytes, small memory model. This is Borland C++, 2.0. The program is nearly 5K lines of code, with include files, and takes around 15 seconds to compile. That's why nobody in the real world wants Ada. >>Everybody begins to realize: "Hey!, looks like Ada's the only >>thing I'm ever gonna have, so I'd better see to it that everything I >>ever plan on doing is part of Ada...", and we get Ada-9x, the language >>which will include all the great features that Ada left out. Kind of like >>quick-sand or one of those old Chinese finger traps... the more you >>struggle, the worse it gets. >You mean like C++ includes all the great features that C left out? Retention of the low-level functionality and performance advantages of C was a prime criterion in the developement of C++. Great care was taken not to end up with another Ada. >Ted, >would it be too much for me to at least insist on logical consistency >and honesty in your arguments? So far you've attacked Ada for (obsolete) >issues of tool maturity and for its planned evolution into the more >complex language Ada 9x, and yet you fall strangely silent when those >same issues could be just as equally applied to C++. Or are you just a >bigot? YOU calling ME a BIGOT!?!?!?!?! You might add the word "CHUTZVAH" to your nifty vocabulary (spell it without the 'c', which is legit, and it goes just behind the I word, your favorite). >>The good news is that, given the speed at which these things happen, >>Ada-9x is probably 10 years away. The bad news is two-fold: first, >>Ada-9x will probably break all existing Ada code >Actually, upward compatibility is sort of a Holy Grail for the 9x folks. >>and, second, the clunk >>factor will likely be so great (1,000,000+ bytes for "HELLO WORLD" might >>actually be achieveable), that no more working Ada code will ever be written >>afterwards. Total paralysis. >Ah. "Hello world." Funny you should mention that: I left a job at a >large successful UNIX workstation vendor several years ago partly due >to an argument over Ada and "Hello world". A developer dismissed Ada >with a wave of his hand, saying "I don't want to take 20 minutes to >write 'Hello world'.". He meant he didn't want to spend 20 minutes watching hello world compile, as I have done, and this on a Unisys 5000/95 with nothing else going on. >>Several times recently, Ada affectionados have posted articles >>concerning the national information clearinghouse for Ada-9x, including >>the phone-modem number (301) 459-8939 for Ada-9x concerns. This BBS >>contains 744 recent user comments on Ada in it's present state; true life >>experiences of actual Ada sufferers. These are grouped in bunches of 50 >>in self-extracting zip files (e.g. 101-150.exe) and may be downloaded. >>For instance: >>complaint #0300 >> PROBLEM: >> >> Currently, to create and mature an Ada compiler, it takes from >> 3..5 years. For the new architectures of the future and rapid >> compiler development, the language needs to be expressed in terms >> that are easy to parse and to generate code. >> The definition should be revamped so that the grammar in Ada to >> conform to LR(m,n) for consistent/complete parsing rules -- the >> most efficient and accurate compiler techniques. Move more >> semantics to the grammar specification to rid the language >> definition of so many special cases. >>The solution proposed, unless I'm missing something, would break nearly >>all existing Ada code, hence it isn't likely to happen. >You're missing something (why am I not surprised?). The removal of >special cases should be largely upward-compatible, since all this >means is that code that compiled previously under a more restrictive >set of rules will compile now under a less restrictive set of rules. The "...definition should be revamped..." obviously refers to the definiton of the language... >>anybody figuring to use Ada starting >>now had best get used to the more minor problems (the 1 out of 10). >>These include: >>complaint #0237 >> We cannot adequately configure large systems as the language now >> stands. There are no standard means of performing the kind of >> operations on library units generally considered desirable. These >> include: >> - creating a new variant or version of a compilation unit; >> - mixed language working, particularly the use of Ada units by >> other languages; >> - access control, visibility of units to other programmers; >> - change control and the general history of the system. >> The inability to do these things arises out of a few loosely worded >> paragraphs in the LRM (in 10.1 and 10.4), which imply the existence >> of a single Ada program library, whose state is updated solely by >> the compiler. This can be an inconvenient foundation on which to >> build. The relationships between compilations in a project will be >> determined by the problem and the organization of work, and any >> automatic enforcement of a configuration control regime must come >> from a locally chosen PSE. Ada especially, as a language with large >> and diverse application, must have a separate compilation system >> which gives the greatest freedom possible in this area. >> >> >> IMPORTANCE: >> >> ESSENTIAL >> >> Ada was intended for use in large projects, involving many people, >> possibly at different centers. These are precisely the projects >> which will collapse if the programming support technology is >> inadequate. >Again, tools. Not at all. The man speaks of the obvious restrictiveness of the Ada programming environment, and the obvious lack of needed flexibility which it engenders. >>That is, Ada can't realistically be used for large systems. >Uh huh. You know, Ted--sometimes you say something so INCREDIBLY dumb >I wonder if you're just pulling our collective leg. Ada has successfully >been used on some of the largest and most complex software projects >ever attempted, many of them over 1MSLOC in size. These succesful projects >have ranged all over the spectrum of application domains, including MIS >and AI. Or are you so completely >ignorant #4 >of the facts that you truly >believe that no projects have ever been successfully completed in Ada? My article in the C++ journal mentioned a few of these successes, for instance the 1.25 M sloc AFATDS project which was declared a success because only 10% of the code (123,600 sloc) had major language-related software problems. Communism could be declared a success that way. >>complaint #0150 >> Due to the availability of virtual memory, most minicomputer >> and mainframe programmers rarely consider the size of main memory >> as a limiting factor when creating their programs. In contrast, >> th size of main memory is a major concern of microcomputer >> programmers. The most widely used microcomputer operating >> systems, MS-DOS, does not have virtual memory capabilities. >> Without the availability of special programming techniques to get >> around this limitation, microcomputer programmers would have to >> severely limit the functionality of their programs, and, it would >> be impossible to create large, integrated information systems for >> microcomputers. One of most widely used of these programming >> techniques is the "chaining" capability provided in many >> programming languages. "Chaining" gives a programmer the ability >> to break down large integrated information systems into separate >> executable programs, and, then, when the system is operated, swap >> these programs in and out of main memory as the need arises. >> "Chaining", in effect, simulates virtual memory. Ada does not >> have the capability to chain programs. As a result, >> microcomputer programmers who use Ada must severely limit the >> functionality of their programs. >> Importance (1-10) >> 1 - Microcomputer programmers who use Ada will have to >> continue limiting the functionality of their programs. >> Current Workarounds >> Programmers must either limit the functionality of their Ada >> programs or use a proprietary CHAIN command supplied by the >> compiler manufacturer - which hurts portability. >>I.e., Ada can't be used for small systems... klunk factor's too high. >Chaining is not defined as part of the C ANSI standard, to the best of >my knowledge. Is it? If not, then any chaining that is done for C >programs is not an inherent part of C, is probably ALSO a proprietary >and non-portable vendor-specific directive, and is therefore no better >or worse than the equivalent support offered for Ada on PCs. Isn't it >fairly standard for PC compiler vendors to kludge in this capability >in some way? Turbo Pascal, for example, offers a chaining capability, >but that certainly isn't part of any Pascal standard I'm aware of. The only problem is that Ada doesn't seem able to do it. >Again, a tools issue. No. This time, seemingly, a logical problem on your part. >>Consider the one feature which might come remotely close to justifying >>this giant klunk factor: object-oriented capabilities. >>complaint #0599 >> >> PROBLEM: >> Inheritance has become one of the standard attributes of >> modern object-oriented programming languages (such as C++ >> and Smalltalk-80). Unfortunately, Ada is quite deficient in >> its support for inheritance ( it is based primarily on >> derived types, and then not particularly well), and this is >> a valid criticism leveled at the language by critics (and C >> bigots who, if forced to learn a new language, simply prefer >> to learn C++). There are currently many proposals to add >> full-blown inheritance (and other standard object-oriented >> attributes, such as polymorphism) to Ada; the scope of this >> revision request is much more modest, intended only to make >> the derived type mechanisms that already exist work better. >> IMPORTANCE: ESSENTIAL >> If the lack of modern object-oriented attributes is not >> addressed in Ada 9X, Ada will almost certainly become the >> FORTRAN of the '90's. >> CURRENT WORKAROUNDS: >> Be thankful for what limited object-oriented support is >> offered by the current language. >I've addressed the issue of the relative importance of inheritance >(particularly as supported by C++) to software engineering elsewhere. >Suffice it to say that I think it represents about 5% of the true >value of C++ over C. The remaining 95% is in the realm of additional >features I term "software engineering oriented", This puts you at odds with the entire mainstream of American computer science, as well as everything which has been in the literature for the last several years. Readers are invited to check out Pinson/Weiner, "Object Oriented Programming and C++" for an estimation of the value of inheritance/polymorphism. Several examples of typical projects are given with both traditional and object-oriented solutions, and it's very clear which way leads into the future. Not only does Showalter claim to know more about computer science than American industry in general, but it becomes clear later in this article that he also knows more about OS design than Unisys, DEC, IBM etc. etc. Keep on reading. The extent to which the Ada community lives in isolation is frightening. >>Consider Ada's original primary mandate: embedded systems: >>complaint #0021 >> PROBLEM: >> A high priority task may be suspended because it needs to rendezvous with >> a low priority task. That low priority task does not get scheduled >> promptly because of its priority. However this causes the high priority >> task to be suspended also. >> >> IMPORTANCE: (7) >> >> This problem makes the use of task priorities extremely difficult to apply >> correctly in a large system. It limits the ability to use task priorities >> to improve throughput in a system. >>complaint #0072 >> PROBLEM: >> The Ada priority system has proved quite inadequate for the >> needs of certain classes of hard realtime embedded systems. >> These are applications where a high degree of responsiveness >> is required. >> >> For example, there is a major conflict between the fifo >> mechanism prescribed for the entry queue and the need for the >> highest priority task to proceed wherever possible. >Yep, this is a known problem, and it will be fixed. Gee, they made >a mistake the first time around. Guess the language is a failure. >>complaint #0084 >> problem >> Ada tasking involves too much run-time overhead for some high-performance >> applications, including many embedded systems applications for which the >> language was designed. This overhead not only slows down the program in >> general, but may also occur at unpredictable times, thus delaying response at >> critical times. To avoid the overhead, real-time programmers frequently >> circumvent Ada tasking. >> The problem is exacerbated by Ada's lack of support for those who do >>try to use tasking in an efficient manner. There is no standard set of >>guidelines to programmers for writing optimizable tasking code, or to >>language implementors, for deciding which optimizations to perform. Also, >>there is no simple way for a programmer who is concerned with writing >>portable high-performance code to check that optimizations applied under >>one implementation will be applied under different implementations. >> The consequences of Ada tasking overhead have not gone unnoticed in higher >> circles of government. A recent General Accounting Office report [1] noted that >> Ada has limitations in real-time applications that require fast processing >> speed, compact computer programs, and accurate timing control. All three of >> these requirements are directly and adversely affected by Ada's current >> tasking overhead. >>complaint #0278 >> PROBLEM: >> In the last 5 years, tomes have been written on the Ada tasking >> model. It is too complex and has too much overhead for embedded >> systems to utilize effectively. It also does not fit well with >> architectures found in embedded systems, e.g., multiprogramming/ >> distributed processing. The control mechanisms are not >> responsive to realtime needs. Applications programs are >> responsible for housekeeping on context switches where the >> process will not return to the previously selected context. The >> model does not support the well-known basic scheduling >> disciplines, e.g., preempt or nonpreempt and resume or nonresume, >> see Conway's Theory of Scheduling. The problems with tasking >> efficiency is not the maturity of the compilers, but in the >> underlying model defined in the language and the validation >> requirements for the compilers. >> >> importance: very high, one of the major goals for the Ada 9x >> >> current workarounds: Programming standards to avoid tasking or >> only initiate a single task and to not use rendezvous of any kind >> as they are too unpredictable and require too much overhead. >> Allow the ACVC not to test this section so that the application >> does not have to absorb a runtime system from a compiler vendor >> that has little experience with the applications. >> >> Or, write in a language like Modula-2 or object oriented C++ that >> does not interfere in the target architecture. >> >>i.e. Ada can't really be used for embedded systems, its original mandate. >>People unfortunate enough to HAVE to use Ada for imbedded systems are >>spending ten hours working around Ada and one hour trying to solve their >>problem. The problem is that someday, somewhere along the line, one of >>our pilots might have to actually fly something programmed like this against >>something which has been programmed using real software tools. >The complaints about tasking overhead and usability are largely unfounded. Bullshit. I don't think the typical reader is going to have any difficulty determining, between the authors of the four quotes above and you, who is serious and who is a clown. I know I certainly don't have any difficulty with that. The four quotes are a very small sampling of what various users had to say about Ada tasking (The Ada9x BBS). None of it was complimentary. >I know of many very successful projects with hard real-time constraints that >have used tasking extensively and met all their performance goals via jerry-rigging and use of other software. Again, four hours working around Ada, one hour solving the problem. Again dangerous, again, not the right way to do anything. >(your >claim that Ada "can't really be used for embedded systems" notwithstanding). >Most complaints about tasking, on closer investigation, turn out to >be due to lack of training and/or immature tools. The few issues that are >real issues are being resolved. At least Ada provides a clear path toward >such resolution... the clear path is deep-six Ada. >By the way, do you have any idea how insulting it is when you say something >about Ada that implies it will kill soldiers? There are a lot of people >committed to Ada precisely because they believe that it offers the BEST >chance of AVOIDING such tragedies, and for you to mock them is rude and >shocking in the extreme, particularly given your generally nonexistent >grasp of the facts. One of the reasons I'm so adamant about Ada and so >down on C is because I regard Ada as inherently safer than C, and I see >that as a good thing. And I'm not alone. The lack of grasp is yours and not mine. I have family members and friends who have been/are/will be soldiers, and everything I've learned about actually developing software over more than 20 years tells me that Ada is a danger to them and I'll be DAMNED if I'd want to hear about any of them dying for the benefit of some government affirmative action program for a goof programming language which would not last a single day in the real world on its own merits. If you and your ilk find that insulting, that's tough shit. As insults go, that's one of the most thoroughly earned I've ever heard of. >>How about something simple like string handling? >>complaint #0163 >>Problem: >> Strings are inadequate in Ada. It is very frequently the case that >> the length of a string is not known until it is formed...after it >> has been declared. This leads to ugly, clumsy constructions (blank >> pad everything, keep track of length separately, play tricks with >> DECLARE's and constant strings, etc.). The obvious solution of >> writing a variable-length string package (see LRM, section 7.6) is >> unsatisfactory: you are lead to a limited private type because >> neither the standard equality test nor assignment are appropriate. >> (you want the both to ignore everything beyond the actual length of >> the strings) For limited private types, however, you have no >> assignment statement at all. We implemented such a package and >> found that using a procedure (SET) for assignment was error-prone >> and hard-to-read. This even for experienced programmers and even >> after getting beyond the initial learning curve for the package. >>How about something REAL SIMPLE, like argc/argv? >Which, being heap allocated, work just EVER so well in embedded >systems with tight memory constraints, right? Ada doesn't support >variable length strings for the same reason it doesn't support >variable length arrays--memory usage in embedded systems has to be >determinable at compile time to the maximum extent possible. That doesn't keep people from using C in embedded systems... not much memory use in most cases, and nice to have for software on larger systems. The quote: "This leads to ugly, clumsy constructions (blank pad everything, keep track of length separately, play tricks with DECLARE's and constant strings, etc." is an example of what I mean by spending four hours working around Ada and one trying to solve your problem. Further, such code is difficult to maintain, difficult to get and keep logically correct and, ultimately, DANGEROUS. >>complaint #355 >> PROBLEM: >> It is difficult, in a standard manner, to get at the operating >> system command line arguments supplied when the program is invoked. >> IMPORTANCE: >> (Scale of 1 - 10, with 10 being most important): >> <<8>> >> CURRENT WORKAROUNDS: >> Look up in vendor-specific manuals the method of accessing the >> command line parameters and access them differently on different >> operating systems. >>What about writing an OS in Ada (so that real "software engineers" won't have >>to screw around with UNIX anymore)? >Not a bad idea, actually--IBM didn't use Ada, but they DID rewrite UNIX from >the ground up for their RS6000 because they deemed the existing implementation >too erroneous to live with... >But I digress. The real issue is that command line arguments are outside >the language, just as they are in C. The only reason you THINK they're >defined in C is that you're so used to arcg/argv that you don't realize >that those are just conventions obeyed in UNIX. Write a C program on UNIX >and try to port it to MS-DOS, and you'll see what I mean (unless the MS-DOS >vender has been kind enough to already supply a workaround for you that >acts like argv/argc). They ALL do. Almost all filter type programs port from UNIX to DOS by recompiling. This complaint is silly and well outside the scope >of the Ada language--if the complaint is that operating systems are not >consistent across different platforms, I certainly agree that this is a >problem, but what does that have to do with Ada? The functionality is ubiquitous enough that everybody writing compilers for the real world provides a solution, and almost all such solutions in the C/C++ world are identical. That is called ADAPTING. In nature, as well as in the real world of business, creatures which do live; those which do not, die. >>complaint #0186 >> It is difficult, if not impossible, to use Ada to write an operating >> system. For example, a multiprocessor naval command and control >> system might need basic software, comparable in complexity to a >> minicomputer network operating system, to support fault tolerance, >> load sharing, change of system operating mode etc. It is highly >> desirable that such important software be written in Ada, and be >> portable, i.e. be quite independent of the compiler supplier's Ada >> run time system. Currently, it would be very difficult to do this >> in Ada, because of the difficulty of manipulating tasks of arbitrary >> type and parentage. >> IMPORTANCE: 7. >> >> CURRENT WORKAROUNDS: >> Use operating systems written in C or assembler. >> Write the operating system as an extension of the Ada run time >> system - this is undesirable because it is non-portable and >> unvalidated. >Well, Rational did it, so it must be possible. >>At a recent question and answer session for vendors involving a Navy >>RFP for a project for which a POSIX compliant OS written in Ada was to >>be required, the vendors informed the contract officer that the R would >>draw no Ps with that requirement. This was in one of the Govt. computer >>tabloids. >Oh, to have been in on the bidding in this case! This case was the Navy Next Generation Computer Resources program, something like $140M, I believe. Vendors at the meeting included Unisys, Hughe's Aircraft, Raytheon, and many others of the same stature, and all claimed the POSIX in Ada idea was prohibitively expensive and/or impossible. Check out Federal Computer Week, June 11 90, p 32. But you know more about OS design than all of those guys, don't you Showalter? I mean, you've called me ignorant four times in this one article and then make an implied statement like that. Question is, can you make that statement and keep a straight face? I know a gentleman who'll hire you on the spot if you can; you'll need some greasepaint and a big round red nose.... >>What about basic portability? >>complaint #0365 >> >> Problem: >> Implementation Options Lead to Non-Portability and >> Non-Reusability. >> >> Discussion: The LRM allows many implementation >> options and this freedom has lead to numerous >> "dialects" of Ada. As programs are written to rely on >> the characteristics of a given implementation, >> non-portable Ada code results. Often, the programmer >> is not even aware that the code is non-portable, >> because implementation differences amy even exist for >> the predefined language features. Further, it is >> sometimes not impossible to compile an Ada program with >> two different implementations of the same vendor's >> compiler. >Ada is not a 100% solution to this particular issue, and there are >certainly a few issues (such as implementation-defined attributes) >being addressed by Ada 9x, but try to remember your objective here: >to beat Ada in comparison to other languages, not to find fault >wherever you can with Ada. If you just want to find fault with Ada, >I can trump you each time by saying "Yes, but it's far far worse >in <language of choice...I suggest C>." Try me: you claim that >Ada is not 100% portable...I respond "Yes, but it's far far more >portable than C". Your move. C is more portable precisely because of the minimalist approach. A user can purchase his own favorite tools for various platforms. Ada implies an all-in-one programming environment, and this all-in-one environment varies quite a lot from platform to platform; that is the gist of the comment. Users have little or no choice. >> Another kind of non-portability is that of the programmer's >> skills, The user interfaces to Ada compilers have become so >> varied that programmers find it very difficult to move from >> one Ada implementation to another, Not only does the >> command line syntax vary, but so do program library >> structures, library sharability between users, compiler >> capabilities, capacity limits. etc. >> Importance: ESSENTIAL >> Current Workarounds: >> Significant amounts of code rewriting, recompilation, and >> testing must be done to get a given Ada program to compile >> and to run successfully using another compiler, if at all >> possible, even on the same host-target configuration. It >> is very difficult to write a truly portable Ada program. >> Another possible solution to porting an Ada program is for >> a customer to carefully choose a compiler to suit the given >> Ada program, or perhaps collaborate with a vendor to tailor >> the compiler to suit these needs. >> Significant amounts of programmer retraining must occur >> when a different Ada compiler is used. >> >>................................................................... >Tools tools tools. Again all outside the scope of the language. Not really in the case of Ada. The language ref insists that a certain type of integrated environment exist, and then does not adequately specify that environment. The user really doesn't seem to have sufficient choice in software development environment. A close reading shows that Showalter's comment is largely irrelevant to the user's statement. Showalter likes the T word almost as much as the I word, it appears. In truth, on many if not most platforms, assuming a certain level of sophistication in a language (i.e. assuming you're talking about C++, EIFFEL, Smalltalk, Turbo Pascal 5.5/6 etc.), then tools more than language really will make most of the differences in productivity, efficiency, and software engineering concerns in most cases. It is interesting that the Smalltalk crew won the recent Windows programming event in California. Ada, unfortunately, does not put a user into the category in which tools make the difference, and there are numerous reasons why. Showalter and others like to talk about tools on rationals, which probably represent .001% of DOD computers, and they forget that military hardware typically lags the private sector by x number of years. Nobody other than DOD is buying Unisys 5000's now. What kinds of tools would save a unisys 5000, or a Zenith 248? C and/or C++ have no problems running on 248's. >Are >all C compilers the same across platforms? Are the C compilers from >the same VENDOR even the same across platforms? Regarding the core of the language, yes. Regarding specialized features for handling specialized hardware, no. That is the correct approach. I was debating whether to make some sort of a statement concerning the requisite intellectual "tools" to conduct a debate without resorting to calling an opponent "ignorant" X number of times in one article, but I suspect I'll save that till next time. I probably won't get back to comp.lang.ada for about another year; two or three of these a year is about what I can stand. Hopefully, Ada will no longer be around a year from now, and it won't be necessary. Ted Holden HTE
jls@netcom.COM (Jim Showalter) (05/25/91)
I said I'd ignore him, but when a lob is coming your direction... >You're wrong on all counts and worse. The option lapses in June. Ada is >supposed to be the last and only programming language in DOD. This >means by definition, as the law states, that after this June, ALL DOD >programming must be done in Ada, period. Unless you can provide a technical and business case to the contrary. If you cannot do so, why should you be allowed to use anything but Ada? >The Borland C++ >interface to assembler is the best thought out example of such an >interface I've seen yet, and I can't picture making such a thing a >language feature. So you prefer instead to have an application written in Borland C++ be incompatible with one written in Zortech C++, and both incompatible with one written in GNU C++? Good thinking. >The minimalist aspects of >C/C++ are precisely what make them the answer to today's problems. I direct you to comp.object for an ongoing series of complaints by C++ practioners about C++'s NON-minimalism. >The following is from Hoare's famous article: > > "You include only those features which you know to be needed for > EVERY single application of the language and which you know to be > appropriate for EVERY single hardware configuration on which the > language is to be implemented. Then, extensions can be specially > designed where necessary for particular hardware devices and for > particular applications. That is the great strength of Pascal, that > there are so few unnecessary features, and almost no need for > subsets. That is why the language is strong enough to support > specialized extensions - Concurrent Pascal for real-time work, > Pascal Plus for discrete event simulation, UCSD Pascal for > microcomputer applications. If only we could learn the right > lessons from our successes of the past, we would not need to learn > from our failures." Ted, you didn't tell me you were a Pascal programmer! There's hope for you yet--next you'll be telling me you understand the value of strong typing. By the way, considering that inheritance is not used in every C++ program, I guess it should be taken OUT of C++, to conform to the criteria in the Hoare quote above, right? I guess basically I just diagree with Hoare. He seems to be favoring non-portability and non-uniformity of language definition: he wants dialects ("extensions") for various purposes instead of a single powerful and highly flexible standardized language that spans all applications. Funny, it was thinking like this that caused the DoD to wind up with 4,200 different languages being used on the projects it was funding and that led to the invention of Ada in the first place. >The whole import of Hoare's speech was that the basic underlying design >philosophy of Ada was entirely wrong, and that this would guarantee >multitudes of major-league troubles, as the user comments adequately >document. Life does not offer us technological cures for philosophical >problems. I would ask if Hoare has actually BUILT the sorts of systems Ada is being used to successfully build. He seems to see only hazards and dangers, and predicts catastrophes if Ada is used, and yet if you go talk to people who have engineered multi-million line systems they'll tell you that Ada added value to the project and made things easier. There are even people who have completed massive projects who will tell you that without Ada they'd have had a hell of a time succeeding. Perhaps one should get their opinions about Ada from someone who has experience engineering success with it, rather than from a well-intentioned but possibly largely incorrect academic, reputation notwithstanding. >[ad hominem attack deleted] >Think of it this way; if I was a masochist like you are and wanted to >link in the inline assembler libraries (as well as every other feature >available in Borland C++) to every application I ever wrote, then all of >my executables would be 600,000+ bytes just like yours are, they'd be >slower than hell, just like yours are, they'd take me forever to >develope, just like yours do... in short, I'd be using Ada, no matter >that the package said C++, wouldn't I? If the law FORCED me to program >like that, then I'd REALLY be hurting. Uh, Ted? Actually, the code I write is compact and executes quickly. This is because I use real industrial strength tools that perform link-time dead code elimination, code pooling, global and local optimization, selective loading, etc. Tools, Ted. Tools. >>When were they doing this complaining?--if >>it was more than 5 years ago it is almost certainly all moot by now: > >No it isn't. The language is identically the same, guaranteed by law, >and will remain so for some time. Yes, but the tools have improved greatly. In my experience, 99% of the complaints that are on the surface directed toward the language turn out on closer inspection to be really about tools issues ("Takes too long to compile.", "Executables are too big.", etc). >Every software project gets done with finite quantities of time, money, >talent, psychic energy etc. Make a language or software development >system but so slow, ponderous, clunky to use, and the software developed >with that system is sooner or later going to suffer. Agreed. But what does this have to do with Ada? Sounds like more tools complaints. I ask you again--have you USED any real development tools for Ada? >What you WILL have will be an overly >complex language, with multitudes of Joe Redneck computer programmer out >there on every Army base in every little podong town in the USA all >trying to use it WITHOUT the benefit of all the pre-packaged stuff. >That's real safe, isn't it? First you said Ada would kill soldiers, now you attack the people writing the code. You know, some people might actually conclude that you are not only ignorant, but genuinely UNPLEASANT as well. I mean, you've even managed to insult people who live in small towns--what did THEY have to do with any of this? >Or such referees as there are do not share your opinions. But you say >you like refereed journals? Almost all communist literature over the >last 70 years or so has been refereed. In the CCCP, they have an >enforced paper recycling program; you turn in old magazines, books, >journals etc. at recycling points (punkti vtoroy syerii, I believe) for >coupons to buy new with. The people in fact buy wheelbarrows full of >the refereed communist literature, which is dirt cheap, and wheel it >straight to the recycling points unread, and get their coupons to buy >real literature with. The commy literature is then converted into more >commy literature, toilet paper (essentially the same thing), and other >useful goods. The analogy between Ada and communism is a good one in >fact; Ada serves about as much useful purpose as communism, its >journals are refereed by bigoted idiots as are those of communism, it is >about as well loved by those forced to deal with it... You'll note I didn't delete this one. It was too bizarre to pass up. Now Ada is part of a communist threat to manufacture toilet paper from refereed journals or something like that?!?!? Ted, you've truly outdone yourself this time! Thank you for the heartiest laugh I've had in months--I mean it, I mean I have actually got tears streaming down my face. P.S. Scientific American is refereed. So is the New England Journal of Medicine. So are MOST technical journals. The commies are everywhere! Run for it, Ted! RUN!!!!!! >>He ignored >>all evidence supporting Ada (including success stories such as STANFINS-R), > >Amongst projects in the federal government generally, and especially in DOD, >there are successes, failures, and then a third kind of animal: abject >failures which are simply declared to be successes and signed off on. >Anybody who has seen it knows what I'm talking about; I personally have >seen a couple of things declared to be successes which, were they to >take place in either private industry or local governments, would have >resulted in lawsuits and/or prison sentences for fraud. STANFINS-R, to >the best of my knowledge, falls into category three, Ada being the chief >culprit. Well, you've insulted people in small towns, people who referee journals, people who write code for the military, and now CSC (the primes on STANFINS-R), who you seem to be accusing of fraud. >Right. Which Ada/C, Ada/Cobol, Ada/C/Cobol, Ada/Cobol/4GL combo are YOU >using this time, Showalter? The only thing beyond C++ which I would >ever need would be the aforementioned link to assembler, rarely. No Ada >user could say that. Again, those Ada/other combos are real portable, >aren't they. C++ supports SQL out-of-the-box? Must be in the newest rev (it is so darned hard to keep up! ;-). Really, Ted--first you argue that Ada is bad because it tries to do too much, then you claim that Ada interfacing to other languages and applications (like a database) is bad because it is non-portable. Which IS it? Is it too much to ask for you to maintain logical consistency in your own arguments, or do I have to do that for you? >Every serious organization I've ever heard of using Ada has had to >entirely bypass Ada tasking and generics, and work around them. The >penalties in performance, reliability, flakey behavior etc. were >intolerable. You mean like IBM, Lockheed, Hughes, Northrop, Xerox, Alcatel, Philips, MBB, Shell, GTE, GE, and CSC? These have all used generics and tasking and have completed projects successfully using Ada. And these are just the ones I've worked with PERSONALLY. Ted, the reason I keep using the word "ignorant" is because you are ignorant. Fortunately, ignorance is curable and, being ever the optomist, I've been giving you the benefit of the doubt--my first impulse was to call you STUPID. [ill-informed and hysterical quote from Hoare deleted] >Bullshit. Ted appears to want to increase the sophistication of his arguments. >At present I am nearly finished with a program which will be used in >language labs, which uses a Sound-Blaster card and VGA text-mode fonts, >and a number of other things, and the whole program including debug code >is around 50K bytes, small memory model. This is Borland C++, 2.0. The >program is nearly 5K lines of code, with include files, and takes around >15 seconds to compile. That's why nobody in the real world wants Ada. Ted, I hate to break it to you but when I was writing Ada at Rational I cranked out about 5K a week of debugged documented code. And I'm SLOW. 5K is a pimple in the sort of projects I'm talking about: on a 1MSLOC project that represents .5% of the total code size. A sneeze. And I think this highlights what I've been trying to point out all along--you truly ARE ignorant of the issues of large-scale software projects, and it shows. It's almost like we're from two cultures: you just don't GET what it is like to build humongous systems, and because of that you hammer Ada without even grasping the fundamentals of the argument. It renders discussion with you essentially pointless, but I persist in doing it because I hope OTHER people who DO understand the problems of complex system development will listen to me instead of you. I have just finished a four year stint helping some of the largest companies in the world engineer some of the largest and most complex software systems ever attempted. You've just written 5K of PC code. I think we have a serious impedence mismatch here. The difference between you and me is that I USED to write code for PCs, so I understand your culture. You do NOT understand my culture, and yet this doesn't prevent you from trumpeting your opinions. Personally, I try not to express opinions about stuff I have no understanding of as a matter of personal integrity. >YOU calling ME a BIGOT!?!?!?!?! You might add the word "CHUTZVAH" to >your nifty vocabulary (spell it without the 'c', which is legit, and it >goes just behind the I word, your favorite). I can write fluently in C, and passably in C++. You do not write fluently in Ada. Who's a bigot? >He meant he didn't want to spend 20 minutes watching hello world >compile, as I have done, and this on a Unisys 5000/95 with nothing else >going on. Tools, Ted. Tools. >My article in the C++ journal mentioned a few of these successes, for >instance the 1.25 M sloc AFATDS project which was declared a success because >only 10% of the code (123,600 sloc) had major language-related software >problems. In alpha test. It currently has bug rates in the maintenance phase considerably lower than in comparable systems written in other languages. I realize it might inconvenience you to have to tell the whole truth when presenting your case, but sins of omission do sort of undermine your credibility over time. >>Chaining is not defined as part of the C ANSI standard, to the best of >>my knowledge. Is it? If not, then any chaining that is done for C >>programs is not an inherent part of C, is probably ALSO a proprietary >>and non-portable vendor-specific directive, and is therefore no better >>or worse than the equivalent support offered for Ada on PCs. Isn't it >>fairly standard for PC compiler vendors to kludge in this capability >>in some way? Turbo Pascal, for example, offers a chaining capability, >>but that certainly isn't part of any Pascal standard I'm aware of. > >The only problem is that Ada doesn't seem able to do it. Neither can C or Pascal! Read the paragraph--the VENDOR'S TOOLS do it. So if a PC Ada compiler vendor wants to, they can add this the same way Borland and Zortech and the rest add it for other languages. >Not only does Showalter claim to know more about computer science than >American industry in general, Indeed, I DO make that claim. That's why they pay me to help them do it. Thanks for the plug! >Bullshit. Ted has learned a new word. >[incredibly vitriolic attack on Ada and me deleted] >[yet another personal attack deleted] -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *