* 7E7 Flight Controls Electronics @ 2004-05-29 1:51 Jeffrey Carter 2004-05-29 10:21 ` Per Dalgas Jakobsen 2004-06-06 10:27 ` I R T 0 siblings, 2 replies; 82+ messages in thread From: Jeffrey Carter @ 2004-05-29 1:51 UTC (permalink / raw) Honeywell is advertising for a software engineer for 7E7 flight controls electronics. The requirements are "Demonstrated experience using C/C++". No mention of Ada. http://honeywell.recruitsoft.com/ has the position listing, #00020024. Would you trust your life to an aircraft with flight controls electronics software hacked by a C coder? -- Jeff Carter "My mind is aglow with whirling, transient nodes of thought, careening through a cosmic vapor of invention." Blazing Saddles 85 ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 1:51 7E7 Flight Controls Electronics Jeffrey Carter @ 2004-05-29 10:21 ` Per Dalgas Jakobsen 2004-05-29 12:58 ` Marin David Condic 2004-06-06 10:27 ` I R T 1 sibling, 1 reply; 82+ messages in thread From: Per Dalgas Jakobsen @ 2004-05-29 10:21 UTC (permalink / raw) > Would you trust your life to an aircraft with flight controls > electronics software hacked by a C coder? Yes I would, because that thing has to be validated, tested, etc., etc. But I would hate to pay the bill, and I would definitely hate to be the project manager that has to tell the bosses that it won't complete on schedule. Per ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 10:21 ` Per Dalgas Jakobsen @ 2004-05-29 12:58 ` Marin David Condic 2004-05-29 13:35 ` Ed Falis 2004-05-29 15:58 ` Preben Randhol 0 siblings, 2 replies; 82+ messages in thread From: Marin David Condic @ 2004-05-29 12:58 UTC (permalink / raw) They're doing this stuff to DO-178b and for high criticality items, this calls out for rather severe levels of structural testing. Basically it means you need to cover all the paths in the software (more complex than this really, but this is the short version) Even with C++, this level of test coverage ought to insure safety of flight. Its just that it will likely cost more and take longer. Of course if you've allowed for it in the schedule, you won't slip the schedule. That depends on your experience with development of similar systems. If Ada has a demonstrable edge in this area (cost and schedule) then a competitor ought to be able to bid the job lower, wouldn't you think? So where are the Ada shops willing to take on the development and offer a lower price? Why isn't there some embedded system development company that is agressively going after these projects and offering Ada with a cost advantage? If they had a bunch of reusable components for the problem domain and they were DO-178b certified, they'd have all that leverage to bring to the table too. We can claim that Ada is superior and bitch because someone else won't see that and use it and call them boneheads for doing so. Alternately, if we really believed in its superiority, we'd have companies offering an Ada alternative and be out-competing the other bidders with low cost/high quality alternatives. I guess Ada needs a little more entrepreneurial spirit if it expects to get in the door on these things. ;-) MDC Per Dalgas Jakobsen wrote: > > Yes I would, because that thing has to be validated, tested, etc., etc. > > But I would hate to pay the bill, and I would definitely hate to be the > project manager that has to tell the bosses that it won't complete on > schedule. > > Per > > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 12:58 ` Marin David Condic @ 2004-05-29 13:35 ` Ed Falis 2004-05-29 17:29 ` Marin David Condic 2004-05-29 15:58 ` Preben Randhol 1 sibling, 1 reply; 82+ messages in thread From: Ed Falis @ 2004-05-29 13:35 UTC (permalink / raw) On Sat, 29 May 2004 12:58:41 GMT, Marin David Condic <nobody@noplace.com> wrote: > > Of course if you've allowed for it in the schedule, you won't slip the > schedule. That depends on your experience with development of similar > systems. If Ada has a demonstrable edge in this area (cost and schedule) > then a competitor ought to be able to bid the job lower, wouldn't you > think? > > So where are the Ada shops willing to take on the development and offer > a lower price? Why isn't there some embedded system development company > that is agressively going after these projects and offering Ada with a > cost advantage? If they had a bunch of reusable components for the > problem domain and they were DO-178b certified, they'd have all that > leverage to bring to the table too. > > We can claim that Ada is superior and bitch because someone else won't > see that and use it and call them boneheads for doing so. Alternately, > if we really believed in its superiority, we'd have companies offering > an Ada alternative and be out-competing the other bidders with low > cost/high quality alternatives. I guess Ada needs a little more > entrepreneurial spirit if it expects to get in the door on these things. > ;-) Jeez Marin, Reading an awful lot into a single job ad, don't you think? See http://www.windriver.com/news/press/20040330b.html regarding the selection of Wind River's AE653 RTOS for the core avionics. See http://www.smiths-aerospace.com/Press/Publication/default.asp?PublicationID=75765A3F-1497-4802-BBE0-69EAFC2E63A0&Type=Press for info about Smiths Aerospace and the 7E7 program. See http://www.gnat.com/pressroom_11.php for the AdaCore announcement. - Ed ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 13:35 ` Ed Falis @ 2004-05-29 17:29 ` Marin David Condic 2004-05-29 17:40 ` Ed Falis ` (2 more replies) 0 siblings, 3 replies; 82+ messages in thread From: Marin David Condic @ 2004-05-29 17:29 UTC (permalink / raw) Or just using it as a soap box from which to rant. :-) Mostly, its because I think it is a complete waste of time to look at jobs going to C++ and opine over how they rightly should be done in Ada. What are we doing to get Ada *into* those jobs? If Ada is really so great and the guys who are picking C++ are such boneheads, then it really must be possible to start a company aimed at developing avionics computers that would just blow the doors off of the competition, right? They're just a bunch of boneheads who are picking the high cost, long schedule option for no better reason that this is what is "popular", right? Idiots like that ought to be *easy* to out-compete on the bidding of the jobs - if Ada really produces that much extra leverage. We'll be knee deep in $$$ by noon tomorrow, right? Or is our confidence in Ada's superiority not so high? Down off my soap box now. ;-) MDC Ed Falis wrote: > > > Jeez Marin, > > Reading an awful lot into a single job ad, don't you think? > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 17:29 ` Marin David Condic @ 2004-05-29 17:40 ` Ed Falis 2004-05-29 18:44 ` Marin David Condic 2004-05-29 17:48 ` Wes Groleau 2004-05-30 7:50 ` Pascal Obry 2 siblings, 1 reply; 82+ messages in thread From: Ed Falis @ 2004-05-29 17:40 UTC (permalink / raw) On Sat, 29 May 2004 17:29:45 GMT, Marin David Condic <nobody@noplace.com> wrote: > Down off my soap box now. ;-) I'm going to get on mine, then. Being involved in this program as the project lead for the Ada compiler, I can make a pretty good guesstimate from early orders and the state of the core technologies being used that the proportion of C++ on this program is likely to be miniscule in the overall software load. My perception is also that Ada will be the dominant language used, though I can't speak for Boeing or its subcontractors. Fair enough? - Ed ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 17:40 ` Ed Falis @ 2004-05-29 18:44 ` Marin David Condic 2004-05-29 18:58 ` Ed Falis 2004-05-30 7:55 ` Pascal Obry 0 siblings, 2 replies; 82+ messages in thread From: Marin David Condic @ 2004-05-29 18:44 UTC (permalink / raw) Sure. I know there is Ada in the 7E7 and elsewhere for that matter. Ada is still in use, but companies are going down other routes. If we want Ada to be used widely in the future, we have to go out there and get it into projects ourselves. The best (and probably *only*) way that is going to happen is because Ada believers are sufficiently convinced of its superior profitability to be willing to start companies that make something that utilizes Ada. It ain't gonna happen if we wait for the C++ advocates to finally see the sweet light of reason. MDC Ed Falis wrote: > > I'm going to get on mine, then. > > Being involved in this program as the project lead for the Ada compiler, > I can make a pretty good guesstimate from early orders and the state of > the core technologies being used that the proportion of C++ on this > program is likely to be miniscule in the overall software load. My > perception is also that Ada will be the dominant language used, though > I can't speak for Boeing or its subcontractors. > > Fair enough? > > - Ed -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 18:44 ` Marin David Condic @ 2004-05-29 18:58 ` Ed Falis 2004-05-30 7:55 ` Pascal Obry 1 sibling, 0 replies; 82+ messages in thread From: Ed Falis @ 2004-05-29 18:58 UTC (permalink / raw) On Sat, 29 May 2004 18:44:11 GMT, Marin David Condic <nobody@noplace.com> wrote: > Sure. I know there is Ada in the 7E7 and elsewhere for that matter. Ada > is still in use, but companies are going down other routes. If we want > Ada to be used widely in the future, we have to go out there and get it > into projects ourselves. The best (and probably *only*) way that is > going to happen is because Ada believers are sufficiently convinced of > its superior profitability to be willing to start companies that make > something that utilizes Ada. It ain't gonna happen if we wait for the > C++ advocates to finally see the sweet light of reason. Looks like somebody already done that on 7E7. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 18:44 ` Marin David Condic 2004-05-29 18:58 ` Ed Falis @ 2004-05-30 7:55 ` Pascal Obry 2004-05-30 11:43 ` Georg Bauhaus 2004-05-31 11:56 ` Marin David Condic 1 sibling, 2 replies; 82+ messages in thread From: Pascal Obry @ 2004-05-30 7:55 UTC (permalink / raw) Marin David Condic <nobody@noplace.com> writes: > Sure. I know there is Ada in the 7E7 and elsewhere for that matter. Ada is > still in use, but companies are going down other routes. If we want Ada to be > used widely in the future, we have to go out there and get it into projects > ourselves. The best (and probably *only*) way that is going to happen is > because Ada believers are sufficiently convinced of its superior > profitability to be willing to start companies that make something that > utilizes Ada. That's only part of the problem. I think everybody on this group can build something that utilizes Ada... The real problem is to *sell* it. This is the difficult part! On many domains now, if your proposal does not contains the word "Java" (whatever it means) you are out ! Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-30 7:55 ` Pascal Obry @ 2004-05-30 11:43 ` Georg Bauhaus 2004-05-30 16:10 ` Pascal Obry 2004-05-31 11:56 ` Marin David Condic 1 sibling, 1 reply; 82+ messages in thread From: Georg Bauhaus @ 2004-05-30 11:43 UTC (permalink / raw) Pascal Obry <pascal@obry.org> wrote: : That's only part of the problem. I think everybody on this group can build : something that utilizes Ada... The real problem is to *sell* it. This is : the difficult part! On many domains now, if your proposal does not contains : the word "Java" (whatever it means) you are out ! so "runs on a Java Virtual Machine" should be a selling point, then? -- Georg ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-30 11:43 ` Georg Bauhaus @ 2004-05-30 16:10 ` Pascal Obry 0 siblings, 0 replies; 82+ messages in thread From: Pascal Obry @ 2004-05-30 16:10 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > so "runs on a Java Virtual Machine" should be a selling point, then? Certainly not. I'm talking about Java the language not the virtual machine, the language is part of the deal in many cases. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-30 7:55 ` Pascal Obry 2004-05-30 11:43 ` Georg Bauhaus @ 2004-05-31 11:56 ` Marin David Condic 1 sibling, 0 replies; 82+ messages in thread From: Marin David Condic @ 2004-05-31 11:56 UTC (permalink / raw) O.K. But if I manufacture a gazorenthorpe with a PowerPC processor in it and I program it in Ada and then go sell the gazorenthorpe to the end customer, what does he care? What language is your VCR programmed in? What about your word processor? Do you know? Do you care? At that level, all you care about is that it works and you got it for a good price. So if someone writes their RFP stipulating that it must be done in Java, oh well. That's a job we're not bidding on. (Or you make a proposal to do the whole job invisibly in Ada and that your $$$ figure is better than everyone else's because Ada is so clearly superior that you can get the job done at substantially lower cost, correct? Or maybe we don't believe that?) But why not come up with some end product that the customer doesn't care about the software beyond the point that it works? Build some useful little thingamabob that satisfies some need and program it in Ada. Sell it successfully and Ada jobs will be created. If Ada jobs are created, there will be more Ada programmers in the world. More Ada programmers makes a healthier environment in which Ada can flourish. It ain't gonna happen if we keep waiting for the rest of the world to see the wisdom of building things in Ada. MDC Pascal Obry wrote: > > That's only part of the problem. I think everybody on this group can build > something that utilizes Ada... The real problem is to *sell* it. This is > the difficult part! On many domains now, if your proposal does not contains > the word "Java" (whatever it means) you are out ! > > Pascal. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 17:29 ` Marin David Condic 2004-05-29 17:40 ` Ed Falis @ 2004-05-29 17:48 ` Wes Groleau 2004-05-29 18:53 ` Marin David Condic 2004-05-30 7:50 ` Pascal Obry 2 siblings, 1 reply; 82+ messages in thread From: Wes Groleau @ 2004-05-29 17:48 UTC (permalink / raw) Marin David Condic wrote: > What are we doing to get Ada *into* those jobs? If Ada is really so > great and the guys who are picking C++ are such boneheads, then it > really must be possible to start a company aimed at developing avionics > computers that would just blow the doors off of the competition, right? > They're just a bunch of boneheads who are picking the high cost, long > schedule option for no better reason that this is what is "popular", > right? Idiots like that ought to be *easy* to out-compete on the bidding Maybe. But I'm aware of defense bids that offered Java or a particular O.S. _because_ the bidder was aware that the contracts would be awarded by boneheads who had let the general culture persuade them that Java or that O.S. was the way to go and that Ada or Unix was obsolete. -- Wes Groleau http://groleau.freeshell.org/teaching/ ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 17:48 ` Wes Groleau @ 2004-05-29 18:53 ` Marin David Condic [not found] ` <n42jb05e8rk7bsrtf2ikesu9t0bsmbphji@4ax.com> 0 siblings, 1 reply; 82+ messages in thread From: Marin David Condic @ 2004-05-29 18:53 UTC (permalink / raw) That's fair enough - if the customer wants something in particular, you can't sell them something else. But I'll reiterate: If Ada is so great and builds such superior systems, then why aren't the Ada advocates out there getting busy building some end-product that they should obviously be able to do at a better cost basis & thus turn superior profitability? If Boeing or Lockmart or Honeywell or whoever doesn't want to build a particular whozits that goes into an airplane by using Ada and that it is stupid, foolish, costly, error-prone, etc. to do it in anything else, then it ought to be a *prime* opportunity to make buckets full of cash by starting a company to produce the lower cost, higher quality whozits using Ada. It costs too much to get into the whozits making business? O.K. Let's find some doohickey that can be built without a billion dollars of venture capital and go out and to that in Ada. If Ada is that much better, the doohickey ought to come out significantly cheaper than its nearest competitor. MDC Wes Groleau wrote: > > Maybe. But I'm aware of defense bids that offered Java > or a particular O.S. _because_ the bidder was aware that > the contracts would be awarded by boneheads who had let > the general culture persuade them that Java or that O.S. > was the way to go and that Ada or Unix was obsolete. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
[parent not found: <n42jb05e8rk7bsrtf2ikesu9t0bsmbphji@4ax.com>]
* Re: 7E7 Flight Controls Electronics [not found] ` <n42jb05e8rk7bsrtf2ikesu9t0bsmbphji@4ax.com> @ 2004-05-31 12:04 ` Marin David Condic 2004-06-06 10:35 ` I R T 1 sibling, 0 replies; 82+ messages in thread From: Marin David Condic @ 2004-05-31 12:04 UTC (permalink / raw) Then let's put this spin on it: Quit trying to sell Ada to Lockmart and getting pissed off at them when they don't buy it because it isn't the current "fad" language. Go find some whozits that the world needs/wants and doesn't care about the language in which it is implemented. (There are millions of examples - look around on your home computer and at all the electronic things in your house just to get started) Go build one and sell it. What about various marine applications? No FAA to get in your way. Possibly some kind of useful app that works with GPS and a PC? Or controller systems for things on the smaller boats? (Like 40/60 foot yachts - not the big container ships, etc. They've already got lots of electronics on them.) If Lockheed doesn't want to see the sweet light of reason and Ada *REALLY* is that much better, then it ought to be possible to go start a venture that uses Ada as a competitive advantage. MDC Dennis Lee Bieber wrote: > > After 20 years at "Flockheed", one has to suggest that > practically nothing gets built UNTIL a customer appears with the $$$... > Which puts us back to your first sentence (as quoted) "...the customer > wants...". > > And when it isn't "customer" driven, it is still management > bean-counter driven. "Teaching" a language is "overhead", and seldom > considered viable. A program I'd been on finally had the chance to move > a subsystem from PDP-11 Macro-11 to microVAX... The program had ~80 > experienced FORTRAN programmers, and 10 Macro-11. Guess what language > they picked to port the subsystem... > > Pascal! Justification: it was the language most new-hires were > familiar with (right... TurboPascal on an MS-DOS/Windows 3.x system is > going to be sufficient for realtime/multi-process VMS programming). Oh, > along with one member of the Macro-11 staff, who seemed to have some > influence... > > When the "survey" came through, I suggested either FORTRAN -- as > we had a large staff familiar with it -- or, if they were going to go > the mile to pick unproven Pascal, they could surely fall over an extra > foot and pick Ada. > > A few years later, when the manager left, he supposedly admitted > that Pascal was /not/ the best choice. > > In the last year, the descendent of that program put out > openings for programmers... This time they wanted Java. I tried to get > back in (I'd been laid-off from the program a few years ago, when the > section I'd been part of died of old age) -- one would think having > spent 20 years /on/ the program would be a good point. Instead, they'd > rather hire "experienced" Java programmers who need to undergo full > security clearance investigations AND be taught what the program does -- > rather than bring in someone whose clearance could probably be > reactivated with a short update, knows the program, and had some ability > with multiple languages (if a master of only one). > > -- > > ============================================================== < > > wlfraed@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG < > > wulfraed@dm.net | Bestiaria Support Staff < > > ============================================================== < > > Home Page: <http://www.dm.net/~wulfraed/> < > > Overflow Page: <http://wlfraed.home.netcom.com/> < -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics [not found] ` <n42jb05e8rk7bsrtf2ikesu9t0bsmbphji@4ax.com> 2004-05-31 12:04 ` Marin David Condic @ 2004-06-06 10:35 ` I R T 1 sibling, 0 replies; 82+ messages in thread From: I R T @ 2004-06-06 10:35 UTC (permalink / raw) Dennis Lee Bieber <wlfraed@ix.netcom.com> writes: > In the last year, the descendent of that program put out > openings for programmers... This time they wanted Java. I tried to get > back in (I'd been laid-off from the program a few years ago, when the > section I'd been part of died of old age) -- one would think having > spent 20 years /on/ the program would be a good point. Instead, they'd > rather hire "experienced" Java programmers who need to undergo full > security clearance investigations AND be taught what the program does -- > rather than bring in someone whose clearance could probably be > reactivated with a short update, knows the program, and had some ability > with multiple languages (if a master of only one). This reality of the market place ( managers want new hires with "current* " skills ) is one reason that many excelelnt niche languages ( Ada, Smalltalk Eiffel ) are in a slow death spiral. *current: whatever new language/technology the manager heard about at lunch. At the moment it is C#... There is a large and growing market for C# programmers. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 17:29 ` Marin David Condic 2004-05-29 17:40 ` Ed Falis 2004-05-29 17:48 ` Wes Groleau @ 2004-05-30 7:50 ` Pascal Obry 2004-05-31 12:25 ` Marin David Condic 2004-06-02 16:45 ` Warren W. Gay VE3WWG 2 siblings, 2 replies; 82+ messages in thread From: Pascal Obry @ 2004-05-30 7:50 UTC (permalink / raw) Marin David Condic <nobody@noplace.com> writes: > Mostly, its because I think it is a complete waste of time to look at jobs > going to C++ and opine over how they rightly should be done in Ada. What are > we doing to get Ada *into* those jobs? What are you doing :) ? > is what is "popular", right? Idiots like that ought to be *easy* to > out-compete on the bidding of the jobs - if Ada really produces that much > extra leverage. We'll be knee deep in $$$ by noon tomorrow, right? Or is our > confidence in Ada's superiority not so high? That's not so easy. I've seen lot of project managers chosing C++ even if they knew that Ada was cheaper/safer. As I said that's not so easy... This is political, choising a technology that everybody uses can't be something that we'll be reproached to you if the project is not on schedule/budget! I think we have already debated about this, nothing have changed and it is still very very hard (impossible?) to win this battle :( Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-30 7:50 ` Pascal Obry @ 2004-05-31 12:25 ` Marin David Condic 2004-06-02 16:45 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 82+ messages in thread From: Marin David Condic @ 2004-05-31 12:25 UTC (permalink / raw) Pascal Obry wrote: > > What are you doing :) ? > Like I said elsewhere: I'm in a position to use Ada internally and sell it on projects. Some of my customers already use Ada and I try to keep it sold. (Increasingly difficult to get them to keep spitting into the wind.) Where I've got potentially new customers, I try to get Ada in there. In any event, I hire people who use Ada on a daily basis so I think I'm doing *my* part for the cause. ;-) > > That's not so easy. I've seen lot of project managers chosing C++ even if > they knew that Ada was cheaper/safer. As I said that's not so easy... This is > political, choising a technology that everybody uses can't be something that > we'll be reproached to you if the project is not on schedule/budget! > > I think we have already debated about this, nothing have changed and it is > still very very hard (impossible?) to win this battle :( > The mistake here is to keep trying to sell to the people who keep saying "No!" They don't want it. They're not interested in it. They're not going to buy it. Move on. I'd contend that they're not just a batch of idiots and that there are often compelling reasons why they go down the path they choose. But if I concede the point and (for the sake of argument) agree that they're all a bunch of idiots with no vision, then what's the answer from there? Quit trying to convince them and do an end-run around them! Perhaps we're not big enough to become the prime contractor on some sophisticated airborne radar or whatever is being done by LockMart, et al. But that doesn't mean that there aren't potential projects that have some significant software in them wherein Ada would have a technical advantage. So long as everyone keeps thinking like a defense contractor ("I've got to wait until the government specifies Ada in a project...") it is *NEVER* going to happen. As soon as some Ada advocates start thinking like entrepreneurs ("I've got an idea for some end-product that would be superior and would cost less to do in Ada...") then we stand a chance. Let's quit crying over the fact that LockMart, Boeing, et al, don't want to use Ada and go figure out who *does* want to use it. (Hint: That would be us.) If those guys (us) go off and build some end product of some sort and successfully sell it, sooner or later it starts spilling over into the LockMart/Boeing/etc. world. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-30 7:50 ` Pascal Obry 2004-05-31 12:25 ` Marin David Condic @ 2004-06-02 16:45 ` Warren W. Gay VE3WWG 2004-06-02 17:48 ` Martin Dowie 2004-06-03 0:09 ` Marin David Condic 1 sibling, 2 replies; 82+ messages in thread From: Warren W. Gay VE3WWG @ 2004-06-02 16:45 UTC (permalink / raw) Pascal Obry wrote: > Marin David Condic <nobody@noplace.com> writes: >>Mostly, its because I think it is a complete waste of time to look at jobs >>going to C++ and opine over how they rightly should be done in Ada. What are >>we doing to get Ada *into* those jobs? ... > That's not so easy. I've seen lot of project managers chosing C++ even if > they knew that Ada was cheaper/safer. As I said that's not so easy... This is > political, choising a technology that everybody uses can't be something that > we'll be reproached to you if the project is not on schedule/budget! It is an even tougher sell on the business side, where it is rarely seen (I know that it is used in business, but perhaps more on the European continent). When I once tried promoting it, the studies/findings about Ada results didn't matter. I got the quiet in the hall hushed remarks such as "Couldn't you suggest something a little more main stream? Ada? Is there nothing more modern that you would recommend? Can you still hire people that use this Ada?" With responses/questions like these, you know that your chances are going to be slim, at best. Eventually, the project never materialized, but I found it interesting to measure the responses. The problem may be more prevalent in Canada. There seems to be a low awareness level of what Ada is, let alone knowing anyone who uses it. If you are considering buying a strange brand of car for example, people like the comfort of knowing someone that owns it (even if from afar). Within Toronto, I think only XWave has been known to offer Ada jobs, for testing of flight systems (IIRC). If the Ada position is lower paying as well, then guess what wins the order of the day for the programming career choice! -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-02 16:45 ` Warren W. Gay VE3WWG @ 2004-06-02 17:48 ` Martin Dowie 2004-06-03 15:57 ` Warren W. Gay VE3WWG 2004-06-03 0:09 ` Marin David Condic 1 sibling, 1 reply; 82+ messages in thread From: Martin Dowie @ 2004-06-02 17:48 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:junvc.97793$tb4.3987814@news20.bellglobal.com... > If the Ada position is lower paying as well, then guess > what wins the order of the day for the programming > career choice! Wouldn't your bosses be interested to hear that they can pay less with better results? :-) ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-02 17:48 ` Martin Dowie @ 2004-06-03 15:57 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 82+ messages in thread From: Warren W. Gay VE3WWG @ 2004-06-03 15:57 UTC (permalink / raw) Martin Dowie wrote: > "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message > news:junvc.97793$tb4.3987814@news20.bellglobal.com... > >>If the Ada position is lower paying as well, then guess >>what wins the order of the day for the programming >>career choice! > > Wouldn't your bosses be interested to hear that they can pay less with > better results? :-) All I can publicly state, was that they were "not my bosses", and that the cost savings seemed to be a lower priority. To them, something "old/unusual" was a high risk. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-02 16:45 ` Warren W. Gay VE3WWG 2004-06-02 17:48 ` Martin Dowie @ 2004-06-03 0:09 ` Marin David Condic 2004-06-03 1:08 ` Ed Falis 1 sibling, 1 reply; 82+ messages in thread From: Marin David Condic @ 2004-06-03 0:09 UTC (permalink / raw) Like I said: If Ada is going to find its way into applications, its going to be because *we* put it there. Trying to persuade those who don't see the advantages isn't and hasn't been working too well. The answer is to develop products that find their way into popular use with Ada inside. MDC Warren W. Gay VE3WWG wrote: > > It is an even tougher sell on the business side, where it > is rarely seen (I know that it is used in business, but > perhaps more on the European continent). When I once tried > promoting it, the studies/findings about Ada results > didn't matter. I got the quiet in the hall hushed remarks > such as "Couldn't you suggest something a little more > main stream? Ada? Is there nothing more modern that > you would recommend? Can you still hire people > that use this Ada?" With responses/questions like > these, you know that your chances are going to be slim, > at best. Eventually, the project never materialized, > but I found it interesting to measure the responses. > > The problem may be more prevalent in Canada. There > seems to be a low awareness level of what Ada is, let > alone knowing anyone who uses it. If you are considering > buying a strange brand of car for example, people like > the comfort of knowing someone that owns it (even if > from afar). Within Toronto, I think only XWave > has been known to offer Ada jobs, for testing > of flight systems (IIRC). > > If the Ada position is lower paying as well, then guess > what wins the order of the day for the programming > career choice! -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-03 0:09 ` Marin David Condic @ 2004-06-03 1:08 ` Ed Falis 2004-06-03 12:06 ` Marin David Condic 0 siblings, 1 reply; 82+ messages in thread From: Ed Falis @ 2004-06-03 1:08 UTC (permalink / raw) On Thu, 03 Jun 2004 00:09:06 GMT, Marin David Condic <nobody@noplace.com> wrote: > Like I said: If Ada is going to find its way into applications, its > going to be because *we* put it there. Trying to persuade those who > don't see the advantages isn't and hasn't been working too well. The > answer is to develop products that find their way into popular use with > Ada inside. I don't get it Marin (well, actually I do). I presented a certain amount of evidence that on the program in question, that started this thread, Ada will be used fairly widely, for good program management reasons. Yet you keep repeating that it's not happening, hasn't happened, won't happen. What gives? Have you got so caught up on the soapbox that you don't see where Ada is reasonably successful, because of the places it's not? You and I know each other for a lot of years, and understand each other to be fairly reasonable people, right? So why ignore reality in this case for the sake of ideology? - Ed ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-03 1:08 ` Ed Falis @ 2004-06-03 12:06 ` Marin David Condic 2004-06-03 12:33 ` Ed Falis ` (3 more replies) 0 siblings, 4 replies; 82+ messages in thread From: Marin David Condic @ 2004-06-03 12:06 UTC (permalink / raw) I don't deny that Ada is being used. After all, I'm using it. ;-) Sure its out there, but any reasonable assessment of the situation is going to conclude that at best Ada is a niche language. The bulk of software development is being done in some other language besides Ada. This is a shame since Ada is such a good language that it ought to survive, flourish and have a much broader appeal. But so long as it only has this little corner of the market, it is in danger of drying up and blowing away. You've seen the comments by other folks here who have tried to persuade their bosses that Ada is the right answer. The reaction is either "Not *that* dead, old, failure!" or "What's Ada???" The only way Ada gets around that problem is by finding a wider market and having a wider appeal. It dies otherwise. Slowly, to be sure, but ultimately it dies. Do you want to see that happen? I don't. I'd like to see it flourish so my job skills don't become an anachronism. :-) For Ada to get over that difficulty of mental perceptions on the part of too many language choosers, (or their legitimate concerns about tying their project to something that might be on the way out) it needs to build a larger base. How would *you* suggest that happen? (Or would you suggest that it doesn't need to happen? Or would you suggest that Ada is having a Renaissance and new customers are flocking to the door? I'd like to see some evidence of thousands of new products being built in Ada and hundreds of thousands of new programming jobs going to Ada - but check the want ads. Its not happening yet, is it?) To attract new users, Ada needs to do something to give them a reason to look at it seriously - like more leverage than they can get with Java or C++ or whatever else is the hip thing at the moment. To overcome the ocean of objections that get raised against it, Ada needs to show more commercial success - like when someone builds a product using Ada and successfully sells it. The commercial successes are critical or there isn't anybody out there to buy compilers and keep compiler writers alive and there isn't anybody out there to hire Ada programmers and encourage an interest in learning the language. That and I guess I've just become fed up with how we constantly hear things in this forum to the effect that "Ada is so obviously technically superior and is so obviously much more productive that managers who don't pick Ada are all just a bunch of idiots or they're downright corrupt and evil..." (Sounds a lot like the objections people raise against the politicians they don't like. "I'm so *obviously* right that anyone who disagrees with me *must* be stupid or evil.") Its time to put up or shut up - and the rest of the programming world knows it. We live in a free country with a free market. If Ada is so great then go out there and build something wonderful with it and out-compete the evil/stupid managers who won't see the sweet light of reason and pick the "obviously" superior technology? Or admit that Ada doesn't really bring enough leverage to the table to truly make a difference in the bottom line of a business. Or admit to a lack of enough courage and faith in the superiority of Ada to put some money and time on the line to prove it. So Ed, I'd guess I'd say to you that I know that Ada is being used in the 7E7 and elsewhere and I'm really glad that it has some market there. I'd like to see it have more of a market so it has long-term survival and prosperity prospects. But this thread got started with a complaint about how another stupid program manager went and picked C++ and it got me on my soapbox. Its time for people who believe in Ada's superiority to quit complaining about other people's choices and actually start *doing* something with it that builds real-world products that sell and make money. MDC Ed Falis wrote: > > I don't get it Marin (well, actually I do). I presented a certain > amount of evidence that on the program in question, that started this > thread, Ada will be used fairly widely, for good program management > reasons. Yet you keep repeating that it's not happening, hasn't > happened, won't happen. What gives? Have you got so caught up on the > soapbox that you don't see where Ada is reasonably successful, because > of the places it's not? > > You and I know each other for a lot of years, and understand each other > to be fairly reasonable people, right? So why ignore reality in this > case for the sake of ideology? > > - Ed -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-03 12:06 ` Marin David Condic @ 2004-06-03 12:33 ` Ed Falis 2004-06-03 16:44 ` Wes Groleau ` (2 subsequent siblings) 3 siblings, 0 replies; 82+ messages in thread From: Ed Falis @ 2004-06-03 12:33 UTC (permalink / raw) On Thu, 03 Jun 2004 12:06:26 GMT, Marin David Condic <nobody@noplace.com> wrote: > So Ed, I'd guess I'd say to you that I know that Ada is being used in > the 7E7 and elsewhere and I'm really glad that it has some market there. > I'd like to see it have more of a market so it has long-term survival > and prosperity prospects. But this thread got started with a complaint > about how another stupid program manager went and picked C++ and it got > me on my soapbox. Its time for people who believe in Ada's superiority > to quit complaining about other people's choices and actually start > *doing* something with it that builds real-world products that sell and > make money. I understand all your points. The reason I came back at you is that this program is an example of Ada being used for all the right reasons, from both a technical and a cost/value management perspective. Rather than acknowledging that "someone" must have done the groundwork, over a long period of time, to help achieve that success, you ignored it and went back on the soapbox. It's sort of like having a teacher who raps your knuckles for only getting a 99 on the test - after a while, you just tune out. - Ed ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-03 12:06 ` Marin David Condic 2004-06-03 12:33 ` Ed Falis @ 2004-06-03 16:44 ` Wes Groleau 2004-06-03 17:52 ` tmoran 2004-06-04 1:13 ` Jeffrey Carter 3 siblings, 0 replies; 82+ messages in thread From: Wes Groleau @ 2004-06-03 16:44 UTC (permalink / raw) Marin David Condic wrote: > folks here who have tried to persuade their bosses that Ada is the right > answer. The reaction is either "Not *that* dead, old, failure!" or :-) To which the solution is too often to use an OLDER failure (C) that's unfortunately still alive. -- Wes Groleau Even if you do learn to speak correct English, whom are you going to speak it to? -- Clarence Darrow ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-03 12:06 ` Marin David Condic 2004-06-03 12:33 ` Ed Falis 2004-06-03 16:44 ` Wes Groleau @ 2004-06-03 17:52 ` tmoran 2004-06-04 1:13 ` Jeffrey Carter 3 siblings, 0 replies; 82+ messages in thread From: tmoran @ 2004-06-03 17:52 UTC (permalink / raw) Two (unfortunate) data points: I got an email ACM Queue subscriber survey the other day. Under "languages used" I had to use Other and fill in Ada. Then Queue magazine arrived with an article on security and programming languages. It says "Remember Ada? What a disaster!" and then goes on to suggest things like turning on compiler warnings and having automatically inserted code to check for memory usage errors in C .. C# code. Sigh. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-03 12:06 ` Marin David Condic ` (2 preceding siblings ...) 2004-06-03 17:52 ` tmoran @ 2004-06-04 1:13 ` Jeffrey Carter 2004-06-04 11:27 ` Marin David Condic 2004-06-06 21:37 ` Leon Winslow 3 siblings, 2 replies; 82+ messages in thread From: Jeffrey Carter @ 2004-06-04 1:13 UTC (permalink / raw) Marin David Condic wrote: > The bulk of software > development is being done in some other language besides Ada. Right. More SW is developed in COBOL than any other language. "COBOL? Not *that* dead, old failure!" -- Jeff Carter "This trial is a travesty. It's a travesty of a mockery of a sham of a mockery of a travesty of two mockeries of a sham. ... Do you realize there's not a single homosexual on that jury?" Bananas 27 ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-04 1:13 ` Jeffrey Carter @ 2004-06-04 11:27 ` Marin David Condic 2004-06-04 18:38 ` Jeffrey Carter 2004-06-06 21:37 ` Leon Winslow 1 sibling, 1 reply; 82+ messages in thread From: Marin David Condic @ 2004-06-04 11:27 UTC (permalink / raw) I'd question that statistic. "Developed" as in "Developed today on new program starts?" or "Developed" as in "Historically since the beginning of computer languages, more programs have been developed in..." Guess it depends on what the meaning of the word "is" is... ;-) I'd also disagree with characterizing Cobol as a "failure" when in its day it succeeded in capturing nearly *all* of the business programming market. Did Ada capture nearly *all* of the embedded programming market? I like Ada, but if the definition of "success" is "achieving the stated goal" and the original stated goal of Ada was to address the embedded market, someone could make a fair case that capturing less than 1% of that market might just qualify as a "failure" by a reasonably objective standard. Or can anyone/anything be a success just by setting the bar low enough? MDC Jeffrey Carter wrote: > > > Right. More SW is developed in COBOL than any other language. > > "COBOL? Not *that* dead, old failure!" > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-04 11:27 ` Marin David Condic @ 2004-06-04 18:38 ` Jeffrey Carter 0 siblings, 0 replies; 82+ messages in thread From: Jeffrey Carter @ 2004-06-04 18:38 UTC (permalink / raw) Marin David Condic wrote: > I'd question that statistic. "Developed" as in "Developed today on new > program starts?" or "Developed" as in "Historically since the beginning > of computer languages, more programs have been developed in..." Guess it > depends on what the meaning of the word "is" is... ;-) Question all you want. How about "developed" as in being used by developers today? It may be modifications to existing programs, but more developers are being paid to use COBOL than any other language. > I'd also disagree with characterizing Cobol as a "failure" when in its > day it succeeded in capturing nearly *all* of the business programming > market. Did Ada capture nearly *all* of the embedded programming market? > I like Ada, but if the definition of "success" is "achieving the stated > goal" and the original stated goal of Ada was to address the embedded > market, someone could make a fair case that capturing less than 1% of > that market might just qualify as a "failure" by a reasonably objective > standard. Or can anyone/anything be a success just by setting the bar > low enough? Ada's goal was to be used for embedded weapon SW for the US DOD. In its heyday, it captured far more than 1% of that market, assisted by the mandate. I guess by your definition Ada was a success. COBOL wasn't a failure. I was simply quoting your own words about Ada in an attempt at humor. It's because of its success that COBOL is so widely used today. Businesses that have a lot of SW in COBOL don't want to have SW in a lot of different languages, so they stick with COBOL. In that they are smarter than the DOD is today. -- Jeff Carter "So if I understand 'The Matrix Reloaded' correctly, the Matrix is basically a Microsoft operating system--it runs for a while and then crashes and reboots. By design, no less. Neo is just a memory leak that's too hard to fix, so they left him in ... The users don't complain because they're packed in slush and kept sedated." Marin D. Condic 65 ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-04 1:13 ` Jeffrey Carter 2004-06-04 11:27 ` Marin David Condic @ 2004-06-06 21:37 ` Leon Winslow 2004-06-07 11:08 ` I R T 2004-06-07 11:19 ` 7E7 Flight Controls Electronics Marin David Condic 1 sibling, 2 replies; 82+ messages in thread From: Leon Winslow @ 2004-06-06 21:37 UTC (permalink / raw) Jeffrey Carter wrote: > Marin David Condic wrote: > > > The bulk of software > > development is being done in some other language besides Ada. > > Right. More SW is developed in COBOL than any other language. > > "COBOL? Not *that* dead, old failure!" > There is an irony here that most people might not appreciate. COBOL was the first language mandated by the federal government. I don't know if Ada was the second or there were one or more other languages in between these two. Some interesting questions might be: Why was one more widely used than the other. What did the government do differently with COBOL and Ada and what effect did it have? Lee Winslow ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-06 21:37 ` Leon Winslow @ 2004-06-07 11:08 ` I R T 2004-06-08 2:22 ` Richard Riehle 2004-06-07 11:19 ` 7E7 Flight Controls Electronics Marin David Condic 1 sibling, 1 reply; 82+ messages in thread From: I R T @ 2004-06-07 11:08 UTC (permalink / raw) Leon Winslow <leon.winslow@notes.udayton.edu> writes: > There is an irony here that most people might not appreciate. COBOL was > the first language mandated by the federal government. I don't know if > Ada was the second or there were one or more other languages in between > these two. > > Some interesting questions might be: Why was one more widely used than > the other. Association with the military was the kiss of death as far as many developers were concerned. COBOL also had the benefit of backing by IBM. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-07 11:08 ` I R T @ 2004-06-08 2:22 ` Richard Riehle 2004-06-08 9:07 ` I R T ` (3 more replies) 0 siblings, 4 replies; 82+ messages in thread From: Richard Riehle @ 2004-06-08 2:22 UTC (permalink / raw) "I R T" <rambam@bigpond.net.au> wrote in message news:oenv7hhc.fsf@pop-server.bigpond.net.au... > Association with the military was the kiss of death as far > as many developers were concerned. > > COBOL also had the benefit of backing by IBM. Actually, the story is a little different. I recall a large USAF project in the late 1960's where IBM was pushing PL/I, and pushing it hard. At that time, there were seven other mainframe companies that wanted to bid on the contract, but only CDC had anything like a useful PL/I compiler. The "Seven Dwarfs" spearheaded by Burroughs and Honeywell protested the PL/I requirement and persuaded the USAF to specify COBOL instead of PL/I. IBM, which intended to let COBOL die a slow death in favor of its own language, was forced to revive its COBOL effort. In the end, IBM did not win the contract. As I recall, it was won by Burroughs. IBM wanted COBOL gone. The only reason it kept it alive was to satisfy RFP requirements from the DoD. In time, COBOL became the dominant language for business data processing, even though IBM continued to insist on the superiority of PL/I. The fact is that PL/I was a superior language. However, it was so dramatically different in look and feel from the languages it was intended to replace (Fortran and COBOL) that neither language user group found it attractive. If IBM had been successful with PL/I, there would probably never have been an Ada. The fundamental elements were already in PL/I, but it also had a lot of inherent flaws that needed to be rectified before it could be selected. BTW, the first Alsys Ada compiler was, if I recall correctly, written in PL/I. Ada was, and always has been, a far better language than PL/I, but PL/I could have been improved with a little effort and cooperation from IBM. However, PL/I, at that time, had already earned a widespread bad reputation, much as Ada has today. Overcoming a bad reputation for a language is almost impossible, even when the language has improved as much as contemporary Ada. I was in a meeting last week where someone commented, "The Chair of our computer science department believes the DoD has banned Ada." With this kind of misinformation as widespead as it is, we will have a difficult time digging Ada out of the hole it is now in. It has been suggested we rename the language. I think it is better to follow Marin's advice and simply build the best systems we can using it. Also, we need to counter the idiotic claims made in ACM's Queue magazine. Richard Riehle ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-08 2:22 ` Richard Riehle @ 2004-06-08 9:07 ` I R T 2004-06-08 11:33 ` Marin David Condic ` (2 subsequent siblings) 3 siblings, 0 replies; 82+ messages in thread From: I R T @ 2004-06-08 9:07 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> writes: > as it is, we will have a difficult time digging Ada out of the hole > it is now in. It has been suggested we rename the language. I Renaming Ada 200x would probably help to spark some interest. Right now, people go," Ada, Oh we know all about that <snigger>" when the truth is that they know sweet f*ck all about Ada. All they know is the usual folklore ( slow, clunky, old, obsolete, large, Pascal with COBOL bolted on etc ) Renaming the next version, would spark some interest, but would not by itself be enough to keep interest. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-08 2:22 ` Richard Riehle 2004-06-08 9:07 ` I R T @ 2004-06-08 11:33 ` Marin David Condic 2004-06-09 21:02 ` Robert I. Eachus 2004-06-11 16:51 ` 7E7 Flight Controls Electronics (COBOL Popularity) Warren W. Gay VE3WWG 3 siblings, 0 replies; 82+ messages in thread From: Marin David Condic @ 2004-06-08 11:33 UTC (permalink / raw) Thanks for the backup on that. ;-) To which I'd add this: We're better off not building more Ada software development tools. While that's not a bad thing, what Ada needs is more *end*user* apps where the end user doesn't care that it is written in Ada. They also need to make money in some manner. If Ada gets more tools, that's nice but it would be better for Ada to get more revenue-generating apps to support itself. Use Ada for some real-world end-user project and it starts creating a life of its own. MDC Richard Riehle wrote: > it is now in. It has been suggested we rename the language. I > think it is better to follow Marin's advice and simply build the > best systems we can using it. Also, we need to counter the > idiotic claims made in ACM's Queue magazine. -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-08 2:22 ` Richard Riehle 2004-06-08 9:07 ` I R T 2004-06-08 11:33 ` Marin David Condic @ 2004-06-09 21:02 ` Robert I. Eachus 2004-06-09 21:22 ` Ed Falis [not found] ` <28rfc01rhesdk2qt27krrr65nnk0n0kihc@4ax.com> 2004-06-11 16:51 ` 7E7 Flight Controls Electronics (COBOL Popularity) Warren W. Gay VE3WWG 3 siblings, 2 replies; 82+ messages in thread From: Robert I. Eachus @ 2004-06-09 21:02 UTC (permalink / raw) Richard Riehle wrote: > BTW, the first Alsys Ada compiler was, if I recall correctly, > written in PL/I. Ada was, and always has been, a far better > language than PL/I, but PL/I could have been improved with > a little effort and cooperation from IBM. However, PL/I, > at that time, had already earned a widespread bad reputation, > much as Ada has today. Overcoming a bad reputation for > a language is almost impossible, even when the language > has improved as much as contemporary Ada. Um, Honeywell delivered a prototype Green compiler to the DoD as part of the "fly off" between Red and Green. Also Honeywell Small Systems--or whatever the division was called that week--developed an Ada cross compiler that ran on Multics, and was written in PL/I, and targeted the Level 6/DPS 6 line of minicomputers. (I worked on that project for several years, mostly on the front-end.) AFAIK though, the first Alsys compiler was written in Ada. At one point was compiled with the DEC Ada compiler. Why? Why not? It saved some time in bootstraping, and eventually, like GNAT it was self-hosting with multiple potential target architectures. -- Robert I. Eachus "The terrorists rejoice in the killing of the innocent, and have promised similar violence against Americans, against all free peoples, and against any Muslims who reject their ideology of murder. Their barbarism cannot be appeased, and their hatred cannot be satisfied. There's only one way to deal with terror: We must confront the enemy and stay on the offensive until these killers are defeated." -- George W. Bush ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-09 21:02 ` Robert I. Eachus @ 2004-06-09 21:22 ` Ed Falis 2004-06-09 23:30 ` Richard Riehle 2004-06-10 2:02 ` Jeffrey Carter [not found] ` <28rfc01rhesdk2qt27krrr65nnk0n0kihc@4ax.com> 1 sibling, 2 replies; 82+ messages in thread From: Ed Falis @ 2004-06-09 21:22 UTC (permalink / raw) On Wed, 09 Jun 2004 17:02:30 -0400, Robert I. Eachus <rieachus@comcast.net> wrote: > AFAIK though, the first Alsys compiler was written in Ada. At one point > was compiled with the DEC Ada compiler. Why? Why not? It saved some > time in bootstraping, and eventually, like GNAT it was self-hosting with > multiple potential target architectures. > A bootstrap compiler was written in PL/1. The real compiler was written in Ada. Alsys and Digital compiled each others' compilers as robustness tests. - Ed ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-09 21:22 ` Ed Falis @ 2004-06-09 23:30 ` Richard Riehle 2004-06-10 2:02 ` Jeffrey Carter 1 sibling, 0 replies; 82+ messages in thread From: Richard Riehle @ 2004-06-09 23:30 UTC (permalink / raw) Ed, Thanks for the clarification. I did recall that PL/I had a role in developing the first Alsys Ada compiler. Richard Riehle ================================================== "Ed Falis" <falis@verizon.net> wrote in message news:opr9ci0hug5afhvo@news.verizon.net... > On Wed, 09 Jun 2004 17:02:30 -0400, Robert I. Eachus > <rieachus@comcast.net> wrote: > > > AFAIK though, the first Alsys compiler was written in Ada. At one point > > was compiled with the DEC Ada compiler. Why? Why not? It saved some > > time in bootstraping, and eventually, like GNAT it was self-hosting with > > multiple potential target architectures. > > > > A bootstrap compiler was written in PL/1. The real compiler was written > in Ada. Alsys and Digital compiled each others' compilers as robustness > tests. > > - Ed ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-09 21:22 ` Ed Falis 2004-06-09 23:30 ` Richard Riehle @ 2004-06-10 2:02 ` Jeffrey Carter 2004-06-10 2:27 ` Ed Falis 1 sibling, 1 reply; 82+ messages in thread From: Jeffrey Carter @ 2004-06-10 2:02 UTC (permalink / raw) Ed Falis wrote: > > A bootstrap compiler was written in PL/1. The real compiler was > written in Ada. Alsys and Digital compiled each others' compilers as > robustness tests. I recall a presentation by Ichbiah in which he stated that the Alsys compiler was written in Ada, but initially compiled by a translation program that translated Ada to PL/1. -- Jeff Carter "My name is Jim, but most people call me ... Jim." Blazing Saddles 39 ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-10 2:02 ` Jeffrey Carter @ 2004-06-10 2:27 ` Ed Falis 2004-06-10 19:54 ` Jeffrey Carter 0 siblings, 1 reply; 82+ messages in thread From: Ed Falis @ 2004-06-10 2:27 UTC (permalink / raw) On Thu, 10 Jun 2004 02:02:42 GMT, Jeffrey Carter <spam@spam.com> wrote: > Ed Falis wrote: >> A bootstrap compiler was written in PL/1. The real compiler was >> written in Ada. Alsys and Digital compiled each others' compilers as >> robustness tests. > > I recall a presentation by Ichbiah in which he stated that the Alsys > compiler was written in Ada, but initially compiled by a translation > program that translated Ada to PL/1. > Actually, that's more accurate than my statement. A subset of Ada was set, translated into PL/1, then compiled. But the use of this thing was about finished when I joined Alsys in '83. Memory gets fuzzy after a while. ;-) - Ed ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-10 2:27 ` Ed Falis @ 2004-06-10 19:54 ` Jeffrey Carter 0 siblings, 0 replies; 82+ messages in thread From: Jeffrey Carter @ 2004-06-10 19:54 UTC (permalink / raw) Ed Falis wrote: > Actually, that's more accurate than my statement. A subset of Ada was > set, translated into PL/1, then compiled. But the use of this thing > was about finished when I joined Alsys in '83. Memory gets fuzzy after > a while. ;-) Right. Once the compiler could compile itself, the translation to PL/1 was no longer needed or used. -- Jeff Carter "That was the most fun I've ever had without laughing." Annie Hall 43 ^ permalink raw reply [flat|nested] 82+ messages in thread
[parent not found: <28rfc01rhesdk2qt27krrr65nnk0n0kihc@4ax.com>]
* Re: non sequitur [not found] ` <28rfc01rhesdk2qt27krrr65nnk0n0kihc@4ax.com> @ 2004-06-12 3:01 ` Robert I. Eachus 0 siblings, 0 replies; 82+ messages in thread From: Robert I. Eachus @ 2004-06-12 3:01 UTC (permalink / raw) Dennis Lee Bieber wrote: > My condolences <G> Why? When we were validating the Ada compiler, I spent some time doing tuning on a 9x system (DPS6-96 I think). But aside from that I did all my development work on Multics. I really feel sorry for anyone who had to use a Level-6 or DPS-6 system running Mod 400 that one of a (very) few people hadn't set up for doing so. The 'normal' settings of Mod 400 made it dog slow as a development system. I went out to Minneapolis to help do that for the system some Ada people used. If you knew which parameters to twiddle you could get impressive performance out of Mod 400. We ran the entire Ada validation suite in around 4 hours on the 9x system, and we ran it on the whole line during the official validation, although it took a lot longer on the DPS-6/22 and /3x machines. > It worked nicely -- until it got warm. Then the circuit card > would sag, breaking contact with the edge connectors, and leaving the > mainframe thinking it had idle connections on one side, and lots of > terminals thinking they had slow connections on the other... It sounds like the Level 6 you had was installed outside a climate controlled environment. When Honeywell had some initial problems on a system for the Navy, they found out that probably 95% of Level 6 systems were installed in the same room as a climate-controlled mainframe. If you had one of what we called the 5x series processors, you could have exactly that problem. The DPS-6 system that replaced it was fine, but for the 9x systems climate control was made a requirement. (Of course, they were really 32-bit mainframes with the 16-bit Level-6/DPS-6 instruction set supported, about equivalent to a VAX 11/785.) A couple of other funny (or nasty now) stories. When we did the Ada compiler validation, we were the first people _ever_ to run a DPS6 or Level 6 machine under Mod 400 24/7 for more than a week. We know this because we found several memory leaks in Mod 400 and patched them. One particularly nasty leak would lose 2 bytes of physical memory each time a new process was started. I particularly remember that one, because I had to turn the patch in on punched cards! (Three of them.) The last time I ever used a card punch, and the only time during my 5 years at Honeywell. One other "high priority" project for the Ada group was to get the process for submitting software to Testing and Configuration moved into the modern era. The first program submitted that was written in Ada came back with two complaints: No copyright string in the executable, and no area reserved for patches! We added two pragmas to the compiler, but by the time I left, we had killed the patch area requirement for products written in high-level languages, and OS patches could be submitted on floppy disk, among other things. -- Robert I. Eachus The ideology he opposed throughout his political life insisted that history was moved by impersonal tides and unalterable fates. Ronald Reagan believed instead in the courage and triumph of free men and we believe it all the more because we saw that courage in him. -- George W. Bush June 11, 2004 ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics (COBOL Popularity) 2004-06-08 2:22 ` Richard Riehle ` (2 preceding siblings ...) 2004-06-09 21:02 ` Robert I. Eachus @ 2004-06-11 16:51 ` Warren W. Gay VE3WWG 2004-06-11 17:18 ` Marin David Condic ` (2 more replies) 3 siblings, 3 replies; 82+ messages in thread From: Warren W. Gay VE3WWG @ 2004-06-11 16:51 UTC (permalink / raw) Richard Riehle wrote: > "I R T" <rambam@bigpond.net.au> wrote in message > news:oenv7hhc.fsf@pop-server.bigpond.net.au... > >>Association with the military was the kiss of death as far >>as many developers were concerned. >> >>COBOL also had the benefit of backing by IBM. > ... > IBM wanted COBOL gone. The only reason it kept it alive > was to satisfy RFP requirements from the DoD. In time, COBOL > became the dominant language for business data processing, even > though IBM continued to insist on the superiority of PL/I. ... > Richard Riehle One of the areas that COBOL was very successful in (and still), is providing the necessary facilities to perform business functions. While it may seem trivial, the need to format numeric values (particularly monetary values) in a picture format is so prevalent, that it becomes a major pain to use other languages that don't conveniently provide this. Imagine trying to report picture clauses in C# or Java? Sure, everyone can write their own objects/routines to do this, but many business shops have people that are not as motivated or organized. The need is so basic, that people expect the platform to provide this. Ada provides for this, but IIRC it is limited to only decimal types (which is a pain). It would be nice to see more support for this in Ada, to make easy to do from floating point or other numeric types (even integers). Of course, I am sure there were many other factors that played into the popular use of COBOL besides this. I've forgotten any COBOL I once knew, but I seem to remember that having builtin support of Indexed files etc. to be a great asset to business. PL/I had a number of whizbang features (for the time), but they didn't exactly pander to the real business needs (I don't recall if the full PL/I language supported the picture formatting or not). Certainly one of PL/I's downfalls, was the shear size of the language, for the time. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics (COBOL Popularity) 2004-06-11 16:51 ` 7E7 Flight Controls Electronics (COBOL Popularity) Warren W. Gay VE3WWG @ 2004-06-11 17:18 ` Marin David Condic 2004-06-11 18:49 ` Richard Riehle 2004-06-11 21:05 ` Frank J. Lhota 2 siblings, 0 replies; 82+ messages in thread From: Marin David Condic @ 2004-06-11 17:18 UTC (permalink / raw) Picture representations are only a type conversion away. :-) Much of the picture features are just naturally geared to something with a fixed decimal point - especially since it usually has to do with money and so forth. But at least it isn't too hard to have some fixed-size numeric thing and just convert integers, etc to it for when you want pictures. Still, its always a nice thing to have for the sake of convenience... MDC Warren W. Gay VE3WWG wrote: > > Ada provides for this, but IIRC it is limited to only > decimal types (which is a pain). It would > be nice to see more support for this in Ada, to make > easy to do from floating point or other > numeric types (even integers). > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics (COBOL Popularity) 2004-06-11 16:51 ` 7E7 Flight Controls Electronics (COBOL Popularity) Warren W. Gay VE3WWG 2004-06-11 17:18 ` Marin David Condic @ 2004-06-11 18:49 ` Richard Riehle 2004-06-11 19:07 ` Marin David Condic 2004-06-11 20:39 ` Warren W. Gay VE3WWG 2004-06-11 21:05 ` Frank J. Lhota 2 siblings, 2 replies; 82+ messages in thread From: Richard Riehle @ 2004-06-11 18:49 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:Nplyc.52642$8k4.1169496@news20.bellglobal.com... > Richard Riehle wrote: > > > "I R T" <rambam@bigpond.net.au> wrote in message > > news:oenv7hhc.fsf@pop-server.bigpond.net.au... > > > >>Association with the military was the kiss of death as far > >>as many developers were concerned. > >> > >>COBOL also had the benefit of backing by IBM. > > > ... > > IBM wanted COBOL gone. The only reason it kept it alive > > was to satisfy RFP requirements from the DoD. In time, COBOL > > became the dominant language for business data processing, even > > though IBM continued to insist on the superiority of PL/I. > ... > > Richard Riehle > > One of the areas that COBOL was very successful in (and still), > is providing the necessary facilities to perform business > functions. While it may seem trivial, the need to format > numeric values (particularly monetary values) in a picture > format is so prevalent, that it becomes a major pain to > use other languages that don't conveniently provide this. You wrote this in reply to my note about the role of the DoD in the survival of COBOL. The events of the time, mentioned in my earlier post, were such that IBM had a virtual monopoly in the computer business, much the way Microsoft has today. At that time, the Federal Government was less inclined to accomodate that monopoly than is the current government. Therefore, a lot of effort was made to ensure that all qualified bidders were able to compete for contracts. For the USAF contract (as with many other contracts at this period of computing history) was originally specified for PL/I. IBM managed to get that requirement into a lot of Requests for Proposal. Protests from several vendors, as well as from the community at large, resulted in that requirement being replaced by COBOL. It was IBM's intention to replace both Fortran and COBOL with PL/I. If IBM had been successful, the history of computer programming languages would have been much different. PL/I was, in many respects, an improvement over COBOL and Fortran. However, IBM failed to manage its acceptance by the computing community -- much the way the DoD mismanaged the Ada initiative almost from the start. > Of course, I am sure there were many other factors that > played into the popular use of COBOL besides this. I've > forgotten any COBOL I once knew, but I seem to remember > that having builtin support of Indexed files etc. to be > a great asset to business. > The survival of COBOL is a complex story. Much of that story is political. Some of it is technological. Most of it is due to Newton's First Law of Motion. > PL/I had a number of whizbang features (for the time), > but they didn't exactly pander to the real business needs > (I don't recall if the full PL/I language supported the > picture formatting or not). Certainly one of PL/I's > downfalls, was the shear size of the language, for the > time. > PL/I did not look like COBOL to COBOL programmers and it did not look like Fortran to Fortran programmers. We all have had to experience of a programmer being resistant to some new language (e.g., Ada), not because it is a bad language design, but because it does not look like the language they are used to. Anyone who has tried to persuade a C programmer to consider Prolog, an Ada programmer to consider C++, a C++ programmer to consider Ada, or a Forth programmer to consider C, understands how this works. PL/I, though it had some small flaws in its original design, had all the elements needed to evolve into a better language than those in widespread use at the time. This is an Ada forum, so we might take notice of the lessons of PL/I when discussing Ada. In the case of PL/I, and large organization, IBM, tried to bully its customers into using a new and strange language to replace what they were already using. In the case of Ada, a large government agency tried to dictate the use of an equally strange and unfamiliar language. The people who actually develop software resisted, sometimes with malicious compliance, other times with outright defiance, and both the PL/I mandate and the Ada mandate failed. The failure had little to do with the relative virtues of the respective languages. It had much to do with the fact that human beings dislike being ordered to change their ways. Now that Ada must be a choice rather than fiat, we have the opportunity to persuade people to use it rather than mandate its use. The only way we can do that is through example. Those who believe it is a superior approach to software development need to prove it by building better software with it. Then they can announce their success with Ada. There is no other avenue for Ada's long-term success. No amount of preaching, complaining about someone else's stupidity, or managerial incompetence will garner a single iota of success. Only success will lead to success. Prove Ada by its fruits, not through declamation and oratory. Richard Riehle ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics (COBOL Popularity) 2004-06-11 18:49 ` Richard Riehle @ 2004-06-11 19:07 ` Marin David Condic 2004-06-11 20:39 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 82+ messages in thread From: Marin David Condic @ 2004-06-11 19:07 UTC (permalink / raw) I might add that it isn't just by being able to point at successful projects in Ada. Certainly through time, we've had any number of successful projects implemented in Ada. It should be obvious to anyone willing to look that Ada *can* be successfully employed. The real trick here is to make projects that are a *commercial* success - invent something that uses Ada and sell it successfully - because it is only through some kind of commercial success that jobs are created, revenues to compiler vendors are created, universities are encouraged to teach Ada, etc. Unless it generates more revenues than expenses, what you've got is a hobby and hobbyist languages don't tend to fare well over the long run. MDC Richard Riehle wrote: > > Now that Ada must be a choice rather than fiat, we have the opportunity > to persuade people to use it rather than mandate its use. The only way > we can do that is through example. Those who believe it is a superior > approach to software development need to prove it by building better > software with it. Then they can announce their success with Ada. There > is no other avenue for Ada's long-term success. No amount of preaching, > complaining about someone else's stupidity, or managerial incompetence > will garner a single iota of success. Only success will lead to success. > Prove > Ada by its fruits, not through declamation and oratory. > > Richard Riehle > > > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics (COBOL Popularity) 2004-06-11 18:49 ` Richard Riehle 2004-06-11 19:07 ` Marin David Condic @ 2004-06-11 20:39 ` Warren W. Gay VE3WWG 2004-06-12 11:16 ` Georg Bauhaus 1 sibling, 1 reply; 82+ messages in thread From: Warren W. Gay VE3WWG @ 2004-06-11 20:39 UTC (permalink / raw) Richard Riehle wrote: > "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message > news:Nplyc.52642$8k4.1169496@news20.bellglobal.com... >>Richard Riehle wrote: >>>"I R T" <rambam@bigpond.net.au> wrote in message >>>news:oenv7hhc.fsf@pop-server.bigpond.net.au... >>... >>>Richard Riehle >> >>One of the areas that COBOL was very successful in (and still), >>is providing the necessary facilities to perform business >>functions. While it may seem trivial, the need to format >>numeric values (particularly monetary values) in a picture >>format is so prevalent, that it becomes a major pain to >>use other languages that don't conveniently provide this. > > You wrote this in reply to my note about the role of the > DoD in the survival of COBOL. The events of the time, > mentioned in my earlier post, were such that IBM had > a virtual monopoly in the computer business, much the > way Microsoft has today. At that time, the Federal > Government was less inclined to accomodate that > monopoly than is the current government. Therefore, a > lot of effort was made to ensure that all qualified bidders > were able to compete for contracts. I wasn't trying to refute/correct/amend the political history as you have laid it out. I was only making a more general comment on COBOL on the basis of its technical merits, which may, as you seem to suggest, have had very little to do with its acceptance. If that is what is being said, I won't argue it. To return to my earlier comment (in a general way), much of today's software seems to overlook things that are so essential for business use. Picture formatting was one example of something that frequently comes up. If I were to make a flying leap and guess, I would say that neither Java, nor C# have a standard routine to do this for the programmer (someone please correct me if there is a 'standard way' to do this in either/both of these). > PL/I did not look like COBOL to COBOL programmers and it > did not look like Fortran to Fortran programmers. In the early 70s, I was using an IBM-1130 with FORTRAN. We also had a compiler known as SL/I (Student Language/I), which was obviously a PL/I subset, though I did not know it at the time. And yes, to a then FORTRAN programer, it sure _DID_ look different (but I loved it at the time). I personally didn't meet up with COBOL, until I met the IBM-360. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics (COBOL Popularity) 2004-06-11 20:39 ` Warren W. Gay VE3WWG @ 2004-06-12 11:16 ` Georg Bauhaus 0 siblings, 0 replies; 82+ messages in thread From: Georg Bauhaus @ 2004-06-12 11:16 UTC (permalink / raw) Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote: : If I were to make a flying leap and : guess, I would say that neither Java, nor C# have : a standard routine to do this for the programmer For Java, there is a NumberFormat class (hierarchy) which uses format strings. Quite flexible, we used them for amounts of money in Swiss notation which uses ' as a group separator. Floats in Java is another story though. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics (COBOL Popularity) 2004-06-11 16:51 ` 7E7 Flight Controls Electronics (COBOL Popularity) Warren W. Gay VE3WWG 2004-06-11 17:18 ` Marin David Condic 2004-06-11 18:49 ` Richard Riehle @ 2004-06-11 21:05 ` Frank J. Lhota 2004-06-14 12:46 ` Warren W. Gay VE3WWG 2 siblings, 1 reply; 82+ messages in thread From: Frank J. Lhota @ 2004-06-11 21:05 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:Nplyc.52642$8k4.1169496@news20.bellglobal.com... > PL/I had a number of whizbang features (for the time), > but they didn't exactly pander to the real business needs > (I don't recall if the full PL/I language supported the > picture formatting or not). Certainly one of PL/I's > downfalls, was the shear size of the language, for the > time. They certainly did. PL/1 was designed to fill the needs of both the COBOL and FORTRAN markets, so they incorporated the best features of both languages. The PL/1 record declarations were clearly modeled after their COBOL counterparts. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics (COBOL Popularity) 2004-06-11 21:05 ` Frank J. Lhota @ 2004-06-14 12:46 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 82+ messages in thread From: Warren W. Gay VE3WWG @ 2004-06-14 12:46 UTC (permalink / raw) Frank J. Lhota wrote: > "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message > news:Nplyc.52642$8k4.1169496@news20.bellglobal.com... > >>PL/I had a number of whizbang features (for the time), >>but they didn't exactly pander to the real business needs >>(I don't recall if the full PL/I language supported the >>picture formatting or not). Certainly one of PL/I's >>downfalls, was the shear size of the language, for the >>time. > > They certainly did. PL/1 was designed to fill the needs of both the COBOL > and FORTRAN markets, so they incorporated the best features of both > languages. The PL/1 record declarations were clearly modeled after their > COBOL counterparts. I know that you are citing record declarations as an example, but I didn't see enough evidence, IIRC, that it was business oriented enough in other ways. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-06 21:37 ` Leon Winslow 2004-06-07 11:08 ` I R T @ 2004-06-07 11:19 ` Marin David Condic 2004-06-07 22:24 ` Alexander E. Kopilovich 2004-06-09 6:31 ` Robert I. Eachus 1 sibling, 2 replies; 82+ messages in thread From: Marin David Condic @ 2004-06-07 11:19 UTC (permalink / raw) Cobol hit the world at a time when the only other programming language choices were Fortran and assembler. For those who had work that looked like business data processing, it was a no-brainer: There was nothing else that even remotely met their needs. Cobol suffered from lots of things like excessive verbosity and clumsy control structures, but it was either that or go use Fortran or assembler. Once it got established, there was no way to eradicate it. Ada, OTOH tried to address the needs of embedded systems programmers and missed the mark for a variety of reasons. Probably chief among them was that embedded programmers already had something - C - which was cheap and small and could be made to fit just about any processor - and was available for just about any microprocessor. Ada was huge and cost a fortune and couldn't be made to work for small microprocessors and was not available for most targets. Given that people had choices and Ada wasn't meeting their needs, mandate or not, they went elsewhere. The moral of the story: Find out what the customer wants/needs before you build a huge product and try to sell it to them. MDC Leon Winslow wrote: > > > There is an irony here that most people might not appreciate. COBOL was > the first language mandated by the federal government. I don't know if > Ada was the second or there were one or more other languages in between > these two. > > Some interesting questions might be: Why was one more widely used than > the other. What did the government do differently with COBOL and Ada > and what effect did it have? > > Lee Winslow > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-07 11:19 ` 7E7 Flight Controls Electronics Marin David Condic @ 2004-06-07 22:24 ` Alexander E. Kopilovich 2004-06-08 1:11 ` Marin David Condic 2004-06-08 2:35 ` Richard Riehle 2004-06-09 6:31 ` Robert I. Eachus 1 sibling, 2 replies; 82+ messages in thread From: Alexander E. Kopilovich @ 2004-06-07 22:24 UTC (permalink / raw) To: comp.lang.ada Marin David Condic wrote: > Cobol suffered from lots of > things like excessive verbosity and clumsy control structures, One of the most evident common things shared by COBOL and Ada was (and perhaps still is) widespread (among programmers) habit to talk about major drawbacks in these languages not knowing them and being induced mostly by own attitude towards the principal application domain (or the internal culture of that domain) for the language. I heard these arguments about excessive verbosity and clumsy control structures - countless times, and always that was said by people who don't understand and don't feel anything about processing of commercial data; most of those people also didn't know COBOL at all, but this is secondary - the primary issue is ignorance and deep dislike of the application domain, which is associated with the language. I used COBOL quite heavily in 80th and never thought that it is excessively verbose or that its control structures are clumsy. It was a language perfectly adequate to its principal application domain taken together with the state of hardware. I think that COBOL "suffered" from its features only in imagination of people who were not involved in real commercial data processing (or were involved, but hated their job for other reasons). Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-07 22:24 ` Alexander E. Kopilovich @ 2004-06-08 1:11 ` Marin David Condic 2004-06-08 2:35 ` Richard Riehle 1 sibling, 0 replies; 82+ messages in thread From: Marin David Condic @ 2004-06-08 1:11 UTC (permalink / raw) O.K. Just for the record, I did time as a COBOL programmer when I was first out of college, so I'm not speaking from either inexperience or ignorance. And I still think that it was both excessively verbose and had clumsy control structures. Others may like it and they are free to do so. I'll stand by my opinion that COBOL succeeded mostly because there was absolutely nothing better available at the time for business data processing - not because it was a shining example of a flawless language loved by all who were asked to use it. It succeeded amazingly well because neither Fortran nor assembler were well suited to the needs of business programming. Now that Ada has lots of support for things like decimal numbers and "picture" statements its harder to argue that COBOL is still the superior language for business data processing. ;-) MDC Alexander E. Kopilovich wrote: > > One of the most evident common things shared by COBOL and Ada was (and perhaps > still is) widespread (among programmers) habit to talk about major drawbacks > in these languages not knowing them and being induced mostly by own attitude > towards the principal application domain (or the internal culture of that > domain) for the language. > I heard these arguments about excessive verbosity and clumsy control > structures - countless times, and always that was said by people who don't > understand and don't feel anything about processing of commercial data; most > of those people also didn't know COBOL at all, but this is secondary - the > primary issue is ignorance and deep dislike of the application domain, which > is associated with the language. > I used COBOL quite heavily in 80th and never thought that it is excessively > verbose or that its control structures are clumsy. It was a language perfectly > adequate to its principal application domain taken together with the state of > hardware. > I think that COBOL "suffered" from its features only in imagination of > people who were not involved in real commercial data processing (or were > involved, but hated their job for other reasons). > > > > Alexander Kopilovich aek@vib.usr.pu.ru > Saint-Petersburg > Russia > > > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-07 22:24 ` Alexander E. Kopilovich 2004-06-08 1:11 ` Marin David Condic @ 2004-06-08 2:35 ` Richard Riehle 2004-06-08 6:59 ` tmoran 2004-06-09 1:32 ` Alexander E. Kopilovich 1 sibling, 2 replies; 82+ messages in thread From: Richard Riehle @ 2004-06-08 2:35 UTC (permalink / raw) "Alexander E. Kopilovich" <aek@VB1162.spb.edu> wrote in message news:mailman.71.1086647025.391.comp.lang.ada@ada-france.org... > I think that COBOL "suffered" from its features only in imagination of > people who were not involved in real commercial data processing (or were > involved, but hated their job for other reasons). COBOL, prior to the 1985 standard, was a dreadful language for structured programming. In fact, it was so horrible that I have no compunction in stating that true structured programming was almost impossible in the language. Even after the improvements in the 1985 standard, COBOL programmers continued to use the language in stupid ways. The ANSI-1985 standard added scope terminators to the IF, READ, and PERFORM statements, added an in-line PERFORM, added the powerful EVALUATE statement, and enabled subroutine calls by both value and reference. These and many other enhancements to the language were substantial improvements. However, most COBOL programmers took a long time to learn to use them. The COBOL EVALUATE statement is one of the most powerful constructs of any existing programming language. I wish we had something like it in Ada, but we don't. We must keep in mind that a large percentage of COBOL programmers were not blessed with a computer science degree. A large company would give its employees the IBM Programming Aptitude Test (PAT) and offer programming school to a few who got an A on that test. COBOL programmers more often than not were people who already understood the application domain and took their new knowledge of programming to that domain. Eventually, they might escape the company that trained them, but they would take the domain knowledge along with the programming skills to another similar domain when they changed jobs. The industry has changed since those early days. Now, we seldom train from within. The computer science graduate comes with a set of technological skills and no knowledge of the domain. Those skills are portable, as they were before, but we must educate that new programmer about the domain. I'm not sure that this is progress. Richard Riehle ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-08 2:35 ` Richard Riehle @ 2004-06-08 6:59 ` tmoran 2004-06-08 19:44 ` Wes Groleau 2004-06-09 1:32 ` Alexander E. Kopilovich 1 sibling, 1 reply; 82+ messages in thread From: tmoran @ 2004-06-08 6:59 UTC (permalink / raw) >more often than not were people who already understood >the application domain As a CS grad student in the late '60s I visited a cousin, who was some kind of manager. He had brought home a COBOL program one of his people had written and asked for help figuring out what it did. It was easy to teach him enough in an afternoon that he could follow (reasonable) code and tell if it was doing the right (application) thing. I've not seen another language where you could expect even a fighting chance of doing that. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-08 6:59 ` tmoran @ 2004-06-08 19:44 ` Wes Groleau 0 siblings, 0 replies; 82+ messages in thread From: Wes Groleau @ 2004-06-08 19:44 UTC (permalink / raw) tmoran@acm.org wrote: > kind of manager. He had brought home a COBOL program one of his people had > written and asked for help figuring out what it did. It was easy to teach > him enough in an afternoon that he could follow (reasonable) code and tell OTOH, someone once (a joke, I think) said: COBOL was invented so that managers could read programs. Instead, it only proved that managers do not read programs. -- Wes Groleau "Lewis's case for the existence of God is fallacious." "You mean like circular reasoning?" "He believes in God. Therefore, he's fallacious." ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-08 2:35 ` Richard Riehle 2004-06-08 6:59 ` tmoran @ 2004-06-09 1:32 ` Alexander E. Kopilovich 2004-06-09 6:23 ` Richard Riehle 2004-06-09 7:54 ` Dmitry A. Kazakov 1 sibling, 2 replies; 82+ messages in thread From: Alexander E. Kopilovich @ 2004-06-09 1:32 UTC (permalink / raw) To: comp.lang.ada Richard Riehle wrote: > COBOL, prior to the 1985 standard, was a dreadful language for > structured programming. In fact, it was so horrible that I have no > compunction in stating that true structured programming was almost > impossible in the language. Certainly you are using here the words "structured programming" as a special term, that is, in Dijkstra's sense. But that way of structuring programs is not the only possible way, and it is not generally best, that is, there are major application domains for which this way isn't the best. There are other ways for structured programming (in general sense), and COBOL was very well suited for some of them. For example, if you have ever read "Principles of Program Design" by Jackson, you may recall that JSP was quite happy with COBOL. Commercial data processing domain in those times required data-based (and not algorithm-based) structuring. Therefore "structured programming" in Dijkstra's sense was absolutely useless for most of applications in that domain, and can be even harmful indeed. > Even after the improvements in the 1985 >standard, COBOL programmers continued to use the language in >stupid ways. Well, there is a section in Dijstra's book "Discipline of Programming", in which the famous author fell into stupidity. It is the section, in which he tried to prove that "commercial" (commercial data processing) programming isn't different in any meaningful way from other kinds of programming (probably meaning scientific programming). The author honestly provided an example and finished with a complete program. Reading that program, and being an expert in that application domain (that time) I concluded that the program is very bad, it would be disaster to put that program on production line, and that this program must be completely rewritten. So that example in fact proved that commercial data processing is (was) different indeed. Several years after that, I read an article (I can't remember the title and the journal, but I think that the name of the author was Lucas or something like that) in which that difference was explained very clearly: in scientific programming the algorithms are eternal - a method for solving a certain kind of equations remains right forever; but in commercial data processing the algorithms are volatile - the rules for calculation of taxes are changed rather frequently. > The ANSI-1985 standard added scope terminators to the IF, READ, > and PERFORM statements, added an in-line PERFORM, added the > powerful EVALUATE statement, and enabled subroutine calls by > both value and reference. These and many other enhancements to > the language were substantial improvements. However, most > COBOL programmers took a long time to learn to use them. > > The COBOL EVALUATE statement is one of the most powerful > constructs of any existing programming language. I wish we had > something like it in Ada, but we don't. I remember that several years ago Robert Dewar remarked (here in comp.lang.ada or elsewhere) that the concept of "object" in current COBOL standard is more rich and complex than even in C++ (and certainly more rich and complex than in Ada). Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-09 1:32 ` Alexander E. Kopilovich @ 2004-06-09 6:23 ` Richard Riehle 2004-06-09 7:09 ` Martin Dowie 2004-06-10 1:41 ` Alexander E. Kopilovich 2004-06-09 7:54 ` Dmitry A. Kazakov 1 sibling, 2 replies; 82+ messages in thread From: Richard Riehle @ 2004-06-09 6:23 UTC (permalink / raw) "Alexander E. Kopilovich" <aek@VB1162.spb.edu> wrote in message news:mailman.75.1086745242.391.comp.lang.ada@ada-france.org... > Richard Riehle wrote: > > > COBOL, prior to the 1985 standard, was a dreadful language for > > structured programming. In fact, it was so horrible that I have no > > compunction in stating that true structured programming was almost > > impossible in the language. > > Certainly you are using here the words "structured programming" as a special > term, that is, in Dijkstra's sense. But that way of structuring programs is > not the only possible way, and it is not generally best, that is, there are > major application domains for which this way isn't the best. There are other > ways for structured programming (in general sense), and COBOL was very well > suited for some of them. For example, if you have ever read "Principles of > Program Design" by Jackson, you may recall that JSP was quite happy with > COBOL. Sorry, but COBOL was totally ill-suited to support of well-formed structures of any kind prior to ANSI-85. Take the horrible model for an IF statement as an example. Those of us who had to use this half-baked conditional formation recall how easily it led to programming mistakes. The addition of END-IF in ANSI-85 solved that problem. The fact that Jackson "was quite happy with COBOL" is simply an indication of the widespread stupidity regarding the shortcomings of the earlier forms of the language. No intelligent contemporary programmer would want to return to hideous mess of tangled code so typical of pre-ANSI-85. Structures, in the Dijkstra sense, was far more than "GO TO Considered Harmful." More important, though, are the elementary control structures of Jacopini and Bohm which, when properly formed, will include scope terminators such as ANSI-85, END-PERFORM, END-READ, END-IF, etc, without which the resulting code is usually a mess. I have written and maintained code written by others, in COBOL 68, 74, and 85. I would never want to do anything in 68 or 74 again. In my view, COBOL, prior to the ANSI-85 standard was not "very well suited" for writing maintainable, dependable, well-structured code, in the Dijkstra sense, the Jackson sense, the Jacopini and Bohm sense, or in any other sense. Since the ANSI-85 standard, COBOL has become one of the most interesting languages around. It has corrected the silliness of the earlier standards, and can be used as effectively for creating maintainabl software as well any of the competing technologies -- when used by a competent programmer. The same could not be said of the earlier standards, where the code so often evolved into a "pile of dry rot held up by a flying buttress." Richard Riehle ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-09 6:23 ` Richard Riehle @ 2004-06-09 7:09 ` Martin Dowie 2004-06-10 1:41 ` Alexander E. Kopilovich 1 sibling, 0 replies; 82+ messages in thread From: Martin Dowie @ 2004-06-09 7:09 UTC (permalink / raw) "Richard Riehle" <adaworks@earthlink.net> wrote in message news:x1yxc.7635$uX2.6317@newsread2.news.pas.earthlink.net... > The fact that Jackson "was quite happy with COBOL" is simply an indication > of the widespread stupidity regarding the shortcomings of the earlier forms > of the language. No intelligent contemporary programmer would want to > return to hideous mess of tangled code so typical of pre-ANSI-85. There was also the point that there were JSP tools that automated the generation of all the control structures. Once the data structures were drawn, all the 'programmer' was left to do was fill in the sequential statements, the branch conditions and the loop termination conditions and BINGO an executable appeared. -- Martin ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-09 6:23 ` Richard Riehle 2004-06-09 7:09 ` Martin Dowie @ 2004-06-10 1:41 ` Alexander E. Kopilovich 2004-06-10 6:13 ` Richard Riehle 1 sibling, 1 reply; 82+ messages in thread From: Alexander E. Kopilovich @ 2004-06-10 1:41 UTC (permalink / raw) To: comp.lang.ada Richard Riehle wrote: > > There are other > > ways for structured programming (in general sense), and COBOL was very well > > suited for some of them. For example, if you have ever read "Principles of > > Program Design" by Jackson, you may recall that JSP was quite happy with > > COBOL. > > Sorry, but COBOL was totally ill-suited to support of well-formed structures > of any kind prior to ANSI-85. COBOL (even 66) was very well suited to support of well-formed *data* structures. As for control structures, oh yes, it did not provide blocks (FORTRAN IV also did not provide them - was that FORTRAN stupid also?), and I think it was right choice, PERFORM statements were better in those circumstances. > Take the horrible model for an IF statement as an example. Hm, what was so horrible there? I have no bad recollections of that IF. > Those of us who had to use this half-baked conditional > formation recall how easily it led to programming mistakes. Well, some people like to count mistakes, while others (including me) prefer to consider real counsequences of those mistakes (on a production line). My experience says that these two accounts lead to rather different results. And anyway, all constructs easily lead to programming mistakes, without exceptions. Take for example those begin-end blocks. The following 3-step scenario I encountered many times: Step 1. Use the same identifier inside and outside of the block: declare i; i := ...; ... begin declare i; i := ...; ... ... := i; end; ... ... =:= i; Step 2. Reuse that variable inside the block: declare i; i := ...; ... begin declare i; i := ...; ... ... := i; ... i := ...; ... ... := i; end; ... ... =:= i; Step 3. Remove the first use of that variable inside the block along with its inner declaration (just forgetting about the second use of it): declare i; i := ...; ... begin ... i := ...; ... ... := i; end; ... ... =:= i; The final result is obvious, I hope. > The fact that Jackson "was quite happy with COBOL" is simply an indication > of the widespread stupidity regarding the shortcomings of the earlier forms > of the language. Is it a new fashion of political correctness to declare previous techniques and tools that didn't become current mainstream - simply stupid? > No intelligent contemporary programmer would want to > return to hideous mess of tangled code so typical of pre-ANSI-85. Well, I can't say for intelligent people (they are so mystically clever, they so easily differentiate and recognize so many puzzling abbreviations -:), but in my humble opinion, a hideos mess of tangled systems and products and concepts and standards isn't much better, and leaves even less hope for keeping things under control. > Structures, in the Dijkstra sense, was far more than "GO TO Considered > Harmful." More important, though, are the elementary control structures > of Jacopini and Bohm which, when properly formed, will include scope > terminators such as ANSI-85, END-PERFORM, END-READ, END-IF, > etc, without which the resulting code is usually a mess. Well, I prefer another "definition of scope" - that of H. Mills - a module that fits into a page, that is, a scope is an amount of code which directly fits into programmer's view. > I have written and > maintained code written by others, in COBOL 68, 74, and 85. I would > never want to do anything in 68 or 74 again. Well, if you prefer to deal with magnificient templates, XSSL, SOAP, ADO, DRM, Java 1.m.n etc., etc. (at the same time, of course) then it is your taste, > In my view, COBOL, prior to the ANSI-85 standard was not "very well > suited" for writing maintainable, dependable, well-structured code, Surely. It was just well suited to make programs which ran on production lines - certainly with much pain, failures etc., but there was no other way that time, in first place because of incomplete and often self-contradictory specifications/requirements and unreliable hardware. > Since the ANSI-85 standard, COBOL has become one of the most interesting > languages around. It has corrected the silliness of the earlier standards, There was no silliness to correct. COBOL just was adapted to changed circumstances - more powerful and reliable hardware, more challenging tasks, more educated/experienced programmers, and better understanding of the processes by analysts. Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-10 1:41 ` Alexander E. Kopilovich @ 2004-06-10 6:13 ` Richard Riehle 2004-06-11 2:03 ` Alexander E. Kopilovich 2004-06-12 2:31 ` Robert I. Eachus 0 siblings, 2 replies; 82+ messages in thread From: Richard Riehle @ 2004-06-10 6:13 UTC (permalink / raw) "Alexander E. Kopilovich" <aek@VB1162.spb.edu> wrote in message news:mailman.85.1086832128.391.comp.lang.ada@ada-france.org... > Richard Riehle wrote: > > > > There are other > > > ways for structured programming (in general sense), and COBOL was very well > > > suited for some of them. For example, if you have ever read "Principles of > > > Program Design" by Jackson, you may recall that JSP was quite happy with > > > COBOL. > > > > Sorry, but COBOL was totally ill-suited to support of well-formed structures > > of any kind prior to ANSI-85. > > COBOL (even 66) was very well suited to support of well-formed *data* > structures. As for control structures, oh yes, it did not provide blocks > (FORTRAN IV also did not provide them - was that FORTRAN stupid also?), and > I think it was right choice, PERFORM statements were better in those > circumstances. The data structures were consistently global, thereby making the notion of localization of data impossible. The fact that FORTRAN also failed to provide adequate scoping rules for conditional constructs does not make the same defect in COBOL any more acceptable. PERFORM was never parameterized and still isn't. In addition, there are somewhat awkward rules for the scope of a PERFORM. We would frequently do one of two things. PERFORM THROUGH where we had a dummy paragraph with an EXIT, or PERFORM by SECTION. In either case, all data was global and that led to no end of maintenance errors. > > > Take the horrible model for an IF statement as an example. > > Hm, what was so horrible there? I have no bad recollections of that IF. I have seen no end of trouble with nested IF statements in COBOL, many of which used the NEXT SENTENCE feature, or worse, a GO TO to escape from nested structure. The cure for this was the END-IF. > > > Those of us who had to use this half-baked conditional > > formation recall how easily it led to programming mistakes. > > Well, some people like to count mistakes, while others (including me) prefer > to consider real counsequences of those mistakes (on a production line). My > experience says that these two accounts lead to rather different results. The need for end of scope for control structures was recognized early in the design of most other programming languages. It came late to COBOL. > > > > The fact that Jackson "was quite happy with COBOL" is simply an indication > > of the widespread stupidity regarding the shortcomings of the earlier forms > > of the language. > > Is it a new fashion of political correctness to declare previous techniques > and tools that didn't become current mainstream - simply stupid? > > > No intelligent contemporary programmer would want to > > return to hideous mess of tangled code so typical of pre-ANSI-85. > > Well, I can't say for intelligent people (they are so mystically clever, they > so easily differentiate and recognize so many puzzling abbreviations -:), > but in my humble opinion, a hideos mess of tangled systems and products and > concepts and standards isn't much better, and leaves even less hope for > keeping things under control. > > > Structures, in the Dijkstra sense, was far more than "GO TO Considered > > Harmful." More important, though, are the elementary control structures > > of Jacopini and Bohm which, when properly formed, will include scope > > terminators such as ANSI-85, END-PERFORM, END-READ, END-IF, > > etc, without which the resulting code is usually a mess. > > Well, I prefer another "definition of scope" - that of H. Mills - a module > that fits into a page, that is, a scope is an amount of code which directly > fits into programmer's view. Well, that is also a rather inadequate definition of a module. I recall people using that definition where they would take a red pencil and simply start a new module every fifty-six lines. A module, properly defined, will adhere to the rules of cohesion and coupling, or follow the advice of Parnas, or Meyer. Certainly modules should be short, whenever that is appropriate, but arbitrary page length or screen length criteria will create more problems than it will solve. > > > I have written and > > maintained code written by others, in COBOL 68, 74, and 85. I would > > never want to do anything in 68 or 74 again. > > Well, if you prefer to deal with magnificient templates, XSSL, SOAP, ADO, > DRM, Java 1.m.n etc., etc. (at the same time, of course) then it is your taste, > Not sure why you make this comparison since it has nothing to do with COBOL. I am simply arguing that early versions of COBOL fell short of what was needed for creating well structured, maintainable code that provided support for good modularity (e.g., cohesion and coupling) and modern COBOL is much improved. > > In my view, COBOL, prior to the ANSI-85 standard was not "very well > > suited" for writing maintainable, dependable, well-structured code, > > Surely. It was just well suited to make programs which ran on production > lines - certainly with much pain, failures etc., but there was no other way > that time, in first place because of incomplete and often self-contradictory > specifications/requirements and unreliable hardware. I have written and maintained so much COBOL over my career that I have no difficulty remembering the problems with it. I have also used contemporary COBOL and it is lightyears ahead of the earlier versions of the language. It is interesting to me to realize that, when I was using those earlier versions of COBOL, I did not understand just how crippled the language was because I learned all the workarounds. > > > Since the ANSI-85 standard, COBOL has become one of the most interesting > > languages around. It has corrected the silliness of the earlier standards, > > There was no silliness to correct. COBOL just was adapted to changed > circumstances - more powerful and reliable hardware, more challenging tasks, > more educated/experienced programmers, and better understanding of the > processes by analysts. > Sorry. But when I compare old-time COBOL with contemporary COBOL, I see such vast improvements that the older versions look to me now like primitive cave drawings. This has nothing to do with improved hardware, improved programmers, or better processes. It has everything to do with a greatly enhanced language definition where I can more effectively create parameterized modules with call by value or reference, can create control structures that have well-defined scope, and can avoid excessive use of global data. Richard Riehle ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-10 6:13 ` Richard Riehle @ 2004-06-11 2:03 ` Alexander E. Kopilovich 2004-06-12 2:31 ` Robert I. Eachus 1 sibling, 0 replies; 82+ messages in thread From: Alexander E. Kopilovich @ 2004-06-11 2:03 UTC (permalink / raw) To: comp.lang.ada Richard Riehle wrote: > > COBOL (even 66) was very well suited to support of well-formed *data* > > structures. As for control structures, oh yes, it did not provide blocks > > (FORTRAN IV also did not provide them - was that FORTRAN stupid also?), > > and I think it was right choice, PERFORM statements were better in those > > circumstances. > > The data structures were consistently global, thereby making the notion of > localization of data impossible. First, not generally impossible - you had subroutines for that. Second, it was just good thing that that localization was not too easy - it would constantly confuse programmers and severely increase number of nasty mistakes. Please don't confuse abstraction skills of typical COBOL programmer (that time) with those of typical Algol-60 programmer (those of average FORTRAN IV programmer - "typical" was't applicable to FORTRANers - were somewhere in between). > The fact that FORTRAN also failed to > provide adequate scoping rules for conditional constructs does not make > the same defect in COBOL any more acceptable. Again, it wasn't a defect - it was adequate for that reality. Well, if there were scopes in COBOL-66, I could use them, but probably I wouldn't - because it would be impossible to explain those "tricks" to almost all programmers around me, and I had no intention to maintain my production programs myself infinitely. And the same was often true for FORTRAN (but not so often as for COBOL). > PERFORM was never parameterized and still isn't. Well, begin-end blocks are non-paramerized also. If you needed parameters you had subroutines for that. > In addition, there > are somewhat awkward rules for the scope of a PERFORM. We would > frequently do one of two things. PERFORM THROUGH where we > had a dummy paragraph with an EXIT, or PERFORM by SECTION. Well, it is true that those rules required either training or experience for their good application, but I don't call then awkward for that - because their relative proximity to the language used by "analysts" (who composed problem specifications/requirements) that time was more important than any abstract clarity. > In either case, all data was global and that led to no end of maintenance > errors. In fact, the was a good opportunity to provide a kind of localization in COBOL-66: you could put you data into a structure even if that data does not participate in I/O and need not be structured for the algorithm. The data remains global, but nevertheless it becomes "localized" in some sense (well, if you wish an exact, abstract definition of this "localization" then here it is: the variables become localized in the space of identifiers). > I have seen no end of trouble with nested IF statements in COBOL, many > of which used the NEXT SENTENCE feature, or worse, a GO TO to > escape from nested structure. The cure for this was the END-IF. Nested IFs are evil (well, dangerous -:) anyway, and there can't be any cure. For me, END-IFs (in all languages that employ them, including Ada) bring little help when IFs are nested - the visibility decreases drastically and the code becomes error-prone. > The need for end of scope for control structures was recognized early in the > design of most other programming languages. It came late to COBOL. Well, that *need* came late to COBOL, not the *recognition* of that need. I hope you agree that 1) COBOL designers most probably were aware of Algol (58/60) and 2) there were no significant syntactic or semantic problems with introducing begin-end blocks into COBOL. > > > I have written and >> > maintained code written by others, in COBOL 68, 74, and 85. I would > > > never want to do anything in 68 or 74 again. > > > > Well, if you prefer to deal with magnificient templates, XSSL, SOAP, ADO, > > DRM, Java 1.m.n etc., etc. (at the same time, of course) then it is your taste, > > > Not sure why you make this comparison since it has nothing to do with COBOL. I pointed at the current programming "biblioware" for commercial data processing. I meant that those problems with early COBOL, which you mentioned, aren't bigger or more painful than current problems (associated with programming languages of various kinds) within the same application domain. > I am simply arguing that early versions of COBOL fell short of what was > needed for creating well structured, maintainable code that provided support > for good modularity (e.g., cohesion and coupling) and modern COBOL is > much improved. Well, you were lucky in that you had opportunity to see and use COBOL-85. I had no such opportunity. Even COBOL-74 was far remote thing for me - I could only see some distorted (translated) documentation. Possibly this difference plays its role - you saw more advanced COBOL and therefore the previous one seems too bad for you, while I saw that old COBOL only, and remember that it was good enough. > It is interesting to me to realize that, when I was using those > earlier versions of COBOL, I did not understand just how crippled the > language was because I learned all the workarounds. Excellent. Now realize that as I did not see later versions of COBOL, the time stopped for me at that point, regarding COBOL. And I'm quite sure that I was not stupid that time, and I definitely knew Algol-60 (and even tried to learn Algol-68 -:) . So if we have a disagreement on this issue, it seems more about of role of time in our opinions than about COBOL-66 itself. > > There was no silliness to correct. COBOL just was adapted to changed > > circumstances - more powerful and reliable hardware, more challenging tasks, > > more educated/experienced programmers, and better understanding of the > > processes by analysts. > > > Sorry. But when I compare old-time COBOL with contemporary COBOL, > I see such vast improvements that the older versions look to me now like > primitive cave drawings. But those people who created cave drawings probable weren't stupid. Moreover, I venture to think that if one of now-famous painters somehow appeared in those caves between those tribesmen then, perhaps, he would decide to create similar drawings - just because they could be understood by people around him. > This has nothing to do with improved hardware, > improved programmers, or better processes. It has everything to do with > a greatly enhanced language definition where I can more effectively create > parameterized modules with call by value or reference, can create control > structures that have well-defined scope, and can avoid excessive use of > global data. Programming language is a language - it must be understood by people who use it. If only 10% of users can properly understand sufficient part of the language then the language will fail. Therefore education of programmers and level of understanding of problems by analysts - matters for a programming language. Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-10 6:13 ` Richard Riehle 2004-06-11 2:03 ` Alexander E. Kopilovich @ 2004-06-12 2:31 ` Robert I. Eachus 2004-06-15 16:07 ` Richard Riehle 1 sibling, 1 reply; 82+ messages in thread From: Robert I. Eachus @ 2004-06-12 2:31 UTC (permalink / raw) Richard Riehle wrote: > The data structures were consistently global, thereby making the notion of > localization of data impossible. The fact that FORTRAN also failed to > provide adequate scoping rules for conditional constructs does not make > the same defect in COBOL any more acceptable. But there was a major difference. It was common in COBOL* in the 60's and 70's to write what we would now make a subroutine as a Cobol program, and use JCL to tie the various COBOL programs together to create an application. Yes, I can agree that programming in JCL was painful, but that had little to do with COBOL, and everything to do with the memory sizes on then current machines. You couldn't fit the whole program--or whole dataset--in memory, and you wouldn't run into thrashing, since most machines did no have virtual memory. (Yes, I know that some 360s and all 370s had virtual memory support, but you had to run an OS that used it.) *Capitilization intentional to distinguish between two versions of the language. -- Robert I. Eachus The ideology he opposed throughout his political life insisted that history was moved by impersonal tides and unalterable fates. Ronald Reagan believed instead in the courage and triumph of free men and we believe it all the more because we saw that courage in him. -- George W. Bush June 11, 2004 ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-12 2:31 ` Robert I. Eachus @ 2004-06-15 16:07 ` Richard Riehle 0 siblings, 0 replies; 82+ messages in thread From: Richard Riehle @ 2004-06-15 16:07 UTC (permalink / raw) "Robert I. Eachus" <rieachus@comcast.net> wrote in message news:demdnZCSTppt91fd4p2dnA@comcast.com... > Richard Riehle wrote: > > > The data structures were consistently global, thereby making the notion of > > localization of data impossible. The fact that FORTRAN also failed to > > provide adequate scoping rules for conditional constructs does not make > > the same defect in COBOL any more acceptable. > > But there was a major difference. It was common in COBOL* in the 60's > and 70's to write what we would now make a subroutine as a Cobol > program, and use JCL to tie the various COBOL programs together to > create an application. Ah, yes. How fondly I recall those // punched cards. :-) > > Yes, I can agree that programming in JCL was painful, but that had > little to do with COBOL, and everything to do with the memory sizes on > then current machines. You couldn't fit the whole program--or whole > dataset--in memory, and you wouldn't run into thrashing, since most > machines did no have virtual memory. (Yes, I know that some 360s and > all 370s had virtual memory support, but you had to run an OS that used it.) Agreed. We so often found ourselves doing workarounds due to program size limitations, along with lots of other entertaining restrictions on the IBM OS's. This particularly frutstrating, at times, with DOS. I preferred the Burroughs OS, but it was not as popular. > Richard Riehle ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-09 1:32 ` Alexander E. Kopilovich 2004-06-09 6:23 ` Richard Riehle @ 2004-06-09 7:54 ` Dmitry A. Kazakov 1 sibling, 0 replies; 82+ messages in thread From: Dmitry A. Kazakov @ 2004-06-09 7:54 UTC (permalink / raw) On Wed, 9 Jun 2004 05:32:19 +0400 (MSD), "Alexander E. Kopilovich" <aek@VB1162.spb.edu> wrote: >I remember that several years ago Robert Dewar remarked (here in comp.lang.ada >or elsewhere) that the concept of "object" in current COBOL standard is more >rich and complex than even in C++ (and certainly more rich and complex than >in Ada). ARM 3.3: "Objects are created at run time and contain a value of a given type." I know no richer concept of object. -- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-07 11:19 ` 7E7 Flight Controls Electronics Marin David Condic 2004-06-07 22:24 ` Alexander E. Kopilovich @ 2004-06-09 6:31 ` Robert I. Eachus 2004-06-09 9:43 ` I R T 2004-06-09 15:28 ` Jerry Petrey 1 sibling, 2 replies; 82+ messages in thread From: Robert I. Eachus @ 2004-06-09 6:31 UTC (permalink / raw) Marin David Condic wrote: > Ada, OTOH tried to address the needs of embedded systems programmers and > missed the mark for a variety of reasons. Probably chief among them was > that embedded programmers already had something - C - which was cheap > and small and could be made to fit just about any processor - and was > available for just about any microprocessor. Ada was huge and cost a > fortune and couldn't be made to work for small microprocessors and was > not available for most targets. Given that people had choices and Ada > wasn't meeting their needs, mandate or not, they went elsewhere. > > The moral of the story: Find out what the customer wants/needs before > you build a huge product and try to sell it to them. No, the HOLWG hit the mark they were aiming at. They wanted to reduce the 800 or so programming languages in use by the DoD, and they succeeded. DoD1 was expected to provide a 'language of last resort', so that the DoD could provide a development environment for DoD1, which became Ada, that would make it usable for any embedded DoD software project. What people on the front lines missed totally about the development of Ada by the DoD was that the goal was not really to force everyone to use one language. It was to be able to say, "No we will not fund you to develop a compiler for this neat new language as part of this procurement project. Here is a list of languages you can use. If you need modifications to a compiler to support particular requirements, we are willing to discuss it. But we won't support any effort to create a new programming language, or modify an existing one. So from the HOLWG point of view Ada succeeded. The lofty goals expressed by government functionaries along the way were nice dreams, the big wonderful thing that the HOLWG got right, was to design the language to meet their requirements before they started implementing it. Compare it to many of the other programmng languages that the DoD sponsored over the years. Many of you may have heard of JOVIAL, which Ada replaced in the Air Force. (There are still systems flying out there written in Jovial, in fact AWACS is still using J3I for part of its systems. RSIP replaced most of the radar system sofware with Ada.) But what about TACPOL? That was the Army's favorite programming language before Ada. The Navy used CMS-2, well CMS-2M and CMS-2Y, just as the Air Force had two different versions of Jovial, J3B and J3I that were combined into J73. Are you seeing a pattern here? Contractors developed compilers for langauges that weren't well specified in advance, and the difference between compilers was big enough that the dialects were treated as different languages. That was why the Ada program said that compilers were required to implement the whole language and only the Ada language, no supersets or subsets. Projects could develop policies that subsetted the language if they chose, and in fact early on it was expected that many programs would not use Ada tasking and others would not use Ada generics. (This was before Text_IO was created which meant that almost everyone would need to use some generics.) We figured, before the name Ada was ever associated with it, that it the HOLWG could get the number of programming languages in use in the DoD below 50, that would count as success. Right now, my guess is that there are less than a dozen general purpose programming languages in use on DoD programs. Just so I don't get accused of being a pollyanna, the HOLWG also failed, big time. There were three parts to HOLWGs plans. First develop the language, and sponsor compiler developments. Then design a development environment for DoD1 (Ada) program development. But the "competition" between two government funded compiler developments, the ALS at Softech, and the AIE at Intermetrics, got way out of hand. There was some justification for the AIE project to design a development enviroment that their Ada compiler would be a part of--the contract anticipated contracting for the development environment after the compiler was ready. However, the ALS project seems to have "just grown" to include a development environment that wasn't in the original contract. On both projects, resources that should have been focused on creating a decent compiler got lost in feeping creaturism. The Intermetrics team finally was given a "stop work" order for anything not part of the compiler, and the Intermetrics compiler eventually turned out to be pretty decent. Another little detail was that the Intermetrics compiler was supposed to target IBM mainframes and Interdata 32 systems. Before the compiler was finished, I think that Interdata was acquired, by Perkin Elmer I think, and I don't know if that version of the Intermetrics compiler ever made it to market. As for the IBM mainframe targets, I'll let people who were in the line of fire describe the problems. Targetting MVS only would have made sense, but the government had its priorities... The ALS compiler was a disaster. If you ask me to describe why it was a disaster, I could give you a blow by blow description of what the contracting office did wrong. It really comes down to the issued the contract too soon--they should have had at least six months more work on design development before freezing a lot of details in the contract. As usual this resulted in a lot of finger pointing, and a totally useless product, that met the requirements of the contract. By that time there were several good commercial Ada compilers developed without government funding and goverment contracts--but validated to meet the goverment standards. The DoD basically abandoned the ALS and AIE projects and started over with a new Ada development enviroment project. Unfortunately, at a meeting I chaired in 1984, the death knell for the Ada CAIS was sounded. And it was such an innocent question. ;-) I asked people who had ported real Ada software from one system to another how it compared to trying to understand the CAIS documentation. The consensus was that the port of some reasonably large software, written in Ada, took less time than it took to understand the CAIS well enough to use it. (I certainly spent over 100 hours studying the documentation, and I was _starting_ to get a clue.) So you could spend three months per person training your programming team in using the CAIS. Then if you used the CAIS for development, it would cut the effort required to reuse the software in half. But if it took three weeks to do a port without the CAIS, you had to be planning on an awful lot of retargeting of software for the CAIS to make sense. There was eventually a European effort called PCTE that developed a programming environment for Ada. (http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-162.pdf) In practice the only reason I know of for using the PCTE is if you are using it for both Ada and C. The tendancy in Ada is to use a "thin" binding to the actual operating system, instead of a thick binding like the PCTE. (In fact, I find the POSIX Ada binding to be a bit too thick for my taste--your opinion may vary.) In any case, if the HOLWG got an A for Ada*, they may not have deserved an F for their efforts at development environments--but that is the lowest grade I can give them. ;-) *Of course what saved the HOLWG was that the interest in Ada was so great, that there were several commercial compilers, and the Rational environment, developed without DoD funding. (NYU's AdaEd did have some DoD funding, but more of a study of Ada semantics, rather than a useable compiler. That it did result in a useable compiler, and eventually in GNAT, has more to do with the genius of those involved rather than DoD management. (Well the DoD project management did the right thing on Ada Ed and GNAT, they worried about implementing Ada right, and what that meant, rather than contract deliverables as such.) -- Robert I. Eachus "The terrorists rejoice in the killing of the innocent, and have promised similar violence against Americans, against all free peoples, and against any Muslims who reject their ideology of murder. Their barbarism cannot be appeased, and their hatred cannot be satisfied. There's only one way to deal with terror: We must confront the enemy and stay on the offensive until these killers are defeated." -- George W. Bush ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-09 6:31 ` Robert I. Eachus @ 2004-06-09 9:43 ` I R T 2004-06-09 15:28 ` Jerry Petrey 1 sibling, 0 replies; 82+ messages in thread From: I R T @ 2004-06-09 9:43 UTC (permalink / raw) "Robert I. Eachus" <rieachus@comcast.net> writes: > "The terrorists rejoice in the killing of the innocent, and have > promised similar violence against Americans, against all free peoples, > and against any Muslims who reject their ideology of murder. Their > barbarism cannot be appeased, and their hatred cannot be > satisfied. There's only one way to deal with terror: We must confront > the enemy and stay on the offensive until these killers are defeated." > -- George W. Bush Please keep the warmongering, pro-torture American ideology out of this. ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-09 6:31 ` Robert I. Eachus 2004-06-09 9:43 ` I R T @ 2004-06-09 15:28 ` Jerry Petrey 1 sibling, 0 replies; 82+ messages in thread From: Jerry Petrey @ 2004-06-09 15:28 UTC (permalink / raw) "Robert I. Eachus" wrote: > -- > > Robert I. Eachus > > "The terrorists rejoice in the killing of the innocent, and have > promised similar violence against Americans, against all free peoples, > and against any Muslims who reject their ideology of murder. Their > barbarism cannot be appeased, and their hatred cannot be satisfied. > There's only one way to deal with terror: We must confront the enemy and > stay on the offensive until these killers are defeated." -- George W. Bush Great signature! ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 12:58 ` Marin David Condic 2004-05-29 13:35 ` Ed Falis @ 2004-05-29 15:58 ` Preben Randhol 2004-05-29 17:45 ` Marin David Condic ` (2 more replies) 1 sibling, 3 replies; 82+ messages in thread From: Preben Randhol @ 2004-05-29 15:58 UTC (permalink / raw) On 2004-05-29, Marin David Condic <nobody@noplace.com> wrote: > We can claim that Ada is superior and bitch because someone else won't > see that and use it and call them boneheads for doing so. Incompetent bonehead managers (which is probably in majority) will only go with the flow and think C/C++ is the answer to everything. They don't see that the costs for educating C/C++ programmers into Ada programmers pays off in the long run. However, in this case it looks like Ada is being used. -- Preben Randhol -------- http://www.pvv.org/~randhol/ () "Violence is the last refuge of the incompetent" /\ - Isaac Asimov ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 15:58 ` Preben Randhol @ 2004-05-29 17:45 ` Marin David Condic 2004-05-29 17:51 ` Ed Falis 2004-05-29 19:55 ` Jeffrey Carter 2004-05-30 7:57 ` Pascal Obry 2 siblings, 1 reply; 82+ messages in thread From: Marin David Condic @ 2004-05-29 17:45 UTC (permalink / raw) Well then let's start a company that has *competent*, *non-bonehead* managers who are going to use Ada and show a whole bunch of productivity improvement over the incompetent, boneheaded managers and their C++ developers. In the long run, we'll be making truckloads of money, right? The only way that Ada is going to get into more projects is if *we* put it there because *we* are the ones making the decisions, doing the work and accepting the responsibility for the end result. If *we* go off and start building avionics computers or some other sort of computer systems and *we* use Ada to do that and *we* demonstrate better productivity & quality and increased profitability as a result, the rest of the crowd will eventually follow. In the mean time, *we* blow *their* doors off and get filthy, stinking, Bill Gates, rich because *we* built the better mouse trap, right? As for me? I'm pushing Ada into projects where I can and trying to take my organization in that direction. Ultimately, some of us have to take on ventures that produce an end product that uses Ada, or it falls apart. (Anyone with an interesting venture out there?) Ada isn't *ever* going to succeed if we just sit around and wait for Boeing or LockMart to decide to put it into their next major aircraft. Calling their management boneheaded won't make one single project turn into an Ada project either. MDC Preben Randhol wrote: > > Incompetent bonehead managers (which is probably in majority) will only > go with the flow and think C/C++ is the answer to everything. They don't > see that the costs for educating C/C++ programmers into Ada programmers > pays off in the long run. > > However, in this case it looks like Ada is being used. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 17:45 ` Marin David Condic @ 2004-05-29 17:51 ` Ed Falis 0 siblings, 0 replies; 82+ messages in thread From: Ed Falis @ 2004-05-29 17:51 UTC (permalink / raw) > Preben Randhol wrote: > >> Incompetent bonehead managers (which is probably in majority) will only >> go with the flow and think C/C++ is the answer to everything. They don't >> see that the costs for educating C/C++ programmers into Ada programmers >> pays off in the long run. However, in this case it looks like Ada is >> being used. Most of these managers are not as boneheaded as you think they are. A lot of them still use Ada because of sunk investment and the reuse platform it provides. The cost of education to use Ada remains overstated in most circles. - Ed ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 15:58 ` Preben Randhol 2004-05-29 17:45 ` Marin David Condic @ 2004-05-29 19:55 ` Jeffrey Carter 2004-05-30 7:57 ` Pascal Obry 2 siblings, 0 replies; 82+ messages in thread From: Jeffrey Carter @ 2004-05-29 19:55 UTC (permalink / raw) Preben Randhol wrote: > Incompetent bonehead managers (which is probably in majority) will only > go with the flow and think C/C++ is the answer to everything. They don't > see that the costs for educating C/C++ programmers into Ada programmers > pays off in the long run. They may not be boneheaded. Many contracts are worded so that the contractor makes more money the longer and more expensive the contract is. Using C/++ tends to make a contract be longer and more expensive than using Ada. -- Jeff Carter "Run away! Run away!" Monty Python and the Holy Grail 58 ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 15:58 ` Preben Randhol 2004-05-29 17:45 ` Marin David Condic 2004-05-29 19:55 ` Jeffrey Carter @ 2004-05-30 7:57 ` Pascal Obry 2004-05-30 18:35 ` Richard Riehle 2 siblings, 1 reply; 82+ messages in thread From: Pascal Obry @ 2004-05-30 7:57 UTC (permalink / raw) Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> writes: > Incompetent bonehead managers (which is probably in majority) will only > go with the flow and think C/C++ is the answer to everything. They don't > see that the costs for educating C/C++ programmers into Ada programmers > pays off in the long run. Well they don't see the costs of educating C/C++ programmers to Java either but they do it since everybody else does it :) And the next wave is C# :) Until the next language... Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-30 7:57 ` Pascal Obry @ 2004-05-30 18:35 ` Richard Riehle 2004-05-31 12:38 ` Marin David Condic 2004-06-04 12:56 ` Warren W. Gay VE3WWG 0 siblings, 2 replies; 82+ messages in thread From: Richard Riehle @ 2004-05-30 18:35 UTC (permalink / raw) "Pascal Obry" <pascal@obry.org> wrote in message news:ulljal52z.fsf@obry.org... > Well they don't see the costs of educating C/C++ programmers to Java either > but they do it since everybody else does it :) And the next wave is C# :) > Until the next language... > Programming language selection, like politicians, is made on the basis of slogans, buzzwords, and half-truths. Almost no one in the DoD contractor community is making programming language selection based on a full and informed basis. The choice of "experienced" Java programmers over experienced domain experts, is one of those kinds of decisions. Experienced software project managers realize that language skills are more easily taught than domain knowledge. Of course, we need a good mix of languages experts and domain experts for any project. More important than experience in some specific programming language is experience developing software in a variety of languages. For safety-critical software, or for software where a high level of dependability is essential, Ada is still the best decision. However, when finding inexpensive university-trained programmers is the goal, Java is the right choice. Of course, those Java-trained programmers are not likely to understand much about real-time controls, the deeper concerns of concurrency, the techniques for achieving efficient low-level constructs, scheduling algorithms, or most of the other stuff we routinely teach our Ada programmers, but no matter; they can write web pages, create little GUI programs, and target the JVM. In one of my classes this Quarter, Programming Paradigms, we are focusing our attention on two languages: C++ and Ada. The students have already had two Quarters of Java before entering this class. We also introduce them to several other languages such Eiffel, Lisp, Prolog, and my favorite, Smalltalk. As they become more and more informed about Ada, after studying C++ and a lot of Java, many tell me how much they enjoy Ada, and ask why it isn't used more. Yes, they continue to use Java, because they know a lot more of it, and they can make those little GUI's (although they also write MS-Windows programs in Ada in this class), and the other professors prefer them to us C++. But they are learning that there are choices, and Ada is a good choice for certain classes of problems. One reason Ada is not more widely accepted is that it has been so badly presented so often. True, C++ is usually taught badly as well. But Ada suffers from the many mistakes we have made over the past twenty years in the way we have taught it. Professors, most of them I know, want nothing to do with Ada. It is not as new and interesting to them as Java. Moreover, they can get papers published more easily in Java than they can in Ada. I have been told not to submit a paper if my examples are in Ada. I am advised to use Java instead. To which I reply, "No thanks. I really don't have a compelling need to publish." C# is an interesting language. It seems to have learned a lot from Ada, as well as from Java. There are some things I dislike about it. There is even one feature I simply find annoying: the misuse of the term "delegation." In OOP, delegation has long had one well-understood meaning, and C# has corrupted that meaning to be the equivalent of a pointer to function. Sheeeeeeesh! Richard Riehle ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-30 18:35 ` Richard Riehle @ 2004-05-31 12:38 ` Marin David Condic 2004-06-04 12:56 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 82+ messages in thread From: Marin David Condic @ 2004-05-31 12:38 UTC (permalink / raw) I know you basically agree with me when I say we have to go off and create the Ada market for ourselves. I understand your frustration with the program managers, the politics, the professors, etc. We can't change them, but we *can* change ourselves. Program managers are driven by factors beyond just technical superiority of a given language. There's all sorts of economics involved and other sorts of practical issues. They're never going to see Ada as a viable choice unless there is some element of popularity in the bigger world. So we should quit complaining about them and get Ada used in a bigger way where we *do* have control. The politics isn't going to change either. Its controlled by perceptions that are historical and at best we can only influence. But if we start making things in Ada and selling them successfully, a lot of those perceptions will start to change. Colleges/professors have their own batch of reasons for why they emphasize one language over another. But they are driven by market forces too. If nobody is hiring their grads because nobody wants Ada programmers and all they teach is Ada, then they quickly start to lose student body. There must be jobs out there or Ada is just some academic curiosity that is maybe worth some mention in a programming language survey course. So we need to *create* those jobs. That can only happen if we create products that use Ada. We've got to quit whining about this and actually *do* something that might increase the popularity of Ada. If not, it will slowly wither away and we'll have nobody to blame but ourselves. (Or maybe we can *try* to blame it all on a few boneheaded managers. :-) MDC Richard Riehle wrote: > > Programming language selection, like politicians, is made on the basis of > slogans, buzzwords, and half-truths. Almost no one in the DoD contractor > community is making programming language selection based on a full > and informed basis. The choice of "experienced" Java programmers > over experienced domain experts, is one of those kinds of decisions. > > Experienced software project managers realize that language skills are > more easily taught than domain knowledge. Of course, we need a > good mix of languages experts and domain experts for any project. > More important than experience in some specific programming > language is experience developing software in a variety of languages. > > For safety-critical software, or for software where a high level of > dependability is essential, Ada is still the best decision. However, > when finding inexpensive university-trained programmers is the goal, > Java is the right choice. Of course, those Java-trained programmers > are not likely to understand much about real-time controls, the deeper > concerns of concurrency, the techniques for achieving efficient low-level > constructs, scheduling algorithms, or most of the other stuff we routinely > teach our Ada programmers, but no matter; they can write web pages, > create little GUI programs, and target the JVM. > > In one of my classes this Quarter, Programming Paradigms, we are focusing > our attention on two languages: C++ and Ada. The students have already > had two Quarters of Java before entering this class. We also introduce > them to several other languages such Eiffel, Lisp, Prolog, and my favorite, > Smalltalk. As they become more and more informed about Ada, after > studying C++ and a lot of Java, many tell me how much they enjoy Ada, > and ask why it isn't used more. Yes, they continue to use Java, because > they know a lot more of it, and they can make those little GUI's (although > they also write MS-Windows programs in Ada in this class), and the > other professors prefer them to us C++. But they are learning that there > are choices, and Ada is a good choice for certain classes of problems. > > One reason Ada is not more widely accepted is that it has been so badly > presented so often. True, C++ is usually taught badly as well. But Ada > suffers from the many mistakes we have made over the past twenty > years in the way we have taught it. Professors, most of them I know, > want nothing to do with Ada. It is not as new and interesting to them as > Java. Moreover, they can get papers published more easily in Java than > they can in Ada. I have been told not to submit a paper if my examples > are in Ada. I am advised to use Java instead. To which I reply, "No > thanks. > I really don't have a compelling need to publish." > > C# is an interesting language. It seems to have learned a lot from Ada, as > well > as from Java. There are some things I dislike about it. There is even > one > feature I simply find annoying: the misuse of the term "delegation." In > OOP, > delegation has long had one well-understood meaning, and C# has corrupted > that meaning to be the equivalent of a pointer to function. Sheeeeeeesh! > > Richard Riehle > > > > > > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ====================================================================== ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-30 18:35 ` Richard Riehle 2004-05-31 12:38 ` Marin David Condic @ 2004-06-04 12:56 ` Warren W. Gay VE3WWG 2004-06-05 8:49 ` Pascal Obry 1 sibling, 1 reply; 82+ messages in thread From: Warren W. Gay VE3WWG @ 2004-06-04 12:56 UTC (permalink / raw) Richard Riehle wrote: > "Pascal Obry" <pascal@obry.org> wrote in message > news:ulljal52z.fsf@obry.org... ... >>but they do it since everybody else does it :) And the next wave is C# :) >>Until the next language... ... > C# is an interesting language. It seems to have learned a lot from Ada, as > well > as from Java. There are some things I dislike about it. There is even > one > feature I simply find annoying: the misuse of the term "delegation." In > OOP, > delegation has long had one well-understood meaning, and C# has corrupted > that meaning to be the equivalent of a pointer to function. Sheeeeeeesh! > > Richard Riehle My quibble with C# is the the fact that Windows people love those stupid butt-ugly square bracket syntax (for those object attributes). Surely, some better syntax could have been used. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-04 12:56 ` Warren W. Gay VE3WWG @ 2004-06-05 8:49 ` Pascal Obry 0 siblings, 0 replies; 82+ messages in thread From: Pascal Obry @ 2004-06-05 8:49 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes: > My quibble with C# is the the fact that Windows people love > those stupid butt-ugly square bracket syntax (for those > object attributes). Surely, some better syntax could have > been used. Well C# is old language ;) Microsoft is working on C-omega now! http://research.microsoft.com/Comega/ Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-29 1:51 7E7 Flight Controls Electronics Jeffrey Carter 2004-05-29 10:21 ` Per Dalgas Jakobsen @ 2004-06-06 10:27 ` I R T 1 sibling, 0 replies; 82+ messages in thread From: I R T @ 2004-06-06 10:27 UTC (permalink / raw) Jeffrey Carter <spam@spam.com> writes: > Would you trust your life to an aircraft with flight controls > electronics software hacked by a C coder? You are already doing that. ^ permalink raw reply [flat|nested] 82+ messages in thread
* 7E7 Flight Controls Electronics
@ 2004-05-30 10:34 Rod Chapman
2004-06-03 8:18 ` Vernon Brown
0 siblings, 1 reply; 82+ messages in thread
From: Rod Chapman @ 2004-05-30 10:34 UTC (permalink / raw)
Jeffrey Carter <spam@spam.com> wrote in message news:<90Stc.15309$be.3117@newsread2.news.pas.earthlink.net>...
> Honeywell is advertising for a software engineer for 7E7 flight controls
> electronics. The requirements are "Demonstrated experience using C/C++".
> No mention of Ada.
I don't think we should read too much into this. Two possibly useful
pieces of information:
1) The Flight Control Electronics (FCE) is not the same thing as the
"Core System" which was recently won by Smiths/Windriver/Ada Core.
2) To the best of my knowledge, the contract for 7E7 FCE has not yet
been awarded. Anyone seen a press release?
I'm sure the development approach, languages and all that stuff will
become far clearer once we know who's actually won the work!
- Rod
^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-05-30 10:34 Rod Chapman @ 2004-06-03 8:18 ` Vernon Brown 2004-06-03 10:45 ` Martin Krischik 2004-06-03 15:52 ` Richard Riehle 0 siblings, 2 replies; 82+ messages in thread From: Vernon Brown @ 2004-06-03 8:18 UTC (permalink / raw) "Rod Chapman" <rod.chapman@praxis-cs.co.uk> wrote in message news:cf2c6063.0405300234.1663792@posting.google.com... > Jeffrey Carter <spam@spam.com> wrote in message news:<90Stc.15309$be.3117@newsread2.news.pas.earthlink.net>... > > Honeywell is advertising for a software engineer for 7E7 flight controls > > electronics. The requirements are "Demonstrated experience using C/C++". > > No mention of Ada. > I work for Honeywell ATS, but these comments are my own. I don't think I'm letting out any secrets here... Some content for 7E7 will be done in C++, just because it's too hard to attract a large number (100s) of engineers who know Ada, or are willing to learn Ada and want to live in Phoenix (it's 86 degrees right now at midnite!) However, a majority of the code will be written/converted to Ada95, just because we have so much Ada83 code to leverage from. I'm guessing the reason for only mentioning C/C++ in the ad is to get sufficient response so that prospective employee's can be interviewed and asked if they would mind learning Ada instead of using C++. In reality, flight control software is very likely to all be Ada95. Currently I don't believe C++ is being proposed for use in any DO178B Level A (safety critical) systems. > I don't think we should read too much into this. Two possibly useful > pieces of information: > > 1) The Flight Control Electronics (FCE) is not the same thing as the > "Core System" which was recently won by Smiths/Windriver/Ada Core. > The toolset supplied by Smiths contains no support for C++. Honeywell is on its own to add compatible C++ tools. > 2) To the best of my knowledge, the contract for 7E7 FCE has not yet > been awarded. Anyone seen a press release? > Correct. > I'm sure the development approach, languages and all that stuff will > become far clearer once we know who's actually won the work! Here's hoping it's Honeywell, 'cause then I'll get to teach a bunch more engineers Ada! Vernon ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-03 8:18 ` Vernon Brown @ 2004-06-03 10:45 ` Martin Krischik 2004-06-03 15:52 ` Richard Riehle 1 sibling, 0 replies; 82+ messages in thread From: Martin Krischik @ 2004-06-03 10:45 UTC (permalink / raw) Vernon Brown wrote: > I'm guessing the reason for only mentioning C/C++ in the ad is to get > sufficient response > so that prospective employee's can be interviewed and asked if they > would mind learning Ada instead of using C++. In reality, flight control > software is very likely to all be Ada95. Well, there is a slight problem with that approach: I am a C++ programmer who would love to switch to Ada. Hiding an opertunity like this is not helpfull here. But then I have never said no to learning a new language. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 82+ messages in thread
* Re: 7E7 Flight Controls Electronics 2004-06-03 8:18 ` Vernon Brown 2004-06-03 10:45 ` Martin Krischik @ 2004-06-03 15:52 ` Richard Riehle 1 sibling, 0 replies; 82+ messages in thread From: Richard Riehle @ 2004-06-03 15:52 UTC (permalink / raw) Aha! Finally an answer to my original question. It is interesting how we can bounce around all over the place in response to a simple question, dispensing advice, proclaiming our preferences, and ranting our doctrine before someone comes forward with exactly the information we were seeking. Thank you Vernon. I can now announce to my students that 7e7 will indeed be programmed largely in Ada. In fact, I am giving a briefing to a group of engineers next Friday on the subject of software practice in safety-critical environments, and this will be useful information. I also intend to introduce them to the ideas in SPARK along with other good stuff. Naturally, my briefing will not be biased toward Ada. Richard Riehle "Vernon Brown" <vernonrbrown@inficad.com> wrote in message news:40bedede$0$97756$4c5eba9e@news.getnet.net... > > I work for Honeywell ATS, but these comments are my own. > I don't think I'm letting out any secrets here... > Some content for 7E7 will be done in C++, just > because it's too hard to attract a large number (100s) of engineers who > know Ada, or are willing to learn Ada and want to live in Phoenix (it's 86 > degrees > right now at midnite!) > > However, a majority of the code will be written/converted to Ada95, just > because we > have so much Ada83 code to leverage from. > I'm guessing the reason for only mentioning C/C++ in the ad is to get > sufficient response > so that prospective employee's can be interviewed and asked if they > would mind learning Ada instead of using C++. In reality, flight control > software is very likely to all be Ada95. > Currently I don't believe C++ is being proposed for use in any DO178B Level > A > (safety critical) systems. > ^ permalink raw reply [flat|nested] 82+ messages in thread
end of thread, other threads:[~2004-06-15 16:07 UTC | newest] Thread overview: 82+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-05-29 1:51 7E7 Flight Controls Electronics Jeffrey Carter 2004-05-29 10:21 ` Per Dalgas Jakobsen 2004-05-29 12:58 ` Marin David Condic 2004-05-29 13:35 ` Ed Falis 2004-05-29 17:29 ` Marin David Condic 2004-05-29 17:40 ` Ed Falis 2004-05-29 18:44 ` Marin David Condic 2004-05-29 18:58 ` Ed Falis 2004-05-30 7:55 ` Pascal Obry 2004-05-30 11:43 ` Georg Bauhaus 2004-05-30 16:10 ` Pascal Obry 2004-05-31 11:56 ` Marin David Condic 2004-05-29 17:48 ` Wes Groleau 2004-05-29 18:53 ` Marin David Condic [not found] ` <n42jb05e8rk7bsrtf2ikesu9t0bsmbphji@4ax.com> 2004-05-31 12:04 ` Marin David Condic 2004-06-06 10:35 ` I R T 2004-05-30 7:50 ` Pascal Obry 2004-05-31 12:25 ` Marin David Condic 2004-06-02 16:45 ` Warren W. Gay VE3WWG 2004-06-02 17:48 ` Martin Dowie 2004-06-03 15:57 ` Warren W. Gay VE3WWG 2004-06-03 0:09 ` Marin David Condic 2004-06-03 1:08 ` Ed Falis 2004-06-03 12:06 ` Marin David Condic 2004-06-03 12:33 ` Ed Falis 2004-06-03 16:44 ` Wes Groleau 2004-06-03 17:52 ` tmoran 2004-06-04 1:13 ` Jeffrey Carter 2004-06-04 11:27 ` Marin David Condic 2004-06-04 18:38 ` Jeffrey Carter 2004-06-06 21:37 ` Leon Winslow 2004-06-07 11:08 ` I R T 2004-06-08 2:22 ` Richard Riehle 2004-06-08 9:07 ` I R T 2004-06-08 11:33 ` Marin David Condic 2004-06-09 21:02 ` Robert I. Eachus 2004-06-09 21:22 ` Ed Falis 2004-06-09 23:30 ` Richard Riehle 2004-06-10 2:02 ` Jeffrey Carter 2004-06-10 2:27 ` Ed Falis 2004-06-10 19:54 ` Jeffrey Carter [not found] ` <28rfc01rhesdk2qt27krrr65nnk0n0kihc@4ax.com> 2004-06-12 3:01 ` non sequitur Robert I. Eachus 2004-06-11 16:51 ` 7E7 Flight Controls Electronics (COBOL Popularity) Warren W. Gay VE3WWG 2004-06-11 17:18 ` Marin David Condic 2004-06-11 18:49 ` Richard Riehle 2004-06-11 19:07 ` Marin David Condic 2004-06-11 20:39 ` Warren W. Gay VE3WWG 2004-06-12 11:16 ` Georg Bauhaus 2004-06-11 21:05 ` Frank J. Lhota 2004-06-14 12:46 ` Warren W. Gay VE3WWG 2004-06-07 11:19 ` 7E7 Flight Controls Electronics Marin David Condic 2004-06-07 22:24 ` Alexander E. Kopilovich 2004-06-08 1:11 ` Marin David Condic 2004-06-08 2:35 ` Richard Riehle 2004-06-08 6:59 ` tmoran 2004-06-08 19:44 ` Wes Groleau 2004-06-09 1:32 ` Alexander E. Kopilovich 2004-06-09 6:23 ` Richard Riehle 2004-06-09 7:09 ` Martin Dowie 2004-06-10 1:41 ` Alexander E. Kopilovich 2004-06-10 6:13 ` Richard Riehle 2004-06-11 2:03 ` Alexander E. Kopilovich 2004-06-12 2:31 ` Robert I. Eachus 2004-06-15 16:07 ` Richard Riehle 2004-06-09 7:54 ` Dmitry A. Kazakov 2004-06-09 6:31 ` Robert I. Eachus 2004-06-09 9:43 ` I R T 2004-06-09 15:28 ` Jerry Petrey 2004-05-29 15:58 ` Preben Randhol 2004-05-29 17:45 ` Marin David Condic 2004-05-29 17:51 ` Ed Falis 2004-05-29 19:55 ` Jeffrey Carter 2004-05-30 7:57 ` Pascal Obry 2004-05-30 18:35 ` Richard Riehle 2004-05-31 12:38 ` Marin David Condic 2004-06-04 12:56 ` Warren W. Gay VE3WWG 2004-06-05 8:49 ` Pascal Obry 2004-06-06 10:27 ` I R T -- strict thread matches above, loose matches on Subject: below -- 2004-05-30 10:34 Rod Chapman 2004-06-03 8:18 ` Vernon Brown 2004-06-03 10:45 ` Martin Krischik 2004-06-03 15:52 ` Richard Riehle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox