Ada ad in Embedded Systems Programming stinks 
Author Message
 Ada ad in Embedded Systems Programming stinks

      Nice try guys, but the Ada ad in the latest issue of Embedded Systems
Programming is a marketing disaster.  Sure, the ad starts out nice with a
catchy header "THOSE WHO SWEAR BY SYSTEMS CHOOSE THEIR LANGUAGE CAREFULLY",
followed by a eye-catching photo of a car assembly line.

      But from there the ad goes downhill quickly.  First off, even though
the ad appears in a journal devoted to real time systems and embedded
programming, there is nothing in the text of the ad that directly refers
to either of these two topics.  Embedded Systems Programming has a very
specialized audience which this ad does not directly address in the text.

      Next look at the body of the text of the ad.  "The language's inherent
readability ensures that an error is easily understood, and is therefore
quickly rectified".  Bullshit.  I can write beautiful code in any language,
and I can write really ugly code in Ada.  Language's don't kill readability
- People kill readability.  Besides, your marketing to realtime programmers
using C/C++ who love writing obscure, unreadable code from time to time.
This sentence has little marketing pull.

      "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.

      "And program parts that you know to function correctly can safely be
re-used".  Well, this might appeal to people who have been reusing C/C++ code
from their libraries for over ten years, but is it enough to make anyone
switch?  Or when they start flipping through magazines trying to find some
libraries of reusable Ada code for sale, and find none, what will they think?
You are offering nothing they don't already have.

      "For a free kit ...., call .....", well Ralph has summarized the mess
with the clearinghouse here.

      I can't believe taxpayer's money was spent to prepare this ad, when
there are so many aspects of Ada that clearly differentiate it from C/C++,
that can be used in an ad.

Greg Aharonian

P.S.

     If you guys want a good example of how to sell, go look at Intermetrics'
C compiler ad - they have they art of selling C to the realtime market handled
real well (or ask DDC-I with their nice realtime C++ kernel, or Tartan with
the DSP C compiler, both who advertise in ESP - geesh, these two companies are
members of the ASA who approved these ads - don't you talk to your C/C++
divisions???)



Mon, 17 Feb 1997 10:12:18 GMT  
 Ada ad in Embedded Systems Programming stinks

Quote:

>      "What's more, the compilers will stop, rather than allow incorrect code
>to go through".

On this one, I side with Greg.  Whoever wrote that sentence seems
to me to be pretty clueless about what compilers are and how they
work.  Same goes for whoever hired them to write it.


Mon, 17 Feb 1997 16:40:46 GMT  
 Ada ad in Embedded Systems Programming stinks
Clearly what they meant to say was something like:

The Ada compiler detects many errors at compile time, and prevents attempted
execution of incorrect programs that in other languages would result in
runtime errors that have to be found through time-consuming testing and
debugging methods, or indeed are never found at all.

Or somesuch ..

I assume this was the thought that got mangled!



Tue, 18 Feb 1997 00:08:26 GMT  
 Ada ad in Embedded Systems Programming stinks
|> Clearly what they meant to say was something like:
|>
|> The Ada compiler detects many errors at compile time, and prevents attempted
|> execution of incorrect programs that in other languages would result in
|> runtime errors that have to be found through time-consuming testing and
|> debugging methods, or indeed are never found at all.

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:

o Running both Lint and a C compiler requires the program text to be
  parsed and semantically analyzed twice.  The results of an Ada
  compiler's parse and semantic analysis are used directly in performing
  consistency checks.

o The rules of Ada provide the opportunity for stronger consistency
  checks than are possible with C.  For example, an Ada programmer can
  declare distinct integer types to represent distinct abstractions.  An
  Ada compiler will catch an inadvertent intermixing of these two types,
  but there is no way a corresponding distinction can be made in C, so
  there is no way for Lint to perform a corresponding check.  Similarly,
  in C, a pointer to an object of type T is indistinguishable from an
  array of objects of type T.

o The rules of the Ada language ensure that the program text provides
  information allowing PRECISE consistency checks.  For example, the
  expression in an Ada case statement can be written to have a static
  subtype, allowing the compiler to ascertain that all possible values
  have been covered without resorting to a default (when others) arm.

o With lack of precise information, Lint has no choice but to be overly
  pessimistic or, with different settings for a complicated set of
  options, overly optimistic.  When it is overly pessimistic, the user
  sees too many "false alarms" and may end up ignoring valid warnings.
  When it is overly optimistic, Lint overlooks certain errors.

o It is impossible to forget to run consistency checks when using an Ada
  compiler.  (Of course a C programming environment could be set up so
  that the C compiler could only be invoked from a script that also
  invokes Lint.)

o A compilation that fails Ada consistency checks is rejected.  A
  compilation that fails Lint consistency checks may still be compiled,
  and its object file used (intentionally or accidently) in building the
  system.  (One cannot automate the rejection of programs that fail Lint
  unless one is certain that there will never be any false warnings.)

o Ada enforces consistency among separately compiled units.

Other counterarguments are welcomed.

Of course even stronger arguments can be made about Ada's RUN-TIME checks
(which can be used with little additional overhead because the
information contained in an Ada program and the knowledge that the
program has passed compile-time consistency checks make it possible to
optimize away the majority of the checks).  These checks, which are
absent in C, tend to smoke out errors early by detecting internal
inconsistencies that might not otherwise be detected during testing.
This reduces the likelihood of fielding a system that appears to work
well during testing but fails in operational use.

--



Wed, 19 Feb 1997 00:04:01 GMT  
 Ada ad in Embedded Systems Programming stinks
C++ handles some of these objections, but not all of them.  For
instance, C++ performs a lot of implicit conversions.  In C++, in
particular, you can get accidental conversions of APPLE_COUNT to
ORANGE_COUNT without any indication of that as a type error.

                                dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors.
-- "A good plan {*filter*}ly 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
-------------------------------------------------------------------------



Tue, 18 Feb 1997 21:22:59 GMT  
 Ada ad in Embedded Systems Programming stinks

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!

--

[ Motorola Communications Israel Ltd. |  Phone (972-3) 565-8638 Fax 565-9507 ]



Thu, 20 Feb 1997 17:27:29 GMT  
 Ada ad in Embedded Systems Programming stinks

:
: o Running both Lint and a C compiler requires the program text to be
:   parsed and semantically analyzed twice.  The results of an Ada
:   compiler's parse and semantic analysis are used directly in performing
:   consistency checks.
: ...
:
: Other counterarguments are welcomed.

Ada compilers can profit from the high-level semantic analysis by selecting
"smart" optimizations based on types, constraints, no pointers into the
stack, etc.  (Apparently, Tartan's Ada compilers do such things and are thus
able to produce highly optimized code.)

--
Magnus Kempe            "I know not what course others may take, but as for me,



Fri, 21 Feb 1997 15:29:19 GMT  
 Ada ad in Embedded Systems Programming stinks

[snip...]

Quote:
>      "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). If you forget to put the address operator on the parameter and,
worse yet, if you're in a Unix environment like I was, the code will
generate the infamous "segmentation fault" (and the "bus error" for
people like me who can really{*filter*}things up :-). Of course,
these errors can occur for any number of reasons. It takes time to find
the place where the address operator should have been placed. At that
time, I figured that each engineer doing development work lost at least
one man-week per year tracking these problems down. This would
absolutely NOT happen in Ada, since such an oversight is caught at
compile time. (This is what the ad means when it says that incorrect
code is not allowed to go through.) So, in this NASA environment, which
has not and is not likely to change, the use of Ada would save a lot of
money. I don't doubt that the ad mentioned above sucks. But don't tell
me that an Ada compiler's ability to catch these kinds of errors and
stop in order to prevent the code from getting linked is trivial. It's
one of the many big advantages Ada has over languages such as C and C++.

P.S. Oh, before I forget...

pragma Soapbox (Off)

--
| Mike Bishop              | The opinions expressed here reflect    |

| Member: Team Ada         | and the entire world.                  |



Fri, 21 Feb 1997 14:11:24 GMT  
 Ada ad in Embedded Systems Programming stinks

|> 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:
|>
|> o The rules of Ada provide the opportunity for stronger consistency
|>   checks than are possible with C.  For example, an Ada programmer can
|>   declare distinct integer types to represent distinct abstractions.  An
|>   Ada compiler will catch an inadvertent intermixing of these two types,
|>   but there is no way a corresponding distinction can be made in C, so
|>   there is no way for Lint to perform a corresponding check.  Similarly,
|>   in C, a pointer to an object of type T is indistinguishable from an
|>   array of objects of type T.

In other words, Lint doesn't check code out HALF as well as Ada can.

My favorite arrgument has always been to bide my time until you get one of
"those" errors. You know the type... where an off-by-one error causes an
array index to go out of range, which causes a garbage data value to be
picked up, which is sent through 3 layers of routines, then across a network
to another machine, then through 3 more layers of routines, then across a
network again to a third machine, then through 4 layers of routines, finaly
causing failure of the fifth routine on machine 3. Of course all these machines
execpt the first are single board computers, with no de{*filter*}s or text output.

After the 2 weeks it takes to track this one down, just mention to your newly
grey-haired co-worker that it would have been caught at compile time by an Ada
compiler.

You might also metion that if Ada had been used anywhere along the way, the
problem would have stopped there.

Now we just have to convince our managers...

T.E.D.



Sat, 22 Feb 1997 19:50:06 GMT  
 Ada ad in Embedded Systems Programming stinks


|>     If someone tried to sell you a car with no brakes, with the
|> explanation that drivers with good eyesight and coordination didn't
|> often use them, you might be tempted to do physical harm to the
|> seller.  But if yhe only automobiles on the market had no brakes, no
|> emergency flashers, no seatbelts, and no airbags, you might not be
|> willing to "pay the extra cost" for this unwanted feature in a new
|> car.

A great posting, but I just had to add that the above car sounds like a boat.

No brakes, no flashers, no seatbelts and no airbags.  :-)

Sorry for the bandwidth.

                          Later,
                          Bill Yow
                          (713) 280-1591

My opinions are my own!



Sat, 22 Feb 1997 22:34:09 GMT  
 Ada ad in Embedded Systems Programming stinks

 > 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++ :)

pragma SERMON(ON);

    Ada is NOT the religion, software engineering is the religion.
Most Ada avocates, myself included, read, understand, and even use C
where appropriate.  We do not treat C programmers as heretics, we
regard those who speak only C illiterate.  Why?  Because those who
only speak George Orwell's Newspeak, or for that matter double plus C,
are unable to understand the problems the only language they know
forced them to live with.

    If someone tried to sell you a car with no brakes, with the
explanation that drivers with good eyesight and coordination didn't
often use them, you might be tempted to do physical harm to the
seller.  But if yhe only automobiles on the market had no brakes, no
emergency flashers, no seatbelts, and no airbags, you might not be
willing to "pay the extra cost" for this unwanted feature in a new
car.  Those who want to use the highways, but find the risk from other
drivers in brakeless cars unacceptable, just throw up their hands when
the drivers who have never learned to use brakes explain why they
don't want them.

     Lest this seem too farfetched, read the history of George
Westinghouse and his "automatic" brakes for railroad cars.  (Yes, once
upon a time the job of the railroad brakeman was to go from car to car
manually adjusting the brakes.)  Or better yet, the fight by WWI
fighter pilots to be permitted to carry parachutes!

     If you accept the need for tools which detect and prevent major
debugging problems before they occur, then you can begin to understand
why software engineers are such Ada advocates.  For example, while C++
designers are just beginning to understand elaboration issues, it has
been at least a year since I had to help an Ada programmer who had
elaboration order problems.  Ada users quickly learn which structures
can cause elaboration issues, use those structures only where
necessary, and track the elaboration order when it may be a problem.
Not painting yourself into a corner early in the design process can
save months later in the development process, usually during
integration.

    Passing an object instead of a pointer to it (the earlier example)
is a difference between Ada and C.  But it is the tip of the iceburg
which most C programmers never see, even after their ship (or project)
sinks beneath the waves.  I will continue to react rudely to any C
programmer who tells me why he doesn't need compile time checking,
just as I would to a driver explaining why his car has no brakes.  I
have had to deal with too many bodies from the (software development)
highway to do otherwise.

pragma SERMON(OFF);
--

                                        Robert I. Eachus

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



Sat, 22 Feb 1997 17:40:18 GMT  
 Ada ad in Embedded Systems Programming stinks


Quote:
>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++ :)


Sat, 22 Feb 1997 06:26:43 GMT  
 Ada ad in Embedded Systems Programming stinks

Quote:


>>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"



Sat, 22 Feb 1997 21:46:15 GMT  
 Ada ad in Embedded Systems Programming stinks

 > 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...



Mon, 24 Feb 1997 17:52:16 GMT  
 Ada ad in Embedded Systems Programming stinks


   Newsgroups: comp.lang.ada
   Date: 5 Sep 1994 02:11:24 -0400
   Organization: Asset Source for Software Engineering Technology



   [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



Mon, 24 Feb 1997 06:44:37 GMT  
 
 [ 36 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Ada ad in Embedded Systems Programming stinks

2. Ada in Embedded Systems Programming.

3. Ada vanishes from Embedded Systems Programming

4. Ada is almost useless in embedded systems

5. CNF: Embedded Systems Club and Ada UK User Group Autumn Conference

6. Real-time embedded systems - Ada resources

7. Ada in embedded systems?

8. Why no Ada at Embedded Systems Conference?

9. Ada for embedded system specification - tools ?

10. Internet Resource Lists - Ada, Embedded Systems - Pointer

11. Ada is almost useless in embedded systems

12. Ada is almost useless in embedded systems

 

 
Powered by phpBB® Forum Software