* Ada's Slide To Oblivion ...
@ 2002-01-30 23:09 Volkert
2002-01-30 23:57 ` Marin David Condic
` (2 more replies)
0 siblings, 3 replies; 78+ messages in thread
From: Volkert @ 2002-01-30 23:09 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-30 23:09 Ada's Slide To Oblivion Volkert @ 2002-01-30 23:57 ` Marin David Condic 2002-01-31 3:04 ` Richard Riehle 2002-01-31 15:14 ` Ted Dennison 2002-01-31 2:37 ` Jim Rogers 2002-02-01 1:42 ` Randy Brukardt 2 siblings, 2 replies; 78+ messages in thread From: Marin David Condic @ 2002-01-30 23:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-30 23:57 ` Marin David Condic @ 2002-01-31 3:04 ` Richard Riehle 2002-01-31 3:05 ` Eric Merritt 2002-01-31 14:37 ` Marin David Condic 2002-01-31 15:14 ` Ted Dennison 1 sibling, 2 replies; 78+ messages in thread From: Richard Riehle @ 2002-01-31 3:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 3:04 ` Richard Riehle @ 2002-01-31 3:05 ` Eric Merritt 2002-01-31 16:26 ` Richard Riehle 2002-01-31 14:37 ` Marin David Condic 1 sibling, 1 reply; 78+ messages in thread From: Eric Merritt @ 2002-01-31 3:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 3:05 ` Eric Merritt @ 2002-01-31 16:26 ` Richard Riehle 2002-01-31 16:41 ` Larry Kilgallen 2002-02-04 4:43 ` Richard Riehle 0 siblings, 2 replies; 78+ messages in thread From: Richard Riehle @ 2002-01-31 16:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 16:26 ` Richard Riehle @ 2002-01-31 16:41 ` Larry Kilgallen 2002-02-02 15:51 ` Zach Swanson 2002-02-04 4:43 ` Richard Riehle 1 sibling, 1 reply; 78+ messages in thread From: Larry Kilgallen @ 2002-01-31 16:41 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 16:41 ` Larry Kilgallen @ 2002-02-02 15:51 ` Zach Swanson 2002-02-02 19:18 ` Richard Riehle 0 siblings, 1 reply; 78+ messages in thread From: Zach Swanson @ 2002-02-02 15:51 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-02 15:51 ` Zach Swanson @ 2002-02-02 19:18 ` Richard Riehle 0 siblings, 0 replies; 78+ messages in thread From: Richard Riehle @ 2002-02-02 19:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 16:26 ` Richard Riehle 2002-01-31 16:41 ` Larry Kilgallen @ 2002-02-04 4:43 ` Richard Riehle 1 sibling, 0 replies; 78+ messages in thread From: Richard Riehle @ 2002-02-04 4:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 3:04 ` Richard Riehle 2002-01-31 3:05 ` Eric Merritt @ 2002-01-31 14:37 ` Marin David Condic 1 sibling, 0 replies; 78+ messages in thread From: Marin David Condic @ 2002-01-31 14:37 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-30 23:57 ` Marin David Condic 2002-01-31 3:04 ` Richard Riehle @ 2002-01-31 15:14 ` Ted Dennison 2002-01-31 17:16 ` Marin David Condic ` (2 more replies) 1 sibling, 3 replies; 78+ messages in thread From: Ted Dennison @ 2002-01-31 15:14 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 15:14 ` Ted Dennison @ 2002-01-31 17:16 ` Marin David Condic 2002-01-31 18:32 ` Steve O'Neill 2002-01-31 18:27 ` Warren W. Gay VE3WWG 2002-01-31 18:28 ` Warren W. Gay VE3WWG 2 siblings, 1 reply; 78+ messages in thread From: Marin David Condic @ 2002-01-31 17:16 UTC (permalink / raw) "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/ ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 17:16 ` Marin David Condic @ 2002-01-31 18:32 ` Steve O'Neill 0 siblings, 0 replies; 78+ messages in thread From: Steve O'Neill @ 2002-01-31 18:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 15:14 ` Ted Dennison 2002-01-31 17:16 ` Marin David Condic @ 2002-01-31 18:27 ` Warren W. Gay VE3WWG 2002-01-31 19:22 ` Marin David Condic ` (2 more replies) 2002-01-31 18:28 ` Warren W. Gay VE3WWG 2 siblings, 3 replies; 78+ messages in thread From: Warren W. Gay VE3WWG @ 2002-01-31 18:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 18:27 ` Warren W. Gay VE3WWG @ 2002-01-31 19:22 ` Marin David Condic 2002-01-31 20:40 ` Christopher A. Bohn 2002-02-01 2:26 ` Richard Riehle 2 siblings, 0 replies; 78+ messages in thread From: Marin David Condic @ 2002-01-31 19:22 UTC (permalink / raw) "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/ ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 18:27 ` Warren W. Gay VE3WWG 2002-01-31 19:22 ` Marin David Condic @ 2002-01-31 20:40 ` Christopher A. Bohn 2002-01-31 21:08 ` Marin David Condic 2002-02-01 2:31 ` Ada's Slide To Oblivion Richard Riehle 2002-02-01 2:26 ` Richard Riehle 2 siblings, 2 replies; 78+ messages in thread From: Christopher A. Bohn @ 2002-01-31 20:40 UTC (permalink / raw) 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" ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 20:40 ` Christopher A. Bohn @ 2002-01-31 21:08 ` Marin David Condic 2002-02-01 14:22 ` [off-topic - to lighten the air] Wes Groleau 2002-02-01 2:31 ` Ada's Slide To Oblivion Richard Riehle 1 sibling, 1 reply; 78+ messages in thread From: Marin David Condic @ 2002-01-31 21:08 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 78+ messages in thread
* [off-topic - to lighten the air] 2002-01-31 21:08 ` Marin David Condic @ 2002-02-01 14:22 ` Wes Groleau 0 siblings, 0 replies; 78+ messages in thread From: Wes Groleau @ 2002-02-01 14:22 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 20:40 ` Christopher A. Bohn 2002-01-31 21:08 ` Marin David Condic @ 2002-02-01 2:31 ` Richard Riehle 2002-02-04 16:51 ` Jerry Petrey 1 sibling, 1 reply; 78+ messages in thread From: Richard Riehle @ 2002-02-01 2:31 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-01 2:31 ` Ada's Slide To Oblivion Richard Riehle @ 2002-02-04 16:51 ` Jerry Petrey 2002-02-04 17:49 ` Richard Riehle 2002-02-06 7:07 ` Anders Wirzenius 0 siblings, 2 replies; 78+ messages in thread From: Jerry Petrey @ 2002-02-04 16:51 UTC (permalink / raw) 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 ----------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-04 16:51 ` Jerry Petrey @ 2002-02-04 17:49 ` Richard Riehle 2002-02-04 18:24 ` Marin David Condic 2002-02-05 13:48 ` Georg Bauhaus 2002-02-06 7:07 ` Anders Wirzenius 1 sibling, 2 replies; 78+ messages in thread From: Richard Riehle @ 2002-02-04 17:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-04 17:49 ` Richard Riehle @ 2002-02-04 18:24 ` Marin David Condic 2002-02-05 9:04 ` DPH 2002-02-05 16:37 ` Wes Groleau 2002-02-05 13:48 ` Georg Bauhaus 1 sibling, 2 replies; 78+ messages in thread From: Marin David Condic @ 2002-02-04 18:24 UTC (permalink / raw) 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++." > ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-04 18:24 ` Marin David Condic @ 2002-02-05 9:04 ` DPH 2002-02-05 14:46 ` Marin David Condic 2002-02-05 16:37 ` Wes Groleau 1 sibling, 1 reply; 78+ messages in thread From: DPH @ 2002-02-05 9:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-05 9:04 ` DPH @ 2002-02-05 14:46 ` Marin David Condic 0 siblings, 0 replies; 78+ messages in thread From: Marin David Condic @ 2002-02-05 14:46 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-04 18:24 ` Marin David Condic 2002-02-05 9:04 ` DPH @ 2002-02-05 16:37 ` Wes Groleau 2002-02-05 17:22 ` Marin David Condic 2002-02-05 18:42 ` Preben Randhol 1 sibling, 2 replies; 78+ messages in thread From: Wes Groleau @ 2002-02-05 16:37 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-05 16:37 ` Wes Groleau @ 2002-02-05 17:22 ` Marin David Condic 2002-02-05 18:42 ` Preben Randhol 1 sibling, 0 replies; 78+ messages in thread From: Marin David Condic @ 2002-02-05 17:22 UTC (permalink / raw) "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/ ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-05 16:37 ` Wes Groleau 2002-02-05 17:22 ` Marin David Condic @ 2002-02-05 18:42 ` Preben Randhol 2002-02-06 21:37 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 78+ messages in thread From: Preben Randhol @ 2002-02-05 18:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-05 18:42 ` Preben Randhol @ 2002-02-06 21:37 ` Warren W. Gay VE3WWG 2002-02-07 11:30 ` Georg Bauhaus 0 siblings, 1 reply; 78+ messages in thread From: Warren W. Gay VE3WWG @ 2002-02-06 21:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-06 21:37 ` Warren W. Gay VE3WWG @ 2002-02-07 11:30 ` Georg Bauhaus 0 siblings, 0 replies; 78+ messages in thread From: Georg Bauhaus @ 2002-02-07 11:30 UTC (permalink / raw) Warren W. Gay VE3WWG <ve3wwg@home.com> wrote: : You'd just get A# ;-) Hm, that's likely to causes trouble with the A+ folk. :-) ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-04 17:49 ` Richard Riehle 2002-02-04 18:24 ` Marin David Condic @ 2002-02-05 13:48 ` Georg Bauhaus 1 sibling, 0 replies; 78+ messages in thread From: Georg Bauhaus @ 2002-02-05 13:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-04 16:51 ` Jerry Petrey 2002-02-04 17:49 ` Richard Riehle @ 2002-02-06 7:07 ` Anders Wirzenius 1 sibling, 0 replies; 78+ messages in thread From: Anders Wirzenius @ 2002-02-06 7:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 18:27 ` Warren W. Gay VE3WWG 2002-01-31 19:22 ` Marin David Condic 2002-01-31 20:40 ` Christopher A. Bohn @ 2002-02-01 2:26 ` Richard Riehle 2002-02-01 14:27 ` A. Nonny Mouse 2002-02-01 17:18 ` Dale Pontius 2 siblings, 2 replies; 78+ messages in thread From: Richard Riehle @ 2002-02-01 2:26 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-01 2:26 ` Richard Riehle @ 2002-02-01 14:27 ` A. Nonny Mouse 2002-02-01 17:18 ` Dale Pontius 1 sibling, 0 replies; 78+ messages in thread From: A. Nonny Mouse @ 2002-02-01 14:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-01 2:26 ` Richard Riehle 2002-02-01 14:27 ` A. Nonny Mouse @ 2002-02-01 17:18 ` Dale Pontius 2002-02-06 2:37 ` Nick Roberts 1 sibling, 1 reply; 78+ messages in thread From: Dale Pontius @ 2002-02-01 17:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-01 17:18 ` Dale Pontius @ 2002-02-06 2:37 ` Nick Roberts 2002-02-06 7:31 ` Ole-Hjalmar Kristensen 2002-02-06 14:59 ` Ian S. Nelson 0 siblings, 2 replies; 78+ messages in thread From: Nick Roberts @ 2002-02-06 2:37 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-06 2:37 ` Nick Roberts @ 2002-02-06 7:31 ` Ole-Hjalmar Kristensen 2002-02-06 21:27 ` Nick Roberts 2002-02-06 14:59 ` Ian S. Nelson 1 sibling, 1 reply; 78+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-02-06 7:31 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-06 7:31 ` Ole-Hjalmar Kristensen @ 2002-02-06 21:27 ` Nick Roberts 2002-02-06 22:03 ` Ian S. Nelson ` (3 more replies) 0 siblings, 4 replies; 78+ messages in thread From: Nick Roberts @ 2002-02-06 21:27 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-06 21:27 ` Nick Roberts @ 2002-02-06 22:03 ` Ian S. Nelson 2002-02-07 1:44 ` Philip Cummins ` (2 subsequent siblings) 3 siblings, 0 replies; 78+ messages in thread From: Ian S. Nelson @ 2002-02-06 22:03 UTC (permalink / raw) 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 > > > > ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-06 21:27 ` Nick Roberts 2002-02-06 22:03 ` Ian S. Nelson @ 2002-02-07 1:44 ` Philip Cummins 2002-02-07 13:56 ` Ian Wild 2002-02-18 3:54 ` David Thompson 3 siblings, 0 replies; 78+ messages in thread From: Philip Cummins @ 2002-02-07 1:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-06 21:27 ` Nick Roberts 2002-02-06 22:03 ` Ian S. Nelson 2002-02-07 1:44 ` Philip Cummins @ 2002-02-07 13:56 ` Ian Wild 2002-02-07 17:25 ` Ray Blaak 2002-02-18 3:54 ` David Thompson 3 siblings, 1 reply; 78+ messages in thread From: Ian Wild @ 2002-02-07 13:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-07 13:56 ` Ian Wild @ 2002-02-07 17:25 ` Ray Blaak 2002-02-07 19:20 ` Hyman Rosen 0 siblings, 1 reply; 78+ messages in thread From: Ray Blaak @ 2002-02-07 17:25 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-07 17:25 ` Ray Blaak @ 2002-02-07 19:20 ` Hyman Rosen 2002-02-07 21:36 ` David Brown 0 siblings, 1 reply; 78+ messages in thread From: Hyman Rosen @ 2002-02-07 19:20 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-07 19:20 ` Hyman Rosen @ 2002-02-07 21:36 ` David Brown 2002-02-08 10:36 ` Ian Wild 0 siblings, 1 reply; 78+ messages in thread From: David Brown @ 2002-02-07 21:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-07 21:36 ` David Brown @ 2002-02-08 10:36 ` Ian Wild 2002-02-08 12:23 ` Ole-Hjalmar Kristensen 2002-02-09 0:39 ` David Brown 0 siblings, 2 replies; 78+ messages in thread From: Ian Wild @ 2002-02-08 10:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-08 10:36 ` Ian Wild @ 2002-02-08 12:23 ` Ole-Hjalmar Kristensen 2002-02-08 12:51 ` Ian Wild 2002-02-08 13:08 ` Nick Roberts 2002-02-09 0:39 ` David Brown 1 sibling, 2 replies; 78+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-02-08 12:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-08 12:23 ` Ole-Hjalmar Kristensen @ 2002-02-08 12:51 ` Ian Wild 2002-02-08 14:28 ` Marin David Condic 2002-02-08 15:52 ` Ole-Hjalmar Kristensen 2002-02-08 13:08 ` Nick Roberts 1 sibling, 2 replies; 78+ messages in thread From: Ian Wild @ 2002-02-08 12:51 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-08 12:51 ` Ian Wild @ 2002-02-08 14:28 ` Marin David Condic 2002-02-08 15:52 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 78+ messages in thread From: Marin David Condic @ 2002-02-08 14:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-08 12:51 ` Ian Wild 2002-02-08 14:28 ` Marin David Condic @ 2002-02-08 15:52 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 78+ messages in thread From: Ole-Hjalmar Kristensen @ 2002-02-08 15:52 UTC (permalink / raw) 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, ******** ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-08 12:23 ` Ole-Hjalmar Kristensen 2002-02-08 12:51 ` Ian Wild @ 2002-02-08 13:08 ` Nick Roberts 2002-02-08 21:28 ` Matthew Woodcraft 2002-02-08 21:45 ` Nick Roberts 1 sibling, 2 replies; 78+ messages in thread From: Nick Roberts @ 2002-02-08 13:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-08 13:08 ` Nick Roberts @ 2002-02-08 21:28 ` Matthew Woodcraft 2002-02-08 21:45 ` Nick Roberts 1 sibling, 0 replies; 78+ messages in thread From: Matthew Woodcraft @ 2002-02-08 21:28 UTC (permalink / raw) 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- ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-08 13:08 ` Nick Roberts 2002-02-08 21:28 ` Matthew Woodcraft @ 2002-02-08 21:45 ` Nick Roberts 2002-02-08 22:44 ` Darren New 1 sibling, 1 reply; 78+ messages in thread From: Nick Roberts @ 2002-02-08 21:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-08 21:45 ` Nick Roberts @ 2002-02-08 22:44 ` Darren New 0 siblings, 0 replies; 78+ messages in thread From: Darren New @ 2002-02-08 22:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-08 10:36 ` Ian Wild 2002-02-08 12:23 ` Ole-Hjalmar Kristensen @ 2002-02-09 0:39 ` David Brown 1 sibling, 0 replies; 78+ messages in thread From: David Brown @ 2002-02-09 0:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-06 21:27 ` Nick Roberts ` (2 preceding siblings ...) 2002-02-07 13:56 ` Ian Wild @ 2002-02-18 3:54 ` David Thompson 3 siblings, 0 replies; 78+ messages in thread From: David Thompson @ 2002-02-18 3:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-06 2:37 ` Nick Roberts 2002-02-06 7:31 ` Ole-Hjalmar Kristensen @ 2002-02-06 14:59 ` Ian S. Nelson 1 sibling, 0 replies; 78+ messages in thread From: Ian S. Nelson @ 2002-02-06 14:59 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 15:14 ` Ted Dennison 2002-01-31 17:16 ` Marin David Condic 2002-01-31 18:27 ` Warren W. Gay VE3WWG @ 2002-01-31 18:28 ` Warren W. Gay VE3WWG 2 siblings, 0 replies; 78+ messages in thread From: Warren W. Gay VE3WWG @ 2002-01-31 18:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-30 23:09 Ada's Slide To Oblivion Volkert 2002-01-30 23:57 ` Marin David Condic @ 2002-01-31 2:37 ` Jim Rogers 2002-01-31 15:02 ` Marin David Condic 2002-02-01 1:42 ` Randy Brukardt 2 siblings, 1 reply; 78+ messages in thread From: Jim Rogers @ 2002-01-31 2:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 2:37 ` Jim Rogers @ 2002-01-31 15:02 ` Marin David Condic 2002-01-31 18:28 ` Steve O'Neill ` (2 more replies) 0 siblings, 3 replies; 78+ messages in thread From: Marin David Condic @ 2002-01-31 15:02 UTC (permalink / raw) "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/ ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 15:02 ` Marin David Condic @ 2002-01-31 18:28 ` Steve O'Neill 2002-01-31 19:41 ` Larry Kilgallen 2002-01-31 19:42 ` Marin David Condic 2002-01-31 18:41 ` Warren W. Gay VE3WWG 2002-02-01 12:28 ` David Gillon 2 siblings, 2 replies; 78+ messages in thread From: Steve O'Neill @ 2002-01-31 18:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 18:28 ` Steve O'Neill @ 2002-01-31 19:41 ` Larry Kilgallen 2002-01-31 19:53 ` martin.m.dowie ` (2 more replies) 2002-01-31 19:42 ` Marin David Condic 1 sibling, 3 replies; 78+ messages in thread From: Larry Kilgallen @ 2002-01-31 19:41 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 19:41 ` Larry Kilgallen @ 2002-01-31 19:53 ` martin.m.dowie 2002-01-31 20:06 ` Marin David Condic 2002-01-31 21:06 ` Steve O'Neill 2 siblings, 0 replies; 78+ messages in thread From: martin.m.dowie @ 2002-01-31 19:53 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 19:41 ` Larry Kilgallen 2002-01-31 19:53 ` martin.m.dowie @ 2002-01-31 20:06 ` Marin David Condic 2002-01-31 21:06 ` Steve O'Neill 2 siblings, 0 replies; 78+ messages in thread From: Marin David Condic @ 2002-01-31 20:06 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 19:41 ` Larry Kilgallen 2002-01-31 19:53 ` martin.m.dowie 2002-01-31 20:06 ` Marin David Condic @ 2002-01-31 21:06 ` Steve O'Neill 2002-01-31 22:28 ` Marin David Condic 2 siblings, 1 reply; 78+ messages in thread From: Steve O'Neill @ 2002-01-31 21:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 21:06 ` Steve O'Neill @ 2002-01-31 22:28 ` Marin David Condic 0 siblings, 0 replies; 78+ messages in thread From: Marin David Condic @ 2002-01-31 22:28 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 18:28 ` Steve O'Neill 2002-01-31 19:41 ` Larry Kilgallen @ 2002-01-31 19:42 ` Marin David Condic 1 sibling, 0 replies; 78+ messages in thread From: Marin David Condic @ 2002-01-31 19:42 UTC (permalink / raw) "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/ ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 15:02 ` Marin David Condic 2002-01-31 18:28 ` Steve O'Neill @ 2002-01-31 18:41 ` Warren W. Gay VE3WWG 2002-01-31 19:52 ` Marin David Condic 2002-02-01 12:28 ` David Gillon 2 siblings, 1 reply; 78+ messages in thread From: Warren W. Gay VE3WWG @ 2002-01-31 18:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 18:41 ` Warren W. Gay VE3WWG @ 2002-01-31 19:52 ` Marin David Condic 2002-02-01 18:31 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 78+ messages in thread From: Marin David Condic @ 2002-01-31 19:52 UTC (permalink / raw) "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/ ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 19:52 ` Marin David Condic @ 2002-02-01 18:31 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 78+ messages in thread From: Warren W. Gay VE3WWG @ 2002-02-01 18:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-31 15:02 ` Marin David Condic 2002-01-31 18:28 ` Steve O'Neill 2002-01-31 18:41 ` Warren W. Gay VE3WWG @ 2002-02-01 12:28 ` David Gillon 2002-02-01 21:02 ` Marin David Condic 2002-02-02 4:02 ` Adrian Hoe 2 siblings, 2 replies; 78+ messages in thread From: David Gillon @ 2002-02-01 12:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-01 12:28 ` David Gillon @ 2002-02-01 21:02 ` Marin David Condic 2002-02-02 4:05 ` Adrian Hoe 2002-02-02 4:02 ` Adrian Hoe 1 sibling, 1 reply; 78+ messages in thread From: Marin David Condic @ 2002-02-01 21:02 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-01 21:02 ` Marin David Condic @ 2002-02-02 4:05 ` Adrian Hoe 2002-02-02 12:51 ` Jeffrey Creem 2002-02-04 15:58 ` Marin David Condic 0 siblings, 2 replies; 78+ messages in thread From: Adrian Hoe @ 2002-02-02 4:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-02 4:05 ` Adrian Hoe @ 2002-02-02 12:51 ` Jeffrey Creem 2002-02-04 15:58 ` Marin David Condic 1 sibling, 0 replies; 78+ messages in thread From: Jeffrey Creem @ 2002-02-02 12:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-02 4:05 ` Adrian Hoe 2002-02-02 12:51 ` Jeffrey Creem @ 2002-02-04 15:58 ` Marin David Condic 1 sibling, 0 replies; 78+ messages in thread From: Marin David Condic @ 2002-02-04 15:58 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-01 12:28 ` David Gillon 2002-02-01 21:02 ` Marin David Condic @ 2002-02-02 4:02 ` Adrian Hoe 2002-02-02 17:35 ` tmoran 1 sibling, 1 reply; 78+ messages in thread From: Adrian Hoe @ 2002-02-02 4:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-02 4:02 ` Adrian Hoe @ 2002-02-02 17:35 ` tmoran 0 siblings, 0 replies; 78+ messages in thread From: tmoran @ 2002-02-02 17:35 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-01-30 23:09 Ada's Slide To Oblivion Volkert 2002-01-30 23:57 ` Marin David Condic 2002-01-31 2:37 ` Jim Rogers @ 2002-02-01 1:42 ` Randy Brukardt 2002-02-01 16:56 ` Nick Roberts 2 siblings, 1 reply; 78+ messages in thread From: Randy Brukardt @ 2002-02-01 1:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ... 2002-02-01 1:42 ` Randy Brukardt @ 2002-02-01 16:56 ` Nick Roberts 0 siblings, 0 replies; 78+ messages in thread From: Nick Roberts @ 2002-02-01 16:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: Ada's Slide To Oblivion ...
@ 2002-02-06 7:02 Christoph Grein
0 siblings, 0 replies; 78+ messages in thread
From: Christoph Grein @ 2002-02-06 7:02 UTC (permalink / raw)
> 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...
^ permalink raw reply [flat|nested] 78+ messages in thread
end of thread, other threads:[~2002-02-18 3:54 UTC | newest] Thread overview: 78+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-01-30 23:09 Ada's Slide To Oblivion Volkert 2002-01-30 23:57 ` Marin David Condic 2002-01-31 3:04 ` Richard Riehle 2002-01-31 3:05 ` Eric Merritt 2002-01-31 16:26 ` Richard Riehle 2002-01-31 16:41 ` Larry Kilgallen 2002-02-02 15:51 ` Zach Swanson 2002-02-02 19:18 ` Richard Riehle 2002-02-04 4:43 ` Richard Riehle 2002-01-31 14:37 ` Marin David Condic 2002-01-31 15:14 ` Ted Dennison 2002-01-31 17:16 ` Marin David Condic 2002-01-31 18:32 ` Steve O'Neill 2002-01-31 18:27 ` Warren W. Gay VE3WWG 2002-01-31 19:22 ` Marin David Condic 2002-01-31 20:40 ` Christopher A. Bohn 2002-01-31 21:08 ` Marin David Condic 2002-02-01 14:22 ` [off-topic - to lighten the air] Wes Groleau 2002-02-01 2:31 ` Ada's Slide To Oblivion Richard Riehle 2002-02-04 16:51 ` Jerry Petrey 2002-02-04 17:49 ` Richard Riehle 2002-02-04 18:24 ` Marin David Condic 2002-02-05 9:04 ` DPH 2002-02-05 14:46 ` Marin David Condic 2002-02-05 16:37 ` Wes Groleau 2002-02-05 17:22 ` Marin David Condic 2002-02-05 18:42 ` Preben Randhol 2002-02-06 21:37 ` Warren W. Gay VE3WWG 2002-02-07 11:30 ` Georg Bauhaus 2002-02-05 13:48 ` Georg Bauhaus 2002-02-06 7:07 ` Anders Wirzenius 2002-02-01 2:26 ` Richard Riehle 2002-02-01 14:27 ` A. Nonny Mouse 2002-02-01 17:18 ` Dale Pontius 2002-02-06 2:37 ` Nick Roberts 2002-02-06 7:31 ` Ole-Hjalmar Kristensen 2002-02-06 21:27 ` Nick Roberts 2002-02-06 22:03 ` Ian S. Nelson 2002-02-07 1:44 ` Philip Cummins 2002-02-07 13:56 ` Ian Wild 2002-02-07 17:25 ` Ray Blaak 2002-02-07 19:20 ` Hyman Rosen 2002-02-07 21:36 ` David Brown 2002-02-08 10:36 ` Ian Wild 2002-02-08 12:23 ` Ole-Hjalmar Kristensen 2002-02-08 12:51 ` Ian Wild 2002-02-08 14:28 ` Marin David Condic 2002-02-08 15:52 ` Ole-Hjalmar Kristensen 2002-02-08 13:08 ` Nick Roberts 2002-02-08 21:28 ` Matthew Woodcraft 2002-02-08 21:45 ` Nick Roberts 2002-02-08 22:44 ` Darren New 2002-02-09 0:39 ` David Brown 2002-02-18 3:54 ` David Thompson 2002-02-06 14:59 ` Ian S. Nelson 2002-01-31 18:28 ` Warren W. Gay VE3WWG 2002-01-31 2:37 ` Jim Rogers 2002-01-31 15:02 ` Marin David Condic 2002-01-31 18:28 ` Steve O'Neill 2002-01-31 19:41 ` Larry Kilgallen 2002-01-31 19:53 ` martin.m.dowie 2002-01-31 20:06 ` Marin David Condic 2002-01-31 21:06 ` Steve O'Neill 2002-01-31 22:28 ` Marin David Condic 2002-01-31 19:42 ` Marin David Condic 2002-01-31 18:41 ` Warren W. Gay VE3WWG 2002-01-31 19:52 ` Marin David Condic 2002-02-01 18:31 ` Warren W. Gay VE3WWG 2002-02-01 12:28 ` David Gillon 2002-02-01 21:02 ` Marin David Condic 2002-02-02 4:05 ` Adrian Hoe 2002-02-02 12:51 ` Jeffrey Creem 2002-02-04 15:58 ` Marin David Condic 2002-02-02 4:02 ` Adrian Hoe 2002-02-02 17:35 ` tmoran 2002-02-01 1:42 ` Randy Brukardt 2002-02-01 16:56 ` Nick Roberts -- strict thread matches above, loose matches on Subject: below -- 2002-02-06 7:02 Christoph Grein
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox