Mainstream Ada

Mainstream Ada

[Al Mole]

What I find slightly frustrating about this newsgroup - and about friends
who are still working in Ada in defence - is the lack of acknowledgement of
what the rest of the world is doing.

The cost of bad code and bad coding practice might not be literally counted
in terms of lives outside the defence and aerospace industries but I reckon
avoidable maintenance has cost me 5 years of my life and I'd guess that
added up over the software community as a whole we're talking thousands of
man years.

Add to that the man years involved in sorting out problems like Code Red and
Nimda (to name two that are the result of bad code) and we're looking at an
awful lot of wasted life.

And this is without counting the financial loss.

Is there any chance of good programming principles, practice and tools going
mainstream ? I've been fighting a losing battle in telecoms for the last 10
years.

Is Ada the right language ? Can it be sold mainstream ?

Re: Mainstream Ada

[Richard Riehle]

Al Mole wrote:

> Is Ada the right language ? Can it be sold mainstream ?

Once the reputation of a virtuous person is sullied by widespread
prevarication, it is difficult to overcome the public perception,
however wrong it may be.

Ada is the right language for many applications where dependability
is a key non-functional requirement.     At present, functional
requirements overshadow non-functional requirements in the world
of commercial software.   That is, features are easier to sell than
quality.   As the users of software products mature and become more
demanding, we may see quality issues become more important.
At present, the major purveyors of software products, especially
those who sell operating systems, have put "bells and whistles"
over quality.

The phenomenon is somewhat analogous to the carrot and stick
technique horse motivation.    We consumers are so fascinated
with the prospects of eating the carrot that we never quite get
it that the stick keeps it out of reach of our teeth.

Richard Riehle

Re: Mainstream Ada

[Hyman Rosen]

Richard Riehle wrote:
> At present, functional requirements overshadow non-functional
 > requirements in the world of commercial software. That is,
 > features are easier to sell than quality.

You know we usually fight over Ada vs. C++ issues, but I think
I'm going to take Ada's side here. I don't like Ada all that
much, but it's mostly for stylistic reasons. I believe, however,
that an Ada programmer can pound out features just as well, and
just as quickly, as a Java or C++ programmer. Are you really
suggesting that commercial software developers who choose Ada
will have to forego adding features to their software? That's
not going to do much for Ada advocacy!

Re: Mainstream Ada

[Larry Kilgallen]

In article <3C78943B.9030600@mail.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Richard Riehle wrote:
>> At present, functional requirements overshadow non-functional
>  > requirements in the world of commercial software. That is,
>  > features are easier to sell than quality.
> 
> You know we usually fight over Ada vs. C++ issues, but I think
> I'm going to take Ada's side here. I don't like Ada all that
> much, but it's mostly for stylistic reasons. I believe, however,
> that an Ada programmer can pound out features just as well, and
> just as quickly, as a Java or C++ programmer. Are you really
> suggesting that commercial software developers who choose Ada
> will have to forego adding features to their software? That's
> not going to do much for Ada advocacy!

I am not Richard, but I agree with the quoted segment.  The point
I see is that language choice can be orthogonal to the quest for
features.  So long as features are the only concern of a vendor,
one can relegate language choice to an afterthought.  A typical
approach is to look at the employment pool will say that you can
get a nominal C++ programmer much more readily than a nominal Ada
programmer.  Companies without a particular concern for quality
will gravitate to those who appear to be in greater number and
choose the "popular" language.  Programmers equally unqualified
in either language will declare themselves as belonging to the
more "popular" language.  And certainly as a C++ advocate, you
must agree that a lot of nominal "C/C++" programmers are "C"
programmers in disguise.

So it is not that developers who choose Ada need to forgo features.
Rather, it is that developers who choose features over quality
have no particular incentive to choose Ada.  Those nasty checks
will get in the way of time-to-market.

Re: Mainstream Ada

[Jim Rogers]

Larry Kilgallen wrote:

> So it is not that developers who choose Ada need to forgo features.
> Rather, it is that developers who choose features over quality
> have no particular incentive to choose Ada.  Those nasty checks
> will get in the way of time-to-market.
> 


I would state this a little bit differently.
Those nasty checks are perceived to get in the way of time-to-market.

My personal experience is that those nasty checks improve
time-to-market by catching a lot of critical errors very early
in the development cycle.

I have told this story before in this forum, but I will repeat it
here.

My previous job put me in the position of software lead in a small
privately held company doing robotics work. I hired in two more
software engineers to complete the software development team.
We were developing a robotic control system under a contract to the
US Army. We were also tasked to be the first shop in the world to
implement the Army's Joint Architecture for Unmanned Ground
Systems (JAUGS). Our company chose Ada.

I was able to hire two highly experienced Ada software engineers.
One had 15 years experience developing software to control radar
systems for the US Air Force. The other had 10 years experience
developing jet engine control software for Pratt and Whitney.

The three of us took the project from initial requirements through
final qualification tests in two years, producing 200K SLOC.
This project was subject to normal DoD processes including design
reviews by the customer, and copious formal documentation.

During the same period I was our company representative on the
JAUGS Working Group, refining the JAUGS architecture. Other
members of the working group came from industry (i.e. Boeing and
SAIC and others), Government (i.e. US Navy, Department of Energy,
National Institute of Standards and Testing, Army Missile Command),
and academia (i.e. University of Florida). All the other members
of the working group were using C++ to develop their own systems.
All the other groups had much larger development teams than my
company. We were the only group that produced an entirely new
system from the beginning. All the other groups managed to add
one or two features to their existing platforms in the same
time period.

I am convinced we could not have achieved the same level of
productivity in the robotics domain using any other language.

What ever happened to that robotic system?

The owner of the company became blinded by his own narcissism.
He laid off the entire software team just before the Army
accepted the project. The Army was shocked by this behavior and
pulled the contract from the company. The company has gone from
about 75 people to about 4 people since then.


Jim Rogers

Re: Mainstream Ada

[Marin David Condic]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:y4d4w9HEmatp@eisner.encompasserve.org...
>
> I am not Richard, but I agree with the quoted segment.  The point
> I see is that language choice can be orthogonal to the quest for
> features.  So long as features are the only concern of a vendor,

Consider it this way: If using language X provides me with lots of libraries
and tools and support and language Y means I've got to build some/most/all
of this up from bottom-dead-center, then things like "reliability" start
taking a back seat. If, otoh, Language Y starts offering me tools,
libraries, support *and* high reliability, then it starts becoming more
attractive as a choice.

Likewise, from the end-user's side, the perspective is one of "what are the
things I can *do* with this software and how does that help me get my
mission accomplished?" From that angle, a few crashes in exchange for some
mission-accomplishing functionality starts becoming a good tradeoff. Now if
you can offer *both* features and high quality, you've got a real winner...

(Side note: I'm beginning to wonder if end users are really as feature-crazy
as the original comments suggest. Isn't Microsoft out there trying to find
all sorts of new marketing angles because end users are going "I really
don't need Word to do anything more than its doing already so thanks but no
thanks, I don't need your upgrade...")

> one can relegate language choice to an afterthought.  A typical
> approach is to look at the employment pool will say that you can
> get a nominal C++ programmer much more readily than a nominal Ada
> programmer.  Companies without a particular concern for quality
> will gravitate to those who appear to be in greater number and
> choose the "popular" language.  Programmers equally unqualified
> in either language will declare themselves as belonging to the
> more "popular" language.  And certainly as a C++ advocate, you
> must agree that a lot of nominal "C/C++" programmers are "C"
> programmers in disguise.
>

A bit of a red herring. Languages that have offered the market something
useful that the market was inclined to want have found acceptance. How did
Java get a toe-hold from nothing to something in a fairly short time? There
was a time when there were no Java programmers - yet companies adopted it  &
got their people up to speed using it because it offered them something they
weren't getting other ways.


> So it is not that developers who choose Ada need to forgo features.
> Rather, it is that developers who choose features over quality
> have no particular incentive to choose Ada.  Those nasty checks
> will get in the way of time-to-market.

I doubt the checks get in the way of time-to-market. I think that (all other
things being equal) the checks hasten time-to-market. I think that's
demonstrable at the bottom line where business decision makers concentrate.

Just beware that the langage that ignores time-to-market does so at its own
risk... :-)

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

Re: Mainstream Ada

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<3C78943B.9030600@mail.com>...
> Richard Riehle wrote:
> > At present, functional requirements overshadow non-functional
>  > requirements in the world of commercial software. That is,
>  > features are easier to sell than quality.
> 
> You know we usually fight over Ada vs. C++ issues, but I think
> I'm going to take Ada's side here. I don't like Ada all that
> much, but it's mostly for stylistic reasons. I believe, however,
> that an Ada programmer can pound out features just as well, and
> just as quickly, as a Java or C++ programmer. Are you really
> suggesting that commercial software developers who choose Ada
> will have to forego adding features to their software? That's
> not going to do much for Ada advocacy!

I understand Richard to be saying that "pounding out features" can be
done in any number of languages, with Ada offering no great advantage
*or disadvantage* in this area, while in the development of reliable
software Ada does offer a great advantage.  Thus, feature-pounders
will have no reason to switch from their comfort language, while
quality-seekers will, in a great many cases, have a reason.

Mike

Re: Mainstream Ada

[Richard Riehle]

Hyman Rosen wrote:

> Richard Riehle wrote:
> > At present, functional requirements overshadow non-functional
>  > requirements in the world of commercial software. That is,
>  > features are easier to sell than quality.
>
> You know we usually fight over Ada vs. C++ issues, but I think
> I'm going to take Ada's side here. I don't like Ada all that
> much, but it's mostly for stylistic reasons. I believe, however,
> that an Ada programmer can pound out features just as well, and
> just as quickly, as a Java or C++ programmer. Are you really
> suggesting that commercial software developers who choose Ada
> will have to forego adding features to their software? That's
> not going to do much for Ada advocacy!

Clever response, Dr. Rosen, but its intent is rather transparent.
We both know it is a wrong interpretation of my message, and
intended only as a provocation, not as a serious comment.

Richard Riehle

Re: Mainstream Ada

[Hyman Rosen]

Richard Riehle wrote:
> Clever response, Dr. Rosen, but its intent is rather transparent.
> We both know it is a wrong interpretation of my message, and
> intended only as a provocation, not as a serious comment.

It's just "Mr. Rosen" - I only have a B.E.E. I was really being
serious, not satirical, but perhaps I misunderstood what you were
trying to say. I thought you were saying that developers choose a
language which will allow them to add more features to their code.
Did you instead mean that developers choose a lnaguage which has
more features? Even so, I think Ada can hold its own for number of
features against other languages!

As I have said before, I dislike Ada mostly for its looks, not its
content. I certainly don't bear the language any ill will. And I
don't really think I troll, just tease a little. I will defend C++
against incorrect statements, and vigorously, but there's nothing
wrong with that.

Thinking about Ada style, I am reminded of some lines from the old
filk song, "Write in C" (to the tune of "Let It Be") -

	I hate the word "procedure", write in C.
	The government loves Ada, write in C.

{ducking} :-)

Re: Mainstream Ada

[Richard Riehle]

Hyman Rosen wrote:

> It's just "Mr. Rosen" - I only have a B.E.E. I was really being
> serious, not satirical, but perhaps I misunderstood what you were
> trying to say. I thought you were saying that developers choose a
> language which will allow them to add more features to their code.
> Did you instead mean that developers choose a lnaguage which has
> more features? Even so, I think Ada can hold its own for number of
> features against other languages!

OK.  I understand.   Let me clarify.   I meant that, it is much easier
to
simply add features than to consider quality.    Sadly, I see this
happen
with Ada developers as well as with developers in other languages.

> As I have said before, I dislike Ada mostly for its looks, not its
> content.

I am reminded of the cartoon vamp, Jessica, in "Who Killed Roger
Rabbit" when she says, "I'm not really bad.  I'm just drawn that way."

> I certainly don't bear the language any ill will. And I
> don't really think I troll, just tease a little. I will defend C++
> against incorrect statements, and vigorously, but there's nothing
> wrong with that.

Nothing at all.   I have even defended it myself from time to time.
In fact, I am currently defending it against a bunch of people who
want to replace it with Visual Basic.   Yuckkk!

> Thinking about Ada style, I am reminded of some lines from the old
> filk song, "Write in C" (to the tune of "Let It Be") -
>
>         I hate the word "procedure", write in C.
>         The government loves Ada, write in C.
>
> {ducking} :-)

Swung on and missed.    :-)

Richard Riehle

Re: Mainstream Ada

[Kevin Cline]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<3C78943B.9030600@mail.com>...
> Richard Riehle wrote:
> > At present, functional requirements overshadow non-functional
>  > requirements in the world of commercial software. That is,
>  > features are easier to sell than quality.
> 
> You know we usually fight over Ada vs. C++ issues, but I think
> I'm going to take Ada's side here. I don't like Ada all that
> much, but it's mostly for stylistic reasons. I believe, however,
> that an Ada programmer can pound out features just as well, and
> just as quickly, as a Java or C++ programmer. Are you really
> suggesting that commercial software developers who choose Ada
> will have to forego adding features to their software? 

The fundamental problem continues to be the lack of high-quality
bindings to non-Ada facilities, e.g. OpenGL, Qt, relational databases, etc.
This does indeed make it much more difficult to add features
to Ada applications.

Re: Mainstream Ada

[Joachim Schröer]

Kevin Cline wrote:

> Hyman Rosen <hyrosen@mail.com> wrote in message news:<3C78943B.9030600@mail.com>...
> 
>>Richard Riehle wrote:
>>
>>>At present, functional requirements overshadow non-functional
>>>
>> > requirements in the world of commercial software. That is,
>> > features are easier to sell than quality.
>>
>>You know we usually fight over Ada vs. C++ issues, but I think
>>I'm going to take Ada's side here. I don't like Ada all that
>>much, but it's mostly for stylistic reasons. I believe, however,
>>that an Ada programmer can pound out features just as well, and
>>just as quickly, as a Java or C++ programmer. Are you really
>>suggesting that commercial software developers who choose Ada
>>will have to forego adding features to their software? 
>>
> 
> The fundamental problem continues to be the lack of high-quality
> bindings to non-Ada facilities, e.g. OpenGL, Qt, relational databases, etc.
> This does indeed make it much more difficult to add features
> to Ada applications.
> 

There are bindings to nearly all important libraries. I developed the
instrument displays of flight simulators in Ada on top of OpenGL.
The kernel of the class library is free and can be found on
	www.adapower.com/schroer
There is also the possibility to generate your own bindings e.g.
with C2Ada.


Best regards
	J. Schr�er

Re: Mainstream Ada

[Al Mole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

Would you say it was advisable to attempt a games engine in Ada using the
OpenGL bindings ?

"Joachim Schr�er" <joachim.schroeer@dornier.eads.net> wrote in message
news:3C8601CB.6050906@dornier.eads.net...
> Kevin Cline wrote:
>
> > Hyman Rosen <hyrosen@mail.com> wrote in message
news:<3C78943B.9030600@mail.com>...
> >
> >>Richard Riehle wrote:
> >>
> >>>At present, functional requirements overshadow non-functional
> >>>
> >> > requirements in the world of commercial software. That is,
> >> > features are easier to sell than quality.
> >>
> >>You know we usually fight over Ada vs. C++ issues, but I think
> >>I'm going to take Ada's side here. I don't like Ada all that
> >>much, but it's mostly for stylistic reasons. I believe, however,
> >>that an Ada programmer can pound out features just as well, and
> >>just as quickly, as a Java or C++ programmer. Are you really
> >>suggesting that commercial software developers who choose Ada
> >>will have to forego adding features to their software?
> >>
> >
> > The fundamental problem continues to be the lack of high-quality
> > bindings to non-Ada facilities, e.g. OpenGL, Qt, relational databases,
etc.
> > This does indeed make it much more difficult to add features
> > to Ada applications.
> >
>
> There are bindings to nearly all important libraries. I developed the
> instrument displays of flight simulators in Ada on top of OpenGL.
> The kernel of the class library is free and can be found on
> www.adapower.com/schroer
> There is also the possibility to generate your own bindings e.g.
> with C2Ada.
>
>
> Best regards
> J. Schr�er
>

Re: Mainstream Ada

[Joachim Schröer]

Al Mole wrote:

> Would you say it was advisable to attempt a games engine in Ada using the
> OpenGL bindings ?
> 


Why not? I think it has been done already. There were some threads
on CLA concerning this topic.
My experience is mainly 2D with a few 3D components you need for
flight instruments (except this XEarth variant published on the link I 
gave yesterday).
The key abstractions I made may be implemented in each OO language as
there is: incorporate the state of a rigid body
(3D position and 3D attitude) in the object; push/pop the modelview
matrix before translate/rotate using that state. So you may implement
modular graphical objects using relative coordinate systems.
But in Ada besides finding errors early you have some benefits, e.g.:
Neither in the Win32 nor in the GLUT implementation I got these bloody
timers to work. So I implemented animation by an extra task. Or:
A C-program generated from a Simulink aircraft model feeds the OpenGL
program with the actual aircraft state which is used to drive the
instruments. The flight model runs with a fixed frequency that is
dictated to stabilize the simulator control loops. The OpenGL program
runs as fast as the actual OpenGL HW allows. A protected object
synchronizes the access to this data. I newer used semaphores or so
to solve those kind of problems. You just don't need to care about this
low level stuff. And the Java guys with their synchronized and thread
classes may impress a C++ programmer but no Ada95 one.

Best regards


> "Joachim Schr�er" <joachim.schroeer@dornier.eads.net> wrote in message
> news:3C8601CB.6050906@dornier.eads.net...
> 
>>Kevin Cline wrote:
>>
>>
>>>Hyman Rosen <hyrosen@mail.com> wrote in message
>>>
> news:<3C78943B.9030600@mail.com>...
> 
>>>>Richard Riehle wrote:
>>>>
>>>>
>>>>>At present, functional requirements overshadow non-functional
>>>>>
>>>>>requirements in the world of commercial software. That is,
>>>>>features are easier to sell than quality.
>>>>>
>>>>You know we usually fight over Ada vs. C++ issues, but I think
>>>>I'm going to take Ada's side here. I don't like Ada all that
>>>>much, but it's mostly for stylistic reasons. I believe, however,
>>>>that an Ada programmer can pound out features just as well, and
>>>>just as quickly, as a Java or C++ programmer. Are you really
>>>>suggesting that commercial software developers who choose Ada
>>>>will have to forego adding features to their software?
>>>>
>>>>
>>>The fundamental problem continues to be the lack of high-quality
>>>bindings to non-Ada facilities, e.g. OpenGL, Qt, relational databases,
>>>
> etc.
> 
>>>This does indeed make it much more difficult to add features
>>>to Ada applications.
>>>
>>>
>>There are bindings to nearly all important libraries. I developed the
>>instrument displays of flight simulators in Ada on top of OpenGL.
>>The kernel of the class library is free and can be found on
>>www.adapower.com/schroer
>>There is also the possibility to generate your own bindings e.g.
>>with C2Ada.
>>
>>
>>Best regards
>>J. Schr�er
>>
>>
> 
> 

Re: Mainstream Ada

[Al Mole]

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3C77CF8C.93F1837@adaworks.com...
> Richard Riehle wrote:
>
> Ada is the right language for many applications where dependability
> is a key non-functional requirement.

Dependability might be a key non-functional requirement for most
applications ... if there's a choice

Re: Mainstream Ada

[Marin David Condic]

That's the first time in recent memory that I've heard someone use that
analogy correctly. Thanks. :-)

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


"Richard Riehle" <richard@adaworks.com> wrote in message
news:3C77CF8C.93F1837@adaworks.com...
>
> The phenomenon is somewhat analogous to the carrot and stick
> technique horse motivation.    We consumers are so fascinated
> with the prospects of eating the carrot that we never quite get
> it that the stick keeps it out of reach of our teeth.
>