Ada's Slide To Oblivion ...

Ada's Slide To Oblivion ...

[Volkert]

found at Embedded Systems Programming:

>Ada is the only language designed to
>significantly reduce and maybe even
>eliminate dumb programming errors. Did
>it fall into disuse because we're
>intellectually lazy?

read more: http://www.embedded.com/story/OEG20020125S0098

Volkert

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

An interesting article. One could argue about the accuracy of the survey,
but it probably isn't that far off from reality.

What I liked about it was that it was fair and balanced. It didn't smack of
the usual anti-Ada vitriol, nor was it filled with misinformation. The
criticism that Ada doesn't have as many tools as C/C++ is reasonably fair -
I think it is a better situation than the author seems to imply, but let's
face it: For just about any embedded board, you can get a C compiler thrown
in with the development kit & you won't find Ada riding along with it as an
alternate choice. (Although Gnat merging with gcc stands to help improve the
situation - but still people have to ask for it or nobody will bother.)

The question about programmers being "intellectually lazy" may have a lot to
do with it. In order to do Ada development in a way that maximizes the
benefits and minimizes the time fighting with the compiler to get it right,
requires that you spend time up front thinking about the organization of the
system - what the relevant data types are, what information should be
hidden, etc. Embedded developers tend to be tinkerers who want to start
hacking some bootstrap code and keep adding things to it until it works.
Weeks of planning and diagram drawing and design meetings prior to writing
any code tends to not be the thing they got into the business to do. Never
mind that it might save months/years of debugging and produce a more
reliable system that improved customer satisfaction and reduced liability -
that's just not the mode of thought that feels comfortable to your average
embedded/C developer.

The question at the end about the government being to blame for not sticking
to its guns is another interesting one. The government instituting "The
Mandate" (especially when compiler technology just wasn't there) probably
raised a lot of hackles over being "forced" to do something. (I *still*
think that had the government tried bribery instead of extortion, it might
have worked. If you were the program manager for some electronic whozits and
the government offered you a $100,000.00 bonus if only you could find a way
to get the project done in Ada, do you think your opposition to Ada would be
so strong?)

Anyway, having had The Mandate, then abandoning it is worse than never
having The Mandate to begin with. Think about it - the perception is that
the government was admitting it made a mistake by mandating Ada, so the
contractors started abandoning it in droves. Standing there saying "No!
Really! I'm *NOT* saying Ada is a bad thing!!!!" doesn't matter. Actions
speak louder than words and perception often *IS* reality. ("Hey, the DoD
dropped Ada like a hot rock. We must have been right all along. Ada really
*did* suck!)

The good news is that if people are writing thoughtful articles like this
and observing that Ada really does have benefits (despite lack of use) maybe
it might generate some renewed interest. The fact that they're writing about
it at all is a sign that Ada isn't a non-issue. IOW, "I don't care what they
say about Ada as long as they capitalize its name right!" :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Volkert" <Volkert.Barr@freenet.de> wrote in message
news:b84db440.0201301508.1e3ea4b6@posting.google.com...
> found at Embedded Systems Programming:
>
> >Ada is the only language designed to
> >significantly reduce and maybe even
> >eliminate dumb programming errors. Did
> >it fall into disuse because we're
> >intellectually lazy?
>
> read more: http://www.embedded.com/story/OEG20020125S0098
>
> Volkert

Re: Ada's Slide To Oblivion ...

[Richard Riehle]

There was an article about software quality in last Sunday's
San Jose Mercury News.   I wrote a letter to the editor in
response to some of the assertions in the article.   The
editorial page editor just contacted me and told me it would
be in this Sunday's editorial section (Computing Section,
probably).  I only mention Ada once, but it is a strong
mention.  Will probably get some reaction from the people
out there who use what I call "error-prone" languages in
my letter.

Richard Riehle

Marin David Condic wrote:

> An interesting article. One could argue about the accuracy of the survey,
> but it probably isn't that far off from reality.
>
> What I liked about it was that it was fair and balanced. It didn't smack of
> the usual anti-Ada vitriol, nor was it filled with misinformation. The
> criticism that Ada doesn't have as many tools as C/C++ is reasonably fair -
> I think it is a better situation than the author seems to imply, but let's
> face it: For just about any embedded board, you can get a C compiler thrown
> in with the development kit & you won't find Ada riding along with it as an
> alternate choice. (Although Gnat merging with gcc stands to help improve the
> situation - but still people have to ask for it or nobody will bother.)
>
> The question about programmers being "intellectually lazy" may have a lot to
> do with it. In order to do Ada development in a way that maximizes the
> benefits and minimizes the time fighting with the compiler to get it right,
> requires that you spend time up front thinking about the organization of the
> system - what the relevant data types are, what information should be
> hidden, etc. Embedded developers tend to be tinkerers who want to start
> hacking some bootstrap code and keep adding things to it until it works.
> Weeks of planning and diagram drawing and design meetings prior to writing
> any code tends to not be the thing they got into the business to do. Never
> mind that it might save months/years of debugging and produce a more
> reliable system that improved customer satisfaction and reduced liability -
> that's just not the mode of thought that feels comfortable to your average
> embedded/C developer.
>
> The question at the end about the government being to blame for not sticking
> to its guns is another interesting one. The government instituting "The
> Mandate" (especially when compiler technology just wasn't there) probably
> raised a lot of hackles over being "forced" to do something. (I *still*
> think that had the government tried bribery instead of extortion, it might
> have worked. If you were the program manager for some electronic whozits and
> the government offered you a $100,000.00 bonus if only you could find a way
> to get the project done in Ada, do you think your opposition to Ada would be
> so strong?)
>
> Anyway, having had The Mandate, then abandoning it is worse than never
> having The Mandate to begin with. Think about it - the perception is that
> the government was admitting it made a mistake by mandating Ada, so the
> contractors started abandoning it in droves. Standing there saying "No!
> Really! I'm *NOT* saying Ada is a bad thing!!!!" doesn't matter. Actions
> speak louder than words and perception often *IS* reality. ("Hey, the DoD
> dropped Ada like a hot rock. We must have been right all along. Ada really
> *did* suck!)
>
> The good news is that if people are writing thoughtful articles like this
> and observing that Ada really does have benefits (despite lack of use) maybe
> it might generate some renewed interest. The fact that they're writing about
> it at all is a sign that Ada isn't a non-issue. IOW, "I don't care what they
> say about Ada as long as they capitalize its name right!" :-)
>
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
>
> "Volkert" <Volkert.Barr@freenet.de> wrote in message
> news:b84db440.0201301508.1e3ea4b6@posting.google.com...
> > found at Embedded Systems Programming:
> >
> > >Ada is the only language designed to
> > >significantly reduce and maybe even
> > >eliminate dumb programming errors. Did
> > >it fall into disuse because we're
> > >intellectually lazy?
> >
> > read more: http://www.embedded.com/story/OEG20020125S0098
> >
> > Volkert

Re: Ada's Slide To Oblivion ...

[Eric Merritt]

for those of us who do not live in san jose can you
post the content?

--- Richard Riehle <richard@adaworks.com> wrote:
> There was an article about software quality in last
> Sunday's
> San Jose Mercury News.   I wrote a letter to the
> editor in
> response to some of the assertions in the article.  
> The
> editorial page editor just contacted me and told me
> it would
> be in this Sunday's editorial section (Computing
> Section,
> probably).  I only mention Ada once, but it is a
> strong
> mention.  Will probably get some reaction from the
> people
> out there who use what I call "error-prone"
> languages in
> my letter.
> 
> Richard Riehle
> 
> Marin David Condic wrote:
> 
> > An interesting article. One could argue about the
> accuracy of the survey,
> > but it probably isn't that far off from reality.
> >
> > What I liked about it was that it was fair and
> balanced. It didn't smack of
> > the usual anti-Ada vitriol, nor was it filled with
> misinformation. The
> > criticism that Ada doesn't have as many tools as
> C/C++ is reasonably fair -
> > I think it is a better situation than the author
> seems to imply, but let's
> > face it: For just about any embedded board, you
> can get a C compiler thrown
> > in with the development kit & you won't find Ada
> riding along with it as an
> > alternate choice. (Although Gnat merging with gcc
> stands to help improve the
> > situation - but still people have to ask for it or
> nobody will bother.)
> >
> > The question about programmers being
> "intellectually lazy" may have a lot to
> > do with it. In order to do Ada development in a
> way that maximizes the
> > benefits and minimizes the time fighting with the
> compiler to get it right,
> > requires that you spend time up front thinking
> about the organization of the
> > system - what the relevant data types are, what
> information should be
> > hidden, etc. Embedded developers tend to be
> tinkerers who want to start
> > hacking some bootstrap code and keep adding things
> to it until it works.
> > Weeks of planning and diagram drawing and design
> meetings prior to writing
> > any code tends to not be the thing they got into
> the business to do. Never
> > mind that it might save months/years of debugging
> and produce a more
> > reliable system that improved customer
> satisfaction and reduced liability -
> > that's just not the mode of thought that feels
> comfortable to your average
> > embedded/C developer.
> >
> > The question at the end about the government being
> to blame for not sticking
> > to its guns is another interesting one. The
> government instituting "The
> > Mandate" (especially when compiler technology just
> wasn't there) probably
> > raised a lot of hackles over being "forced" to do
> something. (I *still*
> > think that had the government tried bribery
> instead of extortion, it might
> > have worked. If you were the program manager for
> some electronic whozits and
> > the government offered you a $100,000.00 bonus if
> only you could find a way
> > to get the project done in Ada, do you think your
> opposition to Ada would be
> > so strong?)
> >
> > Anyway, having had The Mandate, then abandoning it
> is worse than never
> > having The Mandate to begin with. Think about it -
> the perception is that
> > the government was admitting it made a mistake by
> mandating Ada, so the
> > contractors started abandoning it in droves.
> Standing there saying "No!
> > Really! I'm *NOT* saying Ada is a bad thing!!!!"
> doesn't matter. Actions
> > speak louder than words and perception often *IS*
> reality. ("Hey, the DoD
> > dropped Ada like a hot rock. We must have been
> right all along. Ada really
> > *did* suck!)
> >
> > The good news is that if people are writing
> thoughtful articles like this
> > and observing that Ada really does have benefits
> (despite lack of use) maybe
> > it might generate some renewed interest. The fact
> that they're writing about
> > it at all is a sign that Ada isn't a non-issue.
> IOW, "I don't care what they
> > say about Ada as long as they capitalize its name
> right!" :-)
> >
> > MDC
> > --
> > Marin David Condic
> > Senior Software Engineer
> > Pace Micro Technology Americas   
> www.pacemicro.com
> > Enabling the digital revolution
> > e-Mail:    marin.condic@pacemicro.com
> > Web:      http://www.mcondic.com/
> >
> > "Volkert" <Volkert.Barr@freenet.de> wrote in
> message
> >
>
news:b84db440.0201301508.1e3ea4b6@posting.google.com...
> > > found at Embedded Systems Programming:
> > >
> > > >Ada is the only language designed to
> > > >significantly reduce and maybe even
> > > >eliminate dumb programming errors. Did
> > > >it fall into disuse because we're
> > > >intellectually lazy?
> > >
> > > read more:
> http://www.embedded.com/story/OEG20020125S0098
> > >
> > > Volkert
> 
> 
> 
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada


__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com

Re: Ada's Slide To Oblivion ...

[Richard Riehle]

In response to Richard Riehle's note that he had a letter to
the editor being published in this Sunday's San Jose Mercury
News in which he mentions Ada,

Eric Merritt wrote:

> for those of us who do not live in san jose can you
> post the content?

I can post the content after the SJM Sunday edition is printed.
There are two reasons to wait for that event.
        1)  SJM would prefer it to be a newsworthy editorial
        2)  Newspapers have a way of altering ever so slightly
             the original letter, and I would rather post what they
             finally publish rather than what I actually sent.

Richard

Re: Ada's Slide To Oblivion ...

[Larry Kilgallen]

In article <3C597046.DDA2FA6B@adaworks.com>, Richard Riehle <richard@adaworks.com> writes:
> In response to Richard Riehle's note that he had a letter to
> the editor being published in this Sunday's San Jose Mercury
> News in which he mentions Ada,
> 
> Eric Merritt wrote:
> 
>> for those of us who do not live in san jose can you
>> post the content?
> 
> I can post the content after the SJM Sunday edition is printed.
> There are two reasons to wait for that event.
>         1)  SJM would prefer it to be a newsworthy editorial
>         2)  Newspapers have a way of altering ever so slightly
>              the original letter, and I would rather post what they
>              finally publish rather than what I actually sent.

I don't know about the editorial page, but my wife regularly reads
the San Jose Mercury news stories on the web (from Massachusetts).
If there is a URL please post that also, as they might appreciate
the "hits" from all over the world.

Re: Ada's Slide To Oblivion ...

[Zach Swanson]

Just to throw in my two cents at this point, I'd like to say that the
DOD hasn't completley "caved in" concerning Ada. I'm a cadet at the
United States Military Academy and we, the Naval Academy, and the Air
Force Academy are all taught Ada95 as computer science majors. Our
instructors point out on a regular basis that the reasoning behind
this is that Ada is one of the best OO languages available, and that
it encourages good technique in programming.

Re: Ada's Slide To Oblivion ...

[Richard Riehle]

Zach Swanson wrote:

> Just to throw in my two cents at this point, I'd like to say that the
> DOD hasn't completley "caved in" concerning Ada. I'm a cadet at the
> United States Military Academy and we, the Naval Academy, and the Air
> Force Academy are all taught Ada95 as computer science majors. Our
> instructors point out on a regular basis that the reasoning behind
> this is that Ada is one of the best OO languages available, and that
> it encourages good technique in programming.

Also, Ada continues to be taught at the Naval Postgraduate School
in Monterey, CA, even though it is no longer a required course for
the students.   When the subject of Ada comes up in my conversations
with the students, I am often surprised to learn that those students,
while find Java to be more fun and easier to program, understand
the importance of Ada in building dependable software for
weapon systems.   I wish more of our DoD contractors understood
this as well as these students do.  Oh, and NPS students typically
take at least two quarters of C++, one Quarter of Java. Ada is a
one quarter elective a small number of students take because they
want to not because the must.

Richard Riehle

Re: Ada's Slide To Oblivion ...

[Richard Riehle]

Richard Riehle wrote:

> In response to Richard Riehle's note that he had a letter to
> the editor being published in this Sunday's San Jose Mercury
> News in which he mentions Ada,
>
> Eric Merritt wrote:
>
> > for those of us who do not live in san jose can you
> > post the content?

Well, they printed my letter to the editor, some of it.  Unfortunately,
they edited the letter and deleted the sentences in which I reference
Ada.  So the letter ended up substantially diluted from what I had
intended.   Sighhhhhhhhhhhh!.   Well, I tried.

Richard Riehle

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

Its a good thing whenever we get a chance to plug Ada somewhere that it
typically wouldn't find exposure. We all ought to do more of that.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Richard Riehle" <richard@adaworks.com> wrote in message
news:3C58B44C.E63A9C19@adaworks.com...
> There was an article about software quality in last Sunday's
> San Jose Mercury News.   I wrote a letter to the editor in
> response to some of the assertions in the article.   The
> editorial page editor just contacted me and told me it would
> be in this Sunday's editorial section (Computing Section,
> probably).  I only mention Ada once, but it is a strong
> mention.  Will probably get some reaction from the people
> out there who use what I call "error-prone" languages in
> my letter.
>

Re: Ada's Slide To Oblivion ...

[Ted Dennison]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a3a19n$db9$1@nh.pace.co.uk>...
> An interesting article. One could argue about the accuracy of the survey,
> but it probably isn't that far off from reality.

The only thing I found completely wrong was the assertion that you
can't call an Ada compiler "Ada" without going through validation or
the copyright holder to the term will come after you. The DoD isn't
enforcing that copyright anymore. It is the Ada community that demands
validation, not any one entity. But that would probably have been
tougher to explain properly.

> The good news is that if people are writing thoughtful articles like this
> and observing that Ada really does have benefits (despite lack of use) maybe
> it might generate some renewed interest. The fact that they're writing about
> it at all is a sign that Ada isn't a non-issue. IOW, "I don't care what they
> say about Ada as long as they capitalize its name right!" :-)

I really think Ada 83 was just *waaaaay* ahead of its time. Back in
the 80's and early 90's you'd quite often hear people seriously argue
*against* type checking. These days that's pretty rare (see some of
Eric Raymond's writings, if you want a trip back in that particular
way-back machine). Now that folks are using Java and C++ regularly and
can see for themselves the benifits to compile-time checking and
object-oriented design, suddenly Ada doesn't look so bad any more.

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0201310714.650888e1@posting.google.com...
>
> The only thing I found completely wrong was the assertion that you
> can't call an Ada compiler "Ada" without going through validation or
> the copyright holder to the term will come after you. The DoD isn't
> enforcing that copyright anymore. It is the Ada community that demands
> validation, not any one entity. But that would probably have been
> tougher to explain properly.
>
Maybe true, but it seems a nit to pick. There was a time when the DoD *did*
insist that it pass validation if you wanted to use the name Ada - so at
worst, he's a little out of date. This issue was even misunderstood by the
Ada community itself - leading to the view that you couldn't make subsets or
extensions (something that really hurt the use of Ada in embedded machines
in the early days) Anyway, I wouldn't pick on that too much. Its almost
better to leave people with that impression because they will believe in its
standardization, quality and portability - even if it isn't exactly true.


>
> I really think Ada 83 was just *waaaaay* ahead of its time. Back in
> the 80's and early 90's you'd quite often hear people seriously argue
> *against* type checking. These days that's pretty rare (see some of
> Eric Raymond's writings, if you want a trip back in that particular
> way-back machine). Now that folks are using Java and C++ regularly and
> can see for themselves the benifits to compile-time checking and
> object-oriented design, suddenly Ada doesn't look so bad any more.
>
It was waaaaay ahead of its time. Generics and Tasking were barely
understood by the compiler writers. Also ahead of the necessary hardware to
run the compiler or the resultant code. But it did succeed in dragging
compiler technology ahead.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Ada's Slide To Oblivion ...

[Steve O'Neill]

Marin David Condic wrote:

> > I really think Ada 83 was just *waaaaay* ahead of its time. Back in
> > the 80's and early 90's you'd quite often hear people seriously argue
> > *against* type checking. These days that's pretty rare (see some of
> > Eric Raymond's writings, if you want a trip back in that particular
> > way-back machine). Now that folks are using Java and C++ regularly and
> > can see for themselves the benifits to compile-time checking and
> > object-oriented design, suddenly Ada doesn't look so bad any more.
> >
> It was waaaaay ahead of its time. Generics and Tasking were barely
> understood by the compiler writers. Also ahead of the necessary hardware to
> run the compiler or the resultant code. But it did succeed in dragging
> compiler technology ahead.

Yes, compiler knowledge owes a lot to Ada.  It's interesting (and
painful)
to repeatedly find myself in classes and presentations now that talk
about
 the 'new' and 'advanced' concepts introduced by C++ and Java.  Many, if
not most, of these concepts are the result of the advances forced by
Ada.
Arghhh!

Steve

Re: Ada's Slide To Oblivion ...

[Warren W. Gay VE3WWG]

Ted Dennison wrote:

> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a3a19n$db9$1@nh.pace.co.uk>...
> 
>>An interesting article. One could argue about the accuracy of the survey,
>>but it probably isn't that far off from reality.
> 
> The only thing I found completely wrong was the assertion that you
> can't call an Ada compiler "Ada" without going through validation or
> the copyright holder to the term will come after you. The DoD isn't
> enforcing that copyright anymore. It is the Ada community that demands
> validation, not any one entity. But that would probably have been
> tougher to explain properly.


The assertion "That's unheard of in the Ada world, since the compilers
are essentially perfect" was a bit much also. I've run into a few GNAT
bugs that caused me to scratch my head for a while. Ada does not
eliminate a programmer's logic errors, but it sure helps to eliminate
a wider range of stupid erros.


>>The good news is that if people are writing thoughtful articles like this
>>and observing that Ada really does have benefits (despite lack of use) maybe
>>it might generate some renewed interest. The fact that they're writing about
>>it at all is a sign that Ada isn't a non-issue. IOW, "I don't care what they
>>say about Ada as long as they capitalize its name right!" :-)
> 
> I really think Ada 83 was just *waaaaay* ahead of its time. Back in
> the 80's and early 90's you'd quite often hear people seriously argue
> *against* type checking. These days that's pretty rare (see some of
> Eric Raymond's writings, if you want a trip back in that particular
> way-back machine). Now that folks are using Java and C++ regularly and
> can see for themselves the benifits to compile-time checking and
> object-oriented design, suddenly Ada doesn't look so bad any more.


I also have to question "DOD caved, first allowing a few exceptions, 

then many, till now Ada is more an interesting historical aside 

than part of every developer's zeitgeist."  I may be wrong, but as

I understand it, the language is still considered on a project by
project basis. I cannot see them acceptiong anything but Ada for
weapons or flight systems. Or has this really changed?

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
news:3C598CAA.7040801@home.com...
>
>
> The assertion "That's unheard of in the Ada world, since the compilers
> are essentially perfect" was a bit much also. I've run into a few GNAT
> bugs that caused me to scratch my head for a while. Ada does not
> eliminate a programmer's logic errors, but it sure helps to eliminate
> a wider range of stupid erros.
>
>
Well, there's "perfect" and there's "***PERFECT***". :-)

Its possible to consider the compiler "perfect" in the sense that it
implements all of the language features with the semantics intended.
Remember, we're talking about *C* programmers! They're used to diversion
from the standard into completely implementation dependent systax and
semantics. From that seat, Ada has to look pretty "perfect" in comparison.

If we insist that "perfect" means there are no compiler bugs, then clearly
Ada cannot measure up - but nobody else can measure up to that standard
either. I just don't think that's what the author intended to suggest.

But, of course, if people see and believe the line "essentially perfect" it
might get them to start looking at Ada out of curiosity. I would just hope
that they aren't overly disappointed when they encounter some
non-portability or some feature that compiles to incorrect code. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Ada's Slide To Oblivion ...

[Christopher A. Bohn]

On Thu, 31 Jan 2002, Warren W. Gay VE3WWG wrote:

> project basis. I cannot see them acceptiong anything but Ada for
> weapons or flight systems. Or has this really changed?

As a datapoint, my father works for a US-based aerospace company.  A
couple years ago, they did a review to decide whether the company-standard
would remain Ada95 or would switch to C++98 (with exceptions to the
companystandard being considered on a case-by-case basis).  He asked for
my opinion, though I think it was because he was curious about the issues
rather than because he could have had much of an influence, and I
definitely gave him the impression Ada was the smarter choice from a
technical point of view.

But the company opted for C++ because there were more C++ programmers than
Ada programmers in the market, so they'd have a larger pool of talent to
consider when making hiring decisions.  My comment after-the-fact was that
the decision reinforced the rationale -- with fewer jobs requiring Ada,
there will be fewer programmers who learn Ada, or at least fewer who
get/remain proficient with Ada.

cb

-- 
Christopher A. Bohn                        ____________|____________
http://www.cis.ohio-state.edu/~bohn/        ' ** ** " (o) " ** ** '
   "Technology and air power are integrally and synergistically
    related." - P Meilinger, "Ten Propositions Regarding Air Power"

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

Well, that's the chicken & egg problem. The way that gets overcome is for
students, hobbyists & hackers to have enough interest in it to learn the
language and develop useful things in it. Also if smaller firms do
development in Ada, it gets out there and they have less need for a large
pool of trained personnel. (If I was starting a small company that needed 10
programmers, I could probably find/train 10 developers rather easily. If I
had to hire a few hundred, the problem gets harder.)

So it seems to me that in a lot of ways the right things are happening.
There are certainly a number of people who have created useful things using
Ada and it has some exposure in colleges, etc. If some of those hacker
projects and useful subsystems grow into more full-blown tools and possibly
find some commercial success as products, you'll end up seeing usage of Ada
expand and that critical mass for widespread success may be found.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Christopher A. Bohn" <bohn@delta.cis.ohio-state.edu> wrote in message
news:Pine.GSO.4.33.0201311532390.26756-100000@delta.cis.ohio-state.edu...
>
> But the company opted for C++ because there were more C++ programmers than
> Ada programmers in the market, so they'd have a larger pool of talent to
> consider when making hiring decisions.  My comment after-the-fact was that
> the decision reinforced the rationale -- with fewer jobs requiring Ada,
> there will be fewer programmers who learn Ada, or at least fewer who
> get/remain proficient with Ada.
>

[off-topic - to lighten the air]

[Wes Groleau]

> Well, that's the chicken & egg problem. The way that gets overcome is for

The chicken and the egg are in bed.
The egg appears contented (huh?)
The chicken, with a disgusted look,
says, "Well, that answers that question!"

-- 
Wes Troll, Oh!
Please don't feed the troll.
http://freepages.rootsweb.com/~wgroleau

Re: Ada's Slide To Oblivion ...

[Richard Riehle]

"Christopher A. Bohn" wrote:

> But the company opted for C++ because there were more C++ programmers than
> Ada programmers in the market, so they'd have a larger pool of talent to
> consider when making hiring decisions.

This kind of stupidity is all too common among DoD contractors.   Usually it
is
made by people who don't understand Ada, or don't understand C++, or both. For

me, the more I learn about C++, the more horrified I am that anyone would
seriously consider using it for weapon systems software, or any other kind of
software where safety is a factor.   Clearly, Jack Gansle understands this
issue
pretty well.  For the others, I guess ignorance is bliss.

Richard Riehle

Re: Ada's Slide To Oblivion ...

[Jerry Petrey]

Richard Riehle wrote:
> 
> "Christopher A. Bohn" wrote:
> 
> > But the company opted for C++ because there were more C++ programmers than
> > Ada programmers in the market, so they'd have a larger pool of talent to
> > consider when making hiring decisions.
> 
> This kind of stupidity is all too common among DoD contractors.   Usually it
> is
> made by people who don't understand Ada, or don't understand C++, or both. For
> 
> me, the more I learn about C++, the more horrified I am that anyone would
> seriously consider using it for weapon systems software, or any other kind of
> software where safety is a factor.   Clearly, Jack Gansle understands this
> issue
> pretty well.  For the others, I guess ignorance is bliss.
> 
> Richard Riehle


How true Richard.  Here at Raytheon Missile Systems, all our new missile
software is going to C++.  The managers listen to the young engineers who
only know or want to work with C++. There are a few older program like the one
I'm on that uses Ada (thank goodness).  Most of these were started by ex-C
programmers and it is amazing how much like C their Ada code is.
I keep fighting for more Ada usage but I keep getting those same old
arguments - the tools are more expensive, Ada is dead and won't be supported
in the future, C++ programmers are easier to get, ... ad nauseam.
Yet they keep stressing how important it is that these missiles work
right every time - it is a frustrating battle to make them understand.
I applaud your efforts at Adaworks in teaching Ada.  This is want companies
need - some in-depth courses that train software engineers to think in Ada
not just translate C code to Ada.  I hope it has an impact on Ada's future.

Jerry

-- 
-----------------------------------------------------------------------------
-- Jerry Petrey                                                
-- Senior Principal Systems Engineer - Navigation, Guidance, & Control
-- Raytheon Missile Systems          - Member Team Ada & Team Forth
-- NOTE: please remove <NOSPAM> in email address to reply                  
-----------------------------------------------------------------------------

Re: Ada's Slide To Oblivion ...

[Richard Riehle]

Jerry Petrey wrote:

> How true Richard.  Here at Raytheon Missile Systems, all our new missile
> software is going to C++.  The managers listen to the young engineers who
> only know or want to work with C++. There are a few older program like the one
> I'm on that uses Ada (thank goodness).  Most of these were started by ex-C
> programmers and it is amazing how much like C their Ada code is.
> I keep fighting for more Ada usage but I keep getting those same old
> arguments - the tools are more expensive, Ada is dead and won't be supported
> in the future, C++ programmers are easier to get, ... ad nauseam.
> Yet they keep stressing how important it is that these missiles work
> right every time - it is a frustrating battle to make them understand.

I ran into a Raytheon engineer at a conference last year who proudly
announced that one of his responsibilities was to "rip out all that old
Ada code and replace it with C++."   I somehow managed to contain
my fury at such an idiotic concept, and tried to engage him in a dialogue
about this.   During that dialogue, he admitted that Ada is probably a
better language, but everything anyone could do in Ada, could also
be done in C++.   Since C++ was more popular, it made sense to
him that Ada was obsolete.   "In a few years you won't even be
able to get an Ada compiler,"  is the current silliness being
promoted by those who are have decided to "rip out all that old
Ada code ... "

So, even as we hear them recite the refrain, "Ada is probably a better language,"
we hear also the bumper sticker slogan, "It can be done as well in C++."

The cost of converting Ada 83 code to C++ will be greater than that of
converting to Ada 95.   The long term cost of maintaining the C++ code
will be substantially greater than maintaining the equivalent Ada code.
The ability to port C++ code to the next generation of hardware will be
greater than porting ISO standard Ada to that hardware.   If those who
are touting the economics rationale for using C++ instead of Ada were to
actually do an economic analysis of this decision, they would likely be
shocked by the probably cost of C++ over Ada.

The claim is that anything one can do in Ada one can also do in C++. This
is probably true, just as anything you can do in C++ someone else can do
in Assembler.    It is a matter of selecting the right tool for the right job,
and Ada is the right tool for jobs where safety and dependability are the
key factors.   I raised this issue.   "Oh, we simply avoid using those parts
of C++ that are unsafe."     This is one of those arguments that cannot be
won through reason.   Once the decision is made, regardless of how absurd
it might be,  the decision-makers are comitted to it.

Many centuries ago, a King was leading his forces against the great Sultan,
Saladin.    The journey to the battle was short and the King ordered the
oxen-drawn water carts to remain where they were since it would be
too slow to bring them along.   The journey took longer than expected and
the King's advisors suggested they return to get the water carts since thirst
was beginning to become a problem for the knights.   This King was not
to be told he made a bad decision and ordered his troops to press on.  The
Sultan decimated the King's troops, thereby turning the tide of history such
that, even today we are reaping the rewards of that Twelfth Century King's
stubborn tenacity to an ill-considered decision.    The problems we will see
as the result of the decision to abandon Ada in favor of more error-prone
tools will not be immediate.   They will be problems that will persist
long after those who have made them have gone on to other jobs or
retired.   Not only do such decisions fail to use our tax dollars well,
they risk little disasters that probably would not occur if more sound decisions
had been made in the first place.   At this point, pride will not let the decision
makers turn back for water.

Richard Riehle

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

In my mind, the problem comes down to marketing. All of us here know and
pretty much agree on the reasons why Ada is technically superior. We can
even make a pretty good business case in some areas as to why Ada makes more
sense economically. We can even get some acquiescence on the part of many
C/C++/Java programmers that Ada is superior in some ways - maybe even in
most ways. So why is the choice going over to C/C++/Java instead of Ada?

Clearly, Ada is not providing *something* the customer wants. Or if it
provides it, it isn't obvious or it isn't the thing we are touting. Many of
us have theorized about it, but a lot of that is just educated guesses. We
suggest answers, but we lack the coordinated effort to do much about it.

To rehash the past a bit - had the DoD looked at Ada less as something to be
mandated and more as a product that needed to be sold, things might have
gone differently. If Ada had been launched by Micro$oft instead of DoD,
there would have been a coordinated media blitz that would have made Ada the
household buzzword and hot topic in the computer press. But nobody schmoozed
the media or spent money on magazine ads, press junkets, television
spectacles, etc.

Could it be turned around? I think so - but it wouldn't be easy. If Ada
still had a large institutional backer like the DoD, it would make sense to
hire a marketing company to a) research what the market wants, b) figure out
what Ada has - or could be made to have - that addresses that demand and c)
design a marketing campaign that would get the word out effectively. Lacking
the big institutional backer, it might still be possible to get the
marketing research done, but it needs to be done by people with expertise in
this area. Maybe a way could be figured out to get that information under
the umbrella of SIGAda or some other interested group? A published marketing
study with a recommended strategy might serve to give Ada proponents a focus
with which they might be more effective?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Richard Riehle" <richard@adaworks.com> wrote in message
news:3C5EC996.80428514@adaworks.com...
>
> So, even as we hear them recite the refrain, "Ada is probably a better
language,"
> we hear also the bumper sticker slogan, "It can be done as well in C++."
>

Re: Ada's Slide To Oblivion ...

[DPH]

I think part of the problem is the tools availability.

Right now, I'm programming in C++ because the code that someone else
wrote is in Borland C++ Builder 5.0.  I don't much care for the
language, prefer Ada, and if I never saw another pointer as long as I
live, it'd still be too soon.

But, would I rather program with Builder or AdaGide?  Builder, for
sure.  The debugger is far superior in Builder.  I place the cursor
over a variable and its value is displayed in a tooltip.  If I want to
set a breakpoint to "fire" on the 267th iteration thru the code, I can
go to pull-down menus and fill in the blanks and get it done without
remembering any commands.

In contrast, I was programming with the AdaGide interface and was
having trouble just getting the debugger to work at all.  Several
other people in the building had used GNAT and AdaGide and not one of
them could tell me how to make the debugger work.  I finally figured
it out for myself, but the debugger is several orders of magnitude
less usefull than the one in Builder.

I know that this is comparing apples to oranges, as AdaGide is free
and my Builder costs hundreds, but the point is that I _have_ builder,
and a comparable Ada programming environment is not observable in my
immediate vicinity at work.  

Possibly Aonix or RR Software or Green Hills has a comparable PC
programming environment, but I can't get to it because I don't have
the $$$ to invest just to try it.  I tried to buy a full-up version of
Aonix's compiler several years ago when it was advertised for $400ish.
Turned out that to get anything done, compile to DOS, etc. there was
more extras that I needed that quickly pushed the price to the $900
region.  Since I didn't have $900 to spare, I fought like crazy and
got my money back.  Is there a comparable debugger in there somewhere?
Maybe, but I wasn't about to learn the Windows programming
environment, which the Aonix tool was targeting, just to be able to
use it, and like I said, the DOS targeting feature's extra price made
it to be not a viable solution.


But as a student, you can almost always get a copy of some
high-powered C++ development environment because they're all over the
place.  There's a gal that sits across from me at work, does CM,
doesn't have a degree and is therefore getting underpaid, that is
taking C++ in an effort toward getting a computer science degree.
This morning, she's going to get a copy of Builder 5.0 to use.  If she
were taking an Ada course instead, there would be no one in the
building who could show her a comparable programming environment, much
less "loan" her a copy.  Is she gonna be happy with the high-powered
debugger, and the help system with the myriads of examples?  I think
so.  I can't think of a similar tool I could give her that would make
her just as happy with Ada.

So, anyway, I think its largely the tools.

Dave Head

On Mon, 4 Feb 2002 13:24:24 -0500, "Marin David Condic"
<dont.bother.mcondic.auntie.spam@[acm.org> wrote:

>In my mind, the problem comes down to marketing. All of us here know and
>pretty much agree on the reasons why Ada is technically superior. We can
>even make a pretty good business case in some areas as to why Ada makes more
>sense economically. We can even get some acquiescence on the part of many
>C/C++/Java programmers that Ada is superior in some ways - maybe even in
>most ways. So why is the choice going over to C/C++/Java instead of Ada?
>
>Clearly, Ada is not providing *something* the customer wants. Or if it
>provides it, it isn't obvious or it isn't the thing we are touting. Many of
>us have theorized about it, but a lot of that is just educated guesses. We
>suggest answers, but we lack the coordinated effort to do much about it.
>
>To rehash the past a bit - had the DoD looked at Ada less as something to be
>mandated and more as a product that needed to be sold, things might have
>gone differently. If Ada had been launched by Micro$oft instead of DoD,
>there would have been a coordinated media blitz that would have made Ada the
>household buzzword and hot topic in the computer press. But nobody schmoozed
>the media or spent money on magazine ads, press junkets, television
>spectacles, etc.
>
>Could it be turned around? I think so - but it wouldn't be easy. If Ada
>still had a large institutional backer like the DoD, it would make sense to
>hire a marketing company to a) research what the market wants, b) figure out
>what Ada has - or could be made to have - that addresses that demand and c)
>design a marketing campaign that would get the word out effectively. Lacking
>the big institutional backer, it might still be possible to get the
>marketing research done, but it needs to be done by people with expertise in
>this area. Maybe a way could be figured out to get that information under
>the umbrella of SIGAda or some other interested group? A published marketing
>study with a recommended strategy might serve to give Ada proponents a focus
>with which they might be more effective?
>
>MDC

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

I would agree that availability of tools is a big deal. You just can't
compete with the leverage someone can get by using some language that has a
really well integrated IDE. You *almost* get there if you want to pull
together a bunch of things available on the net & learn how to use them with
inadequate documentation - but in a time-to-market driven environment, its
bad enough asking people to learn a language they don't already know without
asking them to cobble together their own development environment & struggle
to learn how to use it.

It might help to develop an IDE and a library full of useful stuff, but
there's still a sales job that needs to be done. Languages aren't usually
born with a full toolset instantaneously available - yet they still get
adopted. So while I'm still 100% behind the notion of developing more &
better tools, I think Ada would benefit from a better understanding of what
the market likes to buy.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"DPH" <rally2xs@compuserve.com> wrote in message
news:4g6v5ugkc46869ahchabrgnbnvu5qn6elf@4ax.com...
> I think part of the problem is the tools availability.
>

Re: Ada's Slide To Oblivion ...

[Wes Groleau]

> gone differently. If Ada had been launched by Micro$oft instead of DoD,

then Windoze would not crash as often.  :-)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3C600A4A.E56A1B78@despammed.com...
>
>
> > gone differently. If Ada had been launched by Micro$oft instead of DoD,
>
> then Windoze would not crash as often.  :-)
>
But then they wouldn't be able to say: "No. Really. Just buy the *next*
version and that particular problem will go away. This time, we're not just
teasing you. Honest. We really mean it. The next version is going to be
*great*. Just give us a little more money....." :-) I am reminded of Charley
Brown running at the football Lucy is holding for him. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Ada's Slide To Oblivion ...

[Preben Randhol]

On Tue, 05 Feb 2002 11:37:30 -0500, Wes Groleau wrote:
> 
> 
>> gone differently. If Ada had been launched by Micro$oft instead of DoD,
> 
> then Windoze would not crash as often.  :-)

Nonono you got it all wrong. Then Ada would be crashing and the
languaged would be mutated into X versions. And it's code would be as
portable as M$ Office. ;-)

Preben

Re: Ada's Slide To Oblivion ...

[Warren W. Gay VE3WWG]

Preben Randhol wrote:

> On Tue, 05 Feb 2002 11:37:30 -0500, Wes Groleau wrote:
>>>gone differently. If Ada had been launched by Micro$oft instead of DoD,
>>>
>>then Windoze would not crash as often.  :-)
> 
> Nonono you got it all wrong. Then Ada would be crashing and the
> languaged would be mutated into X versions. And it's code would be as
> portable as M$ Office. ;-)
> 
> Preben


You'd just get A# ;-)


-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada's Slide To Oblivion ...

[Georg Bauhaus]

Warren W. Gay VE3WWG <ve3wwg@home.com> wrote:
 
: You'd just get A# ;-)

Hm, that's likely to causes trouble with the A+ folk. :-)

Re: Ada's Slide To Oblivion ...

[Georg Bauhaus]

Richard Riehle <richard@adaworks.com> wrote:
:  This is one of those arguments that cannot be
: won through reason.   Once the decision is made, regardless of how absurd
: it might be,  the decision-makers are comitted to it.
 
FWIW, some respected theory about this can be found in the books of
Leon Festinger (dissonance theory, decision making,...),
and related work, from decades ago. I find that it helps in keeping
calm, one may assemble one's mind forces instead.

- georg

Re: Ada's Slide To Oblivion ...

[Anders Wirzenius]

Jerry Petrey @west.raytheon.com> <"jdpetrey wrote in message
<3C5EBC07.6A27AE8A@west.raytheon.com>...

...

>How true Richard.  Here at Raytheon Missile Systems, all our new missile
>software is going to C++.  The managers listen to the young engineers who
>only know or want to work with C++. There are a few older program like the
one
>I'm on that uses Ada (thank goodness).  Most of these were started by ex-C
>programmers and it is amazing how much like C their Ada code is.
>I keep fighting for more Ada usage but I keep getting those same old
>arguments - the tools are more expensive, Ada is dead and won't be
supported
>in the future, C++ programmers are easier to get, ... ad nauseam.
>Yet they keep stressing how important it is that these missiles work
>right every time - it is a frustrating battle to make them understand.
>I applaud your efforts at Adaworks in teaching Ada.  This is want companies
>need - some in-depth courses that train software engineers to think in Ada
>not just translate C code to Ada.  I hope it has an impact on Ada's future.
>
>Jerry

Why not let the money speak.
I used to work for a Norwegian company (Computas) where at least at that
time every work effort was connected to a project number. Every hour spent
in the company was booked on a project number. We were thus able to go into
details to examine how many hours were spent on each software system.
Suggest, Jerry, to your boss that you start to do similarily at your
department. Then sit down at the end of the year, go throuh the figures, and
vote for the most profitable software. Advice him not to listen to people
complaining that all their time is then going to report what they did during
the day. The reporting system worked excellently in the company mentioned
above and has been working in other companies that I have worked for.
By the way, by extending the booking system a little, you are able to come
up with numbers to present a traditional quality cost division, namely
preventive costs, testing costs, internal error correction costs and
external error correction costs. This is easily set up for a company which
have minimal material costs compared to labour costs.

Anders

Re: Ada's Slide To Oblivion ...

[Richard Riehle]

"Warren W. Gay VE3WWG" wrote:

> I understand it, the language is still considered on a project by
> project basis. I cannot see them acceptiong anything but Ada for
> weapons or flight systems. Or has this really changed?

Unfortunately, it has changed for many DoD contractors.   I have
been told that, even though Ada might be a better language,  the
programmers don't want to hire on if they have to do Ada.  They
would rather do C++ because it is better for their career.   So,
just as the DoD capitulated when the whiners complained about
not wanting to "eat their broccoli,"  the contractors have capitulated
because programmers demand to use what they perceive as a
more mainstream language.    Superiority of the language is a
minor point, hardly considered at all anymore.

Imagine a surgeon who discovers how much money can be saved
by purchasing Xacto blades instead of using blades manufactured
to more stringent standards.   That is exactly the situation we are
currently facing when contractors decide to use C or C++ instead
of Ada.   On the surface one gets the same result.  It is only that
superficial result that counts for the lowest bidder.

Richard Riehle

Re: Ada's Slide To Oblivion ...

[A. Nonny Mouse]

Richard Riehle wrote:
> Unfortunately, it has changed for many DoD contractors.   I have
> been told that, even though Ada might be a better language,  the
> programmers don't want to hire on if they have to do Ada.  They
> would rather do C++ because it is better for their career.   So,

And there are people doing Ada, who are recommending
Java to managers who don't know any better, not because
it's good for the project, but because it's good for
their r�sum�s

(I'm not saying Java is always wrong, but sometimes
it is, and I'm sure many of you have read completely
bogus arguments supporting Java over Ada.)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Ada's Slide To Oblivion ...

[Dale Pontius]

In article <3C59FCD3.928144FB@adaworks.com>,
        Richard Riehle <richard@adaworks.com> writes:
...
> Imagine a surgeon who discovers how much money can be saved
> by purchasing Xacto blades instead of using blades manufactured
> to more stringent standards.   That is exactly the situation we are
> currently facing when contractors decide to use C or C++ instead
> of Ada.   On the surface one gets the same result.  It is only that
> superficial result that counts for the lowest bidder.
>
> Richard Riehle
>
You've made it into my file of most interesting quotes with this
one. Every now and then I try to point out that C programming
cost us all billions of dollars in the second half of last year.
But 'what everyone does' must be good enough, even if it's so
expensive, and there is something better.

By today's common programming practices, we have a situation
where the simplest/easiest way of programming string input gives
buffer overflows, and there for security holes. In C, that is.
Don't know about C++, but at least in Ada, the simplest/easiest
way of programming string input at worst would give a DOS
problem as the program crashed, and it wouldn't be much harder
to catch the exception and stop that.

Dale Pontius
NOT speaking for IBM

Re: Ada's Slide To Oblivion ...

[Nick Roberts]

"Dale Pontius" <pontius@btv.MBI.com.invalid> wrote in message
news:a3eikr$tfo$1@news.btv.ibm.com...

> By today's common programming practices, we have a situation
> where the simplest/easiest way of programming string input gives
> buffer overflows, and there for security holes. In C, that is.
> Don't know about C++, but at least in Ada, the simplest/easiest
> way of programming string input at worst would give a DOS
> problem as the program crashed, and it wouldn't be much harder
> to catch the exception and stop that.

To my mind, it seems more appropriate that DoS (Denial of Service) attack
prevention should be undertaken primarily by the IP router module, not by
TCP (or UDP) service applications. The TCP module, and its service
applications, could help by reporting suspicious activity to the IP router
(which should provide an interface to facilitate this).

Both C and C++ are fundamentally insecure languages, because they require a
'flat' address space, with no differentiation between the executable
(read-only) and variable (read-write) parts. This completely subverts the
security mechanisms (e.g. segments with access controls) most modern
processor architectures support and could otherwise fully deploy. Buffer
overrun exploits are but one manifestation of this problem.

I never cease to be amazed at the number of people -- many who should know
better (or be more honest) -- who expound flat address spaces as universally
advantageous. (I emphasise that I understand there are some cases where they
are indeed advantageous.)

Some processor architectures, specifically for the benefit of C code,
support a style of addressing that permits the use of a machine word to
contain a full address into a segmented space, but with only 32 bits to play
(on 32-bit architectures), this doesn't work very well. Of course 64-bit
architectures solve this problem; but then the problems of porting 32-bit C
and C++ code to 64-bit are many, and make hilarious reading for those of a
strong mental constitution.

--
Nick Roberts

Re: Ada's Slide To Oblivion ...

[Ole-Hjalmar Kristensen]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> "Dale Pontius" <pontius@btv.MBI.com.invalid> wrote in message
> news:a3eikr$tfo$1@news.btv.ibm.com...
> 
> > By today's common programming practices, we have a situation
> > where the simplest/easiest way of programming string input gives
> > buffer overflows, and there for security holes. In C, that is.
> > Don't know about C++, but at least in Ada, the simplest/easiest
> > way of programming string input at worst would give a DOS
> > problem as the program crashed, and it wouldn't be much harder
> > to catch the exception and stop that.
> 
> To my mind, it seems more appropriate that DoS (Denial of Service) attack
> prevention should be undertaken primarily by the IP router module, not by
> TCP (or UDP) service applications. The TCP module, and its service
> applications, could help by reporting suspicious activity to the IP router
> (which should provide an interface to facilitate this).
> 
> Both C and C++ are fundamentally insecure languages, because they require a
> 'flat' address space, with no differentiation between the executable
> (read-only) and variable (read-write) parts. This completely subverts the

Where do you get this wild idea from? There is nothing in the language
definition which demands this. At least on UN*X, the executable part
is normally put in a read-only segment. But this is not an attribute
of the language, but of the  hardware, OS, and the linker/loader.

<snip>

Ole-Hj. Kristensen

Re: Ada's Slide To Oblivion ...

[Nick Roberts]

"Ole-Hjalmar Kristensen" <oleh@vlinux.voxelvision.no> wrote in message
news:7v8za79id0.fsf@vlinux.voxelvision.no...

> > Both C and C++ are fundamentally insecure languages, because they
require a
> > 'flat' address space, with no differentiation between the executable
> > (read-only) and variable (read-write) parts. This completely subverts
the
>
> Where do you get this wild idea from? There is nothing in the language
> definition which demands this. At least on UN*X, the executable part
> is normally put in a read-only segment. But this is not an attribute
> of the language, but of the  hardware, OS, and the linker/loader.

Perhaps I did not express myself clearly enough. If you were to re-read what
I said, carefully, I think you will see that what I wrote does not deny that
the executable part is put into read-only memory; on the contrary, I
actually imply it.

Allow me to try to clarify. The C language requires (in practice if not
strictly in theory) that all pointers fit into one machine word. On 32-bit
architectures, this almost invariably forces the use of a 'flat' address
space (just an offset, with no segment number or equivalent). Which means
that, for many architectures, the operating system cannot use segmentation
(or other memory divisions) to detect a call or jump into read-write memory.
If it were able to do this, it could prevent the execution of code which has
been (maliciously caused to be) written into memory (by the program itself,
due to a bug being exploited).

On many architectures, then, C prevents the OS from using available memory
protection mechanisms to prevent buffer overrun exploitation, whereas most
other programming languages do not. In this way, C is a security liability.
C++ generally has the same fault.


"Ian S. Nelson" <nelsonis@earthlink.net> wrote in message
news:3C6144E7.4010801@earthlink.net...

> This is flat out wrong.

I refer the honourable member to my previous answer.


--
Nick Roberts

Re: Ada's Slide To Oblivion ...

[Ian S. Nelson]

Nick Roberts wrote:

> "Ole-Hjalmar Kristensen" <oleh@vlinux.voxelvision.no> wrote in message
> news:7v8za79id0.fsf@vlinux.voxelvision.no...
> 
> 
>>>Both C and C++ are fundamentally insecure languages, because they
>>>
> require a
> 
>>>'flat' address space, with no differentiation between the executable
>>>(read-only) and variable (read-write) parts. This completely subverts
>>>
> the
> 
>>Where do you get this wild idea from? There is nothing in the language
>>definition which demands this. At least on UN*X, the executable part
>>is normally put in a read-only segment. But this is not an attribute
>>of the language, but of the  hardware, OS, and the linker/loader.
>>
> 
> Perhaps I did not express myself clearly enough. If you were to re-read what
> I said, carefully, I think you will see that what I wrote does not deny that
> the executable part is put into read-only memory; on the contrary, I
> actually imply it.
> 
> Allow me to try to clarify. The C language requires (in practice if not
> strictly in theory) that all pointers fit into one machine word. On 32-bit
> architectures, this almost invariably forces the use of a 'flat' address
> space (just an offset, with no segment number or equivalent). Which means
> that, for many architectures, the operating system cannot use segmentation
> (or other memory divisions) to detect a call or jump into read-write memory.
> If it were able to do this, it could prevent the execution of code which has
> been (maliciously caused to be) written into memory (by the program itself,
> due to a bug being exploited).

  

Are we talking about processors with an MMU?  When you create a 
pagetable on most modern processors (I'm think pentiums, alpha, sparc, 
powerpc all with an MMU) you can supply permissions to the pages. 
Readable, writable, execuatable.

So when I load an app I can take the pages the the code sits in and make 
them readable and executable.  Then I can make the heap writable but not 
executable, I can make the stack read-write but not executable.  This is 
done in the kernel and they are page attributes, not address attributes. 
  Then when the mmu does the address translation it can detect page 
faults if you try to do an instruction fetch from a non-executable page 
or try to write to a read-only page which are trapped by the OS.  You 
don't need  segments to do this, and it's already done on several OSes 
one several chips with C and C++ code.

The application cannot take an address and determine the permissions for 
a given address but it shouldn't need to.  The OS will get the trap from 
the processor on a page-fault, it may or may not be able to determine 
the type of page-fault by some flags and then it can kill the process, 
or send a signal to it or whatever.

Now that I think about it, I shouldn't have snapped back so quick. 
There probably are architectures without hardware support for memory 
protection and what have you where you still might want to try to do it 
with things like segments.  I couldn't imagine them performing well 
though, but that's never stopped people.   I don't see that as C's fault 
though.


Ian


> On many architectures, then, C prevents the OS from using available memory
> protection mechanisms to prevent buffer overrun exploitation, whereas most
> other programming languages do not. In this way, C is a security liability.
> C++ generally has the same fault.
> 
> 
> "Ian S. Nelson" <nelsonis@earthlink.net> wrote in message
> news:3C6144E7.4010801@earthlink.net...
> 
> 
>>This is flat out wrong.
>>
> 
> I refer the honourable member to my previous answer.
> 
> 
> --
> Nick Roberts
> 
> 
> 
> 

Re: Ada's Slide To Oblivion ...

[Philip Cummins]

Hello,

> On many architectures, then, C prevents the OS from using available memory
> protection mechanisms to prevent buffer overrun exploitation, whereas most
> other programming languages do not. In this way, C is a security liability.
> C++ generally has the same fault.

Well, I'd say it's more the fault of the OS rather than C (not that I
like C that much). If people were serious about killing off buffer
overflow attacks they'd implement OS allocated buffers with guard pages
to fix the problem and make it impossible to use a stack as a buffer.

PC

Re: Ada's Slide To Oblivion ...

[Ian Wild]

Nick Roberts wrote:
>  
> Allow me to try to clarify. The C language requires (in practice if not
> strictly in theory) that all pointers fit into one machine word. On 32-bit
> architectures, this almost invariably forces the use of a 'flat' address
> space (just an offset, with no segment number or equivalent).


C, in practice as well as theory, has two flavours of pointer,
and there's no operation that will convert between code
pointers and data pointers.  You simply *can't* read or write
via code space pointers, nor can you call a data pointer.  (In
fact, it's not unusual for the two ranges of pointers, when viewed
as integers, to overlap, since "somewhere near the bottom" is
a pretty good place for both to start.)


> Which means
> that, for many architectures, the operating system cannot use segmentation
> (or other memory divisions) to detect a call or jump into read-write memory.

There's nothing in C that prevents split I/D spaces being
used if they're available, as witnessed by the fact that C
(and, indeed, Unix) ran on PDP-11s of yore.  Of course, if the
processor /can't/ separate instructions from data, it can't do
it for *any* language, so it'd be unfair to criticise C alone
for this.

Re: Ada's Slide To Oblivion ...

[Ray Blaak]

Ian Wild <ian@cfmu.eurocontrol.be> writes:
> C, in practice as well as theory, has two flavours of pointer,
> and there's no operation that will convert between code
> pointers and data pointers.  You simply *can't* read or write
> via code space pointers, nor can you call a data pointer.

You most certainly can:

   void foo()
   {
       typedef void (*FUNC)();
   
       // calling some data
       int i = 0;
       FUNC f = (FUNC) &i;
       f();
   
       // writing some code
       f = foo;
       int *p = (int*) f;
       *p = 2;
   }

That this crashes with access violations on a sane OS is a good thing, but
nothing in the language is preventing the code/data conversions.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@telus.net                                The Rhythm has my soul.

Re: Ada's Slide To Oblivion ...

[Hyman Rosen]

Ray Blaak wrote:
> You most certainly can:
>        typedef void (*FUNC)();
>        int i = 0;
>        FUNC f = (FUNC) &i;
> 
> That this crashes with access violations on a sane OS is a good thing, but
> nothing in the language is preventing the code/data conversions.

False. The typecast '(FUNC)&i' is not legal standard C or C++.
It's not even a case of undefined results - it's just illegal.
Some compilers permit it as an extension, though.

Re: Ada's Slide To Oblivion ...

[David Brown]

Hyman Rosen <hyrosen@mail.com> wrote:
> Ray Blaak wrote:
>> You most certainly can:
>>        typedef void (*FUNC)();
>>        int i = 0;
>>        FUNC f = (FUNC) &i;
>> 
>> That this crashes with access violations on a sane OS is a good thing, but
>> nothing in the language is preventing the code/data conversions.
> 
> False. The typecast '(FUNC)&i' is not legal standard C or C++.
> It's not even a case of undefined results - it's just illegal.
> Some compilers permit it as an extension, though.

Legality aside, I have yet to find a compiler that doesn't accept this.
In fact, I have code that does this very thing, it creates a small
amount of data that happens to be instructions, casts it to a function
pointer and calls it.

There are a certain set of problems that would require hand-crafted
assembly to implement if this were not allowed.  These constructs are
usually (hopefully) only done in OS implementations, and runtime
libraries for languages.

Dave Brown

Re: Ada's Slide To Oblivion ...

[Ian Wild]

David Brown wrote:
> 
> Hyman Rosen <hyrosen@mail.com> wrote:
> > Ray Blaak wrote:
> >> You most certainly can:
> >>        typedef void (*FUNC)();
> >>        int i = 0;
> >>        FUNC f = (FUNC) &i;
> >>
> >> That this crashes with access violations on a sane OS is a good thing, but
> >> nothing in the language is preventing the code/data conversions.
> >
> > False. The typecast '(FUNC)&i' is not legal standard C or C++.
> > It's not even a case of undefined results - it's just illegal.
> > Some compilers permit it as an extension, though.
> 
> Legality aside, I have yet to find a compiler that doesn't accept this.

I'll agree that most compilers will accept it, but it's not
C and quite often doesn't do what you're expecting.

> In fact, I have code that does this very thing, it creates a small
> amount of data that happens to be instructions, casts it to a function
> pointer and calls it.

On, say, a high end PDP-11, or a 68000, or an 8086 (but not its
progeny!), code space and data space are physically separate.  There
are wires that come out of the processor to say which space to use.  On
such a system there's NO WAY to write to code space, and it's not
impossible that

  static int x [500];
  int main () {
    if ((void*)&main == (void*)&x)
       printf ("Yes\n");
    return 0;
  }

will print "Yes".  You can fill your array x with
all manner of carefully chosen data, but any attempt
to call it will jump to the corresponding address
in /code space/, which here will re-start the program.

Re: Ada's Slide To Oblivion ...

[Ole-Hjalmar Kristensen]

Ian Wild <ian@cfmu.eurocontrol.be> writes:

> David Brown wrote:
> > 
> > Hyman Rosen <hyrosen@mail.com> wrote:
> > > Ray Blaak wrote:
> > >> You most certainly can:
> > >>        typedef void (*FUNC)();
> > >>        int i = 0;
> > >>        FUNC f = (FUNC) &i;
> > >>
> > >> That this crashes with access violations on a sane OS is a good thing, but
> > >> nothing in the language is preventing the code/data conversions.
> > >
> > > False. The typecast '(FUNC)&i' is not legal standard C or C++.
> > > It's not even a case of undefined results - it's just illegal.
> > > Some compilers permit it as an extension, though.
> > 
> > Legality aside, I have yet to find a compiler that doesn't accept this.
> 
> I'll agree that most compilers will accept it, but it's not
> C and quite often doesn't do what you're expecting.
> 
> > In fact, I have code that does this very thing, it creates a small
> > amount of data that happens to be instructions, casts it to a function
> > pointer and calls it.
> 
> On, say, a high end PDP-11, or a 68000, or an 8086 (but not its
> progeny!), code space and data space are physically separate.  There
> are wires that come out of the processor to say which space to use.  On
> such a system there's NO WAY to write to code space, and it's not
> impossible that

??? This is pure fantasy. How do you think the code got into the code
space in the first place? 


> 
>   static int x [500];
>   int main () {
>     if ((void*)&main == (void*)&x)
>        printf ("Yes\n");
>     return 0;
>   }
> 
> will print "Yes".  You can fill your array x with
> all manner of carefully chosen data, but any attempt
> to call it will jump to the corresponding address
> in /code space/, which here will re-start the program.

Re: Ada's Slide To Oblivion ...

[Ian Wild]

Ole-Hjalmar Kristensen wrote:
>  
> ??? This is pure fantasy. How do you think the code got into the code
> space in the first place?

(sigh)

Let's take the example of a 68000 'cos I've got the data sheet
readily available.  There are three lines coming out of the
processor which distinguish various spaces.  Of interest are:

  supervisor code
  supervisor data
  user code
  user data

If the OS is clever, and many of them were, it's set up the MMU
tables such that 'user code' exists at some point in 'supervisor
data', at least long enough to load the executable from disc.  At
some later point it may re-map things so that 'user data' exists
at that same address in 'supervisor data', letting it initialise
the bss.  At some late stage it initialises the MMU so that
'user code' starts at address 0, 'user data' starts at address 0
(but with the first page unmapped to catch NULL pointers), and
does a mode switch.  There is then NO WAY from user mode to write
to the 'user code' space, and only limited (ie PC relative) access
for reading.

Oh - before anyone suggest it, no, the MMU is not visible from
user mode either.

Is this really rocket science?  I would've though the above
sufficiently obvious that I could have got a patent on it.

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

IIRC, the MC680x0 had pins coming out of it for Supervisor/User and
Code/Data access so that a little bit of silicon could figure out that
User/Code/Write access would not be allowed. A little hardware design would
mean you didn't actually need the MMU to protect the space. Of course if you
could get into Supervisor mode, you'd be handed the keys to the gates of
paradise and all bets are off. But typically the only way to do that would
be a) if your program got loaded at bootstrap or b) whatever program *did*
get loaded at bootstrap had poor design.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ian Wild" <ian@cfmu.eurocontrol.be> wrote in message
news:3C63CB16.645FE25E@cfmu.eurocontrol.be...
>
> (sigh)
>
> Let's take the example of a 68000 'cos I've got the data sheet
> readily available.  There are three lines coming out of the
> processor which distinguish various spaces.  Of interest are:
>
>   supervisor code
>   supervisor data
>   user code
>   user data
>
> If the OS is clever, and many of them were, it's set up the MMU
> tables such that 'user code' exists at some point in 'supervisor
> data', at least long enough to load the executable from disc.  At
> some later point it may re-map things so that 'user data' exists
> at that same address in 'supervisor data', letting it initialise
> the bss.  At some late stage it initialises the MMU so that
> 'user code' starts at address 0, 'user data' starts at address 0
> (but with the first page unmapped to catch NULL pointers), and
> does a mode switch.  There is then NO WAY from user mode to write
> to the 'user code' space, and only limited (ie PC relative) access
> for reading.
>
> Oh - before anyone suggest it, no, the MMU is not visible from
> user mode either.
>
> Is this really rocket science?  I would've though the above
> sufficiently obvious that I could have got a patent on it.

Re: Ada's Slide To Oblivion ...

[Ole-Hjalmar Kristensen]

Ian Wild <ian@cfmu.eurocontrol.be> writes:

> Ole-Hjalmar Kristensen wrote:
> >  
> > ??? This is pure fantasy. How do you think the code got into the code
> > space in the first place?
> 
> (sigh)
> 
> Let's take the example of a 68000 'cos I've got the data sheet
> readily available.  There are three lines coming out of the
> processor which distinguish various spaces.  Of interest are:
> 
>   supervisor code
>   supervisor data
>   user code
>   user data
> 
> If the OS is clever, and many of them were, it's set up the MMU
> tables such that 'user code' exists at some point in 'supervisor
> data', at least long enough to load the executable from disc.  At
> some later point it may re-map things so that 'user data' exists
> at that same address in 'supervisor data', letting it initialise
> the bss.  At some late stage it initialises the MMU so that
> 'user code' starts at address 0, 'user data' starts at address 0
> (but with the first page unmapped to catch NULL pointers), and
> does a mode switch.  There is then NO WAY from user mode to write
> to the 'user code' space, and only limited (ie PC relative) access
> for reading.
> 
> Oh - before anyone suggest it, no, the MMU is not visible from
> user mode either.
> 
> Is this really rocket science?  I would've though the above
> sufficiently obvious that I could have got a patent on it.


What you are saying now is correct, but that's not what you said in your 
previous post. Of course these processors have mecahnisms which can be
used to protect code from being overwritten, but that's very different 
your statement that:

>There
> are wires that come out of the processor to say which space to use.  On
> such a system there's NO WAY to write to code space,
                       ********

Re: Ada's Slide To Oblivion ...

[Nick Roberts]

On Fri, 08 Feb 2002 12:23:48 GMT, Ole-Hjalmar Kristensen
<oleh@vlinux.voxelvision.no> wrote:

>Ian Wild <ian@cfmu.eurocontrol.be> writes:
>
>> David Brown wrote:
>> On, say, a high end PDP-11, or a 68000, or an 8086 (but not its
>> progeny!), code space and data space are physically separate.  There
>> are wires that come out of the processor to say which space to use.  On
>> such a system there's NO WAY to write to code space, and it's not
>> impossible that
>
>??? This is pure fantasy. How do you think the code got into the code
>space in the first place? 

It is not fantasy, but I think factually slightly imperfect.

As far as I recall, neither the 8086 nor the 8088 (nor any of their
progeny) ever had this kind of control signal. I'm not sure, but I don't
think the 68000 did either (and certainly didn't need it, since it had
24-bit physical addressing at the outset). I don't actually know about the
PDPs.

However, I do know that the Zilog Z8002 processor (a typical 16-bit
processor of the 1980s) did indeed have such control signals, which could
be used by onboard circuitry to physically separate instruction space from
data space (and indeed stack space from heap space).

Some configurations merely overlapped them, sticking with the traditional
64KB; others used this as a way of getting 128KB or 192KB address space, at
the expense of much more complex extra decoding logic.

To answer the question:

>How do you think the code got into the code
>space in the first place?

The circuitry also distinguished between normal (user) mode and privileged
(supervisor) mode. It was necessary for a buffer to be provided which
allowed the supervisor (operating system) to gain access to all the
different address spaces, precisely so as to be able to load program code
(and static data) and to prime other spaces.

>> On
>> such a system there's NO WAY to write to code space, and it's not
>> impossible that

It is necessary for processors that do have separate program space to
provide a way for user programs to access data in that space, since static
data associated with the program will also reside there. The Z8000
processors actually had a 'relative address' mode which provided just this
capability, and the capability it provided included writing as well as
reading; however the aforementioned control signals also distinguished
between reads and writes, and so the control circuitry could (and sometimes
did) prevent writing into code space in normal mode.

So it would be better to say that on some targets it would be impossible
(for a user program) to write into code space, but on other targets it
would be possible to do so. (Even considering just targets which have the
differentiation between program space and data space.)

-- 
Nick Roberts

Re: Ada's Slide To Oblivion ...

[Matthew Woodcraft]

nickroberts@ukf.net (Nick Roberts) writes:

> On Fri, 08 Feb 2002 12:23:48 GMT, Ole-Hjalmar Kristensen
> <oleh@vlinux.voxelvision.no> wrote:

> >> David Brown wrote:
> >> On, say, a high end PDP-11, or a 68000, or an 8086 (but not its
> >> progeny!), code space and data space are physically separate.  There
> >> are wires that come out of the processor to say which space to use.  On
> >> such a system there's NO WAY to write to code space, and it's not
> >> impossible that

> It is not fantasy, but I think factually slightly imperfect.
>
> As far as I recall, neither the 8086 nor the 8088 (nor any of their
> progeny) ever had this kind of control signal.

A genuine 8086 had two pins which indicated the segment register which
had been used to calculate an address. I imagine an 8088 did too.

I suppose this could reasonably be used to separate code space from data
space if all the code were in ROM. I also once saw a suggestion that it
could be used to have a separate stack space.

-M-

Re: Ada's Slide To Oblivion ...

[Nick Roberts]

Ian has corrected me in that both the 8086/8 and 68000 did indeed have such
control signals. Later members of both families (I presume) dropped them as
they acquired more sophisticated memory management capabilities.

-- 
Nick Roberts

Re: Ada's Slide To Oblivion ...

[Darren New]

Nick Roberts wrote:
 
> Ian has corrected me in that both the 8086/8 and 68000 did indeed have such
> control signals. Later members of both families (I presume) dropped them as
> they acquired more sophisticated memory management capabilities.

Even the 8080 had a line (M1) that distinguished instruction fetch from
data fetch. 

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
  The opposite of always is sometimes.
   The opposite of never is sometimes.

Re: Ada's Slide To Oblivion ...

[David Brown]

Ian Wild <ian@cfmu.eurocontrol.be> wrote:
> David Brown wrote:

>> Legality aside, I have yet to find a compiler that doesn't accept this.
> 
> I'll agree that most compilers will accept it, but it's not
> C and quite often doesn't do what you're expecting.

The "quite often" part is really going to depend on what you're doing.
Most processors that are used for general purposes these days have the
same memory spaces for code and data.  Every processor that I've seen
posted to this list certainly does.

A good counter example is the Atmel AVR Risc processor.  This is a
microcontroller where instructions are fetched from flash memory, and
data comes from SRAM.  There are separate load instructions to retrieve
data from the two types of memory.  This is an example where data to
function pointer conversions in C aren't going to work.

On most architectures, C compilers will implement the pointer
conversions in the obvious way.  If they didn't, their compilers would
probably be unable to compile operating systems and system libraries.

BTW, I believe that GNAT assumes the address spaces are the same to
construct trampolines for nested procedure pointers.  gcc for C also
does if you nest functions (a gcc extension).

Yes, using this feature is unportable, but hopefully someone
constructing opcodes, writing them in memory, and trying to execute them
isn't expecting it to be portable.

There are a lot of other issues you have to worry about when you do
this, such as cache coherency, since many processors have separate I and
D caches.

David Brown

Re: Ada's Slide To Oblivion ...

[David Thompson]

Nick Roberts <nickroberts@adaos.worldonline.co.uk> wrote :
...
> Allow me to try to clarify. The C language requires (in practice if not
> strictly in theory) that all pointers fit into one machine word.

Not really.  Early versions of C did this (and BCPL and B required it),
but as C became more widely ported and (then) standardized it was
recognized by everyone who was paying attention that you cannot
assume this: "all the world's not a VAX".  It is true that C tends to
stress use and particularly computation of pointers, which puts
a premium on lightweight pointers, where possible.

> On 32-bit
> architectures, this almost invariably forces the use of a 'flat' address
> space (just an offset, with no segment number or equivalent). Which means
> that, for many architectures, the operating system cannot use segmentation
> (or other memory divisions) to [restrict executability]

Only on 32-bit architectures where the segment is (always)
outside the 32-bit address, like 386+.  I have seen several
architectures that put segment+offset into a 32-bit address,
which can work as you want.  Admittedly certain x86 systems
are so widely used that problems on them affect a lot of people,
but I don't think the language is solely or even primarily to blame.

> On many architectures, then, C prevents the OS from using available memory
> protection mechanisms to prevent buffer overrun exploitation, whereas most
> other programming languages do not. In this way, C is a security liability.

Most generalpurpose 3GLs have some way of creating and using
pointers, at least in the form of by-reference argument passing.
It is equally illegal in all these languages to actually overrun a
buffer, and in usual implementations of all of them it is possible
to do so anyway, although almost never as easily as is usual in C,
and if you do the results are equally damaging.

> C++ generally has the same fault.

Except to the extent that you use containers like std::vector
or other encapsulated and checked types and operations
to prevent overruns in the first place.  But you certainly aren't
required, or even all that strongly encouraged, to do so.

--
- David.Thompson 1 now at worldnet.att.net

Re: Ada's Slide To Oblivion ...

[Ian S. Nelson]

Nick Roberts wrote:

> "Dale Pontius" <pontius@btv.MBI.com.invalid> wrote in message
> news:a3eikr$tfo$1@news.btv.ibm.com...
> 
> 
>>By today's common programming practices, we have a situation
>>where the simplest/easiest way of programming string input gives
>>buffer overflows, and there for security holes. In C, that is.
>>Don't know about C++, but at least in Ada, the simplest/easiest
>>way of programming string input at worst would give a DOS
>>problem as the program crashed, and it wouldn't be much harder
>>to catch the exception and stop that.

> Both C and C++ are fundamentally insecure languages, because they require a
> 'flat' address space, with no differentiation between the executable
> (read-only) and variable (read-write) parts. This completely subverts the
> security mechanisms (e.g. segments with access controls) most modern
> processor architectures support and could otherwise fully deploy. Buffer
> overrun exploits are but one manifestation of this problem.
 

This is flat out wrong.

Re: Ada's Slide To Oblivion ...

[Warren W. Gay VE3WWG]

Ted Dennison wrote:

> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a3a19n$db9$1@nh.pace.co.uk>...
> 
>>An interesting article. One could argue about the accuracy of the survey,
>>but it probably isn't that far off from reality.
> 
> The only thing I found completely wrong was the assertion that you
> can't call an Ada compiler "Ada" without going through validation or
> the copyright holder to the term will come after you. The DoD isn't
> enforcing that copyright anymore. It is the Ada community that demands
> validation, not any one entity. But that would probably have been
> tougher to explain properly.


The assertion "That's unheard of in the Ada world, since the compilers
are essentially perfect" was a bit much also. I've run into a few GNAT
bugs that caused me to scratch my head for a while. Ada does not
eliminate a programmer's logic errors, but it sure helps to eliminate
a wider range of stupid erros.


>>The good news is that if people are writing thoughtful articles like this
>>and observing that Ada really does have benefits (despite lack of use) maybe
>>it might generate some renewed interest. The fact that they're writing about
>>it at all is a sign that Ada isn't a non-issue. IOW, "I don't care what they
>>say about Ada as long as they capitalize its name right!" :-)
> 
> I really think Ada 83 was just *waaaaay* ahead of its time. Back in
> the 80's and early 90's you'd quite often hear people seriously argue
> *against* type checking. These days that's pretty rare (see some of
> Eric Raymond's writings, if you want a trip back in that particular
> way-back machine). Now that folks are using Java and C++ regularly and
> can see for themselves the benifits to compile-time checking and
> object-oriented design, suddenly Ada doesn't look so bad any more.


I also have to question "DOD caved, first allowing a few exceptions, 

then many, till now Ada is more an interesting historical aside 

than part of every developer's zeitgeist."  I may be wrong, but as

I understand it, the language is still considered on a project by
project basis. I cannot see them acceptiong anything but Ada for
weapons or flight systems. Or has this really changed?

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada's Slide To Oblivion ...

[Jim Rogers]

Comments and articles similar to this appear occasionally.

I like to try to read between the lines and understand the
assumptions being made by the author. In the case of this
article I find one assumption is that people know Ad as
well as C, and have made a conscious decision toward C and
away from Ada. I do not believe this assumption is even
approximately true.

Most of the embedded programmers currently working embedded
software engineers have only heard rumors about Ada. Most
have never used it. Many have never seen it or heard about
it.

C++ has grown because C programmers were convinced it was
really C with a few unimportant differences. In other words,
C++ was designed to fool people into adopting it. The same
cannot be said about Ada.

My contention is that Ada has never slid into oblivion.
In fact, Ada is slowly climbing out of the initial
oblivion into which it was born.

Jim Rogers
Colorado Springs, Colorado USA

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

"Jim Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:3C58AE09.7070503@worldnet.att.net...
>
> article I find one assumption is that people know Ad as
> well as C, and have made a conscious decision toward C and
> away from Ada. I do not believe this assumption is even
> approximately true.
>
Some part of the decision may be subconscious - many people just use what
they know or what has gone before or what came with their development board.
Others may have given Ada passing consideration, having heard rumors about
it, etc. and at least consciously said "I don't want to use Ada because..."
Still others may have given serious evaluation to Ada and even considered it
to be superior in many respects, but abandoned it because they just couldn't
get it for the platforms for which they were developing. (Remember, this was
about embedded systems in particular. This makes the picture significantly
different from workstation/PC development.)


>
> My contention is that Ada has never slid into oblivion.
> In fact, Ada is slowly climbing out of the initial
> oblivion into which it was born.
>
It may be climbing out of oblivion - but probably more in the Workstation/PC
application world than in the embedded world. I suspect the numbers cited in
the article are pretty close to reality for embedded systems. Maybe its
really 4% instead of 2% of embedded development going on in Ada. Maybe the
2% consists of really big important projects and the 98% are much smaller
software efforts. We could dispute the exact precision of the numbers all
day long, but I don't think anyone will contend that it is really more like
25%. Ada is just a small sliver of the embedded market and almost
nonexistant outside of DoD embedded work. (Depending, of course, on how you
want to count it.)

It would help Ada in the embedded world if there were more SBCs available
with at least Ada as an option for compiler choice. If, for example, the SBC
were to come with the gcc/Gnat compiler built so that developers could
choose to use C, C++ or Ada & still have access to all the development
tools, it might stand a chance. But look at what ships with most SBC
development kits: Some version of C or maybe C++. Never mind that if someone
*really* wanted to use Ada, they could cobble together a kit for themselves
out of parts available from the Internet. The mission of embedded computing
isn't to use some specific language - its to ship a working product out the
door. Spending weeks or months getting a development environment together
when one already comes with the kit is a waste of the stockholder's money.

Its not impossible for Ada to get used for embedded development - but it
sure needs first and formost to be *available* as a choice. Then it needs to
overcome all the usual objections, but at least it can play in the market.
It wouldn't hurt if there was some easily assembled student-level
development kit. That way, Ada would be targeting the developers who don't
already have built in biases and who will soon be making decisions about
what to use on "real" projects.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Ada's Slide To Oblivion ...

[Steve O'Neill]

Marin David Condic wrote:
> It would help Ada in the embedded world if there were more SBCs available
> with at least Ada as an option for compiler choice. If, for example, the SBC
> were to come with the gcc/Gnat compiler built so that developers could
> choose to use C, C++ or Ada & still have access to all the development
> tools, it might stand a chance. 

Yes, that would improve the situation immensely.  People might actually
consider
Ada is they were handed the tools along with the hardware.  Of course,
many of 
those folks would simply dismiss it out of hand but the more open-minded
folks 
might actually try it... and like it.

> But look at what ships with most SBC development kits: Some version of C or 
> maybe C++. 

Well.. how do we fix this?  Probably the first steps are to 1) assemble
the tools/
components necessary to support a family of SBCs and 2) convince the SBC
vendors to
'toss it in the box'.  To have any hope step #2 would have to be at
worst free to
the vendors.

> Never mind that if someone *really* wanted to use Ada, they could cobble 
> together a kit for themselves out of parts available from the Internet. 

Yes, but people usually 1) take the path of least effort and 2) use what
they are
already familiar with and/or already have in hand.

> Spending weeks or months getting a development environment together
> when one already comes with the kit is a waste of the stockholder's money.

Not to mention usually thankless work.

Just my $0.02 worth

Steve O'Neill

Re: Ada's Slide To Oblivion ...

[Larry Kilgallen]

In article <3C598CBD.71740E0D@gbr.msd.ray.com>, Steve O'Neill <oneils@gbr.msd.ray.com> writes:
> Marin David Condic wrote:
>> It would help Ada in the embedded world if there were more SBCs available
>> with at least Ada as an option for compiler choice. If, for example, the SBC
>> were to come with the gcc/Gnat compiler built so that developers could
>> choose to use C, C++ or Ada & still have access to all the development
>> tools, it might stand a chance. 
> 
> Yes, that would improve the situation immensely.  People might actually
> consider
> Ada is they were handed the tools along with the hardware.  Of course,
> many of 
> those folks would simply dismiss it out of hand but the more open-minded
> folks 
> might actually try it... and like it.

I don't understand much about this, so please explain.
I presume SBC stands for "single board computer", sort of an industrial
Heathkit with all the soldering done.

So what good is an SBC to someone building a rocket ship or a subway ?
They aren't really going to build it with SBCs in the production units,
are they ?

Re: Ada's Slide To Oblivion ...

[martin.m.dowie]

> I don't understand much about this, so please explain.
> I presume SBC stands for "single board computer", sort of an industrial
> Heathkit with all the soldering done.
>
> So what good is an SBC to someone building a rocket ship or a subway ?
> They aren't really going to build it with SBCs in the production units,
> are they ?

Well, I don't know about rocket ships, but for Mission Computers, Radar
Systems, Digital Moving Maps, Helmet Mounted Displays, etc. Yes! That's
exactly what systems are using.

The current flavour of the year seems to be PowerPC 750/7400 boards with
some NOVRAM, ethernet, rs232 etc.

see http://www.dy4.com for examples of such SBCs.

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

Yes - SBC means "Single Board Computer".

You're thinking too big if you're thinking about rocket ships and all that.
An SBC typically will have a few discrete lines and a/d - d/a converters on
board and usually some communication links like UARTs or Ethernet. You use
the board to control a bunch of other things - switches, stepper motors,
what have you. The SBC rides along with some other electronics to do some
limited job - like run an irrigation pump out in the field or control an air
conditioner for maximum efficiency. You could (and in many places do) use
them (in some form) in a rocket or railroad - it just depends on exactly
what needs to be done and where you want to locate the "smarts".

Typically, you get a development version of the board with additional
hardware making it possible to program it from a PC. Along with the
development board, you get development software that will include a
compiler, debugging tools, etc.

Just a few examples:

http://www.pc104.org/
http://www.pc104.com/
http://www.zworld.com/
http://www.compulab.co.il/486core.htm

MDC

--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:Bqo0YdSM4fq$@eisner.encompasserve.org...
> In article <3C598CBD.71740E0D@gbr.msd.ray.com>, Steve O'Neill
<oneils@gbr.msd.ray.com> writes:
>
> I don't understand much about this, so please explain.
> I presume SBC stands for "single board computer", sort of an industrial
> Heathkit with all the soldering done.
>
> So what good is an SBC to someone building a rocket ship or a subway ?
> They aren't really going to build it with SBCs in the production units,
> are they ?

Re: Ada's Slide To Oblivion ...

[Steve O'Neill]

Larry Kilgallen wrote:
> 
> In article <3C598CBD.71740E0D@gbr.msd.ray.com>, Steve O'Neill <oneils@gbr.msd.ray.com> writes:
> > Marin David Condic wrote:
> >> It would help Ada in the embedded world if there were more SBCs available
> >> with at least Ada as an option for compiler choice. If, for example, the SBC
> >> were to come with the gcc/Gnat compiler built so that developers could
> >> choose to use C, C++ or Ada & still have access to all the development
> >> tools, it might stand a chance.
> >
> > Yes, that would improve the situation immensely.  People might actually
> > consider
> > Ada is they were handed the tools along with the hardware.  Of course,
> > many of
> > those folks would simply dismiss it out of hand but the more open-minded
> > folks
> > might actually try it... and like it.
> 
> I don't understand much about this, so please explain.
> I presume SBC stands for "single board computer", sort of an industrial
> Heathkit with all the soldering done.

Correct interpretation of SBC.  There's an incredibly wide and diverse
range
of SBCs out there though - everything from something one might expect
from Heath
all the way up to conduction-cooled boards that could be part of a
rocket ship.

> So what good is an SBC to someone building a rocket ship or a subway ?
> They aren't really going to build it with SBCs in the production units,
> are they ?

If they can they will.  The potential cost savings between designing and
building
your own hardware and grabbing a commercial board is potentially huge. 
And the
US DoD has been pushing the use of COTS (Commercial Off-The-Shelf)
components very
hard for the past decade.

Of course there are places where custom designed is the way to go but
this decision
should be made only after evaluating the options.

Steve

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

Well, that's largely a question of the economics of the situation. Suppose
you are making a controller card for a power generating turbine. You sell
these to Florida Power & Light for backup generators, so your sales numbers
are measured in - oh, what? - thousands? hundreds? - lets say 1000 units. To
design a custom board that might eliminate some parts from an off-the-shelf
board could be quite costly. Figure you've got a whole range of tests to run
on it as well to make sure it won't break in its expected use, etc. That
could be a lot of $$$. What do you get for that compared to a COTS board
that maybe you can buy for $100 in quantities of a few hundred? And compared
to the overall price of the end product, its a pretty small item to
optimize. Plus all the headaches of managing the design & manufacture of a
new board and all the risks that go with it. Its probably better to buy one
than attempt to save the cost of the few extra parts you may not need.

Now compare those economics to something that, say, might be more of a
consumer product. Say you're making a microwave oven and plan on selling
them on the order of 1,000,000 units over the life of the design. Suddenly,
some time spent to custom design a board (perhaps based on a COTS-SBC that
you use for development and prototyping) starts making sense. If you can
eliminate $1.00 worth of parts from the board, that saves you $1,000,000 -
which might justify the development and testing costs.

Even for relatively short-run products, it sometimes pays because you might
not be able to get the performance or reliability out of a COTS design that
you need. This is common for rockets because typically you can't buy a COTS
board that would stand up to the extremes of heat, cold and gamma radiation
it has to live through. But that's a rather unusual case. For most shorter
production runs, its going to be more economical to get an SBC that is
reasonably optimized for what you need.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Steve O'Neill" <oneils@gbr.msd.ray.com> wrote in message
news:3C59B1BA.EFCD88C9@gbr.msd.ray.com...
>
> > So what good is an SBC to someone building a rocket ship or a subway ?
> > They aren't really going to build it with SBCs in the production units,
> > are they ?
>
> If they can they will.  The potential cost savings between designing and
> building
> your own hardware and grabbing a commercial board is potentially huge.
> And the
> US DoD has been pushing the use of COTS (Commercial Off-The-Shelf)
> components very
> hard for the past decade.
>

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

"Steve O'Neill" <oneils@gbr.msd.ray.com> wrote in message
news:3C598CBD.71740E0D@gbr.msd.ray.com...
>
> Yes, that would improve the situation immensely.  People might actually
> consider
> Ada is they were handed the tools along with the hardware.  Of course,
> many of
> those folks would simply dismiss it out of hand but the more open-minded
> folks
> might actually try it... and like it.
>
I could imagine a situation that looked a little like this: Find a vendor of
a family of SBCs that is using a gcc compiler already. Look over their
development kit to be familiar with their tools, etc., and discover if there
were any reasons to believe that it wouldn't work with GNAT. Work with the
vendor to make a port of GNAT that targeted their machine and still
supported C & C++ and whatever other front-ends they might want to offer. It
ought to then be a matter of unplugging the gcc they are normally shipping
and plugging in the GNAT you want them to use.

I couldn't tell you what sort of arrangements are common with the SBC
manufacturers and their potential suppliers, but I would imagine that it
would be to their advantage to be able to say "Hey! Pick our board and you
can use C, C++ Fortran, Pascal, Cobol or Ada to write your embedded system
in!!!" They might be willing to go to a third party supplier to get that
work done - I bet a number of them already have arrangements with Cygnus. It
might be possible for a garage operation to get something started that aimed
at the niche of mixing and matching existing gcc front/back ends.
Hmmmmmmmm....... :-)


>
> Well.. how do we fix this?  Probably the first steps are to 1) assemble
> the tools/
> components necessary to support a family of SBCs and 2) convince the SBC
> vendors to
> 'toss it in the box'.  To have any hope step #2 would have to be at
> worst free to
> the vendors.
>
Not necessarily. You might be able to front-load the deal or back-load the
deal. They might already be paying for compiler support. (Either they do it
themselves - and it costs money, or they get someone else to do it - and it
costs money.) They might be willing to provide a percentage deal on every
development kit they sell. Remember, they are primarily *hardware* vendors
who want to sell a million SBCs to be installed in every refrigerator or
auto some manufacturer makes. They do the software because they have to in
order to sell the hardware, but it isn't what drives their business.

I'd suggest that the place to start is as I described above - find one or
more SBCs that use a gcc based environment and see how hard it would be to
plug GNAT into it. If the SBC didn't cost much and a student could download
an Ada solution, it might find some followers.


>
> > Spending weeks or months getting a development environment together
> > when one already comes with the kit is a waste of the stockholder's
money.
>
> Not to mention usually thankless work.
>
Yup. And if a business can't see some way that it ends up making them money,
you'll end up doing it on the weekends and evenings.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Ada's Slide To Oblivion ...

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> "Jim Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
> news:3C58AE09.7070503@worldnet.att.net...
> 
>>article I find one assumption is that people know Ad as
>>well as C, and have made a conscious decision toward C and
>>away from Ada. I do not believe this assumption is even
>>approximately true.
>>
> Some part of the decision may be subconscious - many people just use what
> they know or what has gone before or what came with their development board.
> Others may have given Ada passing consideration, having heard rumors about
> it, etc. and at least consciously said "I don't want to use Ada because..."
> Still others may have given serious evaluation to Ada and even considered it
> to be superior in many respects, but abandoned it because they just couldn't
> get it for the platforms for which they were developing. (Remember, this was
> about embedded systems in particular. This makes the picture significantly
> different from workstation/PC development.)


I think that even for those people that gave Ada an honest try, they still
tend to slide back into what they know best. Not only does one have to learn
the language, but they need time to discover the standard packages and the
different ways things need to be done in Ada (due to its software engineering
restrictions that are enforced). People will make a feeble attempt to start
something, and then hit a wall. Time runs out and they abandon the new approach
for a known one, in order to get the job done.

Only a desire to master it will overcome this type of resistance. Education in
Ada in Universities is another bright spot, because Ada will be hopefully what
new recruits will want to fall back to.

But I agree, that for many, Ada is just some rumour they have heard about.

>>My contention is that Ada has never slid into oblivion.
>>In fact, Ada is slowly climbing out of the initial
>>oblivion into which it was born.
>>
> It may be climbing out of oblivion - but probably more in the Workstation/PC
> application world than in the embedded world. 


As systems get more complicated, and people become concerned about software
quality, I sure hope that it is "climbing out of oblivion".  In all the years
that have passed since the first computers were built, software is still very
much a sesspool of unreliability. The difference today IMO, is that we are
building towers on shaky buggy foundations.

...

> MDC
> --
> Marin David Condic

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
news:3C598FF1.4040706@home.com...
>
>
> I think that even for those people that gave Ada an honest try, they still
> tend to slide back into what they know best. Not only does one have to
learn
> the language, but they need time to discover the standard packages and the
> different ways things need to be done in Ada (due to its software
engineering
> restrictions that are enforced). People will make a feeble attempt to
start
> something, and then hit a wall. Time runs out and they abandon the new
approach
> for a known one, in order to get the job done.
>

But there's a way to fix that. If a bunch of Ada die-hards who are convinced
that it is a better way were to identify some niche of the embedded market
that they wanted to go for and started doing it better/faster/cheaper,
they'd start becoming very effective competition. If your competitors are
always out the door a few months ahead of you because they aren't chasing
bugs forever, you have to start wondering what they are doing that you
aren't.

I think the problem has been that the guys who like Ada aren't the ones who
go off and design embedded products. Its a double-E guy who dreams up "Hey!
I can build this nifty little board that will do this spiffy job - and oh,
yeah, I'll have to do some software to get it all to work...". What if we
Ada guys turned that around? "Hey, I've got this spiffy idea for a neat
software system and all I'll need is a couple of SBC's that can drive these
devices....." I keep kicking around a few of those ideas in my copius spare
time. :-)


MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Ada's Slide To Oblivion ...

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
> news:3C598FF1.4040706@home.com...
> 
>>I think that even for those people that gave Ada an honest try, they still
>>tend to slide back into what they know best. Not only does one have to
>>learn the language, but they need time to discover the standard packages and the
>>different ways things need to be done in Ada (due to its software
>>engineering restrictions that are enforced). 

>>People will make a feeble attempt to start
>>something, and then hit a wall. Time runs out and they abandon the new
>>approach for a known one, in order to get the job done.
> 
> But there's a way to fix that. If a bunch of Ada die-hards who are convinced
> that it is a better way were to identify some niche of the embedded market
> that they wanted to go for and started doing it better/faster/cheaper,
> they'd start becoming very effective competition. If your competitors are
> always out the door a few months ahead of you because they aren't chasing
> bugs forever, you have to start wondering what they are doing that you
> aren't.


I agree that measurement of the competition may have its own influence.


> I think the problem has been that the guys who like Ada aren't the ones who
> go off and design embedded products. 


Probably a big part of the problem, I agree.

> Its a double-E guy who dreams up "Hey!
> I can build this nifty little board that will do this spiffy job - and oh,
> yeah, I'll have to do some software to get it all to work...". 


Thinking of someone I know who used to work in hardware, and got
pushed into software, what he would know and try would be C/C++.
Ada would be that strange thing he heard about in the distant
past. So I think part of the trouble is "Ada image" and awareness.

The other problem is, as you've pointed out, he is not a software
guy. But he's going to attempt it anyway, because he wants to. C
is easy to work in and so even given a choice between C and Ada,
he'll take the easiest route (not knowing that it will cost him
time debugging etc. later).

> What if we
> Ada guys turned that around? "Hey, I've got this spiffy idea for a neat
> software system and all I'll need is a couple of SBC's that can drive these
> devices....." I keep kicking around a few of those ideas in my copius spare
> time. :-)
> 
> MDC


Even when the guy has an Ada software expert nearby, given the opportunity

to do it himself, I expect he will, in C (unless he understands the profit

side of the exercise, and has a direct motive in this area).


I'm not sure what the answer is, but you've hit one of the embedded systems
area problems on the head, I think. One solution is a better image for Ada,
and thus better awareness on the part of owner/managers of these types of
projects.

The other factor that keeps coming up is this "hiring for Ada programmers"

thing. This was the very first objection when I mentioned Ada at my

work. The merits of the language never even started the discussion. So

I hope that with GNAT, open source and interest in Ada in the Universities,
that this situation may someday change. I just hope it's not too late.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada's Slide To Oblivion ...

[David Gillon]

Marin David Condic wrote:

> I suspect the numbers cited in
> the article are pretty close to reality for embedded systems. Maybe its
> really 4% instead of 2% of embedded development going on in Ada. Maybe the
> 2% consists of really big important projects and the 98% are much smaller
> software efforts. 

I suspect this may be the case. A more interesting set of figures (ok,
more flattering to Ada) might be man years of effort, or project value.
1 Ada box going into F-22, 777 or whatever will likely take considerably
more effort and earn more value than a dozen C boxes running
air-conditioning systems.

> Ada is just a small sliver of the embedded market and almost
> nonexistant outside of DoD embedded work.

DoD aren't the only defence ministry out there! OTOH it would be foolish
to deny that defence work is still the backbone of Ada effort.


-- 


David Gillon

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

Like I said - it depends on what you want to count. We could discuss that
until the cows come home. Clearly, some consumer-oriented box with 5000
lines of C code in it is not really in the same league with an F-22 with
millions of lines of Ada code in it. But last I heard the government was
only going to buy a few hundred F-22s over the project life whereas the
little 5000 line C doohickie might be selling in the millions of units. So
which is the more "important" project and how would you stack them up with
respect to which is the more "important" programming language for embedded
systems?

I still don't think that any way you want to count it that Ada is going to
score as a major player in the embedded computing world anymore. It's kind
of relegated to the "also ran" category - which is a shame because lots of
people will admit that it really is a good language for embedded computing.
There are just a lot of factors that hinder its success in this area.

I think that as Ada continues to grow in the non-embedded fields it will
start encouraging more usage in the embedded world. Tools become more
prevalent and experience builds with it and along the way it will trickle
into the embedded world. But it will be a slow process and it is dependent
on how successfully Ada penetrates the more "normal" sorts of application
development.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"David Gillon" <david.gillon@baesystems.com> wrote in message
news:3C5A8A09.95084CAD@baesystems.com...
>
> I suspect this may be the case. A more interesting set of figures (ok,
> more flattering to Ada) might be man years of effort, or project value.
> 1 Ada box going into F-22, 777 or whatever will likely take considerably
> more effort and earn more value than a dozen C boxes running
> air-conditioning systems.
>

Re: Ada's Slide To Oblivion ...

[Adrian Hoe]

Marin David Condic wrote:
> 
> Like I said - it depends on what you want to count. We could discuss that
> until the cows come home. Clearly, some consumer-oriented box with 5000
> lines of C code in it is not really in the same league with an F-22 with
> millions of lines of Ada code in it. But last I heard the government was
> only going to buy a few hundred F-22s over the project life whereas the
> little 5000 line C doohickie might be selling in the millions of units. So
> which is the more "important" project and how would you stack them up with
> respect to which is the more "important" programming language for embedded
> systems?
> 
> I still don't think that any way you want to count it that Ada is going to
> score as a major player in the embedded computing world anymore. It's kind
> of relegated to the "also ran" category - which is a shame because lots of
> people will admit that it really is a good language for embedded computing.
> There are just a lot of factors that hinder its success in this area.
> 
> I think that as Ada continues to grow in the non-embedded fields it will
> start encouraging more usage in the embedded world. Tools become more
> prevalent and experience builds with it and along the way it will trickle
> into the embedded world. But it will be a slow process and it is dependent
> on how successfully Ada penetrates the more "normal" sorts of application
> development.

More people are accepting Ada now, at least in my company (new staff).
Ada will not have the glory of other development tools eg. C++ Builder,
Delphi, etc. until much bindings are available for programmers'
disposal. GtkAda and Glade are just the beginning. There is still a long
way to go for Ada to be accepted in the non-embedded, business
applications area.

> MDC

-- 
                              -- Adrian Hoe
                              -- http://greenlime.com/users/adrian.hoe

Re: Ada's Slide To Oblivion ...

[Jeffrey Creem]

Don't forget to point out to the non-embedded people that there are very
nice Ada bindings available under windows for ALL COM libraries. This
is a big deal since there are thousands of libraries that have COM
interfaces.


"Adrian Hoe" <byhoe@greenlime.com> wrote in message
news:3C5B659A.7BAADE49@greenlime.com...
> Marin David Condic wrote:
> >
> > Like I said - it depends on what you want to count. We could discuss
that
> > until the cows come home. Clearly, some consumer-oriented box with 5000
> > lines of C code in it is not really in the same league with an F-22 with
> > millions of lines of Ada code in it. But last I heard the government was
> > only going to buy a few hundred F-22s over the project life whereas the
> > little 5000 line C doohickie might be selling in the millions of units.
So
> > which is the more "important" project and how would you stack them up
with
> > respect to which is the more "important" programming language for
embedded
> > systems?
> >
> > I still don't think that any way you want to count it that Ada is going
to
> > score as a major player in the embedded computing world anymore. It's
kind
> > of relegated to the "also ran" category - which is a shame because lots
of
> > people will admit that it really is a good language for embedded
computing.
> > There are just a lot of factors that hinder its success in this area.
> >
> > I think that as Ada continues to grow in the non-embedded fields it will
> > start encouraging more usage in the embedded world. Tools become more
> > prevalent and experience builds with it and along the way it will
trickle
> > into the embedded world. But it will be a slow process and it is
dependent
> > on how successfully Ada penetrates the more "normal" sorts of
application
> > development.
>
> More people are accepting Ada now, at least in my company (new staff).
> Ada will not have the glory of other development tools eg. C++ Builder,
> Delphi, etc. until much bindings are available for programmers'
> disposal. GtkAda and Glade are just the beginning. There is still a long
> way to go for Ada to be accepted in the non-embedded, business
> applications area.
>
> > MDC
>
> --
>                               -- Adrian Hoe
>                               -- http://greenlime.com/users/adrian.hoe

Re: Ada's Slide To Oblivion ...

[Marin David Condic]

Well, its easier to adopt Ada for a PC/Workstation app than to adopt it for
an embedded platform. At least there is an Ada compiler somewhere targeted
to most of the popular PC/Workstation environments - something that is not
always true of embedded machines.

I've looked briefly at GtkAda and Glade in the past and not having a serious
use for them at the time (and a general lack of time for fooling around! :-)
I kind of let the effort wither on the vine. I've got something going on
that might be able to make use of them now, so I'll probably ressurect the
effort. I've noticed an on-line tutorial or two that might help
coinsiderably. (I couldn't quite figure out how to use Glade to get a GUI
built that didn't look like a P.O.S. A tutorial on driving it around may
help if it shows how to organize the widgets into a nice looking interface.
I just don't have time to tinker with it forever and figure it out.)

Tools like this are moving things in the right direction because it starts
providing the application development leverage that other languages might
already have. It would be nice to see all these pieces wired together into a
single tool - some version of a source code browser/editor as the main
interface that you point at a "project library" and then initiate Glade,
Gdb, etc from that platform as needed & have them all working together. (I
noticed in scanning some of the pages about Gtk that there were a whole set
of Gnome widgets that looked really useful - but they didn't come along for
the ride with GtkAda. It would add even more leverage to have these, or
similar widgets available.)

Anyway, the point is that as Ada finds more ways of getting into the
PC/Workstation development arena, it makes it easier to commit to it for
embedded systems because more and more tools become available as well as
building up an experience base. In general, its a good thing.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Adrian Hoe" <byhoe@greenlime.com> wrote in message
news:3C5B659A.7BAADE49@greenlime.com...
>
> More people are accepting Ada now, at least in my company (new staff).
> Ada will not have the glory of other development tools eg. C++ Builder,
> Delphi, etc. until much bindings are available for programmers'
> disposal. GtkAda and Glade are just the beginning. There is still a long
> way to go for Ada to be accepted in the non-embedded, business
> applications area.
>

Re: Ada's Slide To Oblivion ...

[Adrian Hoe]

David Gillon wrote:
> 
> Marin David Condic wrote:
> 
> > I suspect the numbers cited in
> > the article are pretty close to reality for embedded systems. Maybe its
> > really 4% instead of 2% of embedded development going on in Ada. Maybe the
> > 2% consists of really big important projects and the 98% are much smaller
> > software efforts.
> 
> I suspect this may be the case. A more interesting set of figures (ok,
> more flattering to Ada) might be man years of effort, or project value.
> 1 Ada box going into F-22, 777 or whatever will likely take considerably
> more effort and earn more value than a dozen C boxes running
> air-conditioning systems.
> 
> > Ada is just a small sliver of the embedded market and almost
> > nonexistant outside of DoD embedded work.
> 
> DoD aren't the only defence ministry out there! OTOH it would be foolish
> to deny that defence work is still the backbone of Ada effort.


Right. Ada is still pretty much under the umbrella of defence. Ada is
unlikely to strive in general computing sector until the "general
public" shed off the defence relationship of Ada.


> --
> 
> David Gillon

-- 
                              -- Adrian Hoe
                              -- http://greenlime.com/users/adrian.hoe

Re: Ada's Slide To Oblivion ...

[tmoran]

>Right. Ada is still pretty much under the umbrella of defence. Ada is
>unlikely to strive in general computing sector until the "general
>public" shed off the defence relationship of Ada.
  Broaden "defence" to "security" and there's great market opportunity
for Ada in America.

Re: Ada's Slide To Oblivion ...

[Randy Brukardt]

Volkert wrote in message ...
>found at Embedded Systems Programming:
>
>>Ada is the only language designed to
>>significantly reduce and maybe even
>>eliminate dumb programming errors. Did
>>it fall into disuse because we're
>>intellectually lazy?
>
>read more: http://www.embedded.com/story/OEG20020125S0098


I hope that some of the people pontificating on this newsgroup are
actually providing feedback to the author of the article (which he asks
for at the end). I'd do it myself, but my embedded software experience
is limited to supporting customers doing it. All of my good war stories
are on desktops and servers.

Writing here might make people feel good, but does nothing whatsoever to
promote Ada or convince people that using C/C++ is dangerous.


            Randy Brukardt

Re: Ada's Slide To Oblivion ...

[Nick Roberts]

I wrote to the editor correcting (commenting on) the obvious points (that
seem to have been largely borne out in this thread - phew). However, I
fought shy of 'war stories' for fear of sounding too much like an advocate!

--
Nick Roberts


"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:u5jskk38g43je7@corp.supernews.com...

> I hope that some of the people pontificating on this newsgroup are
> actually providing feedback to the author of the article (which he asks
> for at the end). I'd do it myself, but my embedded software experience
> is limited to supporting customers doing it. All of my good war stories
> are on desktops and servers.
>
> Writing here might make people feel good, but does nothing whatsoever to
> promote Ada or convince people that using C/C++ is dangerous.

Re: Ada's Slide To Oblivion ...

[Christoph Grein]

> But then they wouldn't be able to say: "No. Really. Just buy the *next*
> version and that particular problem will go away. This time, we're not just
> teasing you. Honest. We really mean it. The next version is going to be
> *great*. Just give us a little more money....." :-) I am reminded of Charley
> Brown running at the football Lucy is holding for him. :-)


Sorry, this time it wasn't...