C++ vs. Ada -- Is Ada loosing?
srhe...@happy.colorado.edu
sliced bread. C++ is a truly wonderful toy because you can redefine the
language for your application.
For example you can provide the function that is invoked in response to
assignment so you can optimize your matrix class to (1) only pass a pointer to
the matrix data instead of actually making a physical copy and (2) defer the
actual copy operation to the point in time when (and if) the target of the
assignment is modified. This is impressive.
HOWEVER, please read "A dynamic Vector is harder than it looks" from the June
1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5 no 4.
*THIS ARTICLE IS SCARY* Basically Tom Cargill pointed out a bug that nearly
all C++ textbooks have made when they implement a dynamically sized array.
This includes the textbook written by the implementor of the AT&T Cfront
compiler (will I get in trouble if I mention his name?). If the language is so
convoluted that even the experts (including the compiler writers) cannot get
their simple textbook examples correct, then I conclude there is something
drastically wrong with the language.
I don't want anybody writing code in C++ for satellites funded with my tax
dollars!
I heard a rumer about a multi-million (or multi-billion) dollar satellite going
astray because some one left a comma out of a FORTRAN DO loop and it was still
syntactically legal. Can anybody give me a reference on this?
So we have C++ with very similar problems to this problem in FORTRAN that (I
believe, correct me if I am wrong) Ada was supposed to solve. You can insert a
";" between the ")" and the "{" in any while or if statement and the C++
program is still syntactically correct but semantically disasterous.
So, Ada was on the seen. I spent some significant time as a project lead with
Ada in '89-90. I was excited about the language. Now I am independent and
make my living with C++.
Where is Ada going? Is it dying? That thread on "Is GNU-Ada self-insulting"
suggests that Ada is floundering. How badly is Ada floundering? Does that mean
I'll never see inheritance in Ada?
Thanks,
Sieg
Mark A Biggar
>Where is Ada going? Is it dying? That thread on "Is GNU-Ada self-insulting"
>suggests that Ada is floundering. How badly is Ada floundering? Does that mean
>I'll never see inheritance in Ada?
But, Ada already has inheritance. That's what derived types provide. What
Ada doesn't currently have are type extension and dynamic dispatching, Both
of which are being added to Ada9x.
--
Mark Biggar
m...@wdl1.wdl.loral.com
Kurt Olender
srhe...@happy.colorado.edu writes:
... stuff deleted ...
HOWEVER, please read "A dynamic Vector is harder than it looks" from the
June 1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5
no 4. *THIS ARTICLE IS SCARY* Basically Tom Cargill pointed out a bug that
nearly all C++ textbooks have made when they implement a dynamically sized
array. This includes the textbook written by the implementor of the AT&T
Cfront compiler (will I get in trouble if I mention his name?). If the
language is so convoluted that even the experts (including the compiler
writers) cannot get their simple textbook examples correct, then I conclude
there is something drastically wrong with the language.
Well, without making any statements about the relative merits of Ada and C++,
I don't think you can make much real hay out of this fact. After all, legend
has it that that it was 10 years from the first publication of a binary search
algorithm to the first publication of a correct binary search algorithm.
Perhaps it only says that we're not really good at these things, until we've
done them a few (dozens, hundreds, thousands?) of times.
news
[...is Ada losing?...]
No. It LOST. You've simply got your tense wrong.
--
Ted Holden
HTE
Gregory Aharonian
"Can a language nurtured in a socialist environment (Ada) compete with
a language nurtured in a free market environment (C/C++)?"
Note this shifts the argument (as I have been long arguing, apparently to
myself) away from language syntax and semantics, and towards language
socioeconomics.
Posed this way, one answer would be that "Ada started in at most fourth
place (after Cobol, Fortran, and C/C++) and will never catch up".
C/C++ is an imperfect language that thrives because its flaws creates
markets for software tools that create more use of the language and more
tools, etc., resulting in a thriving market. (One of the early claims of
some Ada vendors was that you didn't need many software tools to use Ada.)
C/C++ is an open language, constantly being debated, as well as its
environments and methodologies, subject to the evolutionary forces of the
free markets. Ada is hostage to a bureacracy that suppresses criticism
and ignores free markets.
Thus, if you had money to invest in a software company, would you do it
for Ada or C/C++?
Greg Aharonian
--
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178
Dag Bruck
>
>HOWEVER, please read "A dynamic Vector is harder than it looks" from the June
>1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5 no 4.
>*THIS ARTICLE IS SCARY* Basically Tom Cargill pointed out a bug that nearly
>all C++ textbooks have made when they implement a dynamically sized array.
>This includes the textbook written by the implementor of the AT&T Cfront
>compiler (will I get in trouble if I mention his name?). If the language is so
>convoluted that even the experts (including the compiler writers) cannot get
>their simple textbook examples correct, then I conclude there is something
>drastically wrong with the language.
I agree that Tom Cargill wrote an interesting article, but I think the
conclusion is exactly what Cargill writes: a dynamic vector class is
harder than it looks.
People sometimes fall into the trap of thinking that hard problems are
easier to solve with a "stricter" programming language. This is often
not the case. It is particularly difficult to realize a library that
is natural to use, and at the same time efficient with regard to space
and time. A matrix library is a good example:
- a trivial matrix library is not hard to write
- it becomes much harder if you want to implement a full
set of natural operations, e.g., slices
- it becomes harder if you want to provide automatic
memory management
- it becomes *much* harder if you want to provide "optimal"
memory management that immediately reuses space for used
temporaries.
[Optimal space utilization is for example to use only one temporary
variable to calculate the matrix expression "X := A+B+C".]
Dag Bruck
Jorge Luis Diaz-Herrera
|> 1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5 no 4.
|> *THIS ARTICLE IS SCARY* Basically Tom Cargill pointed out a bug that nearly
|> all C++ textbooks have made when they implement a dynamically sized array.
|> This includes the textbook written by the implementor of the AT&T Cfront
|> compiler (will I get in trouble if I mention his name?). If the language is so
|> convoluted that even the experts (including the compiler writers) cannot get
|> their simple textbook examples correct, then I conclude there is something
|> drastically wrong with the language.
|> Thanks,
|> Sieg
I could not find this article! The June issue is volume 3 (not there) and
vlume 4 is July/August (not there!!)
jld-h
--..--
Robert I. Eachus
Nice to get some facts in here. As I remember it, there were two
bugs involving Venus probes. One was code that assumed that an
uninitialized variable always start life equal to zero. When this code
was rerun after several months in space... The FORTRAN bug which
resulted in the destruction of the first Venus probe was that in:
DO 20 I = 1,10
the comma was replaced by a period:
DO 20 I = 1.10
of course in FORTRAN (in particular FORTRAN 66) the spaces are
ignored, and this was interpreted as:
DO20I = 1.10
(Implicitly declaring a real variable DO20I and assigning to it.)
This had not caused a problem on earlier launches as the loop was to
refine the amount of correction for wind, and a single repetition was
usually enough. But when a gust hit, the inaccurate calculation
resulted in an oscillation, and the RSO destroyed the missile.
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
Richard Harter
>
> Nice to get some facts in here. As I remember it, there were two
>bugs involving Venus probes. One was code that assumed that an
>uninitialized variable always start life equal to zero. When this code
>was rerun after several months in space... The FORTRAN bug which
>resulted in the destruction of the first Venus probe was that in:
>
> DO 20 I = 1,10
>
>the comma was replaced by a period:
>
> DO 20 I = 1.10
The history of this particular bit of computer folklore has been gone
over thoroughly in the alt.computer.folklore group a number of times.
First of all the blow up was due to the misreading of a superscript
in creating the formal specs for the program from the mathematics.
The program was in assembler; the assembly program correctly reflected
the specs; the specs were wrong.
The comma-period bug was in an ephemerides program at Johnson Space
Center. It was not a real time program; it was a data analysis program.
The bug was caught because the output was palpably wrong.
The sequence of events went through several authors who rearranged
history bit by bit (you should excuse the expression) until the proper
moral was reached.
--
Richard Harter: SMDS Inc. Net address: r...@smds.com Phone: 508-369-7398
US Mail: SMDS Inc., PO Box 555, Concord MA 01742. Fax: 508-369-8272
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
J. Giles
|> [...] The FORTRAN bug which
|> >resulted in the destruction of the first Venus probe was that in:
|> >
|> > DO 20 I = 1,10
|> >
|> >the comma was replaced by a period:
|> >
|> > DO 20 I = 1.10
|> [...]
|> First of all the blow up was due to the misreading of a superscript
|> in creating the formal specs for the program from the mathematics.
|> The program was in assembler; the assembly program correctly reflected
|> the specs; the specs were wrong.
|>
|> The comma-period bug was in an ephemerides program at Johnson Space
|> Center. It was not a real time program; it was a data analysis program.
|> The bug was caught because the output was palpably wrong.
|>
|> The sequence of events went through several authors who rearranged
|> history bit by bit (you should excuse the expression) until the proper
|> moral was reached.
Well, not quite. The proper moral is that all programming languages
(even informal specification languages) have contexts in which single
character errors can lead to linguistically correct programs which
don't compute the intended functionality. The moral often stated
instead is that this is a bad feature of Fortran. While Fortran
could indeed have been designed better, it is not the only language
with, or even the most severly affected by, this kind of problem.
--
J. Giles
Todd A Sorensen
>
> Where is Ada going? Is it dying? That thread on "Is GNU-Ada self-insulting"
> suggests that Ada is floundering. How badly is Ada floundering? Does that mean
> I'll never see inheritance in Ada?
>
> Thanks,
> Sieg
I can tell you that Ada is alive and well at most Honeywell Divisions. Almost
all of the programs here are now being developed or translated into Ada. This
was a big step from Jovial and C which use a lot of pointers to manipulate data
in our real-time systems. Ada 9X should bring Ada up to date, although you can
still write very good (maintainable) code with Ada 83.
--
-------------------------------------------------------------------------------
Todd A Sorensen Honeywell Defense Avionics Systems Division
(505) 828-5611 internet: t...@dasd.honeywell.com
fax: (505) 828-5500
-------------------------------------------------------------------------------
Are You Free if you have a Job?
-------------------------------------------------------------------------------
Michael Feldman
[stuff deleted]
>
>Well, not quite. The proper moral is that all programming languages
>(even informal specification languages) have contexts in which single
>character errors can lead to linguistically correct programs which
>don't compute the intended functionality. The moral often stated
>instead is that this is a bad feature of Fortran. While Fortran
>could indeed have been designed better, it is not the only language
>with, or even the most severly affected by, this kind of problem.
>
You make a good point. Perhaps the modern equivalent of that Fortran
single-keystroke bug is my favorite bit of C code (and no, I don't
want to bash C, just point out how common these flukes are):
int x;
...
x = 1;
while (x <= 10);
{
printf("%d\n", x);
x++;
}
For 10 points on your grade: what is printed? Why?
Try explaining it to a freshman.
Any similar idiosyncracies in Ada?
Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee
Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfel...@seas.gwu.edu (Internet)
"Americans want the fruits of patience -- and they want them now."
------------------------------------------------------------------------
Michael Ben-Gershon
>
> HOWEVER, please read "A dynamic Vector is harder than it looks" from the
> June 1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5
> no 4. *THIS ARTICLE IS SCARY*
I searched for the article you mention, but couldn't find it. The June
1992 issue of JOOP is Vol 5 no 3, but I looked at July/August (vol 5 no 4)
and also September - November and still couldn't find it. Are you sure
that you gave the correct reference?
Michael Ben-Gershon
my...@cs.huji.ac.il
Dag Bruck
>
> HOWEVER, please read "A dynamic Vector is harder than it looks" from the
> June 1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5
> no 4. *THIS ARTICLE IS SCARY*
Tom Cargill: "A dynamic Vector is harder than it looks," The C++
Report, Vol. 4, No. 5, June 1992.
The article that spawned Tom Cargill to comment is:
Glen McCluskey: "An environment for template instantiation," The C++
Report, Vol. 4, No. 2., February 1992.
Jack Beidler
Practically all of the posting are missing the "real" reason. It has
to do with economic considerations (read my company wants to make
more money). Think of it this way: I'm a governement software
contractor. If I build a perfect, or at least a close to perfect
system, I make all my money (read profit) by the time I deliver
the system. However, if I build a buggy system with unreadable
source code, I make money (again read profit) over the entire life
of the software. Since I can build buggier unreadable software in
C and C++, naturally I want to use C and C++ so I can make more
money over a longer period of time.
--
+------------------------------------------------------------------+
| John (Jack) Beidler |
| Prof. of Computer Science Internet: BEI...@JAGUAR.UOFS.EDU |
| University of Scranton bei...@guinness.cs.uofs.edu|
| Scranton, PA 18510 Bitnet : BEIDLER@SCRANTON |
| |
| Phone: (717) 941-7446 FAX: (717) 941-4250 |
+------------------------------------------------------------------+
Rob Spray
>of the software. Since I can build buggier unreadable software in
>C and C++, naturally I want to use C and C++ so I can make more
>money over a longer period of time.
Yes, but many organizations can support C and C++.
A better scheme is to use a language that few people use,
like HAL/S, DG/L, PL/S or Bliss. That way there's less chance of a
competitor undercutting your rates when the support contract
is recompeted. Even if you've had to deliver a Software Development
Facility as part of the initial contract, it sure helps your BAFO if your
competition has to retrain their personnel to use your language.
Of course, your proposal would have a pretty chart detailing just
how many dedicated professionals you had on tap who were already fluent
in your obscure language.
I recall that this tactic was mentioned in some of the HOLWG papers.
--Rob
--sp...@convex.com
Alex Blakemore
> If I build a perfect ... system, I make all my money ...
> by the time I deliver the system. However, if I build a buggy system with unreadable
> Since I can build buggier unreadable software in
> C and C++, naturally I want to use C and C++ so I can make more
> money over a longer period of time.
It may not be that cynically planned, but I agree economics are a primary driver.
A simpler economic explanation is just that:
the (promised) savings of Ada are experienced by the customer over the long run.
the (real) cost of switching to Ada is experienced by the contractor up front.
the contractor has little or no incentive to save the customer money over the long run,
and may in fact view serious attempts in that direction as contrary to his interest.
so its not suprising that contractors often fight using Ada and that may actually
be a sign that its the right thing to do.
--
---------------------------------------------------
Alex Blakemore al...@cs.umd.edu NeXT mail accepted
fred j mccall 575-3539
>I've enjoyed reading all the postings on why Ada is loosing to C++.
>Practically all of the posting are missing the "real" reason. It has
>to do with economic considerations (read my company wants to make
>more money). Think of it this way: I'm a governement software
>contractor. If I build a perfect, or at least a close to perfect
>system, I make all my money (read profit) by the time I deliver
>the system. However, if I build a buggy system with unreadable
>source code, I make money (again read profit) over the entire life
>of the software. Since I can build buggier unreadable software in
>C and C++, naturally I want to use C and C++ so I can make more
>money over a longer period of time.
More fuel for the flames. <sigh>
Why is it your assumption that anyone who prefers a different language
than you do must be involved in some plot to deliberately write buggy
software?
--
"Insisting on perfect safety is for people who don't have the balls to live
in the real world." -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred....@dseg.ti.com - I don't speak for others and they don't speak for me.
fred j mccall 575-3539
>In article <1992Dec8.1...@newshost.lanl.gov> j...@cochiti.lanl.gov (J. Giles) writes:
>[stuff deleted]
>>
>>Well, not quite. The proper moral is that all programming languages
>>(even informal specification languages) have contexts in which single
>>character errors can lead to linguistically correct programs which
>>don't compute the intended functionality. The moral often stated
>>instead is that this is a bad feature of Fortran. While Fortran
>>could indeed have been designed better, it is not the only language
>>with, or even the most severly affected by, this kind of problem.
>>
>You make a good point. Perhaps the modern equivalent of that Fortran
>single-keystroke bug is my favorite bit of C code (and no, I don't
>want to bash C, just point out how common these flukes are):
> int x;
> ...
> x = 1;
> while (x <= 10);
> {
> printf("%d\n", x);
^^^
> x++;
> }
>For 10 points on your grade: what is printed? Why?
>Try explaining it to a freshman.
Nothing is printed. You built an infinite loop. This is hard to
understand? You made a while loop with an empty body and a condition
that is never met because you never increment x. Your freshmen don't
get this?
>Any similar idiosyncracies in Ada?
Single character ones? Probably not, but that just indicates that Ada
is incredibly more verbose than C. One of the things I DISlike about
it, by the way.
Robb Nebbe
int x;
...
x = 1;
while (x <= 10);
{
printf("%d\n", x);
x++;
}
For 10 points on your grade: what is printed? Why?
Try explaining it to a freshman.
Fred McCall:
Nothing is printed. You built an infinite loop. This is hard to
understand? You made a while loop with an empty body and a condition
that is never met because you never increment x. Your freshmen don't
get this?
Me:
Good syntax means that code should do what it looks like it should do. The
above code is an example of less than optimal bordering on poor language
syntax. The reason being that many compilers don't detect that what is
obviously wrong code is wrong. On top of that the problem is rather inocuous
and if I didn't know that the problem was there I might miss it when reading
through the code. Basically the presence of a typo must be detected by having
your program hang. A far from optimal situation.
The far worse problem with C syntax is the one that caused the problem for
ATT. (This is all second hand so anyone in the know should correct me if I'm
wrong.) A programmer had left out a break in a switch statement. I don't
know the what the actual code was like by a switch looks like this.
switch (x)
{
case 1:
printf("x == 1\n");
break;
case 2:
printf("x == 2\n");
break;
default:
printf("x != 1 && x != 2\n");
}
printf("done");
The break is necessary to leave the switch because the cases only serve as
labels and execution will fall through to the next case statement. This is a
case (no pun) where assembler shows through the C syntax. The machine code that
is generated for the switch is a jump table based on the value of x. At the end
of the statements another jump is required to avoid executing the rest of the
code from the other case statements.
The fact that these problems exist in C is well known and most C texts point
them out. I would like to point out that these idiosyncracies have not
prevented C from being succesfully used in a phenomenal amount of code.
People need to put C in perspective. When people started using C it was
because the choice was between assembler and C for many projects. For larger
projects the choice was between something like FORTRAN with some assembler
and C. My experience in mixing assembler and FORTRAN is very limited but it is
far from a trivial endevour. In both cases I would unhesitatingly choose C.
Now there are other choices such as Ada for doing programs that interface with
the hardware. Why do people keep using C? A lot of it has to do with inertia.
Another reason that we shouldn't forget is that a good C/C++ programmer can
turn out some very high quality code and if it aint broke don't fix it. In
fact I would go as far as to say that well written C/C++ code is almost as
readable as Ada.
The problem with Ada is that it is a lot more difficult to do code generation
in my head ;-) Some of you will scoff but my education is in computer
engineering (thus hardware) and there is a tremendous amount a satisfaction in
knowing what it is that I am telling the hardware to do and not just in the
abstract sense.
When I program in Ada this sense of satisfaction is just not there. Programming
in C is sort of like making a piece of furniture yourself from scratch and
programming in Ada is like buying a kit.
However I put such personal feelings aside when I have to do a project because
my level of confidence in 5000 lines of Ada is definitely higher than my
level of confidence in 5000 lines of C/C++. This isn't that I'm a better
programmer in Ada than in C/C++. To the contrary I'm sure that I master C
better than Ada but I probably know Ada better than C++. The reason is that
when I write code in Ada it usually won't compile if it wasn't what I meant.
In C/C++ the compiler isn't as helpful. For novice Ada programmers however this
is viewed as frusterating because the compiler won't except their code and it
is what they mean :^)
Michael Feldman:
|> >Any similar idiosyncracies in Ada?
Fred McCall:
|>
|> Single character ones? Probably not, but that just indicates that Ada
|> is incredibly more verbose than C. One of the things I DISlike about
|> it, by the way.
Me:
Actually the fact that Ada is verbose has absolutly nothing to do with the
fact that it doesn't have any similar idiosyncracies. The difference is that
the syntax of Ada was studied to avoid such problems and this wasn't a
concern when they thought up the syntax for C. If they designers of C had been
interested in avoiding such problems it wouldn't have been too hard.
Robb Nebbe ne...@lglsun.epfl.ch
P.S. If you don't put the breaks in the switch it would print the following
if x == 1:
x == 1
x == 2
x != 1 && x != 2
done
with breaks and x == 1 it works as one would expect printing
x == 1
done
Tucker Taft
ne...@lglsun.epfl.ch (Robb Nebbe) writes:
> . . .
>The problem with Ada is that it is a lot more difficult to do code generation
>in my head ;-) Some of you will scoff but my education is in computer
>engineering (thus hardware) and there is a tremendous amount a satisfaction in
>knowing what it is that I am telling the hardware to do and not just in the
>abstract sense.
>
>When I program in Ada this sense of satisfaction is just not there. Programming
>in C is sort of like making a piece of furniture yourself from scratch and
>programming in Ada is like buying a kit.
I tend to agree with this assessment of Ada 83.
One of our goals for Ada 9X has been to give system programmers
back this feeling of satisfaction, so that you can do "code generation
in your head" for most Ada constructs. In other words,
you can predict about how many machine instructions (and
generally which ones ;-) will be generated for each
construct in your program. For a real-time embedded language,
this seems particulary important.
For example, an allocator in Ada 9X will be defined in terms
of a call on an appropriate Allocate procedure, user-replacable on
an access-type by access-type basis.
Similarly, a call on an instantiation of Unchecked_Deallocation
becomes a call on an appropriate user-replacable Deallocate routine,
preceded if appropriate by a call on a user-defined Finalize routine.
We have also provided the ability to create an access value
designating a declared variable, so long as it is marked "aliased,"
coupled with more control over by-reference vs. by-copy
parameter passing.
We also allow access to subprograms, allowing a pointer to
a procedure to be passed for the purpose of a call-back,
iteration over a data structure, etc. This avoids some of
the heaviness and somewhat more-difficult-to-predict performance
of generics for certain simple situations.
Finally, the protected type feature is designed to allow
the construction of synchronization primitives with predictable
performance, including things like mailboxes, queues,
counting semaphores, etc.
Given some of these features, we hope that Ada 9X
will provide both the safety and high-level aspects
of Ada 83, but also the more "down-to-earth" feel appropriate for
systems programming, when you want it.
We would appreciate any specific suggestions about this
issue of "control" or "predictability" of implementation
model, as it relates to systems programming in Ada 9X.
S. Tucker Taft s...@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA 02138
Michael Feldman
>
>>For 10 points on your grade: what is printed? Why?
>>Try explaining it to a freshman.
>
>Nothing is printed. You built an infinite loop. This is hard to
>understand? You made a while loop with an empty body and a condition
>that is never met because you never increment x. Your freshmen don't
>get this?
Sure they get it. I just don't want to take my time or theirs on this
kind of silliness. Which is why I keep saying that C should be
everyone's second language and nobody's first.
>
>>Any similar idiosyncracies in Ada?
>
>Single character ones? Probably not, but that just indicates that Ada
>is incredibly more verbose than C. One of the things I DISlike about
>it, by the way.
>
You're certainly entitled to your opinion. I'm not down on C. I'd
rather train my teenager on a nice, verbose, safe car and give him
the keys to the Porsche after he's proven himself on the Chevy.
Less chance he'll waste his time crashing and burning. And the 70% or
more of the freshman teachers who are going to Ada or sticking with
Pascal (only slightly less verbose than Ada) agree.
Please - no more language wars.
Mike
Pascal Obry
Fred,
> Single character ones? Probably not, but that just indicates that Ada
> is incredibly more verbose than C. One of the things I DISlike about
> it, by the way.
Why do you use english ?
( > @ - + / ~ $
==============================
Because I'am the only one to know this language I put below the dictionary :
> this
( try
$ word
+ it
, -
/ is
@ language
~ without
==============================
I like Ada because you can *read* it. And this seem to be one of the most
important thing about a language. With goods choices for the identifier, you
can read an Ada progam like a text, you don't have to translate what you read.
You write a program one time, but how many time you read it ?
Pascal.
--
-------------------------------------------------------------------------------
-- Pascal OBRY --
-- Room 2D-337 e_mail : ob...@bellcore.com --
-- Bellcore --
-- 445 South Street voice : 1 - 201 829 4039 --
-- Post Office Box 1910 FAX : 1 - 201 829 5981 --
-- Morristown, New Jersey 07962-1910 --
-------------------------------------------------------------------------------
`` inheritance is surely a good answer, but who knows the question ? ''
John Nestoriak III
>One of our goals for Ada 9X has been to give system programmers
>back this feeling of satisfaction, so that you can do "code generation
>in your head" for most Ada constructs. In other words,
>you can predict about how many machine instructions (and
>generally which ones ;-) will be generated for each
>construct in your program. For a real-time embedded language,
>this seems particulary important.
Are there plans to add bitwise operations to Ada 9X? Lack of
built in shift operators was a disappointing discovery for me.
I know that Ada is a high order language and therefor less suitable
for manipulating bits than say C, but there are high level functions
that need to manipulate bits. I'm thinking in particular of
compression routines. The project I work on is Ada but we had to
implement compression using C.
Tucker Taft
Yes. We are planning to add "modular types" to Ada 9X,
which are unsigned, wrap-around types with a user-specified
modulus (normally a power-of-2). These types will have +/-, etc.,
bit-wise and, or, xor, and not, as well as a language-defined
generic package that provides shift operations. This
package is intended to be recognized by the compiler, so
that these shift operations result in inline machine instructions for
shifting.
Here is the tentative syntax:
type Unsigned_16 is mod 2**16; -- declare a 16-bit unsigned type
package Shift_16 is new System.Shifts(Unsigned_16); use Shift_16;
-- Get the shift functions
X : Unsigned_16 := 16#00FF#;
Y, Z : Unsigned_16;
begin
Y := Left_Shift(X, 5); -- Try them out
Z := X and Y;
if Z /= 16#00E0# then
Put_Line("Send the 9X compiler back"); -- ;-)
etc...
Bob Kitzberger
>I like Ada because you can *read* it. And this seem to be one of the most
>important thing about a language. With goods choices for the identifier, you
>can read an Ada progam like a text, you don't have to translate what you read.
It is rare that I feel that Ada code is too verbose. One of the instances
that comes to mind is the syntax for representation specifications, which
basically require duplicating the type definition just to provide the repspec.
For hundreds of lines of type specifications (e.g. a protocol definition)
the doubling of line count hinders maintenance (i.e. each change to a
data structure requires at least two changes: one in the type definition,
and one in the rep spec.) OH well.
What is much, much more frustrating are the verbose, useless commenting
standards that one often finds on DoD projects. What was once a
simple subprogram specification, with descriptive identifer names,
too often becomes a morass of useless information, often several
screens full of junk that some DoD or corporate coding standard requires.
Grrrrr.
.Bob.
----------------
Bob Kitzberger VisiCom Laboratories, Inc.
r...@visicom.com 10052 Mesa Ridge Court, San Diego CA 92121 USA
+1 619 457 2111 FAX +1 619 457 0888
Fergus James HENDERSON
>You make a good point. Perhaps the modern equivalent of that Fortran
>single-keystroke bug is my favorite bit of C code (and no, I don't
>want to bash C, just point out how common these flukes are):
>
> int x;
> ...
> x = 1;
> while (x <= 10);
> {
> printf("%d\n", x);
> x++;
> }
A good compiler would give a warning that the call to printf was
unreachable code. The only compiler I have available, gcc, unfortunately
doesn't give any such warning. But the Pascal-subset compiler I wrote (as one
of the projects for a 3rd-year subject) gives the following warnings for
the equivalent Pascal code:
warning: variable 'x' is not used after assignment, so assignment has no effect
warning: 'while' statement will cause an infinite loop
>Any similar idiosyncracies in Ada?
The difference between '<' and '>' is only a single keystroke.
More insidious perhaps is the difference between '<' and '<='.
So it can happen even in Ada.
However I do agree that Ada syntax is less error-prone than C or Fortran.
This is not because it is verbose but rather because the Ada designers took
this issue into careful consideration. I believe that it would be quite
possible to design a syntax that was concise but that was no more error-prone
than Ada.
--
Fergus Henderson f...@munta.cs.mu.OZ.AU
This .signature virus is a self-referential statement that is true - but
you will only be able to consistently believe it if you copy it to your own
.signature file!
Fergus James HENDERSON
>I like Ada because you can *read* it. And this seem to be one of the most
>important thing about a language. With goods choices for the identifier, you
>can read an Ada progam like a text, you don't have to translate what you read.
>
>You write a program one time, but how many time you read it ?
When learning a foreign language, there is a critical point at which you
cease translating from the foreign tongue into your own and back again,
and start to *think* in the foreign language.
The same is true of programming languages. After a very short span of time,
you start to *think* in terms of the constructs that your programming
language offers. Once this point is reached, using symbols instead of
words makes very little difference to the readability. Indeed the more
verbose form may often be less readable. We all learn how to read
mathematical equations - would you prefer that they be spelt out using
"plus" instead of "+", etc.? If you want a language where programs read
like text, try COBOL. Personally I believe that many common programming
language constructs are better expressed symbolically.
Michael Feldman
>
>A good compiler would give a warning that the call to printf was
>unreachable code. The only compiler I have available, gcc, unfortunately
>doesn't give any such warning. But the Pascal-subset compiler I wrote (as one
>of the projects for a 3rd-year subject) gives the following warnings for
>the equivalent Pascal code:
>
>warning: variable 'x' is not used after assignment, so assignment has no effect
>warning: 'while' statement will cause an infinite loop
This is particularly good "advising" on the part of the compiler. A good
compiler is really a rule-based system, with lots of heuristics that
represent the domain expertise (potential logic errors). Most compiler
writers don't bother. The syntax and associated semantics of a carefully
designed language should work to minimize this sort of error anyway.
In the Pascal case, I believe that whether a null statement is legal
turns out to be implementation dependent. Great standard.
>
>>Any similar idiosyncracies in Ada?
>
>The difference between '<' and '>' is only a single keystroke.
>More insidious perhaps is the difference between '<' and '<='.
>So it can happen even in Ada.
Well, this is a bit different. "+" and "*" are single keystrokes too.
Arithmetic operators generally are. At least the operator is saying what it
means a little more clearly.
A better Ada example is the problem of procedure specifications vs. bodies.
PROCEDURE P;
is a valid statement in most contexts, so
PROCEDURE P;
BEGIN
-- something
END P;
will often lead to propagation errors. This is confusing to students
because the error messages don't point to the real error location.
Try it on your favorite compiler; most Ada compilers have little or
no "expertise" that would catch this. Ada/Ed picks up some of it;
discussion with the GNAT folks informs me that their parser has a
lot of this kind of intelligence.
But at least the ";" vs. "IS" problem is picked up _somewhere_ as a
compilation error. The single keystroke ";" problem in C arises because
people carelessly type extra semicolons where they don't belong. The
magnitude of the logic bug is far out of proportion with the magnitude
of the keying error. These things should (somehow) be more proprtionate.
Intuitively, in Ada they are. Having taught intro-level Ada to many
hundreds, if not thousands, of students, I have found quite consistently
that - at that level - a program that compiles without errors will
_generally_ run without really strange behavior. Of course, this does
not prevent students from writing programs with logic errors, but
those are generally _logic_ errors and not _keying_ errors.
I have had very many students and colleagues who have studied and used
both Ada and C. I've never done a formal survey, but my informal survey -
done as far as possible without bias, leads me to a fairly form conclusion
that the real work in coding an Ada program (design questions aside!)
is in getting it through the compiler, while the real work in coding
a C program is in finding the reasons for the unexpected run-time
behavior. I am NOT arguing Ada's "superiority" in any global sense,
just pointing out where the real workload seems to be in both languages.
(At least this is true in the environments I have worked in.)
>
>However I do agree that Ada syntax is less error-prone than C or Fortran.
>This is not because it is verbose but rather because the Ada designers took
>this issue into careful consideration. I believe that it would be quite
>possible to design a syntax that was concise but that was no more error-prone
>than Ada.
>
Programmers seem to have a "thing" about verbosity. Ada's designers were
quite open about their intention that Ada code be easier to read than to write,
because as Pascal Obry pointed out yesterday, a program is written once but
read hundreds of times.
Mike
news
^I've enjoyed reading all the postings on why Ada is loosing to C++.
^Practically all of the posting are missing the "real" reason. It has
^to do with economic considerations (read my company wants to make
^more money). Think of it this way: I'm a governement software
^contractor. If I build a perfect, or at least a close to perfect
^system, I make all my money (read profit) by the time I deliver
^the system. However, if I build a buggy system with unreadable
^source code, I make money (again read profit) over the entire life
^of the software. Since I can build buggier unreadable software in
^C and C++, naturally I want to use C and C++ so I can make more
^money over a longer period of time.
The more I think about it, Ada (safe, sane....) reminds me of the Volvo.
You see all those advertisements for Volvos tauting safety features, and
they never mention the best safety feature, i.e. the fact that they usually
don't run and you can only hurt yourself so badly sitting under a tree
in a car.
Likewise with Ada. If you figure all the things which it simply can't do,
as was so heavily documented in the 700 or so tales of grief from the AdaWoe
BBS, that really doesn't leave much. Basically, all most people do when forced
to use Ada in projects is to write some stupid menu system in Ada to call C
or C++ routines and hope the Ada part doesn't screw the whole thing up
too badly. That SHOULD be safe...
--
Ted Holden
HTE
Pascal Obry
He is up again.
Please, can somebody unplug him !
he/it seem to have some processes control problems.
fred j mccall 575-3539
>Fred,
>> Single character ones? Probably not, but that just indicates that Ada
>> is incredibly more verbose than C. One of the things I DISlike about
>> it, by the way.
>Why do you use english ?
Because it's what everyone else speaks? If this is your defense of
Ada, it is a poor one. If you want something that 'everybody can
read', you should be using COBOL. It was designed with the idea in
mind that MANAGERS should be able to look at a program and tell what
it does without knowing the language.
>( > @ - + / ~ $
>==============================
>Because I'am the only one to know this language I put below the dictionary :
>> this
>( try
>$ word
>+ it
>, -
>/ is
>@ language
>~ without
>==============================
>I like Ada because you can *read* it. And this seem to be one of the most
>important thing about a language. With goods choices for the identifier, you
>can read an Ada progam like a text, you don't have to translate what you read.
Golly gee whiz, you have to actually KNOW THE LANGUAGE to read it.
Horrors! Oddly enough, I expect anyone reading a program and
expecting to understand it to be able to read the language. If you
hand somebody a bunch of Ada code, they're going to be able to read
and understand it? Gee, how is that going to work? They're going to
know what pragmas do, things like packages and generics, etc.? I
don't THINK so.
>You write a program one time, but how many time you read it ?
As many times as I need to? Why is this a problem?
fred j mccall 575-3539
>Michael Feldman:
> int x;
> ...
> x = 1;
> while (x <= 10);
> {
> printf("%d\n", x);
> x++;
> }
>For 10 points on your grade: what is printed? Why?
>Try explaining it to a freshman.
>Fred McCall:
>
>Nothing is printed. You built an infinite loop. This is hard to
>understand? You made a while loop with an empty body and a condition
>that is never met because you never increment x. Your freshmen don't
>get this?
>Me:
>Good syntax means that code should do what it looks like it should do. The
>above code is an example of less than optimal bordering on poor language
>syntax.
It looks like it does what it should do to me, other than the abysmal
and unnecessary use of braces and indentation. It's the language's
fault that poor coders can write poorly formatted code?
>The reason being that many compilers don't detect that what is
>obviously wrong code is wrong. On top of that the problem is rather inocuous
>and if I didn't know that the problem was there I might miss it when reading
>through the code. Basically the presence of a typo must be detected by having
>your program hang. A far from optimal situation.
Well, I prefer to think of it as the presence of a typo must be
detected by knowing the language -- a situation that is hardly
peculiar to C, and that is, in fact, pretty much a prerequisite for
writing working code in ANY language.
>The far worse problem with C syntax is the one that caused the problem for
>ATT. (This is all second hand so anyone in the know should correct me if I'm
>wrong.) A programmer had left out a break in a switch statement. I don't
>know the what the actual code was like by a switch looks like this.
From reports I've seen, this isn't what caused the problem.
> switch (x)
> {
> case 1:
> printf("x == 1\n");
> break;
> case 2:
> printf("x == 2\n");
> break;
> default:
> printf("x != 1 && x != 2\n");
> }
> printf("done");
>The break is necessary to leave the switch because the cases only serve as
>labels and execution will fall through to the next case statement. This is a
>case (no pun) where assembler shows through the C syntax. The machine code that
>is generated for the switch is a jump table based on the value of x. At the end
>of the statements another jump is required to avoid executing the rest of the
>code from the other case statements.
Gee, once again one is expected to know the language to write working
code in the language. Funny how that works. And if I implement the
wrong algorithm in Ada, it will tell me that I've made an error?
Just by the way, I believe that the actual problem was caused by
someone who put a 'break' statement inside an 'if', with the intention
of exiting the 'if' from the middle. Of course, this doesn't work,
and he actually wound up leaving an enclosing loop prematurely. It
was something like that, anyway. The problem was the PRESENCE of a
'break', not the absence of one.
>The fact that these problems exist in C is well known and most C texts point
>them out. I would like to point out that these idiosyncracies have not
>prevented C from being succesfully used in a phenomenal amount of code.
>People need to put C in perspective. When people started using C it was
>because the choice was between assembler and C for many projects. For larger
>projects the choice was between something like FORTRAN with some assembler
>and C. My experience in mixing assembler and FORTRAN is very limited but it is
>far from a trivial endevour. In both cases I would unhesitatingly choose C.
>Now there are other choices such as Ada for doing programs that interface with
>the hardware. Why do people keep using C? A lot of it has to do with inertia.
>Another reason that we shouldn't forget is that a good C/C++ programmer can
>turn out some very high quality code and if it aint broke don't fix it. In
>fact I would go as far as to say that well written C/C++ code is almost as
>readable as Ada.
Personally, I find well-written C a lot MORE readable than Ada. But I
think the point is well taken. It is possible to write opaque code in
ANY language.
>Me:
Well, there is just a bit more to it that that, and I think someone
back there a while ago posted a list showing a few 'peculiar'
structures for Ada, as well. I wish I still had it.
>Robb Nebbe ne...@lglsun.epfl.ch
>P.S. If you don't put the breaks in the switch it would print the following
>if x == 1:
>x == 1
>x == 2
>x != 1 && x != 2
>done
This is a surprise? If you don't put in the print statements it
doesn't print anything. These two results are about equally
surprising.
fred j mccall 575-3539
>In article <1992Dec11.1...@mksol.dseg.ti.com> mcc...@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
>>
>>>For 10 points on your grade: what is printed? Why?
>>>Try explaining it to a freshman.
>>
>>Nothing is printed. You built an infinite loop. This is hard to
>>understand? You made a while loop with an empty body and a condition
>>that is never met because you never increment x. Your freshmen don't
>>get this?
>Sure they get it. I just don't want to take my time or theirs on this
>kind of silliness. Which is why I keep saying that C should be
>everyone's second language and nobody's first.
I agree. I feel the same way about Ada, by the way. There's simply
too much there to be teaching it to people as a first language.
>>
>>>Any similar idiosyncracies in Ada?
>>
>>Single character ones? Probably not, but that just indicates that Ada
>>is incredibly more verbose than C. One of the things I DISlike about
>>it, by the way.
>>
>You're certainly entitled to your opinion. I'm not down on C. I'd
>rather train my teenager on a nice, verbose, safe car and give him
>the keys to the Porsche after he's proven himself on the Chevy.
>Less chance he'll waste his time crashing and burning. And the 70% or
>more of the freshman teachers who are going to Ada or sticking with
>Pascal (only slightly less verbose than Ada) agree.
Pascal tends to be a somewhat more appropriate choice for a first
language. It's a nice protected environment with a limited set of
features.
>Please - no more language wars.
I concur -- which is why I took exception to the original
characterizations of 'the C community'.
J. Giles
|> Michael Feldman:
|>
|> int x;
|> ...
|> x = 1;
|> while (x <= 10);
|> {
|> printf("%d\n", x);
|> x++;
|> }
One of the first things I do when a C program misbehaves is to check
the trivial pitfalls. One of the things I look for is "compound
statements" that aren't the direct object for some control-flow
construct. If I used C more frequently, I would be tempted to
write a preprocessor which flagged such things. In this case,
such a preprocessor would issue a warning that the `{' and `}'
were redundant.
Without explicitly looking for the above type of error, or having
an automated tool which looks for it on your behalf, this could be
a difficult to find error. The problem is that programmers look
at code and *know* what it's supposed to do. They tend to skim
the code looking for glaring errors. They miss this sort of thing
because it's next to invisible. In a large code in which the location
of the problem is not easy to determine (like maybe this is in one
of 500 routines which *could* be causing the problem), this could
take some time to isolate.
Now, I think that the "compound statement" is a poor language design
feature. This is one of the reasons I think so. Therefore, it's one
of the features I'm most suspicious of when code goes wrong. I would
prefer that C would have the following style syntax:
int x
...
x = 1
while (x <= 10)
printf("%d\n", x)
x++
endwhile
Now there's no way to mix-up where the `while' loop terminates.
The code is much easier to read and will have significantly
fewer errors of the "I know what this means, but it's not doing
it" variety.
--
J. Giles
John Bollenbacher
--
-----------------------------------------------------------------------------
- John Bollenbacher j...@dale.cts.com -
- Titan Linkabit Corp. (619) 552-9963 -
- 3033 Science Park Rd. -
- San Diego, Ca. 92121 -
-----------------------------------------------------------------------------
Bob Kitzberger
to help them to avoid language "problems". Ada programmers also have
rules of thumb to help them avoid language "problems". If you were to
list the top five C rules of thumb, they'd be something like:
1. Use conditional preprocessor directives in .h files to avoid
multiple file inclusions (oops! That's a C preprocessor rule ;-)
2. Always use curly braces in conditionals
3. Be careful to use '==' when you mean it, instead of '='
4. Always malloc one more byte then your array length for strings
5. Always use 'break' in each switch case, unless you really mean it
The top five rules of thumb for Ada are probably something like:
1. Don't get carried away using tasks as units of decomposition
2. Don't use the predefined types; define your own types
3. Use packages as units of decomposition.
4. Use private types to hide implementation details
5. Avoid the USE clause; consider RENAMES instead.
Note that the Ada rules of thumb are more geared towards programming
in the large, and reflect the fact that the Ada programmer spends less
time on annoying *run-time* syntax glitches (*), and more time on
encapsulation and decomposition issues.
.Bob.
(*) Of course, Ada programmers spend more time with compile-time syntax
errors than anyone else ;-)
Michael Feldman
>
>I agree. I feel the same way about Ada, by the way. There's simply
>too much there to be teaching it to people as a first language.
actually _doing_ it, and (most of) our students, like what they see.
We don't tell the students what a verbose, hairy, big, risky dinosaur
Ada is, so they somehow get the impression they can learn it. And they do.
We teach our infant children a subset of English (or German, or whatever),
and we teach our freshmen a subset of Ada. They learn the rest as they
grow up. It's a language you can grow into.
>
>Pascal tends to be a somewhat more appropriate choice for a first
>language. It's a nice protected environment with a limited set of
>features.
The downside is that vanilla Pascal (the ISO standard version) is much
too underpowered for the software engineering stuff (like separate
compilation) we want to do, even with first-years. So many teachers go
with Turbo. Only trouble is, Philippe has decided that Turbo for Unix
isn't worth his trouble, so yanking the kids off their PC's onto the
Unix boxes in the lab is impossible unless they switch to C...or Ada.
Mike Feldman
Michael Feldman
>God, don't you people ever tire of this?
>
Mike
Dag Bruck
>Experienced C programmers have rules of thumb that they follow in order
>to help them to avoid language "problems".
I also think we can close this discussion now.
Anyone interested in the problems of C should read the following
excellent book:
Andrew Koenig: C Traps and Pitfalls, Addison-Wesley.
Dag Bruck
David Emery
Ada Traps and Pitfalls. At least this will be a technically oriented
discussion on Ada, rather than Comp.Lang.Jihad.
I'll think about it and send in some of my rules.
dave
fred j mccall 575-3539
>In article <1992Dec14.1...@mksol.dseg.ti.com> mcc...@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
>>
>>I agree. I feel the same way about Ada, by the way. There's simply
>>too much there to be teaching it to people as a first language.
>Well, you're certainly entitled to your opinion. Those of us who are
>actually _doing_ it, and (most of) our students, like what they see.
There are also a lot of places that are teaching C as a first
language. That doesn't make it any less a mistake, in my opinion.
>We don't tell the students what a verbose, hairy, big, risky dinosaur
>Ada is, so they somehow get the impression they can learn it. And they do.
Substitute C for Ada in the above sentence and it makes equally good
sense. I still don't think it's a good idea.
>We teach our infant children a subset of English (or German, or whatever),
>and we teach our freshmen a subset of Ada. They learn the rest as they
>grow up. It's a language you can grow into.
As is any language. I don't consider this a particularly good
argument for using it in a beginning class.
>>
>>Pascal tends to be a somewhat more appropriate choice for a first
>>language. It's a nice protected environment with a limited set of
>>features.
>The downside is that vanilla Pascal (the ISO standard version) is much
>too underpowered for the software engineering stuff (like separate
>compilation) we want to do, even with first-years. So many teachers go
>with Turbo. Only trouble is, Philippe has decided that Turbo for Unix
>isn't worth his trouble, so yanking the kids off their PC's onto the
>Unix boxes in the lab is impossible unless they switch to C...or Ada.
Then they should make the switch. One would hope you're planning on
them learning more than one language, anyway.
Michael Feldman
[good stuff deleted]
>
>(*) Of course, Ada programmers spend more time with compile-time syntax
> errors than anyone else ;-)
I think this is _almost_ right. In my experience, the difficulty is
not with _syntax_ (are the structures formed correctly?) but with
_semantic checking_ (do the types match?). Both are compile-time
issues. In my experience with everyone from freshmen to experienced
industry folks, the pure syntax problems go away after a few weeks of
coding; the semantic ones never do. Ada's type system is complicated,
powerful, and designed to be _very_ safe, and therefore the type
checking is a pain in the neck to get through the compiler.
It should come as no surprise to regular readers of my junk that I think
it's worth it.
Mike Feldman
PS - the semantic checking is harder to write into the compiler, too!
Richard Pattis
When I introduce recursion in my CS1/CS2 class, this one never fails to show
up. It is truly a C-like error (excuse the pejorative term) in that the
distinction between a statement and value is clouded to reduce the number of
reserved words.
Often the base case of a recursive function to manipulate a list looks like:
IF mumble = NULL THEN
RETURN NULL;
ELSE ...
What my students sometimes write is
IF mumble = NULL THEN
NULL;
ELSE ...
Here the statement NULL replaces the returning of a NULL value (which might be
better to denote as NIL, at the expense of another reserved word). Of course,
this is all syntactically legal and the error shows up only at execution time:
often as a PROGRAM_ERROR (so at least Ada catches it at some time) if there
are no other statements after the IF in the function. Of course, some compilers
will give a warning based on the functions data flow information.
Rich Pattis
--
------------------------------------------------------------------------------
Richard E. Pattis "Programming languages are like
Department of Computer Science pizzas - they come in only "too"
and Engineering sizes: too big and too small."
Tucker Taft
pat...@cs.washington.edu (Richard Pattis) writes:
> . . .
>Often the base case of a recursive function to manipulate a list looks like:
>
> IF mumble = NULL THEN
> RETURN NULL;
> ELSE ...
>
>What my students sometimes write is
>
> IF mumble = NULL THEN
> NULL;
> ELSE ...
>
>Here the statement NULL replaces the returning of a NULL value (which might be
>better to denote as NIL, at the expense of another reserved word). . . .
Oh boy. That is a nasty one. This argues for a "friendly"
Ada compiler giving a warning about any use of "null;" other
than the idiomatic ones like "when others => null;" or "begin null; end;"
(especially in a function that returns an access type ;-).
In retrospect, one could argue that it would have been better
to have no "null" statement at all (other than simply ";") than
to create a situation allowing this kind of one word error.
>Rich Pattis
S. Tucker Taft s...@inmet.com
Robert I. Eachus
Oh boy. That is a nasty one. This argues for a "friendly"
Ada compiler giving a warning about any use of "null;" other
than the idiomatic ones like "when others => null;" or "begin null; end;"
(especially in a function that returns an access type ;-).
In retrospect, one could argue that it would have been better
to have no "null" statement at all (other than simply ";") than
to create a situation allowing this kind of one word error.
Actually, there is an Ada rule which normally catches this, and
which Robert Dewar and I have argued should be removed in Ada 9X. (A
function must contain a return statement RM 6.5(1).) If it belongs on
the top ten list, then the rule should stay.
(What Robert Dewar and I objected to was that certain functions
whose only intended effect is to raise an exception must still contain
a return statement. This results in junk return statements in stubbed
out code, and makes a stubber much harder to write.)
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
Pascal Obry
>>Why do you use english ?
>
>Because it's what everyone else speaks? If this is your defense of
I hope you didn't mean *everyone*, because in this case you would have
forgotten 3/4 of the world (and maybe more in the univers). Anyhow if you mean
that you should travel a bit !
>Ada, it is a poor one. If you want something that 'everybody can
>read', you should be using COBOL. It was designed with the idea in
>mind that MANAGERS should be able to look at a program and tell what
>it does without knowing the language.
I had to learn COBOL for one of my courses 5 years ago, and by the way it
does very well what it is suppose to do : file manipulation and form to enter
data.
>Why do you use english ?
Because it's what everyone else speaks? If this is your defense of
Ada, it is a poor one. If you want something that 'everybody can
read', you should be using COBOL. It was designed with the idea in
mind that MANAGERS should be able to look at a program and tell what
it does without knowing the language.
>( > @ - + / ~ $
>==============================
>Because I'am the only one to know this language I put below the dictionary :
>> this
>( try
>$ word
>+ it
>, -
>/ is
>@ language
>~ without
>==============================
>>I like Ada because you can *read* it. And this seem to be one of the most
>>important thing about a language. With goods choices for the identifier, you
>>can read an Ada progam like a text, you don't have to translate what you read
>>Golly gee whiz, you have to actually KNOW THE LANGUAGE to read it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>Horrors! Oddly enough, I expect anyone reading a program and
>>expecting to understand it to be able to read the language. If you
>>hand somebody a bunch of Ada code, they're going to be able to read
>>and understand it? Gee, how is that going to work? They're going to
>>know what pragmas do, things like packages and generics, etc.? I
>>don't THINK so.
I don't agree here. let me take a small example :
In C++ :
cout << "un text" << endl;
c++;
if (i) { ... }; /* let suppose i is an integer */
for (k=0; k<4; k++) {...}
In Ada :
text_io.put_line ("Un text");
c := c + 1;
if i = 1 then ... end if;
for k in 0 .. 3 loop ... end loop;
I bet that people that don't know either C++ and Ada will understand the Ada
code. Could we think the same of C++ code ? there is too much conventions
in C/C++ :
if (i) {..}
true if i = 1, you can invent that, you have to learn it
for (k=0; k<4; k++) {...}
first parameter is to initialize
second stop test
third whatever you want
Ok, this is only one instruction. But don't you think that a whole program is
a set of instructions.
And we can find a lot of more exemple like this. But I don't want to start a
language war.
Anyhow this is only one part of the readability. The low-level readability or
instruction readability. I don't mean that an Ada algorithm of many lines will
be easy to understand at the first look. But at least, I think it will be
easy to follow line by line what it does.
An Ada program does what it says.
Harry Koehnemann
>In article <1992Dec15.2...@inmet.camb.inmet.com> s...@spock.camb.inmet.com (Tucker Taft) writes:
>
> Oh boy. That is a nasty one. This argues for a "friendly"
> Ada compiler giving a warning about any use of "null;" other
> than the idiomatic ones like "when others => null;" or "begin null; end;"
> (especially in a function that returns an access type ;-).
>
>which Robert Dewar and I have argued should be removed in Ada 9X. (A
>function must contain a return statement RM 6.5(1).) If it belongs on
>the top ten list, then the rule should stay.
The "null;"/"return null;" was a problem with the base case in a
recursive function (null is overloaded, and even worse it's an
expression *and* a statement - isn't that something we hate about
C :). This implies there will be additional returns somewhere in
the routine and it will not be caught by the compiler. The real
problem is that there exists an execution path that can lead out
of the function without encountering a return. And, won't Ada
catch this at run-time? Granted it would be nice for the language
to catch it at compile time, but the compiler could easily print a
warning saying that such a path exists.
--
Harry Koehnemann Arizona State University
koeh...@enuxha.eas.asu.edu Computer Science Department
Harry Koehnemann
>|> Michael Feldman:
>|> ...
>|> x = 1;
>|> while (x <= 10);
>|> {
>|> printf("%d\n", x);
>|> x++;
>|> }
>an automated tool which looks for it on your behalf, this could be
>a difficult to find error. The problem is that programmers look
>at code and *know* what it's supposed to do. They tend to skim
>the code looking for glaring errors. They miss this sort of thing
>because it's next to invisible.
But, that skimming process is a good thing - it's a way of using
abstraction. I don't concern myself with the details of each statement,
rather I abstract out the function of a set of statements. Another
problem is that a programmer is usually thinking in terms of the problem
domain rather than in terms of the language, which makes it harder
to locate these little language flukes. Abstraction is an important
tool, but can stab you in the back when you're not looking.
I've seen the above example on many exams and have always had mixed
emotions about it. Sure it tests the knowledge of the language, but
it's not encouraging the abstraction concepts taught in the class and
may actually be counterproductive.
Another great test question:
i = 1;
while (i <= 10)
printf("%d\n");
i++;
What's the output? The indentation is a pattern we recognize and it's
easy to "skim" over it and assume we understand something we don't.
For what it's worth.
fred j mccall 575-3539
>>>Why do you use english ?
>>
>>Because it's what everyone else speaks? If this is your defense of
>I hope you didn't mean *everyone*, because in this case you would have
>forgotten 3/4 of the world (and maybe more in the univers). Anyhow if you mean
>that you should travel a bit !
Well, I expect that I've travelled at least as much as most (all that
military time, you know), and I'll stand by that statement. Why are
we speaking English here? Why do all pilots and ATC centers speak it
(except those in the former Soviet Union -- and they'll probably wind
up changing over)?
>>Ada, it is a poor one. If you want something that 'everybody can
>>read', you should be using COBOL. It was designed with the idea in
>>mind that MANAGERS should be able to look at a program and tell what
>>it does without knowing the language.
>I had to learn COBOL for one of my courses 5 years ago, and by the way it
>does very well what it is suppose to do : file manipulation and form to enter
>data.
[The attributions got screwed up somewhere along in here, since I said
part, but not all, of what is below with >>>. Let's be careful out
there!]
>In C++ :
>In Ada :
Why would one expect (or want) people who do not know a language to be
looking at and evaluating code?
> if (i) {..}
> true if i = 1, you can invent that, you have to learn it
> for (k=0; k<4; k++) {...}
> first parameter is to initialize
> second stop test
> third whatever you want
>Ok, this is only one instruction. But don't you think that a whole program is
>a set of instructions.
>And we can find a lot of more exemple like this. But I don't want to start a
>language war.
Then why bring it up? Is it standard practice where you are for
people who don't know a language to be evaluating, writing, or
maintaining code? 'Readability' is a red herring, except insofar as
it applies to people who know the language. It applies not to 'funny
function names' or 'verboseness', but to the ability to build
constructs that someone who UNDERSTANDS the language has difficulty
deciphering the effect of. This is certainly probably easier in C/C++
than in Ada, but that's not exactly germane. It just says that people
who don't understand how to write readable code should probably
preferentially be working in a language that will TRY to force them to
(like Pascal or Ada). Note, however, that this is certainly no
guarantee, since obscure or opaque code can be written in any
language.
>Anyhow this is only one part of the readability. The low-level readability or
>instruction readability. I don't mean that an Ada algorithm of many lines will
>be easy to understand at the first look. But at least, I think it will be
>easy to follow line by line what it does.
As will the C++ program, if you 'speak' C++
>An Ada program does what it says.
So does any other program. Your argument seems to boil down to saying
that Ada is 'better' because it can be understood by someone who
doesn't know Ada. That is both irrelevant AND untrue.
Mark A Biggar
> Oh boy. That is a nasty one. This argues for a "friendly"
> Ada compiler giving a warning about any use of "null;" other
> than the idiomatic ones like "when others => null;" or "begin null; end;"
> (especially in a function that returns an access type ;-).
> In retrospect, one could argue that it would have been better
> to have no "null" statement at all (other than simply ";") than
> to create a situation allowing this kind of one word error.
> Actually, there is an Ada rule which normally catches this, and
>which Robert Dewar and I have argued should be removed in Ada 9X. (A
>function must contain a return statement RM 6.5(1).) If it belongs on
>the top ten list, then the rule should stay.
> (What Robert Dewar and I objected to was that certain functions
>whose only intended effect is to raise an exception must still contain
>a return statement. This results in junk return statements in stubbed
>out code, and makes a stubber much harder to write.)
How about a rule that requires a function to contain either a return or an
explisit raise statement? Would that not satisfy both sides?
--
Mark Biggar
m...@wdl1.wdl.loral.com
Bob Kitzberger
> (What Robert Dewar and I objected to was that certain functions
>whose only intended effect is to raise an exception must still contain
>a return statement. This results in junk return statements in stubbed
>out code, and makes a stubber much harder to write.)
Robert, I can't think of a reason to have a function that does nothing
but raise an exception... can you provide an example? (I'm not
questioning the need for it -- just curious)
.Bob.
Charles H. Sampson
>
> In retrospect, one could argue that it would have been better
> to have no "null" statement at all (other than simply ";") than
> one word error.
The problem being discussed was a result of the overloading of
NULL in Ada. IMO, there's too much overloading of reserved words in
Ada in an effort to minimize the number of reserved words. (For those
who don't know, keeping the number of reserved words down was a design
requirement.) However, denoting a null statement by the absense of a
statement is not the way to go, as Mike Feldman's example from C illus-
trates. I worked for many years in another language that also had this
"feature". I was amazing how many times the statement controlled by
an IF would vanish by the careless insertion of an unneeded statement
terminator. The associated debugging problems were severe.
Furthermore, an explicit null statement clearly says, "At this point,
do nothing." For those of us who believe in readability, this is impor-
tant.
Charlie
Erik Magnuson
>but raise an exception... can you provide an example? (I'm not
>questioning the need for it -- just curious)
Howabout when you have a common interface, but cannot (or choose not
to) implement the function for a specific implementation.
function Foo return Foo_Type is
begin
raise Not_Supported;
end Foo;
Currently you have to write:
function Foo return Foo_Type is
Dummy : Foo_Type; -- should this be initialized?
begin
raise Not_Supported;
return Dummy;
end Foo;
>
> .Bob.
>----------------
>Bob Kitzberger VisiCom Laboratories, Inc.
>r...@visicom.com 10052 Mesa Ridge Court, San Diego CA 92121 USA
> +1 619 457 2111 FAX +1 619 457 0888
--
Erik
Julian C. Lander
|> eac...@oddjob.mitre.org (Robert I. Eachus) writes:
|>
|> > (What Robert Dewar and I objected to was that certain functions
|> >whose only intended effect is to raise an exception must still contain
|> >a return statement. This results in junk return statements in stubbed
|> >out code, and makes a stubber much harder to write.)
|>
|> Robert, I can't think of a reason to have a function that does nothing
|> but raise an exception... can you provide an example? (I'm not
|> questioning the need for it -- just curious)
|>
I didn't write this one, but it is in some code I'm using.
The situation is interface with C-language functions, which return
error codes. The chunk of code before me (I don't know a good noun
for what it is--it builds about 3 different executables) has a function
called Raise_Appropriate_Exception, which raises the exception
corresponding to the return code it has been passed.
Since it never gets a 0 (its caller should avoid that), it doesn't return.
I don't know that it's the best solution to the problem (I'm not wild
about it, frankly), but that's what I have.
Julian C. Lander
jcla...@mitre.org
John Bollenbacher
: In article <EACHUS.92D...@oddjob.mitre.org> eac...@oddjob.mitre.org (Robert I. Eachus) writes:
: >In article <1992Dec15.2...@inmet.camb.inmet.com> s...@spock.camb.inmet.com (Tucker Taft) writes:
: >
: > Oh boy. That is a nasty one. This argues for a "friendly"
: > Ada compiler giving a warning about any use of "null;" other
: > than the idiomatic ones like "when others => null;" or "begin null; end;"
: > (especially in a function that returns an access type ;-).
: >
: > Actually, there is an Ada rule which normally catches this, and
: >which Robert Dewar and I have argued should be removed in Ada 9X. (A
: >function must contain a return statement RM 6.5(1).) If it belongs on
: >the top ten list, then the rule should stay.
:
: The "null;"/"return null;" was a problem with the base case in a
: recursive function (null is overloaded, and even worse it's an
: expression *and* a statement - isn't that something we hate about
: C :). This implies there will be additional returns somewhere in
: the routine and it will not be caught by the compiler. The real
: problem is that there exists an execution path that can lead out
: of the function without encountering a return.
Seems to me the real problem is that there is a potential path out if the
function which does not raise an exception but has the 'wrong' value, e.g.
if mumble = null then
null;
end if;
...
return new mumble_ptr;
Thanks for pointing out this gotcha. I'd never seen it before.
Robert I. Eachus
In article <2...@visicom.com> r...@VisiCom.COM (Bob Kitzberger) writes:
Robert, I can't think of a reason to have a function that does nothing
but raise an exception... can you provide an example? (I'm not
questioning the need for it -- just curious)
Stubbing is the major reason for doing this, i.e. something not
available in the current version of the software, but the interface is
provided.
Another case is where a generic requires an operation as a formal
parameter which is meaningless for a particular actual. There are
cases where providing a function which raises an error is more useful
than rewriting the generic. For example, assume you have a "standard"
interface to IO devices, for some current_position would return a
value, for other devices the function of the same name would
immediately raise an exception.
A more subtle use in when you are not sure an obsolete interface
or object can be eliminated. Putting in a function which prints a
meaningful message then returns is more polite than ripping it out,
and waiting until some user of the package screams.
One more use I have found was for a private type where user created
objects were verboten. (Put in a component with such a function as
the default initial value. User created objects will cause the
function to be evaluated.)
Lots of uses, but only the difficulties the rule creates in
stubbers is compelling.
John Halper
Good idea, how about a moderated group. I sure would like to be able to
read technically oriented discussions without having to wade through all
the crud. Mind you I would never suggest suppressing the ever witty Fred
and Ted show. I just want to be able to turn to another channel.
J. Halper
Charles H. Sampson
>I didn't write this one, but it is in some code I'm using.
>The situation is interface with C-language functions, which return
>error codes. The chunk of code before me (I don't know a good noun
>for what it is--it builds about 3 different executables) has a function
>called Raise_Appropriate_Exception, which raises the exception
>corresponding to the return code it has been passed.
>
>Since it never gets a 0 (its caller should avoid that), it doesn't return.
>
>I don't know that it's the best solution to the problem (I'm not wild
>about it, frankly), but that's what I have.
I can think of a number of questions about this function. The one
I'm most interested in is why is it a function rather than a procedure?
Particularly a function whose name is a verb phrase?
Charlie
Terry J. Westley
["this" refers to substituting "null" for "return null" by mistake]
>and
>which Robert Dewar and I have argued should be removed in Ada 9X. (A
>function must contain a return statement RM 6.5(1).) If it belongs on
>the top ten list, then the rule should stay.
>
> (What Robert Dewar and I objected to was that certain functions
>whose only intended effect is to raise an exception must still contain
>a return statement. This results in junk return statements in stubbed
>out code, and makes a stubber much harder to write.)
>
>--
>
> Robert I. Eachus
Many compilers produce a warning for such a situation. IMHO, this is
good but doesn't go far enough.
I hate compiler warnings; I will typically do anything to eliminate them
because I done't want to keep rereading the same warnings every time a unit
is compiled. Sometimes, they cannot be eliminated as in the example above.
I would like to have the ability, perhaps with a pragma, which allows me to
tell the compiler that I know a certain statement will raise a warning of
a certain class and to suppress the warning. This must be done on a statement
by statement (really warning by warning) basis. Turning off all the warnings
is too dangerous. They really are useful.
Have any compiler gurus considered this?
--
Terry J. Westley, Principal Computer Scientist
Calspan Corporation, P.O. Box 400, Buffalo, NY 14225
wes...@calspan.com
Let's hear it for smart mailers that cut off long signa
Richard A. O'Keefe
> The more I think about it, Ada (safe, sane....) reminds me of the Volvo.
> You see all those advertisements for Volvos tauting safety features, and
> they never mention the best safety feature, i.e. the fact that they usually
> don't run and you can only hurt yourself so badly sitting under a tree
> in a car.
I have deleted the rest of Holden's flame. Let me offer a data point.
Just recentrly, I posted an article to comp.lang.c in which I listed a
number of errors in a textbook. The textbook is about data structures
in C. The authors understand data structures very well.
Author X "is chair of the CS dept and Professor of CS&EE at
<famous university>. [He] has published 30 proceedings, managed
research grants totalling over US$3.5 million, ... "
Author Y "is Professor of CS in <not so famous university but I've
heard of it even here>. [He] has published over 140 articles and
has written several texts. He is an editor of four professional
journals and has managed over US$8 million in research grants."
Author Z "is chair of <a third good university>'s CS dept and a
veteran of 14 years of teaching."
The authors thank Profesor P, Dr Q, and Messrs R & S for "debugging"
the book. They also thank Mr T of AT&T Bell Labs (who has written
several books on C himself) for reviewing the manuscript.
Sounds good, no? The authors also say that the code in the book is not
specially typeset because every example has been tested, and they didn't
want to introduce any errors.
On p6 they write "all programs in this book follow the rules of ANSI C".
The first example is on p7, facing this claim, and it contains an OBVIOUS
violation of the ANSI standard, and a known portability problem (which
X3J11 invented a new macro for the express purpose of fixing), and calls
an operation which may fail without checking whether it succeeded. The
last example in the book has a type error, and the authors' only comment
is to say that the compiler's error message can be ignored.
In my posting in comp.lang.c I described (with page numbers) several other
mistakes. My personal favourite is one which appears to reveal a fairly
basic misunderstanding about C scope rules. There are others which should
never have been accepted by any C compiler, although they are legal C++.
Many of the problems are potentially serious. As it happens, with the
exception of the scope problem, GCC or an ANSI lint _would_ catch all of
them. But Professors X, Y, and Z "tested" their programs under an awesome
total of two compilers, which evidently did _not_ catch these errors.
I can never quite remember the line in "Life, the Universe, and Everything."
"Don't worry, Arthur Dent ............... be very very frightened."
You see, I had been talking with a publisher's representative, and had
complained about another publisher's recent book which had about one
factual error every two pages. The publisher's representative said, "well,
OURS are checked. I'll send you one I think you'll be able to use."
Well, no, I can't. I think my students are better off being shown how to
write CORRECT C code for a smaller variety of data structures than
INCORRECT C code for an impressive range of data structures. I also think
that a textbook that TALKS so much about abstract data types should teach
students to DO it, but although it is easy to define a stack type in C
so that a program using it has no clue about the implementation, the code
in this book just isn't like that. The authors never even mention how to
use header files to get modular code.
Am I worried about C, when experienced people who are managing huge
amounts of money (once upon I time I paid US taxes, some of that was
my money) manifestly don't understand C, even though they imagine they
think they understand it well enough to instruct others?
Worried? No.
I'm very very frightened.
I believe that Ada is a bigger language than C. Both languages have "dark
corners". But there seems to be a tradition of Ada compilers being picky
and C compilers letting it all hang out. With all due respect to "The
Emperor's New Clothes", which I loved when it came out, I am now _more_
frightened about critical software being written in C or C++ than in Ada.
This is actually an important point. A programming language is more than
a standard. There is also a tradition, a way of approaching the language.
(It's something I have observed about Prolog: if you plug into the
Edinburgh _tradition_, Prolog is a simple, comprehensible, and powerful
tool, but if you just look at a manual, most people never learn how to
use it effectively, and that most especially applies to the authors of
textbooks about it.) It would be perfectly possible to have an "Ada"
compiler which was as sloppy as a C compiler, and it is possible to have
C systems which are very strict.
My current impression is that Ada textbooks tend to be more accurate in
the claims they make about what is or is not valid Ada, and tend to have
a higher level view of the software process, than C books. Is this an
illusion, due to my knowing C relatively better than I know Ada?
Michael Feldman
>not take the analogy beyond that.
>
>George
>
Funny thing, George. Every now and then my wife looks over my shoulder
when I'm reading this group, and she always chuckles at what she calls
"typical male pi**ing contests". She is still waiting to see a female
name on comp.lang.ada (she hasn't lucked into seeing one of Deborah's
posts).
Mike
Steve Rogers
>Just recentrly, I posted an article to comp.lang.c in which I listed a
>number of errors in a textbook. The textbook is about data structures
>in C. The authors understand data structures very well. . . . .
<deleted>
>I believe that Ada is a bigger language than C. Both languages have "dark
>corners". But there seems to be a tradition of Ada compilers being picky
>and C compilers letting it all hang out. With all due respect to "The
>Emperor's New Clothes", which I loved when it came out, I am now _more_
>frightened about critical software being written in C or C++ than in Ada.
>
>My current impression is that Ada textbooks tend to be more accurate in
>the claims they make about what is or is not valid Ada, and tend to have
>a higher level view of the software process, than C books. Is this an
>illusion, due to my knowing C relatively better than I know Ada?
>
I'm not sure this is true; the Barnes Ada book has LOTS of examples that
violate the LRM. I think perhaps it's more of a way of teaching than
a symptom of the particular language. In my CS education, many instructors
(and books) adopted a method of presenting a narrow version of the language
as though it were the whole truth, then expanding it in steps with each
new lesson; perhaps under the theory that this would make it easier to
grasp the wider concepts. I found it tiring after a while. It would
go something like (exaggerated)
1. Variables are letters A-Z. Use like A = 1.
2. Yesterday we learned variables are letters, today we will see that
variables can have numbers appended for extra clarity. Like A1 = 1.
3. Today we see that variables can also have multiple letters and
underscores for even more clarity: ADD_VALUE = 1
. . . .
The frustrating thing is that they would never get around to specifying
the fundamental principle behind the concept. Eventually you find
yourself saying: OK, OK, but what is a variable, *really*? It
seems more natural, IMHO, to start with the broad statement, then explain
what it means with examples in various contexts; rather than assume an
inital narrow context, then try to expand to more general cases.
I would say that C instruction does this more than Ada instruction, but
by no means is it a C phenomena. I don't know what the mistakes were
that you found, but the ones I have noticed in the Barnes book are
all due to simplification. I attribute it to the idea (IMHO mistaken)
that a student can benefit from an example that illustrates an idea
in a very clear and simple way, but which is invalid in the full context
of the language.
--
| Steven Rogers MCC/ESL 3500 West Balcones Drive
| Austin, Texas 78759-6509 (512) 338-3691 sro...@mcc.com
Dirk Craeynest
>I can never quite remember the line in "Life, the Universe, and
>Everything."
>"Don't worry, Arthur Dent ............... be very very frightened."
FYI, the exact quote from the book "Life, the Universe, and Everything"
by Douglas Adams is:
-------
The sign changed itself again. It said:
Do Not be Alarmed.
After a pause, it added:
Be Very Very Frightened, Arthur Dent.
Once again it flicked off. Once again it left him in darkness.
-------
Dirk Craeynest | domain: di...@cs.kuleuven.ac.be
Ada-Belgium Newsletter editor | uucp: di...@kulcs.uucp
Katholieke Universiteit Leuven | ...!mcsun!ub4b!kulcs!dirk
Department of Computer Science | phone: ++32(0)16-201015 x3555
Celestijnenlaan 200 A | fax: ++32(0)16-205308
B-3001 Leuven (Heverlee), Belgium | telex: 23674 kuleuv b
Michael Feldman
>the claims they make about what is or is not valid Ada, and tend to have
>a higher level view of the software process, than C books. Is this an
>illusion, due to my knowing C relatively better than I know Ada?
>
errors because nobody had good compilers around to test their code with.
Now that everyone has correct compilers (as least as far as validation
can show them correct), we can test our stuff.
My data structures book (1985) had lots of errors in the code, but these
were either _algorithm_ errors or "version control" problems where the
pieces did not fit together correctly because of author and publisher
carelessness. None were "Ada errors" or nonportabilities.
My freshman book (1991) had a lot of typos when it first came out, but
these were in the _text_ - misspellings and inconsistencies in the
English, tables, blah blah. Lots of UW students got to point out these
errors during my year in Seattle; I paid $1.00 for the first report of
each error.
There were a few algorithm errors and other quibbles that had nothing to do
with Ada. And ONE nonportability: there are two programs in which I made
a bad assumption about float-to-integer conversion, so the programs will
give different results depending on whether the float is truncated or rounded
where the fractional part is in the middle of the interval. This is 2
programs of 180, and the error was my own stupidity.
I tested (nearly) everything under at least 4 compilers, and other
adopters of the book are using any number of other compilers that I
don't have access to. I have yet to get a report of a portability bug
in any one of them; indeed, I am not getting bug reports at all.
The book includes a diskette of all the programs, so nobody ever has to
endure a keying error to use them.
The purpose of this is not to hype the book, but just to point out
how easy it is to develop Ada code that'll really be compiler-independent,
given today's compilers and programs that don't use a lot of Chapter 13
stuff (you wouldn't find that in a freshman book!).
You might quibble with an author's coding style, or choice of algorithm,
but these days you'll have to work very hard to find a language error
in today's Ada books.
Mike Feldman
PS - My $1.00 per error still stands.
Robert I. Eachus
I'm not sure this is true; the Barnes Ada book has LOTS of examples that
violate the LRM...
Which edition? The first edition was published before the ANSI (83)
standard was finalized. However, it wasn't really Ada 80, more like
81 1/2.
George C. Harrison, Norfolk State University
fred j mccall 575-3539
>In article <16...@goanna.cs.rmit.oz.au> o...@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>>Just recentrly, I posted an article to comp.lang.c in which I listed a
>>number of errors in a textbook. The textbook is about data structures
>>in C. The authors understand data structures very well. . . . .
> <deleted>
>>I believe that Ada is a bigger language than C. Both languages have "dark
>>corners". But there seems to be a tradition of Ada compilers being picky
>>and C compilers letting it all hang out. With all due respect to "The
>>Emperor's New Clothes", which I loved when it came out, I am now _more_
>>frightened about critical software being written in C or C++ than in Ada.
>>
>>My current impression is that Ada textbooks tend to be more accurate in
>>the claims they make about what is or is not valid Ada, and tend to have
>>a higher level view of the software process, than C books. Is this an
>>illusion, due to my knowing C relatively better than I know Ada?
>>
>I'm not sure this is true; the Barnes Ada book has LOTS of examples that
>violate the LRM. I think perhaps it's more of a way of teaching than
>a symptom of the particular language. In my CS education, many instructors
>(and books) adopted a method of presenting a narrow version of the language
>as though it were the whole truth, then expanding it in steps with each
>new lesson; perhaps under the theory that this would make it easier to
>grasp the wider concepts.
This is why I don't approve of Ada as a first language. The language
is simply too large and powerful, and when you try to teach
restrictive subsets you wind up teaching things that are 'wrong' in
the broader scope. C++ has this same problem, along with a problem
that it 'inherits' from C. The biggest problem with C isn't the size
of the language (it's actually fairly small), but that so much of the
power and expressiveness of the language relies on things that
beginning students typically have a great deal of trouble with;
pointers and recursion. When you add the somewhat arcane syntax
required for declaring complex types and all the safety of an
unshielded buzz saw, C is an even worse choice for a first language
than Ada is.
I think students would be best served by using something INTENDED for
teaching, which is relatively safe and small. That pretty much means
Pascal. Some schools have had good luck with LISP/SCHEME style
languages, but I'm not sure how easy they are to deal with as first
languages, either.
Morris J. Zwick
(fred j mccall 575-3539) writes:
>
>I think students would be best served by using something INTENDED for
>teaching, which is relatively safe and small. That pretty much means
>Pascal. Some schools have had good luck with LISP/SCHEME style
>languages, but I'm not sure how easy they are to deal with as first
>languages, either.
>
AMEN!!
___________________________________________________________________
/ Morris J. Zwick Internet: mzw...@vitro.com
__ / Vitro Corporation Voice: (301) 231-2784
\ / 14000 Georgia Ave. ___________________________
\ / Silver Spring, MD 20906-2972 |"I don't want the world; |
* | I just want your half!" |
| - They Might Be Giants |
Steve Rogers
>
> I'm not sure this is true; the Barnes Ada book has LOTS of examples that
> violate the LRM...
>
> Which edition? The first edition was published before the ANSI (83)
>standard was finalized. However, it wasn't really Ada 80, more like
>81 1/2.
>
The edition I am looking at is the 3rd edition. Two examples: The
FRAME program on page 325 violates LRM 9.1.4 - the type of the task
cannot be used as a typemark within the task itself. It's easy to
see what the program means, but it doesn't comple. There is a task
example on page 311 that has nested accepts for the same entry which
violates LRM 9.5(8). Again, its clear what the program intends, but
it has been simplified in a way that keeps it from compiling. These
are the latest ones I have noticed. It seems to me that it would be
better to include such details in examples (certainly after several
hundered pages) so that the student/reader learns to see Ada and
the LRM as a consistent whole, rather than a lot of nit-picky
rules that get in the way.
I'm assuming that these things have been left in on purpose and
reflect a particular approach to teaching rather than simple
oversight. This simplification is consistent with the practice
I have seen in my CS education (addressed in my previous post)
and it is the 3rd edition, after all. It is not my intent
to critisize this book - I bought the first edition and I'll
probably buy the 4th edition. I'm addressing a particular
method of teaching CS. The piecemeal approach is not as good
as a wholistic approach. I think students need to learn to
see the language as a consistent wholistic system, rather than
a hodge-podge box of semantic tools. I think it is easier to
see this aspect of programming languages in Ada than most
others. This is why I think it makes a good first language,
despite its complexity (just leave off tasks at first).
Michael Feldman
>In article <1992Dec18.1...@mksol.dseg.ti.com> mcc...@mksol.dseg.ti.com
>(fred j mccall 575-3539) writes:
>>
>>I think students would be best served by using something INTENDED for
>>teaching, which is relatively safe and small. That pretty much means
>>Pascal. Some schools have had good luck with LISP/SCHEME style
>>languages, but I'm not sure how easy they are to deal with as first
>>languages, either.
>>
>
>AMEN!!
>
first language, or Ada as a first language. I can't speak for the former
and wouldn't presume to, as I have neither learned nor taught LISP or
Scheme as a first language. I and many others have taught Ada as a
first language and we see little wrong with it in that context, and
a whole lot right. Ada is as easy as Pascal if taught by people who
trouble themselves to know what they are doing, using one of the
eight recently published texts written for the purpose. And it gives
the student something to grow into.
Somehow we are willing to teach "big" natural languages (English, for
example), to babies. What is the problem people have with teaching
"big" computer languages (Turbo Pascal, C++, Ada) to beginning
programmers. Babies assimilate natural language, and students
assimilate programming language, in ever-increasing subsets.
At the risk of offending, let me state that I think people who don't
teach much (or at all), and have spent a number of years since their
first college programming course (or never had one), are not in a
good position to tell us what or how to teach. You should be quite
happy that we are teaching an industrial-strength language, right
from the start, so that our students don't see SOFTWARE ENGINEERING
as a "special topic" but rather assimilate it as simply the natural
way to develop programs.
Have you spoken recently to any student who learned Ada as a first language?
Have you looked at any of the texts published in the last 3-4 years,
targeted to first-year students learning Ada as their first language?
Your comments would certainly be more credible if you supplied a bit of
information as to how your recent experience qualifies you to make
pronouncements of this kind. (I won't bore the net with mine, but
you are welcome to them by e-mail if you wish.)
I can send by e-mail a list of schools where Ada is the first language,
and of texts targeted to that audience. If you are interested.
I apologize to my net friends for this immodesty, but I get kinda
tired of being told how and what to teach by people who have never tried it.
Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee
Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfel...@seas.gwu.edu (Internet)
"Americans want the fruits of patience -- and they want them now."
------------------------------------------------------------------------
D. Samson
Iam interested in Ada as an information systems language to be taught
in a college of business and economics. I teach at Weber State Univ.
in Ogden, Utah, where we have a large government and contractor community
which hires our graduates. It could be advantageous for our graduates
to know Ada, and so I am exploring the availability of business-oriented
Ada textbooks. If you know of any, or can refer me to any schools where
Ada is taught from an IS perspective, I'd appreciate your help.
Dolly Samson
Weber State University
Ogden, UT 84408-3804
dsa...@cc.weber.edu
-----------------------------------------------------
George C. Harrison, Norfolk State University
Mike Feldman writes:
> George C. Harrison writes:
>> Mike Feldman writes:
>>> John Bollenbacher writes:
>>>>God, don't you people ever tire of this?
>>>>
>>> I do.
>>>
>>> Mike
>>I do too. Reminds me of what seventh grade boys do in locker rooms, but I'll
>>not take the analogy beyond that.
>>
> when I'm reading this group, and she always chuckles at what she calls
> "typical male pi**ing contests". She is still waiting to see a female
> name on comp.lang.ada (she hasn't lucked into seeing one of Deborah's
> posts).
>
> Mike
With luck John McCormick (who can't respond) is reading this. His wife is a
sexual disorder (or something like that)-psychologist.
If his wife wishes to respond, I'll forward her message on here.
George
Mark Meyer
I'm new to this group, basically because I'm new to Ada.
Even so, I just have to comment on this:
In article <1992Dec21....@mcc.com> sro...@teenwolf.mcc.com (Steve Rogers) writes:
> The edition I am looking at is the 3rd edition.
Are you sure? I'm looking at the 3rd Edition myself. When
was your copy printed? This book seems to go through a reprint twice
every year, and mine's from 1990. I only ask because both your
examples of errors seem to be in error themselves, at least as far as
my copy is concerned.
> Two examples: The FRAME program on page 325 violates LRM 9.1.4 - the
> type of the task cannot be used as a typemark within the task itself.
> It's easy to see what the program means, but it doesn't comple.
No, it doesn't violate 9.1.4. I could tell that by
inspection. I was even able to compile it (after removing references
to the FRAME package - I don't know how to get our compiler to build a
library and someone else has the manual). Nowhere in the task body of
FILTER does anyone try to use FILTER as a type. In fact, on p. 327
Barnes specifically states, "(The use of the function MAKE_FILTER is
necessary to overcome a rule that in the body of a task type its name
refers to the current task and not the type.)"
> There is a task example on page 311 that has nested accepts for the
> same entry which violates LRM 9.5(8). Again, its clear what the
> program intends, but it has been simplified in a way that keeps it
> from compiling.
I was able to compile this program too. In my copy of the
book, the accepts are not nested. Do you have the 3rd Edition,
printed in 1990? Maybe your book was printed earlier?
--
Mark Meyer | mme...@dseg.ti.com |
Texas Instruments, Inc., Plano TX +--------------------+
Every day, Jerry Junkins is grateful that I don't speak for TI.
"There's lots of bread in the freezer!" "No, I threw it out. Hard as a rock."
Jo Uhde
[bunch of stuff deleted]
My spouse was rather distracted at the dinner table last night after a long
day battling with C. This morning, my spouse sent me the following e-mail:
#The answer to my C problem is: [^,-,].
#
#Long live Ada.
> > Funny thing, George. Every now and then my wife looks over my shoulder
> > when I'm reading this group, and she always chuckles at what she calls
> > "typical male pi**ing contests". She is still waiting to see a female
> > name on comp.lang.ada (she hasn't lucked into seeing one of Deborah's
> > posts).
> >
> > Mike
Given that I am in a _legal_ (hetero) marriage and posting from my own account,
here's the puzzle:
Are my spouse's comments just part of a "typical male pi**ing contest", but
you've now seen a post on c.l.a from a female? Or is my spouse a female
participating in a "typical male pi**ing contest", and you've yet to get
your quota of female posters to c.l.a? ;-)
Its getting pretty silly around here as the rocket scientists and space cadets
are ready to blast off into a new year.
HAPPY NEW YEAR Y'ALL
DrJo *** uh...@ollie.jsc.nasa.gov
-- Not much of a sig, but it _is_ my NASA nickname.
-- Please, apply all of the usual disclaimers. I don't want to be sent
-- into orbit in the (unpressurized) cargo bay of the Orbiter.
Steve Rogers
>
> I'm new to this group, basically because I'm new to Ada.
>Even so, I just have to comment on this:
>
>In article <1992Dec21....@mcc.com> sro...@teenwolf.mcc.com (Steve Rogers) writes:
>> The edition I am looking at is the 3rd edition.
>
> Are you sure? I'm looking at the 3rd Edition myself. When
>was your copy printed? This book seems to go through a reprint twice
>every year, and mine's from 1990. I only ask because both your
>examples of errors seem to be in error themselves, at least as far as
>my copy is concerned.
>
>> Two examples: The FRAME program on page 325 violates LRM 9.1.4 - the
>> type of the task cannot be used as a typemark within the task itself.
>> It's easy to see what the program means, but it doesn't comple.
>
> No, it doesn't violate 9.1.4. I could tell that by
>inspection. I was even able to compile it (after removing references
>to the FRAME package - I don't know how to get our compiler to build a
>library and someone else has the manual). Nowhere in the task body of
>FILTER does anyone try to use FILTER as a type. In fact, on p. 327
>Barnes specifically states, "(The use of the function MAKE_FILTER is
>necessary to overcome a rule that in the body of a task type its name
>refers to the current task and not the type.)"
The date on my copy is 1989. The FILTER task references itself on page 326.
I suppose the error was found and corrected in later editions.
>> There is a task example on page 311 that has nested accepts for the
>> same entry which violates LRM 9.5(8). Again, its clear what the
>> program intends, but it has been simplified in a way that keeps it
>> from compiling.
>
> I was able to compile this program too. In my copy of the
>book, the accepts are not nested. Do you have the 3rd Edition,
>printed in 1990? Maybe your book was printed earlier?
Whoops! I misread this one.
The correction of the FRAME error answers the larger question of whether
or not the errors were intentionally included to make the examples
"easier" to understand. It appears that this is NOT the case.
bra...@gmail.com
A terrific thread to read with some sound discussion.
What are everybody’s opinions now in 2019?
robin....@gmail.com
> There are a lot of people out there who think C++ is the greatest thing since
> sliced bread. C++ is a truly wonderful toy because you can redefine the
> language for your application.
>
> For example you can provide the function that is invoked in response to
> assignment so you can optimize your matrix class to (1) only pass a pointer to
> the matrix data instead of actually making a physical copy and (2) defer the
> actual copy operation to the point in time when (and if) the target of the
> assignment is modified. This is impressive.
>
> HOWEVER, please read "A dynamic Vector is harder than it looks" from the June
> 1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5 no 4.
> *THIS ARTICLE IS SCARY* Basically Tom Cargill pointed out a bug that nearly
> all C++ textbooks have made when they implement a dynamically sized array.
> This includes the textbook written by the implementor of the AT&T Cfront
> compiler (will I get in trouble if I mention his name?). If the language is so
> convoluted that even the experts (including the compiler writers) cannot get
> their simple textbook examples correct, then I conclude there is something
> drastically wrong with the language.
>
> I don't want anybody writing code in C++ for satellites funded with my tax
> dollars!
>
> I heard a rumer about a multi-million (or multi-billion) dollar satellite going
> astray because some one left a comma out of a FORTRAN DO loop and it was still
> syntactically legal. Can anybody give me a reference on this?
I think that you are referring to a DO statement like:
DO 50 I = 1.20
instead of
DO 50 I = 1,20
In FORTRAN 77, both statements are correct.
They are correct because spaces are ignored, but the first statement
is an assignment statement, viz,
DO50I = 1.20
not a loop control statement, and without any structure on a DO loop
(there's no END of loop statement) the error could not be diagnosed
by a compiler.
If this was reported as a real event, this info may help you to
find it.
> So we have C++ with very similar problems to this problem in FORTRAN that (I
> believe, correct me if I am wrong) Ada was supposed to solve. You can insert a
> ";" between the ")" and the "{" in any while or if statement and the C++
> program is still syntactically correct but semantically disasterous.
>
> So, Ada was on the seen. I spent some significant time as a project lead with
> Ada in '89-90. I was excited about the language. Now I am independent and
> make my living with C++.
>
> Where is Ada going? Is it dying? That thread on "Is GNU-Ada self-insulting"
> suggests that Ada is floundering. How badly is Ada floundering? Does that mean
> I'll never see inheritance in Ada?
>
> Thanks,
> Sieg
robin....@gmail.com
> I heard a rumer about a multi-million (or multi-billion) dollar satellite going
> astray because some one left a comma out of a FORTRAN DO loop and it was still
> syntactically legal. Can anybody give me a reference on this?
This has come up in a couple of threads in the last month or two, so I finally got around to looking it up. The famous FORTRAN punctuation error occured on Mariner 1 in 1962. Here is a description of the error:
"There is a useful lesson to be learned from the failure of one of the earliest planetary probes launched by NASA. The cause of the failure was eventually traced to a statement in its control software similar to this:
DO 15 I = 1.100
when what should have been written was:
DO 15 I = 1,100
but somehow a dot had replaced the comma. Because Fortran ignores spaces, this was seen by the compiler as:
DO15I = 1.100
which is a perfectly valid assignment to a variable called DO15I and not at all what was intended."
Information found here:
http://www.star.le.ac.uk/~cgp/prof77.html#tth_sEc1.3
Jeffrey R. Carter
>
> DO 15 I = 1.100
>
> when what should have been written was:
>
> DO 15 I = 1,100
>
> but somehow a dot had replaced the comma. Because Fortran ignores spaces, this was seen by the compiler as:
>
> DO15I = 1.100
> which is a perfectly valid assignment to a variable called DO15I and not at all what was intended."
variables, so the above would create a new variable DO15I. I don't know what
flavor of FORTRAN was used in Mariner 1, but FORTRAN 66 added the IMPLICIT
statement, which declared the type used for undeclared variables. Adding
IMPLICIT LOGICAL A-Z at the beginning of your code helped to catch these kinds
of things. FORTRAN 77 added IMPLICIT NONE, which required you to declare all
variables. Sometime in the late 1970s-early 1980s people moved away from punched
cards in ALL UPPER CASE and started calling the language Fortran.
Given the kind of testing such software would have undergone, I somehow doubt
that an absence of looping would have gone unnoticed, so I suspect this story is
apocryphal. While it probably didn't cause the failure of a space probe, people
did get bitten by this language design flaw, which is an example of a
single-character error (added, omitted, or changed) that results in valid code.
This is something that competent language designers go to great lengths to
avoid. Note that C and most of its descendants (most of the commonly used
languages today) have this flaw.
--
Jeff Carter
"I like it when the support group complains that they have
insufficient data on mean time to repair bugs in Ada software."
Robert I. Eachus
91
Keith Thompson
In other accounts, the bug consisted of:
* a period typed in place of a comma, causing a FORTRAN DO loop
statement to be misinterpreted (although there is no evidence that
FORTRAN was used in the mission), of the form "DO 5 K=1. 3"
interpreted as assignment "DO5K = 1.3" There are anecdotal
reports that there was in fact such a bug in a NASA orbit
computation program at about this time, but it was a program for
Project Mercury, not Mariner, and the claim was that the bug was
noticed and fixed before any serious consequences resulted.
Also discussed on RISKS Digest, including an account from someone who
worked at NASA in 1963. The error caused a DO loop to execute just once
rather than iterating to a more precise solution. The resulting
calculation was good enough for the Mercury suborbital flights, but not
for the later orbital flights.
http://catless.ncl.ac.uk/Risks/9.54.html#subj1.1
And see here:
http://catless.ncl.ac.uk/Risks/8/75#subj1
for a description of a missing "bar" in a hand-written calculation that
apparently caused the loss of the Mariner 1 Venus probe in 1962.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
robin....@gmail.com
> >
> > DO 15 I = 1.100
> >
> > when what should have been written was:
> >
> > DO 15 I = 1,100
> >
> > but somehow a dot had replaced the comma. Because Fortran ignores spaces, this was seen by the compiler as:
> >
> > DO15I = 1.100
> > which is a perfectly valid assignment to a variable called DO15I and not at all what was intended."
>
> Some people on here may not be aware that FORTRAN did not require declaration of
> variables,
> so the above would create a new variable DO15I. I don't know what
> flavor of FORTRAN was used in Mariner 1,
> but FORTRAN 66 added the IMPLICIT
> statement, which declared the type used for undeclared variables. Adding
> IMPLICIT LOGICAL A-Z at the beginning of your code helped to catch these kinds
> of things. FORTRAN 77 added IMPLICIT NONE, which required you to declare all
> variables.
variables do not need to be declared.
> Sometime in the late 1970s-early 1980s people moved away from punched
> cards in ALL UPPER CASE and started calling the language Fortran.
>
> Given the kind of testing such software would have undergone, I somehow doubt
> that an absence of looping would have gone unnoticed,
the looping DID go unnoticed. [try google]
> so I suspect this story is
> apocryphal.
> While it probably didn't cause the failure of a space probe, people
> did get bitten by this language design flaw, which is an example of a
> single-character error (added, omitted, or changed) that results in valid
> code.
J-P. Rosen
>> While it probably didn't cause the failure of a space probe, people
>> did get bitten by this language design flaw, which is an example of a
>> single-character error (added, omitted, or changed) that results in valid
>> code.
> Single-character errors are still possible, whatever the language.
>
But outside of mathematical formulas, can you give an example of
single-character error in Ada?
--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr
Niklas Holsti
> Le 09/08/2019 à 03:57, robin....@gmail.com a écrit :
>>> While it probably didn't cause the failure of a space probe, people
>>> did get bitten by this language design flaw, which is an example of a
>>> single-character error (added, omitted, or changed) that results in valid
>>> code.
>> Single-character errors are still possible, whatever the language.
>>
> Of course, you can type "-" instead of "+" in any language.
>
> But outside of mathematical formulas, can you give an example of
> single-character error in Ada?
thought) called Address, of type System.Address.
Then, in a certain statement dealing with a record object R of that
type, I mistakenly wrote
R'Address
when I meant
R.Address
Silly me.
I now have a personal coding rule: never use the name Address for a
record component of type System.Address. Perhaps this should be expanded
to forbid using any record-attribute name as a component name; for
example, Size.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
Maciej Sobczak
> single-character error in Ada?
procedure Test is
procedure P (I, J : Integer) is
begin
Ada.Text_IO.Put_Line ("Killing people");
end;
procedure P (f : Float) is
begin
Ada.Text_IO.Put_Line ("Not killing people");
end;
begin
P (1,2); -- or should it be P (1.2); ?
end;
And of course we have to implement the Initialise operation for our Controlled types, right?
--
Maciej Sobczak * http://www.inspirel.com
J-P. Rosen
> I now have a personal coding rule: never use the name Address for a
> record component of type System.Address. Perhaps this should be expanded
> to forbid using any record-attribute name as a component name; for
> example, Size.
Nasser M. Abbasi
P (I=>1, J=>2);
No chance to mix it up with
P (f=>1.2);
--Nasser
Jeffrey R. Carter
> On 19-08-09 09:28 , J-P. Rosen wrote:
>> Le 09/08/2019 à 03:57, robin....@gmail.com a écrit :
>>>> While it probably didn't cause the failure of a space probe, people
>>>> did get bitten by this language design flaw, which is an example of a
>>>> single-character error (added, omitted, or changed) that results in valid
>>>> code.
>>> Single-character errors are still possible, whatever the language.
>>>
>> Of course, you can type "-" instead of "+" in any language.
>>
>> But outside of mathematical formulas, can you give an example of
>> single-character error in Ada?
>
> I once declared a record type that contained a component, aptly (I thought)
> called Address, of type System.Address.
>
> Then, in a certain statement dealing with a record object R of that type, I
> mistakenly wrote
>
> R'Address
>
> when I meant
>
> R.Address
regardless of the developer's choice of identifiers. By that criterion, this is
not a single-character error in the language design. Compare it to =/== in C and
its descendants.
--
Jeff Carter
"[A] brilliant military career that after thirty
years catapulted him to the rank of corporal."
Take the Money and Run
138
Maciej Sobczak
>
> P (I=>1, J=>2);
Which, ultimately, makes it more difficult for Ada to gain attention of C++ programmers, for example.
Lucretia
Luke.
Paul Rubin
> You could always have a enforce named parameters compiler option,
enforce or at least suggest it. So P(1, 2) is valid but P(1. 2) should
be a syntax error.
It's interesting to hear that using named parameters at the call site is
considered good Ada style. In Haskell and C++ one sometimes uses
separate types for the args to make sure they get passed in the right order.
Shark8
> On Saturday, December 5, 1992 at 7:18:16 AM UTC+11, srhe...@happy.colorado.edu wrote:
> >
> > HOWEVER, please read "A dynamic Vector is harder than it looks" from the June
> > 1992 is issue of JOOP (Journal of Object Oriented Programming) - vol 5 no 4.
> > *THIS ARTICLE IS SCARY* Basically Tom Cargill pointed out a bug that nearly
> > all C++ textbooks have made when they implement a dynamically sized array.
> > This includes the textbook written by the implementor of the AT&T Cfront
> > compiler (will I get in trouble if I mention his name?). If the language is so
> > convoluted that even the experts (including the compiler writers) cannot get
> > their simple textbook examples correct, then I conclude there is something
> > drastically wrong with the language.
https://drive.google.com/open?id=1PHUleua3FpIYRrumkboxBCLhMjc_mkxj