7E7 Flight Controls Electronics

7E7 Flight Controls Electronics

[Jeffrey Carter]

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

Re: 7E7 Flight Controls Electronics

[Per Dalgas Jakobsen]

> 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

Re: 7E7 Flight Controls Electronics

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics

[Ed Falis]

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

Re: 7E7 Flight Controls Electronics

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics

[Ed Falis]

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

Re: 7E7 Flight Controls Electronics

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics

[Ed Falis]

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.

Re: 7E7 Flight Controls Electronics

[Pascal Obry]

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

Re: 7E7 Flight Controls Electronics

[Georg Bauhaus]

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

Re: 7E7 Flight Controls Electronics

[Pascal Obry]

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

Re: 7E7 Flight Controls Electronics

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics

[Wes Groleau]

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/

Re: 7E7 Flight Controls Electronics

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics

[I R T]

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.

Re: 7E7 Flight Controls Electronics

[Pascal Obry]

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

Re: 7E7 Flight Controls Electronics

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

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

Re: 7E7 Flight Controls Electronics

[Martin Dowie]

"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? :-)

Re: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

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

Re: 7E7 Flight Controls Electronics

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics

[Ed Falis]

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

Re: 7E7 Flight Controls Electronics

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics

[Ed Falis]

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

Re: 7E7 Flight Controls Electronics

[Wes Groleau]

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

Re: 7E7 Flight Controls Electronics

[tmoran]

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.

Re: 7E7 Flight Controls Electronics

[Jeffrey Carter]

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

Re: 7E7 Flight Controls Electronics

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics

[Jeffrey Carter]

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

Re: 7E7 Flight Controls Electronics

[Leon Winslow]

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

Re: 7E7 Flight Controls Electronics

[I R T]

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.

Re: 7E7 Flight Controls Electronics

[Richard Riehle]

"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

Re: 7E7 Flight Controls Electronics

[I R T]

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

Re: 7E7 Flight Controls Electronics

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics

[Robert I. Eachus]

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

Re: 7E7 Flight Controls Electronics

[Ed Falis]

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

Re: 7E7 Flight Controls Electronics

[Richard Riehle]

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

Re: 7E7 Flight Controls Electronics

[Jeffrey Carter]

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

Re: 7E7 Flight Controls Electronics

[Ed Falis]

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

Re: 7E7 Flight Controls Electronics

[Jeffrey Carter]

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

Re: non sequitur

[Robert I. Eachus]

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

Re: 7E7 Flight Controls Electronics (COBOL Popularity)

[Warren W. Gay VE3WWG]

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

Re: 7E7 Flight Controls Electronics (COBOL Popularity)

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics (COBOL Popularity)

[Richard Riehle]

"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

Re: 7E7 Flight Controls Electronics (COBOL Popularity)

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics (COBOL Popularity)

[Warren W. Gay VE3WWG]

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

Re: 7E7 Flight Controls Electronics (COBOL Popularity)

[Georg Bauhaus]

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.

Re: 7E7 Flight Controls Electronics (COBOL Popularity)

[Frank J. Lhota]

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

Re: 7E7 Flight Controls Electronics (COBOL Popularity)

[Warren W. Gay VE3WWG]

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

Re: 7E7 Flight Controls Electronics

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics

[Alexander E. Kopilovich]

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

Re: 7E7 Flight Controls Electronics

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics

[Richard Riehle]

"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

Re: 7E7 Flight Controls Electronics

[tmoran]

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

Re: 7E7 Flight Controls Electronics

[Wes Groleau]

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

Re: 7E7 Flight Controls Electronics

[Alexander E. Kopilovich]

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

Re: 7E7 Flight Controls Electronics

[Richard Riehle]

"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

Re: 7E7 Flight Controls Electronics

[Martin Dowie]

"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

Re: 7E7 Flight Controls Electronics

[Alexander E. Kopilovich]

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

Re: 7E7 Flight Controls Electronics

[Richard Riehle]

"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

Re: 7E7 Flight Controls Electronics

[Alexander E. Kopilovich]

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

Re: 7E7 Flight Controls Electronics

[Robert I. Eachus]

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

Re: 7E7 Flight Controls Electronics

[Richard Riehle]

"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

Re: 7E7 Flight Controls Electronics

[Dmitry A. Kazakov]

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

Re: 7E7 Flight Controls Electronics

[Robert I. Eachus]

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

Re: 7E7 Flight Controls Electronics

[I R T]

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

Re: 7E7 Flight Controls Electronics

[Jerry Petrey]

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

Re: 7E7 Flight Controls Electronics

[Preben Randhol]

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

Re: 7E7 Flight Controls Electronics

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics

[Ed Falis]

> 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

Re: 7E7 Flight Controls Electronics

[Jeffrey Carter]

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

Re: 7E7 Flight Controls Electronics

[Pascal Obry]

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

Re: 7E7 Flight Controls Electronics

[Richard Riehle]

"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

Re: 7E7 Flight Controls Electronics

[Marin David Condic]

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

======================================================================

Re: 7E7 Flight Controls Electronics

[Warren W. Gay VE3WWG]

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

Re: 7E7 Flight Controls Electronics

[Pascal Obry]

"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

Re: 7E7 Flight Controls Electronics

[I R T]

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.

7E7 Flight Controls Electronics

[Rod Chapman]

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

Re: 7E7 Flight Controls Electronics

[Vernon Brown]

"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

Re: 7E7 Flight Controls Electronics

[Martin Krischik]

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

Re: 7E7 Flight Controls Electronics

[Richard Riehle]

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