Reasons for dropping Ada

Reasons for dropping Ada

[Ted Holden]

 
 
 
Sorry to be awhile getting back to comp.lang.ada;  I've
been pretty busy lately, and the crusade against Ada isn't really very
high up on my list of hobbies right now.
 
Actually, there are worse problems than Ada in the government:  there is
a procurement system which requires so much time to obtain any kind of
thing that people choose computers with no other thought than "what
contract is it on;  how easy will it be to get my paws on..."  There
is the disengenious system of using huge numbers of contractors at real
costs of over $100,000/year/person rather than just hiring these same
people as government employees and paying them real salaries (even at
$5000-$10000 more a year, the govt. would save more than double).
There is the problem of companies which seem only to deal with the
government;  this is kind of like the problem they get in India when a
tiger gets too old and run-down to kill its normal quarry and begins
eating people.  That kind of movie usually ends happily, as the white
hunter bags the tiger with the 375.  I don't really know how to make the
other variant end happily except, maybe, to require that no more than X
percent of any company's business be government related.
 
And then, there's the Ada/Software-Engineering problem;  if it isn't
grandiose, it's not worth thinking about, much less doing.  Not that
there aren't grandiose success stories, such as UNIX or WordPerfect,
around in the world.  But wordPerfect started out as a simple little
editor program written in PC assembler and added features every six
months or so until it finally EVOLVED into something grandiose.  If the
same program were to be "designed" and written under DOD specs, then
they would just be getting version 1.0 out the door now, after seven
years of design, followed by two years of coding, at the end of which
the entire package would be magically required to function properly,
just like the Airbus control system, the Space Telescope, Stanfins, WIS,
and all of your other great successes do.
 
The truth as I see it is that anything which takes two or three years or
more to do under present circumstances is going to bear no relationship
to reality when fielded; if you can't get some kind of a first version of
a product into users' hands within a year, you're doomed.
 
Karl had requested some background info: for the purposes
of USENET which, unfortunately, nobody else connected with any of my
other endeavors is interested in, I represent only myself (HT
Enterprises).  My personal experience with Ada has been in connection
with my work as a systems consultant with SofTech/EER of Vienna, Va. and
involved writing Ada/C and Ada/4GL interfaces, typically 300 or fewer lines
of code, and then watching Ada compilers take 30 minutes to compile those
little programs into 400K executables.  I have turned down offers to work
on typical Ada/Software-engineering projects (design for a year while the
thought police check computers for code, and then code for three
months), because long experience has tought me that reasonable software
cannot be developed that way and I do not wish to be a part of anything
which I would regard as doomed apriori.
 
Most of the horror stories I quote regarding Ada come from friends more
involved with it, and mostly outside of SofTech or other think-tanks,
although there are at least two or three people there who share my
views.  The people I've spoken to involved in Ada projects all have
claimed to have to work around Ada, multiplying the level of work
involved in doing anything at all by at least two, and this seems to be
in line with most of what I read concerning Ada in journals.
 
I speak numerous variants of computer languages, and two other human
languages more or less, other than English.  My only serious claim to
fame as a programmer is the little polyphonic VMUSIC program on the
PC BBS's, which was written in a combination of Turbo Pascal and
assembler.  Thank God.  If that program had been written in Ada, the
Bach pieces would sound like three dogs growling at eachother, and you'd
be hearing the HIGH notes.
 
Ada has problems which would be serious enough under any set of
circumstances, but the biggest problem it has is simply the fact that it
isn't C.
 
When Cobol came out, industry had no better answer sitting around, and
pounced on it.  Nobody's pouncing now.  The fact that C totally
dominates the mini-micro world, something like 70 % of all usage last I
heard, coupled with the increasingly obvious notion that the mini-micro
(DOS/UNIX) world is just about the only one which counts anymore, says
that C (or C++) is about the only rational choice of a major language
any more, especially for any government agency.  Under the best of
circumstances, all you could hope to do with Ada would be to duplicate
the C/UNIX world which is out there now at five+ times the cost.
 
Which presents a problem.  Beltway banditry and defense contracting are
about to go bye-bye, and we're all going to be out there trying to
actually make it in the world by competing the way the Japanese do.
And, if we are to actually compete with other nations such as the
Japanese, we're going to have to eliminate almost every form of waste
and abuse in our whole society.  When doctors earn $700,000 average in
this country, that gets built into the price of everything we ever try
to sell.  Likewise, the machinations of Ivan Boesky get built into
product prices, and on and on.  If government agencies are to be
required to spend five or more times the going rate for all their
software needs, that will get built into prices as well.
 
Hence, there is an incentive to simply drop Ada as a patriotic act;
there is also an incentive from the point of view of personal survival.
I am hearing that Ada 9-x will probably only include fixes for present
bugs and woes;  nothing at all about object-oriented features.  You want
to be a software engineer in the future?  Better start learning about
one of the languages those people use (Eiffel, C++, etc.)
 
But then, I have it on good authority that the inventors of C/UNIX fill
out the occupation slot on their tax returns with "programmer".  Kind
of makes you wonder just a little bit, doesn't it.
 
 
Ted Holden
HTE
 
 
 
 

Re: Reasons for dropping Ada

[Richard S D'Ippolito]

In article <19409@grebyn.com> ted@grebyn.com (Ted Holden) writes:

>And then, there's the Ada/Software-Engineering problem;  if it isn't
>grandiose, it's not worth thinking about, much less doing.  Not that
>there aren't grandiose success stories, such as UNIX or WordPerfect,
>around in the world.  But wordPerfect started out as a simple little
>editor program written in PC assembler and added features every six
>months or so until it finally EVOLVED into something grandiose.  If the
>same program were to be "designed" and written under DOD specs, then
>they would just be getting version 1.0 out the door now, after seven
>years of design, followed by two years of coding, at the end of which
>the entire package would be magically required to function properly,
>just like the Airbus control system, the Space Telescope, Stanfins, WIS,
>and all of your other great successes do.

You have cited UNIX and WordPerfect before as "success" stories, and had
been asked several months ago by another reader to provide supporting data.
I have not seen your reply.  Have you made it?  I would suggest that the
number of users of a product is not a direct measure of quality or of
engineering prowess.  (Horses were widespread until displaced by autos.)

If you haven't cited numbers to demonstrate productivity and quality of
those products, will you please do so now?  I will accept either number of
source lines of code per person-month and number of errors per KLOC, or
other results based on your own definitions.

I understand that a version of WordPerfect was rewritten from scratch in C.
This might be a good one for you to comment on as to the amount of design,
implementation, and integration times spent and how close the company came
to meeting the targeted release date.

I have a UNIX system here that still has numerous errors, some of which are
listed rather triumphantly, if not belligerently in the manuals.  Let me
quote a sample of them:

	
	BBEMACS(1)  I tinker too much, so occasionally I mess up and it
	         don't work no good.  But then I fix it, hooray.
	DAB(!1)  There is a mysterious bug causing occasional core dumps...
	         ...just send mail to the author.
	FILE(1)  It often makes mistakes.
	JOBS(3J)  There is no excuse for the "getwd" routine to be in the
	         jobs library.  There is even less reason for this routine
	         not to have been documented by the author(s) at Berkeley.
	PARSEDATE(3)  The grammar is incomplete and always will be.
	PUTC(3)  Errors can occur long after the call to 'putc'.
	SCANF(3S)  The success of literal matches and suppressed
	         assignments is not directly determinable.
	SIN(3M)  The value of 'tan' for arguments greater than about 2**31
	         is garbage.
	CTAGS(1)  ...if you have two Pascal procedures in different blocks
	         with the same name, you lose.
	EMACS(1)  Not bloody likely.
	TC(1)    The aspect ratio option is unbelievable.
	UNITS(1)  Don't base your financial plans on the currency
	         conversions.

Now, your system may have different texts for some of these, but I have
several sets of manuals spanning years which contain some of the same texts
(DEC substitutes the word 'unreliable' for the original 'garbage').  As I
said, these kinds of messages aren't universal, but there enough of them
spanning a large enough sample of years and programmers to cause me to
question the kind of attitude of the folks you continually hold up as model
programmers.

There is a more fundamental question, however, that we can save for another
time, having to do with the suitability of the current software models
implied by the systems and languages you support for large-scale projects.
It makes no sense to touch it when there is such an obvious disconnect.


Rich
-- 
Hitting baseballs and writing software are two professions where you can
become a millionare with a 75% performance failure rate.
							 rsd@sei.cmu.edu
------------------------------------------------------------------------

Reasons for keeping Ada

[David Kassover]

I was hoping not to get involved in a flame war, but:
 
C and Unix have growed like topsy.  That's the difficulty, they
are an open system, and just about anybody can contribute.
 
Then there are things like Mainframe Operating systems, which
were designed to make the applications run fast, not the design
of applications feel good.
 
Then there are things like VMS, which is not totally open, but
not totally closed.  Digital *tells you* the Digital way, and
encourages you to use it, so that everybody does it the same way
without leaving anyone out in the cold.
 
I'm a professional, and the thing that is most important to me is
that my product work, and continue to work.  I don't care if it
is bigger than I can handle myself  (I prefer projects to get
that big, I make more money that way 8-) )
 
It may not matter to you whether a trivial typo causes one of
your programs to splatter barfums on your screen, Mr. Holden, but
when one of my systems does so to one of my customers and I lose
a multi-kilodollar sale or a mega-dollar account because of it, I
hurt.
 
Ada may not be perfect, but it and it's philosophy go a long way
toward eliminating expensive mistakes.  Twenty thousand miles
above the surface of Venus is one HELL of a time to find out
someone used a decimal point instead of a comma.
 
Just in case no one knows the reference, the following code
fragment was responsible for the failure of a control algorithm
in a (not too) recent Venus probe:
 
		DO 100 I = 1.100
			.
			.
			.
	100	CONTINUE

This compiled, and the loop merrily executed only once.

So, Mr. Holden, please exercise some restraint, and direct your
diatribes to someplace else, like alt.flame, and allow us
professionals to go about our business, unhindered.
 
E(nd) O(f) S(ermon)

Re: Reasons for keeping Ada

[Clement Pellerin]

In article <5417@crdgw1.crd.ge.com> kassover@control.crd.ge.com (David Kassover) writes:
>		DO 100 I = 1.100
>		   ...
>	100	CONTINUE
>This compiled, and the loop merrily executed only once.

because Fortran discards spaces.  The do statement is in fact an assignment
statement.  You can check it out by printing the value of DO100I before
line 100.  No wonder Fortran is not context free!
-- 
news <clement
Clement Pellerin, McGill University, Montreal, Canada
clement@opus.cs.mcgill.ca

Re: Reasons for dropping Ada

[Loren Louis Hart]

I would say the best way to deal with Ted Holden is not to post any responses,
but to mail your responses to him.  This will cut down the amount of junk we
all have to read, and will also allow anyone who wants to, to respond.  
Frankly, I don't think his opinions are worth posting any responses to.
The only reason I am posting this response is to try to help keep the useless
trafic down.

Loren L. Hart
loren@cup.portal.com
San Jose, California

Re: Reasons for dropping Ada

[Mike Coffin]

[Speaking of Tom Holden]
From article <27187@cup.portal.com> (Loren Louis Hart):
> Frankly, I don't think his opinions are worth posting any responses to.
> The only reason I am posting this response is to try to help keep the useless
> trafic down.

Actually, I thought his last article had an interesting arguement---
not against the quality of Ada, but against the idea that Ada will
ever become popular.  The fact that Unix seems to be taking over the
world certainly seems to give C and C++ a *big* leg up.  Not only are
all the Unix tools built for, and based on, C, but the operating
system itself is optimized for running C programs.  Given that many
contracts in the future will specify Unix, there will be a
considerable tendency to also specify C or C++.

-- 
Mike Coffin				mike@arizona.edu
Univ. of Ariz. Dept. of Comp. Sci.	{allegra,cmcl2}!arizona!mike
Tucson, AZ  85721			(602)621-2858

if UNIX then USE_C ?? (was: Reasons for drop)

[Dennis M. O'Connor]

mike@cs (Mike Coffin) writes:
] The fact that Unix seems to be taking over the
] world certainly seems to give C and C++ a *big* leg up.
] Not only are all the Unix tools built for, and based on, C,

Which is probably irrelevant, given that plenty of CASE
environments for Ada exist for UNIX ...
Saying that UNIX somehow leads to favors programming in C is like saying
that CISC architectures leads to programming in microcode.

] but the operating system itself is optimized for running C programs.

If we allow that UNIX is optimized for anything ;-), just what
are these C-specific optimizations that favor C and C++ over Ada ?

] Given that many contracts in the future will specify Unix, there will
] be a considerable tendency to also specify C or C++.

Sorry, I disagree. Operating systems provide a "virtual machine"
for the applications programs to execute on; compilers provide
a "virtual machine" for the programmer to write programs for.

An operating system that is only able to efficiently support one
language or one family of languages is an inadequate operating system :

Assumption : there is no one language that is appropriate 
( much less best ) for authoring solutions to all problems.
[e.g. try an inference engine in C or Ada, or a real-time
      embedded system in Prolog, or an interupt handler in a 4GL ]

Conclusion : an operating system incapable of adequate support
for a broad spectrum of languages does not adequately
support a broad spectrum of applications, and is not a wise
choice as a general-purpose operating system.

Does UNIX fit this description ? I don't dare venture an opinion ;-)
--
  Dennis O'Connor      OCONNORDM@CRD.GE.COM      UUNET!CRD.GE.COM!OCONNOR
  "Let's take a little off the top ... a bit off the sides ...
    trim the back a bit ... Surprise ! You've been bald-ed !"

Re: if UNIX then USE_C ?? (was: Reasons for drop)

[Barry Margolin]

In article <5476@crdgw1.crd.ge.com> oconnordm@CRD.GE.COM (Dennis M. O'Connor) writes:
>mike@cs (Mike Coffin) writes:
>] but the operating system itself is optimized for running C programs.
>If we allow that UNIX is optimized for anything ;-), just what
>are these C-specific optimizations that favor C and C++ over Ada ?

The most obvious way in which a particular OS is oriented towards a
particular language is when it comes to data being passed between
application programs and OS routines.  Unix kernel routines and system
library routines expect things like null-terminated strings and structures
laid out the way that system's C compiler lays them.  Programs written in
other languages often need to transform data when passing it into and out
of the OS.

Another area of language bias is documentation.  Unix manual pages for
subroutines generally describe the invocation mechanism and argument types
in C syntax.

Ada representation clauses may be useful for solving some parts of the
first problem, but such programs are not portable.  Further, the manual
pages are written portably, so they don't describe argument representation.
In order to write the rep spec for a structure being passed to a system
routine you would have to go through the C compiler documentation and find
out how it lays out structures (hopefully this is documented).

These problems aren't as bad so long as programs stick to OS-independent
libraries, such as stdio for C and the standard packages that Ada provides.
However, the data transformation overhead is still there, buried inside the
library implementation.

>Sorry, I disagree. Operating systems provide a "virtual machine"
>for the applications programs to execute on; compilers provide
>a "virtual machine" for the programmer to write programs for.

But there's opportunities to optimize when the two virtual machines have
similarities.  For instance, both the Unix VM and the C VM share the same
string abstraction, so it is never necessary to convert C strings to Unix
strings.

>An operating system that is only able to efficiently support one
>language or one family of languages is an inadequate operating system :

Unfortunately, many OSes are inadequate.  The Mac OS is Pascal-oriented,
Unix is C-oriented, Genera (the OS on Symbolics Lisp Machines) is
Lisp-oriented, Multics is PL/I-oriented, etc.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

Re: if UNIX then USE_C ?? (was: Reasons for drop)

[Loren Louis Hart]

In an article posted by barmar@think.com on this topic
>In article <5476@crdgw1.crd.ge.com> oconnordm@CRD.GE.COM (Dennis M. O'Connor) 
w
>rites:
>>mike@cs (Mike Coffin) writes:
>>] but the operating system itself is optimized for running C programs.
>>If we allow that UNIX is optimized for anything ;-), just what
>>are these C-specific optimizations that favor C and C++ over Ada ?
>
>The most obvious way in which a particular OS is oriented towards a
>particular language is when it comes to data being passed between
>application programs and OS routines.  Unix kernel routines and system
>library routines expect things like null-terminated strings and structures
>laid out the way that system's C compiler lays them.  Programs written in
>other languages often need to transform data when passing it into and out
>of the OS.

I would say that things like null terminators and other system representations
are implementation issues of the compiler, particularly with respect to Ada.
Having written the Unix system interface for an Ada database, I would have
to say that the Verdix compiler's implementation is superior.  Ada allows for
the implementation to deal with terminating strings and other such platform
specific issues.  I found that the Verdix Ada compiler provided all the 
necessary capabilites to write an effective, reliable, and efficient Unix
Interface.

>Another area of language bias is documentation.  Unix manual pages for
>subroutines generally describe the invocation mechanism and argument types
>in C syntax.

In our case it was helpful to know some C to write the OS interface; however
since our project, Verdix has written and provided the text of the Ada package
specifications for many of the unix system calls.  I often find these Ada
package specifications clearer than the unix manuals on issues of types and
parameter passing mechanisms.

>Ada representation clauses may be useful for solving some parts of the
>first problem, but such programs are not portable.  Further, the manual
>pages are written portably, so they don't describe argument representation.
>In order to write the rep spec for a structure being passed to a system
>routine you would have to go through the C compiler documentation and find
>out how it lays out structures (hopefully this is documented).

>These problems aren't as bad so long as programs stick to OS-independent
>libraries, such as stdio for C and the standard packages that Ada provides.
>However, the data transformation overhead is still there, buried inside the
>library implementation.

Again, given the right choice of compiler in a given instance, what little
data transformation overhead is negligable by comparison to the inherent cost
of a system call.

>>Sorry, I disagree. Operating systems provide a "virtual machine"
>>for the applications programs to execute on; compilers provide
>>a "virtual machine" for the programmer to write programs for.

>But there's opportunities to optimize when the two virtual machines have
>similarities.  For instance, both the Unix VM and the C VM share the same
>string abstraction, so it is never necessary to convert C strings to Unix
>strings.

Again with the Verdix implementatio, their strings are null terminated and
there is never a need to convert them.

>>An operating system that is only able to efficiently support one
>>language or one family of languages is an inadequate operating system :

>Unfortunately, many OSes are inadequate.  The Mac OS is Pascal-oriented,
>Unix is C-oriented, Genera (the OS on Symbolics Lisp Machines) is
>Lisp-oriented, Multics is PL/I-oriented, etc.

Again I argue that a proper implementation of an Ada compiler should be in 
line with the platform it runs on.  A platform for a compiler includes not only
the particular CPU, but the OS as well.  I will admit that there are some
special purpose operating systems that make these kinds of adaptations next
to impossible, but I would not put Unix into this category!
--
Loren L. Hart
loren@cup.portal.com
San Jose, California

Re: if UNIX then USE_C ?? (was: Reasons for drop)

[David Kassover]

In article <34196@news.Think.COM> barmar@think.com (Barry Margolin) writes:
...
>The most obvious way in which a particular OS is oriented towards a
>particular language is when it comes to data being passed between
>application programs and OS routines.  Unix kernel routines and system
>library routines expect things like null-terminated strings and structures
>laid out the way that system's C compiler lays them.  Programs written in
>other languages often need to transform data when passing it into and out
>of the OS.
>
>Another area of language bias is documentation.  Unix manual pages for
>subroutines generally describe the invocation mechanism and argument types
>in C syntax.
>
...
 
C and Unix go together because they were implemented together,
the C language to make the writing of the OS (which, after all,
is just another computer program) easier.
 
 
Using standard libraries (all that means is that *someone else*
has implemented the interface from particular hardware to the
language specification  (Go ahead, flame.  I know that's
simplistic)).  If one is writing a truly embedded system, then
it's easy to fulfill the requirements of the Requirements and
Functional specifications (assuming you have them...).
 
On the other hand, if you're trying to implement a software
system where there are specific (or specified) desires to take
advantage of a particular platform feature, or that is intented
to by interacted with by humans, you have to start getting into
language extensions or hardware features, etc.



Back to Ada vs. C.  Ada, as specified, does a rather complete job
of eliminating bugs caused by single character typos.  (Ref the
DO statement problem)  One which it will not catch is that case
where two variables whose names differ by one character are both
declared in the same scope.
 
C, on the other hand, does still have cases where the placement
of a semicolon in the wrong place will alter the meaning of a
program without having a failed compile (Yes, I know Lint can ask
about things like this.  I know some compilers warn about
assumptions they are making.  ANyone out there ever use PL/C?).

Re: if UNIX then USE_C ?? (was: Reasons for drop)

[John F Nixon]

kassover@jupiter.crd.ge.com (David Kassover) writes:
>Back to Ada vs. C.  Ada, as specified, does a rather complete job
                 ^
>of eliminating bugs caused by single character typos.  (Ref the
>DO statement problem)

Sorry, you must be thinking of FORTRAN (e.g., DO 100 I = 1.10), not C.
If c.l.a is going to be comparing languages, let's get them right.

--
----
jnixon@atl.ge.com                    ...steinmetz!atl.decnet!jnxion

Re: if UNIX then USE_C ?? (was: Reasons for drop)

[David Kassover]

In article <204@puma.ge.com> jnixon@andrew.ATL.GE.COM (John F Nixon) writes:
>Sorry, you must be thinking of FORTRAN (e.g., DO 100 I = 1.10), not C.
>If c.l.a is going to be comparing languages, let's get them right.
>
No need to apologize, I *was* thinking of FORTRAN, specifically
that example, since we discussed it in particular.
 
But it is possible to make single character mistakes in C.
Just as bad, you can make single word mistakes in C, since there
are cases where things like semicolons and breaks are optional.

(Unless I misunderstand, or those options have been eliminated
since I read K&R.  If so, I apologise)

Or even worse, I think, is the use of {} for many different kinds
of block statements.  In Ada I end a loop with end loop;  I end
an if with end if;
 
In C, both of these things are delimited by {}.  Can anyone out
there honestly say he's never got his braces tangled?  8-)
(That's a pun, by the way)

FORTRAN is even worse:
 
	DO 100 I=1,10
	DO 100 J=1,10
	   .
	   .
	   .
100	CONTINUE
	   .
	   .
	   .
	GOTO 100

At least VAX FORTRAN provides an ENDDO and a DO WHILE

Re: if UNIX then USE_C ?? (was: Reasons for drop)

[John F Nixon]

kassover@jupiter.crd.ge.com (David Kassover) writes:
>No need to apologize, I *was* thinking of FORTRAN, specifically
>that example, since we discussed it in particular.

Whoops, I though you were talking about C.

>But it is possible to make single character mistakes in C.

It is possible to make single character mistakes in Ada.  Suppose I have
a loop named MISSLE_A and a loop (interior to MISSLE_A) named MISSLE_B.
I can "exit" a named loop, and screw up the name.  Admittedly a contrived
example, but the principle extends to anything with a name (identifiers,
types, ...).  Nothing in *Ada* prevents this, only the discipline of the
software developer.

C does have several built in traps (= vs. ==), but there are ways of
dealing with these problems at the developer level.

----
jnixon@atl.ge.com                    ...steinmetz!atl.decnet!jnxion

Re: if UNIX then USE_C ?? (was: Reasons for drop)

[David Kassover]

In article <209@puma.ge.com> jnixon@andrew.ATL.GE.COM (John F Nixon) writes:
>It is possible to make single character mistakes in Ada.
...

 I thought I said that.  I thought I gave an example analogous to
yours, involving quantites declared by the programmer with one
character differences.

We often do this kind of thing because we don't want to type
stuff like in COBOL programs where everything with less than 3
_'s is a reserved word.
 
It's difficult to avoid when it is necessary to type an explicit
index into an array, so as to specifically distinguish x(1) from
x(2).

(it is impractical to avoid *all* litterals)

My personal preference for Ada over C has to do with the fact
that when I must write (or FIX) a program, the less time I spend
avoiding traps rather than doing my work, the better.

Also, personally, I have a hard time reading one-line wonders,
especially other people's.  It's harder to create such in Ada,
therefore I see less of them.

Re: if UNIX then USE_C ?? (was: Reasons for drop)

[Jeremy Epstein]

[I promised myself I wouldn't join this grudge match, but...]

In article <5563@crdgw1.crd.ge.com>, kassover@jupiter.crd.ge.com (David Kassover) writes:
> In article <204@puma.ge.com> jnixon@andrew.ATL.GE.COM (John F Nixon) writes:
> Or even worse, I think, is the use of {} for many different kinds
> of block statements.  In Ada I end a loop with end loop;  I end
> an if with end if;

While that's certainly true, look at how Ada overloads symbols.  For
example, parentheses are used for parameters as well as subscripts
(that's something that totally confuses me as an old-time C programmer).
And while we're on the subject of Ada "end", why is it that Ada sometimes
uses "end" to match "begin", and other times to match other keywords?
-- 
Jeremy Epstein
epstein@trwacs.uu.net
TRW Systems Division
703-876-4202

Re: if UNIX then USE_C ?? (was: Reasons for drop)

[Alex Blakemore]

In article <184@trwacs.UUCP> epstein@trwacs.UUCP (Jeremy Epstein) writes:
> ... look at how Ada overloads symbols.  For
> example, parentheses are used for parameters as well as subscripts
> (that's something that totally confuses me as an old-time C programmer).

This is a strength of Ada not an inconsistency.  This way you can change
between using an array and a function to provide some info - for example
the text sin(x) refers to some real value.  sin could be a constant
array or a function (a time/space tradeoff) - only the providing package
need know.  You can change your mind in one place and need only recompile.
Provided you avoid named parameter association in this case.

This is consistent with some formal proof methods (like Tony Hoare's)
which treat array references as function calls. Logically they
have the same effect.  Mathematically a function is essentially a table
anyway.  Of course, there is a difference when you assign to an array
element.

The same syntactic overloading lets you reference a constant, variable
or parameterless function using the exact same syntax.  One safe way
to have read only global variables is to define a visible (spec level)
function that returns the current value, but hide the variable inside
the package body - so only trusted operations can update it. Again, 
why should the code making the reference need to know how it is resolved-
that is between the owning package and the compiler?

C has some elegance but why should the programmer have to remember
when to use [] or () ?  just to make the compiler easier to write ?

--
-------------------------------------------------------------------------
Alex Blakemore             blakemore@software.org          (703) 742-7125
Software Productivity Consortium   2214 Rock Hill Road Herndon, VA  22070
------------------------   Eschew Obfuscation !!! -----------------------

Ada functions versus arrays (i.e. () vs [] )

[Richard A Hammond]

In article <598@software.software.org> blakemor@software.org (Alex Blakemore) writes:
>In article <184@trwacs.UUCP> epstein@trwacs.UUCP (Jeremy Epstein) writes:
>> ... look at how Ada overloads symbols.  For
>> example, parentheses are used for parameters as well as subscripts
>> (that's something that totally confuses me as an old-time C programmer).

>This is a strength of Ada not an inconsistency.  This way you can change
>between using an array and a function to provide some info  ...

>This is consistent with some formal proof methods (like Tony Hoare's)
>which treat array references as function calls. Logically they
>have the same effect.  Mathematically a function is essentially a table
>anyway.  Of course, there is a difference when you assign to an array
>element.

...

>C has some elegance but why should the programmer have to remember
>when to use [] or () ?  just to make the compiler easier to write ?

Last point first:  I think the reason is to give the programmer a cue
to what is going on.  Remember, the goal of C is to provide constructs
which map in a straightforward way to machine code.  Thus, the C
programmer is interested in the difference between an
array reference and a function call.  Besides, functions in C have the
attributes of Ada procedures and Ada functions, i.e. the Ada
function is more limited than a C function(no out or in/out parameters).
So in C: a = b(d,e) + f; could modify the value not just of a, but of
what d and/or e pointed to (if they were access types) or d/e themselves
if they are defined via macros as more complicated objects.

In fact, the argument that "an array ref" is the same as a "function call"
is true for mathematical functions but not Ada ones.  Ada functions can
have side effects, which is a software engineering deficiency in Ada.

For that reason, I'd want to know when a function call is being made.
Even a function without parameters, which is why I like C's "foo()" better
than Ada's "foo" for calling a parameterless function.
And why I'd like to distinguish between function calls and array refs.

Please, I'm trying to discuss Ada and not Ada versus C, except that
because C does some things wrong doesn't mean you can't steal the
good ideas.

Rich Hammond

Re: Ada functions versus arrays (i.e. () vs [] )

[Alex Blakemore]

I previously posted the next two lines AB
> >C has some elegance but why should the programmer have to remember
> >when to use [] or () ?  

In article <5619@crdgw1.crd.ge.com> hammondr@sunroof.crd.ge.com (Richard A Hammond) writes:
> ...  I think the reason is to give the programmer a cue
> to what is going on.  Remember, the goal of C is to provide constructs
> which map in a straightforward way to machine code.

That is not Ada's goal (as most compilers remind us :-)
The question is what you mean by "what is going on".
The important thing for the caller is the type and content of whatever
name (args) returns, not how/when it is computed.  (That is important too,
but the responsibility for that lies with the code providing the service.)

> The C programmer is interested in the difference between an
> array reference and a function call.

So are Ada programmers, no one is keeping that information from you.
You are free to go look in the package spec any time to see what exactly 
you are referencing.  And if you dont like the way it is implemented,
you can change it IN EXACTLY ONE PLACE. The meaning of calling programs
is not changed if the switch between array/function implements the same
abstract function.  Only their efficiency changes.

(i.e. Ada allows you do it right, there are still ways to mess it up such as ...)

> In fact, the argument that "an array ref" is the same as a "function call"
> is true for mathematical functions but not Ada ones.  Ada functions can
> have side effects, which is a software engineering deficiency in Ada.

I agree that side effects are best avoided - they definitely mess up this
scheme.  I assume the language designers left them in for the 
very few times when they are justifiable (e.g. next_random_number).
Quite possibly a language design error forced on them by C programmers :-)

At least this syntactic overloading is consistent with other Ada features,
such as private types.  One of the things I love about Ada is being able
to encapsulate the representation of a type or object using a private type.
Again, this doesnt mean the user of the type shouldn't know how it is
implemented.  It means he can confidently change the representation
in one place and easily reason about how that change will affect
the rest of the program (if at all).

--
-------------------------------------------------------------------------
Alex Blakemore             blakemore@software.org          (703) 742-7125
Software Productivity Consortium   2214 Rock Hill Road Herndon, VA  22070
------------------------   Eschew Obfuscation !!! -----------------------

Re: Ada functions versus arrays (i.e. () vs [] )

[Robert Firth]

In article <608@software.software.org> blakemor@software.org (Alex Blakemore) writes:

>I agree that side effects are best avoided - they definitely mess up this
>scheme.  I assume the language designers left them in for the 
>very few times when they are justifiable (e.g. next_random_number).
>Quite possibly a language design error forced on them by C programmers :-)

As I recall, we left them in for the same reason Algol-60 did: it is
impossible to rule out the bad uses without also ruling out the good
ones.  It is the responsibility of the programmer not to employ the
bad uses.

Let me give you a couple of examples that fall within the present
discussion.  You have to implement a mapping of some kind - call
it M.  The user then writes M(I) to apply the mapping to object I
in the domain of M.

Initially, this domain is small and compact, so you implement M
as an array.  During subsequent maintenance, it becomes rather
large, so you implement M as a virtual array, ie an array that is
held on backing store.  M is now a function that - shock! horror!
keeps an internal buffer cache and does some hairy I/O periodically.

This is a side effect that any rule would prohibit.  But it is a
good one: M appears to the user as a pure function; its implementation
is of no consequence and should not be visible to the invoker.  To
force M to be rewritten as a procedure pollutes the use context with
information about the implementation.

As a second example, consider a dictionary used by a spelling checker.
There is a function Check(W) that checks whether W is in the dictionary.
Many implementations of this function are adaptive: they use a temporary
cache of some kind that is dynamically reorganised so that words
occurring frequently in the document in question float to the front.
Over a long document, this can substantially speed the checking process.
Again, this is a benign and proper use of side effects within a function.

Robert Firth

Re: Ada functions versus arrays (i.e. () vs [] )

[Mike Harrison]

In article <6281@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:

>As a second example, consider a dictionary used by a spelling checker.
>There is a function Check(W) that checks whether W is in the dictionary.
>Many implementations of this function are adaptive: they use a temporary
>cache of some kind that is dynamically reorganised so that words
>occurring frequently in the document in question float to the front.
>Over a long document, this can substantially speed the checking process.
>Again, this is a benign and proper use of side effects within a function.

I question whether this is really a side-effect.
Clearly it is a side-effect at the level of the implementation, in that it
causes a change of state from a call of the function, but if you view the 
function as a mapping from elements of its domain to elements of its range
then there is no observable change at the appropriate level of abstraction.

This is not a disagreement with Robert's point, because the Ada code of the 
function body will clearly cause side-effects.
It is rather an attempt to point out that 'pernicious' side-effects are those
which are visible at the same level of abstraction as the function definition,
rather than its implementation.

The problem is writing a compiler which can recognise the distinction.

Mike,




Michael P. Harrison - Software Group - Inmos Ltd. UK.
-----------------------------------------------------------
UK : mph@inmos.co.uk             with STANDARD_DISCLAIMERS;
US : mph@inmos.com               use  STANDARD_DISCLAIMERS;

Re: Ada functions versus arrays (i.e. () vs [] )

[Scott Simpson]

In article <6281@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
>In article <608@software.software.org> blakemor@software.org (Alex Blakemore) writes:
>
>>I agree that side effects are best avoided - they definitely mess up this
>>scheme.  I assume the language designers left them in for the 
>>very few times when they are justifiable (e.g. next_random_number).
>>Quite possibly a language design error forced on them by C programmers :-)
>
>As I recall, we left them in for the same reason Algol-60 did: it is
>impossible to rule out the bad uses without also ruling out the good
>ones.  It is the responsibility of the programmer not to employ the
>bad uses.

Meyer summed this up much more beautifully I think in his book
Object-Oriented Software Construction when he said that side-effects
are harmless when they only affect the *concrete* state and not the
*abstract* state.  This division is important.  See section 7.7.3, page
135 of OOSC.
Scott Simpson    TRW Information Networks Division    simpson@trwind.trw.com

Re: Ada functions versus arrays (i.e. () vs [] )

[Mike Harrison]

In article <608@software.software.org> blakemor@software.org (Alex Blakemore) writes:

>I agree that side effects are best avoided - they definitely mess up this
>scheme.  I assume the language designers left them in for the 
>very few times when they are justifiable (e.g. next_random_number).
>Quite possibly a language design error forced on them by C programmers :-)
>
Remember that preliminary Ada had procedures, functions *and* 'value-returning
procedures'. 
Functions were not allowed to have side-effects, value-returning procedures
were.

It's all a long time ago but, I talked to several members of the design team 
about this, and if my memory is correct, the problem was that detecting
side-effects in non-trivial functions (written in an imperative langauge) was
impracticable (if not impossible).
So they decided not to include in the language concepts which could not be 
enforced.
The same argument (about side-effects) also led to the removal of the ASSERT
statement.

Mike,


Michael P. Harrison - Software Group - Inmos Ltd. UK.
-----------------------------------------------------------
UK : mph@inmos.co.uk             with STANDARD_DISCLAIMERS;
US : mph@inmos.com               use  STANDARD_DISCLAIMERS;

Re: Ada functions versus arrays (i.e. () vs [] )

[Erland Sommarskog]

I think the main reason that Ada does not use [] for array
indexing is that symbols like () are far easier to read
than using letters like C does. Of course Ada could have
used something like (..) as Pascal permit, but it feels
clumsy. And the flexibility aspect of being able to switch
between an array and a function is not to be disregarded.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se

Re: Ada functions versus arrays (i.e. () vs [] )

[John Goodenough]

In article Re: Ada functions versus arrays (i.e. () vs [] ) of 6 Mar 90
19:13:21 GMT sommar@enea.se (Erland Sommarskog) writes:

>I think the main reason that Ada does not use [] for array
>indexing is that symbols like () are far easier to read
>than using letters like C does. Of course Ada could have
>used something like (..) as Pascal permit, but it feels
>clumsy. And the flexibility aspect of being able to switch
>between an array and a function is not to be disregarded.

All these are plausible reasons, but the real reason is appallingly mundane --
the requirements specification for Ada directed that all Ada programs be
representable in a small character set, the basic_characters, and this
character set does not include [ and ].  (Although the possible use of
brackets was discussed at at least one design review meeting, given the
character set requirement, the possibility was dismissed almost immediately.)


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

Re: if UNIX then USE_C ?? (was: Reasons for drop)

[RCAPENER]

In article <598@software.software.org>, blakemor@software.org (Alex Blakemore
writes:
> 
> C has some elegance but why should the programmer have to remember
> when to use [] or () ?  just to make the compiler easier to write ?
> 

Well, heck, I thought it was because we wanted to distinguish arrays
from other constructs. (8-)  If you want to talk about making a compiler
easier to write, how about those semicolons in PASCAL?  Obviously, it
has created so much consternation and problems that Borland allows lots
of slack on where you can put the consarned things!  Then there is Ada.
Damn the torpedos, full speed ahead in writing a language that is so
big that in rivals Common LISP in size, and the writing of a compiler
for it is one of the major undertakings of the past decade.  Is there
REALLY a full-featured Ada compiler out there that has all the features
that it is supposed to have?

					Using friends' account
					Mail flames to:
					dharvey@wsccs.weber.edu

Re: if UNIX then USE_C ?? (was: Reasons for drop)

[David Kassover]

In article <184@trwacs.UUCP> epstein@trwacs.UUCP (Jeremy Epstein) writes:
>[I promised myself I wouldn't join this grudge match, but...]
>
>In article <5563@crdgw1.crd.ge.com>, kassover@jupiter.crd.ge.com (David Kassover) writes:
>> In article <204@puma.ge.com> jnixon@andrew.ATL.GE.COM (John F Nixon) writes:
>> Or even worse, I think, is the use of {} for many different kinds
>> of block statements.  In Ada I end a loop with end loop;  I end
>> an if with end if;
>
>While that's certainly true, look at how Ada overloads symbols.  For
>example, parentheses are used for parameters as well as subscripts

Sigh.  I promised myself I would stop.  Oh, well.
 

C is the first language  (no, wait a minute, I've repressed
Basic.  I think.  I can't remember...) I encountered that used [
] for subscripts.  Not to mention a doubly dimensioned array
using the notation [][]  (which *really* screwed me up once,
because the comma is an operator and the syntax x [a,b] is
perfectly legal, even when x is declared [i] [j])  In ada,
pointers are pointers and arrays are arrays, and never the twain
will share syntax.
 
In Fortran, there is really very little to distinguish a function
call from an array reference.  In fact, I submit that from the
standpoint of examining a program that contains a statement such
as
 
 	A = F (i,j,k)
 
it really doesn't matter whether a simple memory transfer or a
complex subprogram execution is called for.  What can screw you
up here is a "SIDE EFFECT", which Ada flatly refuses to allow.
(Has anyone out there *never* done something like:
 
	A = F(1)

where F was a function that caused a side effect that changed
*all* literal 1's to 3.14159265's (or whatever integer those bits
happened to represent?  What, not never?)
 
And while we're on the subject of side effects, the C treatment
of assignment as a function that returns a value, with the side
effect of making the assignment has balled me up more than once.
Especially when I tried to get too cute with fancy one-line
wonder macros that expanded in grand and glorious unanticipated ways...
 
 
Jeremy also mentions that in Ada the word end is used as a
closure for begin, and also as a closure for loop, and also as a
closure for if...
 
End all by itself ends begin.  End loop ends a loop, and if you
try to make it end an if, the compiler will complain.  If you
want to end an if, you must use end if;  If you want to end a
named loop, you must use an end loop AND reference the name of
the named loop.  End all by itself, without a matching begin,
will cause a complaint from the compiler.  This is a lot
different from } ending the last unmatched {.

Re: if UNIX then USE_C ?? (was: Reasons for drop)

[Steve Tynor]

In article <5638@crdgw1.crd.ge.com> kassover@control.crd.ge.com (David Kassover) writes:
>complex subprogram execution is called for.  What can screw you
>up here is a "SIDE EFFECT", which Ada flatly refuses to allow.

It's perfectly legal to write functions with side effects in Ada - there's no
restriction on what happens in the function's body - the only restriction Ada
makes is that a function's _parameters_ must not be affected (hence `in' only).

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
inherit STD_DISCLAIMER; -- Insist on Eiffel!
                     
    Steve Tynor
    Georgia Tech Research Institute
    Artificial Intelligence Branch
    tynor@prism.gatech.edu

Re: if UNIX then USE_C ?? (was: Reasons for drop)

[David Kassover]

In article <6553@hydra.gatech.EDU> tynor@prism.gatech.EDU (Steve Tynor) writes:
>In article <5638@crdgw1.crd.ge.com> kassover@control.crd.ge.com (David Kassover) writes:
>>complex subprogram execution is called for.  What can screw you
>>up here is a "SIDE EFFECT", which Ada flatly refuses to allow.
>

It should be obvious by now that what I was referring to as a
SIDE EFFECT was the changing of the values of parameters of
functions, that is, a PARAMETER that gets changed incidentally to
the generation of the return value.  This is how I have always
understood the term to be meant, as mentioned in K&R and K&P.
 

Re: if UNIX then USE_C ?? (was: Reasons for drop)

[Robert D. Houk]

In article <5563@crdgw1.crd.ge.com> kassover@jupiter.crd.ge.com (David Kassover) writes:

   Or even worse, I think, is the use of {} for many different kinds
   of block statements.  In Ada I end a loop with end loop;  I end
   an if with end if;

   In C, both of these things are delimited by {}.  Can anyone out
   there honestly say he's never got his braces tangled?  8-)
   (That's a pun, by the way)

Yeah, I've tangled up {}'s in C proggies. I've also put in lots of
"endif"s and just plain "end"s in Ada. And I've left ";"s out of both.
Overall, I prefer {}'s simply because they emphasize or make code blocks
stand out better when perusing the listing (to my way of thinking anyways)
[i.e., I look at "end if;" and want to see a meaningful source statement
at the same code-level as the originating "if" clause, not a tail-end of
something earlier. I don't know if that makes sense to anyone, but that's
the way I think...]

					-RDH
--
  "If you build a system                 RDH@SLI.COM  |	 uunet!sli!rdh
 that even a fool could use,             Robert D. Houk
   then only a fool                      Software Leverage, Inc.
 would want to use your system."         485 Massachusetts Avenue
        -Somebody-r-Other's Law          Arlington, Mass.  02174
                                         Office (617) 648-1414

Re: if UNIX then USE_C ?? (was: Reasons for drop)

[Andy DeFaria]

>/ hpclapd:comp.lang.ada / epstein@trwacs.UUCP (Jeremy Epstein) / 10:55 am  Feb 27, 1990 /
>[I promised myself I wouldn't join this grudge match, but...]

>While that's certainly true, look at how Ada overloads symbols.  For
>example, parentheses are used for parameters as well as subscripts
>(that's something that totally confuses me as an old-time C programmer).

Why does C insist on differentiating between "=" meaning assignment and "="
meaning equality test.  People naturally write "A = B" and "if  A  = B...".
Based on the context the compiler should be able  to figure out whether the
"=" sign refers to assignment or equality test.   I know  that C allows you
to do the  assignment and  then check the value of  the assignment and that
this is often useful but it is IMO something that totally  confuses me as a
novice C programmer.

>And while we're on the subject of Ada "end", why is it that Ada sometimes
>uses "end" to match "begin", and other times to match other keywords?

I looks like you  need a little  look-ahead.  Ada matches  a  "end" with  a
"begin" but matches an "end if" with an "if" ("end  case" with "case", "end
loop" with "loop", etc).

Re: Reasons for dropping Ada

[Jeffrey M. Schweiger]

In article <19409@grebyn.com> ted@grebyn.com (Ted Holden) writes:
>
> 
[ much stuff deleted ...] 
> 
>...  My personal experience with Ada has been in connection
>with my work as a systems consultant with SofTech/EER of Vienna, Va. and
>involved writing Ada/C and Ada/4GL interfaces, typically 300 or fewer lines
>of code, and then watching Ada compilers take 30 minutes to compile those
>little programs into 400K executables. ... 
> 

Ted -

If you think that the above numbers are typical of Ada, you are much mistaken.
If they are an exageration that you are using to make a point, it isn't very
credible, and using such exagerations totally buries any valid points you
might have.  For what it's worth, last summer I wrote a 1000+ lines of code
Ada program in about 3 weeks.  It compiles in about 2 1/2 minutes and
generates an executable of less than 85K in size (BTW, it does work).  This
was written using the IntegrAda compiler on a 386/20 machine.

Jeff Schweiger

-- 
*******************************************************************************
Jeff Schweiger	  CompuServe:  74236,1645	Standard Disclaimer
ARPAnet (Defense Data Network):		        schweige@cs.nps.navy.mil
*******************************************************************************