Re: Ada ad in Embedded Systems Programming stinks

Re: Ada ad in Embedded Systems Programming stinks

[david.c.willett]

From article <34g5v3INN6q2@phage.cshl.org>, by pjm@isis.cshl.org (Pat Monardo):
> In article <34ecqc$b5q@source.asset.com>,
> Michael M. Bishop <bishopm@source.asset.com> wrote:
>>some development work on some NASA applications in which I was forced to
>>write in C. In C, of course, if you want to supply an OUT or IN OUT
>>parameter as an actual, you have to pass its address. C compilers
>>couldn't care less whether or not you actually pass an address. (I think
>>ANSI C compilers give you a *warning* - big deal: it still accepts the 
>>code). If you forget to put the address operator on the parameter and, 
> 
> Now I understand why languages are religions. Listening to an Ada
> person describe C is like listening to a Christian describe Hinduism.
> Remember, C is a language, not an environment. If want to impose
> discipline on your C code, then find a tool that supports your
> religion. If you allow warnings to stay in your code,
> then you are indeed in need of disciplining, try C++ :)
>

Pat, you win second place in the "short-sighted statement of the week" 
contest.  The discipline you speak of is of no value to a program's writer.
It is of value to those who must read the code.  There are many more such
folk then there are code writers.  Furthermore, you neglect C's intrinsic
low-level structure which makes warnings not all bad.  Sometimes, even 
legitimate and safe C code will generate warnings.  So it is quite
hard to find a tool the "supports your religion" if your religion happens
to be something like Ada's environment.

<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Dave Willett          AT&T Advanced Technology Systems
                      Greensboro, NC USA

When short, simple questions have long, complex answers -- your 
organization's in trouble.

	Adapted from "In Search of Excellence"

Re: Ada ad in Embedded Systems Programming stinks

[Dag Bruck]

>>>>> "RE" == Robert I Eachus <eachus@spectre.mitre.org> writes:

RE> Most Ada avocates, myself included, read, understand, and even use
RE> C where appropriate.  We do not treat C programmers as heretics,
RE> we regard those who speak only C illiterate.

I agree completely that experience with multiple languages is a great
help in attacking programming problems, not the least because an idiom
commonly used in another language may perfectly describe something
that is unusual in the language you normally use.  For example, in
natural languages the Swedish word "lagom" describes something between
two extremes that is satisfactory to all parties; I haven't yet found
an English word with the same connotations (so pardon me for the
imprecise description).

I digress; I would instead point out that there are significant
differences between C and C++, and several postings on comp.lang.ada
do C++ unjustice by taking problems in C and transfering them to C++.

First, there are several areas where checking in C++ is tighter than
in C, for example:

	- function must be declared before it is called
	- function arguments must declared (not in K&R C)
	- no implicit conversion from void* to any other pointer
	- no implicit conversion from integer to enumeration
	- jumps may not by-pass variable initialization

Second, C++ encourages a programming style that leads to better
programs:

	- constructors/destructors provide guaranteed initialization
	  and finalization
	- objects can be declared between statements, which gives a
	  style where variables are not declared until they can be
	  initialized (=> no uninitialized variables)
	- references, in particular as function parameters, reduces
	  the use of pointers (references must be initialized and
	  refer to an object)
	- classes give better program structure (cf. Ada packages)
	- better encapsulation of data (private parts of objects)

It worth pointing out that the items above are "traditional" in the
sense that they have nothing to do with object-oriented programming;
C++ is more than "OO-C."  There are of course newer features, such as,

	- support for OOP, inheritance and virtual functions
	- generics
	- overloading
	- exception handling

RE>     Passing an object instead of a pointer to it (the earlier
RE> example) is a difference between Ada and C.

As described above, this is a case where C++ should appeal more than C
to the Ada programmer.

Finally a comment on the Ada/C/C++ "language wars:" I think the issue
is to use C++ instead of C, not to use C++ instead of Ada, at least
for the great majority of programmers.


					-- Dag Bruck, C++ fan

Re: Ada ad in Embedded Systems Programming stinks

[Robert I. Eachus]

In article <DAG.94Sep8090447@bellman.control.lth.se> dag@control.lth.se (Dag Bruck) writes:

 > I digress; I would instead point out that there are significant
 > differences between C and C++, and several postings on comp.lang.ada
 > do C++ unjustice by taking problems in C and transfering them to C++...

 > Finally a comment on the Ada/C/C++ "language wars:" I think the issue
 > is to use C++ instead of C, not to use C++ instead of Ada, at least
 > for the great majority of programmers.

   Hmmm...  I will reply, but mildly.  I have found several areas where C
is a better implementation language than Ada.  Since Ada is much
better at programming in the large, this generally leads to large Ada
applications with perhaps one or two percent of the unit bodies
written in C.  Of course when interfacing to large bodies of legacy C
code, these numbers go up.

   However, when I have tried to use C++, the only advantages over Ada
83 lie in areas where other Ada 83 features make Ada the better
choice.  (Yes doing OOP in Ada 83 is painful, but I never found a way
to use C++ OOP and encapsulate it.  So the entire program structure
must be in C++, and except on small projects, where the benefits of
OOP are not that great, I'd much rather use Ada for program structure.)
With Ada 9X now here, I get all of the advantages of C++ and none of
the drawbacks--even if I don't use tagged types.  (Generic package
parameters and generic derived type parameters are enough to make
static typed OOP work nicely.  And I much prefer to use static typing
when possible.  Of course, in Ada 9X, I have a choice...) 

   So even with C++ as a completely viable language choice, I never
choose it.  But I still sometimes use C.  (And wash my hands
afterwards. ;-) For that matter I still use APL and Lisp, and if I had
a good Algol W compiler for a modern processor, I might use that to.
(Why Algol W and not Pascal or Modula?  There are times when real call
by name and own variables are useful, but everything in Pascal and
Modula can be found in Ada.)

--

					Robert I. Eachus

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

Re: Ada ad in Embedded Systems Programming stinks

[Dag Bruck]

>>>>> "RE" == Robert I Eachus <eachus@spectre.mitre.org> writes:

RE> I have found several areas
RE> where C is a better implementation language than Ada.

What areas, he asked curiously...  I would be greatly interested in a
discussion of things that C does better than Ada, in particular from
someone whose understanding of Ada is beyond doubt.

					-- Dag Bruck

Re: Ada ad in Embedded Systems Programming stinks

[Robert I. Eachus]

In article <DAG.94Sep8191257@bellman.control.lth.se> dag@control.lth.se (Dag Bruck) writes:

  > What areas, he asked curiously...  I would be greatly interested in a
  > discussion of things that C does better than Ada, in particular from
  > someone whose understanding of Ada is beyond doubt.

   The canonical example is device drivers.  But any code where the
bit representation is more important than the data's value or where
you spend a lot of time "punning" between two different views of the
same data fall in the same category.  For example, a compression
algorithm that uses variable length representations of repeated
strings.  You can write these in Ada--with liberal use of
Unchecked_Conversion--but it is more readable if you use bit
operations on integers, or union types, etc.

   Another (ancient) case was where I needed to find the first bit set
in a large Boolean array.  The trick was to convince the compiler to
use the special string processing operations, then do a conversion
from the first non-null character found to a bit offset.  (Anyone else
remember translate and test instructions?  In any case, the array was
very sparse, and this way the only use of memory bandwidth was to
fetch data.)  Could have written it in assembler, but this code was
portable.  It just wouldn't run anywhere near as fast on a different
hardware architecture.

--

					Robert I. Eachus

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

Re: Ada ad in Embedded Systems Programming stinks

[Brendan WALKER]

In article <DAG.94Sep8090447@bellman.control.lth.se>,
Dag Bruck <dag@control.lth.se> wrote:
>>>>>> "RE" == Robert I Eachus <eachus@spectre.mitre.org> writes:
>
>RE> Most Ada avocates, myself included, read, understand, and even use
>RE> C where appropriate.  We do not treat C programmers as heretics,
>RE> we regard those who speak only C illiterate.
>
  [stuff deleted]

>I digress; I would instead point out that there are significant
>differences between C and C++, and several postings on comp.lang.ada
>do C++ unjustice by taking problems in C and transfering them to C++.
>
>First, there are several areas where checking in C++ is tighter than
>in C, for example:
>
	[deleted features of C++ in addition to C]

>RE>     Passing an object instead of a pointer to it (the earlier
>RE> example) is a difference between Ada and C.
>
>As described above, this is a case where C++ should appeal more than C
>to the Ada programmer.
>
>Finally a comment on the Ada/C/C++ "language wars:" I think the issue
>is to use C++ instead of C, not to use C++ instead of Ada, at least
>for the great majority of programmers.
>
>
>					-- Dag Bruck, C++ fan

This is a good opportunity for some opinion from "down under". On the
project I am currently working on we did see our choice as being between
C++ or Ada. C was never considered. For general information, I will outline
the main reasons why we chose C++ over Ada:

	- Use of GNU C++ Compiler coupled with Signus support contract
	  was MUCH cheaper than purchase of multiple Ada compiler
	  licences. We needed to distribute licences to many different
	  machines, sites, and sub-contractors.

	- Price and availability of a wide range of proven development
	  tools for C++ vs Ada. Especially in the area of GUI and
	  other rapid prototyping tools.

	- Object Oriented Programming features of C++ over Ada-83, (9X was
	  still twinkling in peoples eyes when we had to make our decision).

	- Ease of implementing low-level device driver and UNIX/VX-Works
	  compatible Comms software with C syntax over Ada.

Our project is a distributed 68040/VME and HP-Work Station based system
that is being produced under contract to the Royal Australian Air Force.

Note that most of the Engineers on the project have Ada backgrounds, with
maybe a little C. We have found over-all that former Ada Software Engineers
design and write excellent C++ software.

Coming from an Ada background myself, I can add that I personally prefer
C++ over Ada-83 in many ways, but particularily due to the extra dimension
that the OOP features add to my ability to produce elegant designs and
implementations. I suggest that the C++ critics actually give it a try....

In terms of tools and support (compiler bug fixes etc), down here the GNU
C++/Signus compination is miles ahead of the Ada competition. The last Ada
project I worked on here was stricken by a terribly slow and buggy
compiler, a primitive tool-set, and an absolutely shocking level of 
support from the US-based compiler vendor, who shall remain nameless,
suffice to say that they were one of the "biggies".

The jury is still out until we finish our current project, but so far
it looks as if C++ is here to stay in our organisation.

PS: We do NOT have an Ada mandate from our DoD in Australia, but on
some defence projects in the past Ada has been specified. This practice
is now almost extinct.

-----------------------------------------------------------------------------
-- 
Brendan Walker		| The opinions expressed above are obviously
IASSF Project, 		| the ramblings of a troubled mind, and 
EASAMS (Australia)	| therefore not those of my employer.

Re: Ada ad in Embedded Systems Programming stinks

[John Goodsen]

In article <34ecqc$b5q@source.asset.com> bishopm@source.asset.com (Michael M. Bishop) writes:

   From: bishopm@source.asset.com (Michael M. Bishop)
   Newsgroups: comp.lang.ada
   Date: 5 Sep 1994 02:11:24 -0400
   Organization: Asset Source for Software Engineering Technology

   In article <CvFI4J.D5M@world.std.com>,
   Gregory Aharonian <srctran@world.std.com> wrote:
   [snip...]
   >      "What's more, the compilers will stop, rather than allow incorrect code
   >to go through".  Are you serious???   Do you think anyone will be impressed
   >by this claim?  Has anyone at DISA ever looked at current C/C++ compilers,
   >which stop when they encounter errors and jump you back into the code, a
   >feature that has been around for years?  As a marketing teaser, this statement
   >is useless.  You might as well claim that Ada compilers allow you to compile,
   >link and run from the same pulldown menu.

   pragma Soapbox (On)

   Anybody with an ounce of software engineering sense should be impressed
   by the above claim! A couple of years ago (1990-91, actually), I did
   some development work on some NASA applications in which I was forced to
   write in C. In C, of course, if you want to supply an OUT or IN OUT
   parameter as an actual, you have to pass its address. C compilers
   couldn't care less whether or not you actually pass an address. (I think
   ANSI C compilers give you a *warning* - big deal: it still accepts the 
   code). 

Wrong. A respectable ANSI C compiler will yell louder than a warning.
And puke out on the compile when you don't pass a pointer when expected.
-- 
--
John Goodsen                         Currently on-site at:
The Dalmatian Group                       JP Morgan 
User Interface Specialists                60 Wall St., New York City
jgoodsen@radsoft.com                      jgoodsen@jpmorgan.com

Re: Ada ad in Embedded Systems Programming stinks

[Keith Thompson @pulsar]

In <JGOODSEN.94Sep7184437@trinidad.radsoft.com> jgoodsen@trinidad.radsoft.com (John Goodsen) writes:
[...]
> Wrong. A respectable ANSI C compiler will yell louder than a warning.
> And puke out on the compile when you don't pass a pointer when expected.

One data point: Sun's ANSI C compiler, in strict ANSI mode (cc -Xc)
issues a warning:

pulsar 1) cat -n foo.c
     1  #include <stdio.h>
     2
     3  void func(int *p)
     4  {
     5      printf("p = %p\n", p);
     6  }
     7
     8  int main(int argc, char **argv)
     9  {
    10      int i = 42;
    11      func(i);
    12      exit(0);
    13  }
pulsar 2) cc -Xc foo.c
"foo.c", line 11: warning: improper pointer/integer combination: arg #1

I don't know what other ANSI C compilers do, but I presume Sun's is one
of the most commonly used.

-- 
Keith Thompson (The_Other_Keith)  kst@alsys.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
/user/kst/.signature: I/O error (core dumped)

Re: Ada ad in Embedded Systems Programming stinks

[John Goodsen]

In article <1994Sep4.092729.21408@lmpsbbs.comm.mot.com> davidk@mcil.comm.mot.com (David Kramer) writes:


   To add to Norman Cohen's list of reasons why an Ada compiler is more
   effective than lint:

     It is much too easy to get around type mismatches in C - as any 
     unscrupulous C programmer knows - all you have to do is use a cast!
     (eg. (Apples)oranges = apples). The lints that I have used had no 
     problems with this - in fact in one project I worked on we were instructed
     to use lint and to have no warnings. The way our 'project leader' 'fixed'
     type mismatch problems was by casting it away!

This isn't much easier than doing unchecked conversions in Ada.  You identified
a project management/process problem, not really a technological advantage
of one language over another...

-- 
--
John Goodsen                         Currently on-site at:
The Dalmatian Group                       JP Morgan 
User Interface Specialists                60 Wall St., New York City
jgoodsen@radsoft.com                      jgoodsen@jpmorgan.com

Re: Ada ad in Embedded Systems Programming stinks

[Keith Thompson @pulsar]

In <JGOODSEN.94Sep7184648@trinidad.radsoft.com> jgoodsen@trinidad.radsoft.com (John Goodsen) writes:
> In article <1994Sep4.092729.21408@lmpsbbs.comm.mot.com> davidk@mcil.comm.mot.com (David Kramer) writes:
>    To add to Norman Cohen's list of reasons why an Ada compiler is more
>    effective than lint:
> 
>      It is much too easy to get around type mismatches in C - as any 
>      unscrupulous C programmer knows - all you have to do is use a cast!
[...]
> This isn't much easier than doing unchecked conversions in Ada.
> You identified a project management/process problem, not really a
> technological advantage of one language over another...

Any Ada program that uses an unchecked conversion must have an explicit
context clause for the generic function Unchecked_Conversion.  This makes
it very easy to tell that the program is doing something low-level and
potentially dangerous.  Furthermore, Ada clearly distinguishes between
unchecked and checked conversions.  C uses the same construct (the cast)
for arithmetic conversions from int to float that it uses to coerce one
pointer type to another.

Ada doesn't prevent you from writing ugly, low-level, non-portable code,
but it makes it more difficult to do it accidentally -- and that *is*
a technological advantage.

-- 
Keith Thompson (The_Other_Keith)  kst@alsys.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
/user/kst/.signature: I/O error (core dumped)

Re: Ada ad in Embedded Systems Programming stinks

[David Emery]

It's my experience in porting software that the context clause ("with
list") is one of the key parts of Ada portability.  It establishes
quite clearly what any given unit depends on.  

This observation is one of the major reasons that POSIX/Ada is defined
as a set of packages, rather than one huge package.  This way, if you
see "with POSIX_Files, POSIX_IO;", you know there's a dependence on
the file system, but NOT on processes and signal handling.

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Re: Ada ad in Embedded Systems Programming stinks

[Michael M. Bishop]

In article <347idh$15ss@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>And whenever I try to explain this to a dedicated C programmer, I receive
>the reply, "What's wrong with just using Lint?"  Ada promoters should be
>prepared to answer this objection before they make the argument about Ada
>facilitating the detection of errors.  Here are some counterarguments,
>some more compelling than others: 
[lots of good reasons that Ada compilers are better than C compilers +
Lint snipped]

My $0.02: The few times I tried to use Lint, either it didn't catch some
actual problems with the code, or I had trouble figuring out the listing
it generated. (Maybe I have a built-in bias against C or I'm just
stupid. :-) Ada error messages include references to sections of the LRM
so programmers can figure out why the compiler issued the error.
-- 
| Mike Bishop              | The opinions expressed here reflect    |
| bishopm@source.asset.com | those of this station, its management, |
| Member: Team Ada         | and the entire world.                  |

Re: Ada ad in Embedded Systems Programming stinks

[Robert Dewar]

Mike says:  

"Ada compilers include LRM references so the programmer can figure out the
 error"

This of course is an attribute of an implementation not a language (C
compilers and Lint could equally well include references to the ANSI
standard).

There are however real language differences that show up, e.g. when in C
you casually write an unchecked conversion from pointer to integer, or
you casually assume that pointers and integers occupy the same amount of
space, or, or, or ... these are not errors in the sense of being static
violations of some rule that Lint can easily catch. 

That being said, the fact that in Ada, the compiler is required to catch
things means that it certainly will. A given implementation of Lint may
or may not catch all the possible static errors (which were not designed
into C in a manner guaranteeing that they could be detected). It's really
that fundamental philosophical difference that is important. Standards like
the COBOL, Fortran and C standards are basically only positive standards,
they tell you what a legal program *is*, and what a conforming implementation
must do with a legal program. The Ada standard is equally concerned with
the class of illegal programs, and worries about what a conforming
implementation must do with an illegal program.

This isn't just theory, IBM has at least in one incident I know of, officially
refused to accept as a valid bug report from an important COBOL user, a
complaint that the compiler did not diagnose an error.

Speaking of LRM references, especially with Ada 9X, where parts of the RM
are very technical and do not even pretend to be simple easy to read English,
I am not at all sure that routinely sending people off to look at the RM is
a favor.

In GNAT we really concentrate on giving an error message that is clear enough
at a simple informal level to avoid the need to rummage in the LRM. Our
eventual plans are to have an auxiliary utility which will further explain
an error message, using additional text as well as references to the RM,
AARM, Rationale or whatever.

We haven't started work on that utility, but we have a good name for it
GNOME (GNAT Online Message Explanation).

That seems the best compromise. After all, remember that the user who is
most likely to need further help is also the user least likely to be able
to read the RM. If you really know the RM well, you shouldn't be making
errors in the first place, and you certainly should be able to figure
them out :-)

Re: Ada ad in Embedded Systems Programming stinks

[Robert Dewar]

ABOUT SUBJECT LINES                             

You will notice that a long thread now, mostly discussing the issues of
error detection in Ada and C, has had the above inflammatory subject,
inherited from the original GA post. Now of course, many of us posting
in this thread don't agree at all with the premise of the subject (I
certainly don't), but I hesitate to change the subject since this will
make it harder for some folks to follow the thread in thread reading
news readers.

It's an old trick in the newsgroup world to editorialize like this in
subject lines, but it's really rather poor netiquette. It's better to
post a neutral subject line (e.g. in this case leave of the stinks), and
keep the flaming to the body of the text. That way we don't get misleading
subject lines as the thread extends.

Greg, we know from the author the tone of the message in advance anyway, so
could you please try to use more neutral subjects. I think it will help the
tone of discourse. Certainly it would be nice if others will follow this
simple rule!

Re: Ada ad in Embedded Systems Programming stinks

[Norman H. Cohen]

In article <34v0od$i0n@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar)
writes: 

|> It's an old trick in the newsgroup world to editorialize like this in
|> subject lines, but it's really rather poor netiquette. It's better to
|> post a neutral subject line (e.g. in this case leave of the stinks), and
|> keep the flaming to the body of the text. That way we don't get misleading
|> subject lines as the thread extends.

It seems that my news reader, xrn, did the work for me!  In its list of
unread articles, it truncates the subject line to 42 characters, so until
I saw Robert's post, I truly believed that all these postings had the
subject line

   Re: Ada ad in Embedded Systems Programming

(The body of the message contains the full subject line, of course, but I
tend to ignore the header lines in a message body.)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Ada ad in Embedded Systems Programming stinks

[Erik Naggum]

|   That seems the best compromise. After all, remember that the user who is
|   most likely to need further help is also the user least likely to be able
|   to read the RM. If you really know the RM well, you shouldn't be making
|   errors in the first place, and you certainly should be able to figure
|   them out :-)

kidding aside, I think this is a harmful view, because it assumes that
those who are experts in a particular area of the language will also be
experts in _all_ areas, and while possibly not _obviously_ wrong, this
nevertheless has the unfortunate side effect of discouraging people from
exploring new areas.  this is what happens with C and C++, for instance,
where once you get some particular way of doing something to work, you are
not likely to look into ill-described alternatives.  Ada should encourage
programmers to become better programmers, not more "get it to work, dammit"
programmers.

programmers who _don't_ have readily available copies of the reference
manual for the language(s) and libraries they use are a dangerous breed.

#<Erik>
--
Microsoft is not the answer.  Microsoft is the question.  NO is the answer.

Re: Ada ad in Embedded Systems Programming stinks

[Robert Dewar]

But Erik, surely you can't think the RM is the right place to learn Ada
style. Indeed much of the RM, of necessity, discusses marginal cases and
rules that are there for semantic consistency, but are hardly valuable
tools in the Ada programmer's arsenal. 

In the past, I have been a big supporter of the idea of all Ada programmers
using the Ada RM as a major reference tool, but the Ada 9X RM, partly as a
result of the increased complexity of the language, particularly in its
type model, and partly because of the greater emphasis on a somewhat more
formal style (in an attempt to be more precise), is considerably more
difficult to understand than the Ada 83 RM.

Erik, I would be interested if your opinions are arrived at with a thorough
familiarity with the 9X RM, or are more just the way you hope things should
be.

Anyway, I continue to think that having optional RM references is what
serves the community of people using GNAT best. 95% of the time, the
RM reference would be completely unnecessary, even for a novice
programmer, and only in a faction of the remaining 5% of cases would
it really be a big help, and that's the case in which you can look it
up.

Note also that the GNOME approach gives much MORE than simply an RM
reference, it gives a more thorough explanation, of which the RM
reference is only one aspect.

THe issue of how accessible defining documents should be is an interesting
one. I am one of the relatively few people who got to know the Algol-68 
revised report thoroughly. At that level of knowledge, it is a superb
document, extremely precise, very complete, and very accessible.

However, the great majority of people found it completely inpenetrable,
and it clearly contributed to the demise of the language.

I am afraid that if people's first introduction to using Ada at a simple
level points to the RM, this will NOT be helpful in convincing people
that Ada is simple to learn and easy to use.

Of course experienced programmers will continue to use the RM as a primary
reference source, and that's why it is valuable to get the error references
when you need them.

Re: Ada ad in Embedded Systems Programming stinks

[Dag Bruck]

>>>>> "R" == Robert Dewar <dewar@cs.nyu.edu> writes:

R> THe issue of how accessible defining documents should be is an
R> interesting one. I am one of the relatively few people who got to
R> know the Algol-68 revised report thoroughly. At that level of
R> knowledge, it is a superb document, extremely precise, very
R> complete, and very accessible.

R> However, the great majority of people found it completely
R> inpenetrable, and it clearly contributed to the demise of the
R> language.

Have you seen the Draft International Standard for Modula-2?

If nothing else will kill Modula-2, this document will!  More
seriously, the Modula-2 standard mixes natural language and VDM-SL (a
formal specification language), and I think the mix is totally
incomprehensible.  The last statement is of course also a statement on
my level of education.

By the way, the reference manual has grown from some 30 pages to about
600 pages, and is bigger than the DIS for Ada 9X.

					-- Dag Bruck

Re: Ada ad in Embedded Systems Programming stinks

[David Weller]

In article <DAG.94Sep12082826@bellman.control.lth.se>,
Dag Bruck <dag@control.lth.se> wrote:
>[Robert Dewar writes]
>R> However, the great majority of people found it completely
>R> inpenetrable, and it clearly contributed to the demise of the
>R> language.
>
>Have you seen the Draft International Standard for Modula-2?
>
>If nothing else will kill Modula-2, this document will!  More
>seriously, the Modula-2 standard mixes natural language and VDM-SL (a
>formal specification language), and I think the mix is totally
>incomprehensible.  The last statement is of course also a statement on
>my level of education.
>
>By the way, the reference manual has grown from some 30 pages to about
>600 pages, and is bigger than the DIS for Ada 9X.
>

I recall the "bragging claim" for Modula-3 was that it not exceed 50
pages.  Hmm, let's see, if we remove spaces, examples, libraries,
implementation notes, cross-references, and reduce down to a 2-point
font, we ought to be able to do that too :-)

[Actually, a bit of trivia here (maybe not), the Ada 9X RM, sans
Annexes,is actually smaller than the C++ Annotated Ref Manual 
(which I consider roughly equivalent) ]

(for those of you looking to trash C++, this isn't a good metric --
both RM's take different approaches to describing features).

the closest equivalent)

-- 
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
             Ada 9X -- It doesn't suck                       ||  father's Ada
For all sorts of interesting Ada 9X tidbits, run the command:||________________
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)

Re: Ada ad in Embedded Systems Programming stinks

[Erik Naggum]

[Robert Dewar]

|   Erik, I would be interested if your opinions are arrived at with a
|   thorough familiarity with the 9X RM, or are more just the way you hope
|   things should be.

as we have discussed privately, my comments stemmed mostly from experience
with Ada 83 RM.  I have not come far enough into the RM9X to really see the
differences you see as so enormous.  so, a possibly premature apology for
the possibly premature comments.  however, I'm no foreigner to standards
and their prose, which may of course also provide some bias in readability
questions.  (failed to understand Algol 68, though, but that was 10 years
ago.)

I don't usually confuse hopes with reality, but they _have_ tended to
influence eachother.

#<Erik>
--
Microsoft is not the answer.  Microsoft is the question.  NO is the answer.

Re: Ada ad in Embedded Systems Programming stinks

[Maarten Landzaat]

Erik Naggum writes:

>programmers who _don't_ have readily available copies of the reference
>manual for the language(s) and libraries they use are a dangerous breed.
>
>#<Erik>
>--
>Microsoft is not the answer.  Microsoft is the question.  NO is the answer.

Your statement is not the answer. It is the question. NO is the answer.

But seriously: I think you are exaggerating. Programmers should write
'good' code. One of the virtues of good code is that it uses constructs
that anybody can understand. It's the same as with natural language:
difficult sentences sound bombastic and don't get the message across.

Although a manual within reach IS of course very useful...
-- 
Maarten Landzaat (gijs@mbase97.xs4all.nl)
Amsterdam, Double bass, Fender Jazz Bass, Atari ST, Roland Sound Canvas.
Listen to M-BASE music!

Re: Ada ad in Embedded Systems Programming stinks

[Richard A. O'Keefe]

gijs@mbase97.xs4all.nl (Maarten Landzaat) writes:
>But seriously: I think you are exaggerating. Programmers should write
>'good' code. One of the virtues of good code is that it uses constructs
>that anybody can understand. It's the same as with natural language:
>difficult sentences sound bombastic and don't get the message across.

I think you have misunderstood the reason why it is essential to keep
checking the manual.  I personally am sick and tired of C code "that
uses constructs that anybody can understand" but doesn't work.  Example:
someone else's code I'm _still_ trying to fix after a couple of weeks
(ok, I'm not doing this full time) which, amongst other things, assumes
that (a) pointers and 'int's are the same size and (b) casting a pointer
to an int preserves all the bits.  If I tell you that this is not true,
you can probably guess which machine and what memory model...

The point of checking the manual is not to become intimate with all kinds
of super-whizzy features that demonstrate your wizard-hood, but to learn
what kinds of things to _avoid_.  Far too many people confuse what happens
to work in their implementation, or what seems to them like the obvious
translation, with what the language actually promises.  The C standard,
for example, is exceptionally valuable because it has appendices with
long lists of things you _thought_ were ok but aren't.  I was really shocked
when I found out how many things I had relied on were just 'common
extensions'.

If you only have the programmer's reference manual for Brand X, you don't
know what you _shouldn't_ be using.

-- 
The party that took Australia into Vietnam wants to smash the inner-city
yacht school and put a Grand Prix in its place.  They don't change.

Re: Ada ad in Embedded Systems Programming stinks

[Fred McCall]

In <353tqe$7pa@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au Richard A. O'Keefe writes:

>I think you have misunderstood the reason why it is essential to keep
>checking the manual.  I personally am sick and tired of C code "that
>uses constructs that anybody can understand" but doesn't work.  Example:
>someone else's code I'm _still_ trying to fix after a couple of weeks
>(ok, I'm not doing this full time) which, amongst other things, assumes
>that (a) pointers and 'int's are the same size and (b) casting a pointer
>to an int preserves all the bits.  

Obviously written by someone who has been ignoring the advice of people
who know C (the phrase "All the world is not a VAX" emanating from the
direction of Toronto comes to mind).  Note that someone who does this
isn't going to be helped by a language manual.  They're going to need to
know a bit more about their environment -- which to my mind is
information they ought to know, anyway.

>The point of checking the manual is not to become intimate with all kinds
>of super-whizzy features that demonstrate your wizard-hood, but to learn
>what kinds of things to _avoid_. 

Or better yet, to learn what 'misfeatures' to look for in other peoples'
code.  Personally, I learned more C by reading comp.lang.c than I got
from the books.  Would that newsgroups were still as informative as they
used to be.

Howevver, I think it is a valid issue that Ada programmers typically
NEED to look in the language reference more often.  This is an expected
result of the language being 'pickier' about what it will let you do.

--
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
---------------------------------------------------------------------------
merlin@annwfn.com -- I don't speak for others and they don't speak for me.

Re: Ada ad in Embedded Systems Programming stinks

[Mitch Gart]

Yes, lint catches some errors in C programs.  But the Ada
and C type models are fundamentally different.  In Ada
you might have:

    type Time is new Integer;
    type Temperature is new Integer;

and then objects of these types are marked as being different, 
and cannot be assigned or mixed in arithmetic operations without 
a type conversion.  The equivalent in C is:

    typedef int Time;
    typedef int Temperature;

but now both of these types are treated like synonyms for "int".
All the integer assignment and arithmetic operations are available,
mixing objects of these types, without type coercions.  

Because of this fundamental difference in the type model, a whole 
class of errors won't be detected at compile time by any C compiler 
(ANSI or not) or lint.

	Mitch Gart

Re: Ada ad in Embedded Systems Programming stinks

[Bob Wells #402]

Brendan WALKER <bjw@F111.IASSF.EASAMS.COM.AU> writes

> PS: We do NOT have an Ada mandate from our DoD in Australia, but on
> some defence projects in the past Ada has been specified. This practice
> is now almost extinct.

G'day Brendan,
Do you mean that the Collins submarine project, the ANZAC frigate project
and the JOHRN project aren't being done in Ada?
Bob W. (-: