Ada noob here! Is Ada widely used?
in [ADA]
|
Prev: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)
Next: Gnat cross compiler
From: Yannick Duchêne (Hibou57) on 24 May 2010 18:38 Le Tue, 25 May 2010 00:21:56 +0200, Jeffrey R. Carter <spam.jrcarter.not(a)spam.acm.org> a écrit: > The Verdix compiler was started in C and later changed to Ada. This is > where the comparison in > http://www.adaic.org/whyada/ada-vs-c/cada_art.html comes from, one of > the few hard data points in language comparisons. Never head about Verdix before. Thanks for that -> it goes in my bookmarks. Will read carefully soon. -- There is even better than a pragma Assert: a SPARK --# check.
From: Stephen Leake on 24 May 2010 22:02 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: > On Mon, 24 May 2010 05:00:58 -0400, Stephen Leake wrote: > >> Duke Normandin <dukeofperl(a)ml1.net> writes: >> >>> On 2010-05-23, Jeffrey R. Carter <spam.jrcarter.not(a)spam.acm.org> wrote: >>>> Bruno Le Hyaric wrote: >>>>> >>>>> One question, why did Lockheed Martin choose C++ for avionics software >>>>> on the JSF aircraft project? >>>> >>>> Money. >>>> >>>> Most US Defense project contracts are set up so the contractor makes more money >>>> the more the project costs. A poor but "popular" language choice, lots of >>>> coders, and no SW engineers is one way to drive the cost up and make more money. >>>> Defense contractors have maximizing the profit down to a fine art. >>> >>> That's outright scary when you ponder all the implications. So much for >>> using the "right tool, for a particular task". Greed, greed, and more greed >>> is what is putting us at at risk in this embedded computer age. >> >> It's not the contractor's fault; it's the DOD's fault. If they wrote the >> contract so that the contractor made more money by using the right tools >> and writing good software, that's what would happen. >> >> It's the contractor's job to make as much money as possible; it's the >> client's job to set the terms of the contract. > > Nice theory, not working in practice. Imagine your baker trying making as > much money as possible and you setting terms on the bread's ingredients. Not a valid comparison; I don't have nearly as much buying power as the DOD. A better comparison is a national supermarket chain negotiating with several large bakery chains. And that does work much better than the DOD vs the military contractors. > It is the fault of the CS ? Civil Servants? Computer Science? > unable to deliver a sound background for software engineering. Which > is more shamanism than engineering. If it's shamanism, then how are the computer science schools at fault? "Worship Microsoft" sounds like good shamanism. It used to be "worship IBM". The complaint was that the contractors are greedy. Under capitalism, the assumption is that _everyone_ is greedy, but the government sets the rules so the societies best interest is served by everyone's greed. It takes a long term view, and adequate social/political education on everyone's part. _that's_ why it doesn't work; thinking is hard, most people don't want to do it. Just like writing good code in Ada is harder than writing sloppy code in C. To bring this mildly back on topic. > This in turn makes it impossible to impose *reasonable* regulations on > what software is and how it is to be engineered. We don't need regulations, we need success oriented contracting. Part of the problem is people don't know how to manage large systems; that's why the air traffic control system is not replaced yet. > (Unreasonable regulations are plenty, of course) Meaningful > regulations exist, for example, for bakers, so when you buy bread it > is bread. Depends; if I buy it at the local grocery store, it's more like plastic. If I buy it at the farmer's market, then it is bread. The only regulation involved is health; no bacteria or mold allowed. > When you buy software it can be anything. Because nobody knows for > sure how to do it "right". It is much easier to measure results than to enforce process. But people don't want to spend the time to do that either. > It is "our" word against the word of c-java-dot-net-UML camp. The > latter is far more vocal. So what do you expect DoD to do? Require results, not process. Banks get good software for their central money servers, because they insist that they actually work, and are secure, and spend the money to ensure that happens (and some of them are written in SPARK). NASA's space shuttle software doesn't fail, because they insist on not killing astronauts. The strategy in response to that requirement is to take CMM to heart, and don't let new hires write code until they know what they are doing. But it's the insistence on the goal that matters. Commercial airline software is more reliable than the rest of the plane. Good software is possible, it's just hard work on everyone's part. -- -- Stephe
From: Stephen Leake on 24 May 2010 22:07 Duke Normandin <dukeofperl(a)ml1.net> writes: > it doesn't make _any_ difference to the health and welfare of this > planet if the next video game to hit the shelves is buggier than hell, > because it was written in whatever, taking 3 times as long to write > than what it could have taken using saner tools. I'm in an arguing mood tonight, so I'll argue with this, too :). If the customers insisted on games that are nicely playable, didn't crash, had good sound and smooth video, and the programmers were able to deliver that, then everyone would be happier. That counts a lot towards "welfare". The programmers would be happier because they'd be forced to use better tools and processes. I'm far happier when I'm writing in Ada with Emacs than when I'm writing in VHDL with Modelsim! > which leads me to academia!. Some egg-head(s) get it into their skulls that > this or that language is cool, so some university starts to push flavor A, > at the expense of other "industry-proven" technology. My impression is it's the other way around. Java took over in universities because Sun marketed it. But I don't have any good data to back that up. -- -- Stephe
From: Stephen Leake on 24 May 2010 22:10 Duke Normandin <dukeofperl(a)ml1.net> writes: > On 2010-05-24, Stephen Leake <stephen_leake(a)stephe-leake.org> wrote: >> Duke Normandin <dukeofperl(a)ml1.net> writes: >> >>> On 2010-05-23, Jeffrey R. Carter <spam.jrcarter.not(a)spam.acm.org> wrote: >>>> Bruno Le Hyaric wrote: >>>>> >>>>> One question, why did Lockheed Martin choose C++ for avionics software >>>>> on the JSF aircraft project? >>>> >>>> Money. >>>> >>>> Most US Defense project contracts are set up so the contractor makes more money >>>> the more the project costs. A poor but "popular" language choice, lots of >>>> coders, and no SW engineers is one way to drive the cost up and make more money. >>>> Defense contractors have maximizing the profit down to a fine art. >>>> >>> >>> That's outright scary when you ponder all the implications. So much for >>> using the "right tool, for a particular task". Greed, greed, and more greed >>> is what is putting us at at risk in this embedded computer age. >> >> It's not the contractor's fault; it's the DOD's fault. If they wrote the >> contract so that the contractor made more money by using the right tools >> and writing good software, that's what would happen. > > I don't buy it! If if can't make money using the correct tool for the job, > thereby generating a safe, workable product, then don't bid the job! Right. So someone who is perfectly happy taking the DOD's money, and spending it on bad tools and processes gets the job. So you are agreeing with me. > Then go out and get provably safe technology, and the best people that > you can to use it. Work ethics and pride of workmanship, two values > that have gone out the door for the most part, along time ago. And who is going to buy that? AdaCore customers, for one. But they are not the final consumers. >> It's the contractor's job to make as much money as possible; it's the >> client's job to set the terms of the contract. > > Spoken like a true capitalist bean-counter - which is OK provided you are > not screwing up the environment, and otherwise endangering people's lives > and well-being in the process. Effects on the environment need to be included in the cost of the contract. That we don't do well (or at all) at the moment. But that is the way forward; include the true cost of everyone's activities in a free market, and you will get the results you want. -- -- Stephe
From: Stephen Leake on 24 May 2010 22:11
Duke Normandin <dukeofperl(a)ml1.net> writes: > On 2010-05-21, Warren <ve3wwg(a)gmail.com> wrote: >> Ludovic Brenta expounded in news:87d3wqbayp.fsf(a)ludovic-brenta.org: >> >>> Duke Normandin writes: >>>> On 2010-05-20, Anonymous <cripto(a)ecn.org> wrote: >>>>>> Just curious to know if Ada is still widely used, and in what >>>>>> area(s) does it excel, e.g. data processing, number crunching, >>>>>> graphics, etc? TIA.. >> >> It's ok to be curious but this begs the question of why >> it is important for it to be "popular"? >> >> Do you have to sell it's use at your company? >> >> Are you considering the availability of tools and/or >> source code? >> >> Or, are you interested in it for your own (or open sourced) >> projects? >> >> Depending on the answers to some of these factors, >> popularity may not be important. > > Nothing too terribly mind-boggling! ;) Just don't want to spend the time > learning a "soon-to-be" fossil of a language, with no where to go but in a > museum. Been there; done that! I'm also looking at learning Miranda - but > guess what? Nice, simple functional language - but zero community and > support. It _may_ get a second life - maybe. Meanwhile, I'm liking Ada. You have told us why you are scared of learning Ada (it might be a waste of time), but not why you want to learn Ada. Are you just curious? -- -- Stephe |