The future of Ada

The future of Ada

[Gordon Dodrill]

A few weeks ago someone in this newsgroup mentioned that 
Ada is a $100M industry.  If this number is reasonable, 
then assuming a loaded salary of $120K per year, there are
only about 830 full time Ada developers.

I attended the JavaOne conference in the spring of 1998 
which had over 15,000 in attendance.  I also attended the 
SigAda conference in St Louis in the Fall of 1997, which
had less than 400 in attendance.  I understand that the
Software Development conference (West), which is heavily
oriented toward C++, is still attracting about 6,000 
attendees

I am completely sold on Ada concerning its type safety and
its economy of use.  In fact, I am the local Ada evangelist
and successfully convinced a group of 18 developers to use
Ada on a new project.  This involved teaching a beginning 
class in Ada myself, then having Ben Brosgol teach an 
advanced Ada class at our location last May.

Ten months into the project, the project leader announced
very abruptly that Ada would be scrapped, C++ would be used,
and there would be a six month slip in the project to permit
training in C++ and rewriting the  completed Ada code.  His 
reason - "There may not be any Ada programmers to do 
maintenance several years from now, but we will always be 
able to get C++ programmers."

I am obviously frustrated.  How can I continue to promote 
the use of Ada when the numbers mentioned in the first two 
paragraphs above indicate a lack of growth in Ada compared
to the other languages?  Any thoughts, either positive or
negative, will be appreciated.

Gordon Dodrill
Sandia National Laboratories - Albuquerque, New Mexico

Re: The future of Ada

[Richard D Riehle]

In article <36E690FA.4B9C@sandia.gov>,
	Gordon Dodrill <gjdodri@sandia.gov> wrote:

>Ten months into the project, the project leader announced
>very abruptly that Ada would be scrapped, C++ would be used,
>and there would be a six month slip in the project to permit
>training in C++ and rewriting the  completed Ada code.  His 
>reason - "There may not be any Ada programmers to do 
>maintenance several years from now, but we will always be 
>able to get C++ programmers."

 A project manager who makes this kind of decision probably does
 not understand Ada or C++.  This kind of stupidity abounds. 
 The one thing that seems to work out is, once a team that 
 was programming Ada starts to really learn C++, they begin to 
 realize the serious risks of associated with C++.  Unfortunately, 
 it is often too late to once again reverse the decision.  
 This is sometimes called "buyer's remorse."  The decision to 
 abandon Ada in favor of C++ is almost always wrong.  It is 
 certainly wrong for safety-critical software, which is what 
 most of the weapons systems are.

>I am obviously frustrated.  How can I continue to promote 
>the use of Ada when the numbers ...

 How can you possibly eat at a salad bar when the numbers of
 burger franchises clearly outnumber the number of salad bars?

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com
 

Re: The future of Ada

[Tom Moran]

And the number, availability, and cheap labor rate of short-order
cooks greatly exceeds that of chefs.

Re: The future of Ada

[Steve O'Neill]

Richard D Riehle wrote:
> 
> In article <36E690FA.4B9C@sandia.gov>,
>         Gordon Dodrill <gjdodri@sandia.gov> wrote:
> 
> >Ten months into the project, the project leader announced
> >very abruptly that Ada would be scrapped, C++ would be used,
> >and there would be a six month slip in the project to permit
> >training in C++ and rewriting the  completed Ada code.  His
> >reason - "There may not be any Ada programmers to do
> >maintenance several years from now, but we will always be
> >able to get C++ programmers."
> 
>  A project manager who makes this kind of decision probably does
>  not understand Ada or C++.  This kind of stupidity abounds.

Indeed it does.  I'm witnessing this very stupidity taking place but at
a corporate level.  The decision is not being made on technical merit of
the languages but on the fact that Ada developers are harder to find and
more expensive.  They make no consideration for the potential benefits
and detriments of the languages merely that C++ programmers are a 'dime
a dozen'.  Something about getting what you pay for comes to mind...

>  The one thing that seems to work out is, once a team that
>  was programming Ada starts to really learn C++, they begin to
>  realize the serious risks of associated with C++.  Unfortunately,
>  it is often too late to once again reverse the decision.
>  This is sometimes called "buyer's remorse."  The decision to
>  abandon Ada in favor of C++ is almost always wrong.  It is
>  certainly wrong for safety-critical software, which is what
>  most of the weapons systems are.

There is also a strong 'Ada is too complicated' feeling within this
company.  The fact that they have not learned to properly use the
language does not cross their minds.  But they think nothing of taking
the leap to C++ which I consider to be more complicated and more
difficult to use properly than Ada.  But, nonetheless, they will make
this leap and I suspect in a few years will be back in the very same
situation.

I unfortunately gave up tilting at this windmill.

Steve O'Neill

Re: The future of Ada

[Al Christians]

Gordon Dodrill wrote:
> 
> A few weeks ago someone in this newsgroup mentioned that
> Ada is a $100M industry.  If this number is reasonable,
> then assuming a loaded salary of $120K per year, there are
> only about 830 full time Ada developers.
> 

This is a complete non-sequitur.  The $100MM figure was given 
as the worldwide market volume for Ada tools.  If spending on 
tools is (pick a number) $5,000 per tool-user, per year, that 
is 20,000 developers worldwide using Ada.  Figure 1% of the C++
market.

Although Ada is designed to give long-run benefits, if you are 
making good use of Ada and it meets your requirements,  it may
also be giving you substantial short-run financial benefits,
i.e. lower cost this year to develop what you must develop this
year.  Management always likes short-run benefits, i.e. fast $.
Tell them that even if you ultimately have to convert to C++,
there is a big and expensive productivity chasm during the period
in which the change is made, and that you can finance the switch
with the savings from using Ada for a while longer.  Then, if and 
when Ada gets to be more exensive than C++, you can take the leap. 
Maybe that day will never come.  

If that doesn't work, then tell them that Java is much more 
like Ada and would be easier to switch to than C++.  Tell them 
that it would be wise to wait for Java to stabilize, for better
Java development tools to proliferate, and for more efficient Java
VM's to show up.  That when Java gets to be a better choice than
Ada, you will change to Java instead.  That day might never come
either.

Al

Re: The future of Ada

[dewar]

In article <36E6ADE7.86A76235@easystreet.com>,
  Al Christians <achrist@easystreet.com> wrote:
> This is a complete non-sequitur.  The $100MM figure was
> given as the worldwide market volume for Ada tools.  If
> spending on tools is (pick a number) $5,000 per
> tool-user, per year, that is 20,000 developers worldwide
> using Ada.  Figure 1% of the C++ market.

I think $5000/year/developer is far too high a figure. Yes
I know some of our competitors charge more than for GNAT,
but some of our competitors also charge less. That figure
is too high by a factor.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[robert_dewar]

In article <36E690FA.4B9C@sandia.gov>,
  gjdodri@sandia.gov wrote:
> I am obviously frustrated.  How can I continue to promote
> the use of Ada when the numbers mentioned in the first
> two paragraphs above indicate a lack of growth in Ada
> compared to the other languages?  Any thoughts, either
> positive or negative, will be appreciated.

Clearly some old projects will drop Ada, and some new
projects will adopt Ada, and some other projects will
just continue to use Ada.

We see far more people adopting Ada, but that may be
because we stress the move to Ada 95, and did so early,
and also the open source nature of GNAT is what encourages
some companies to consider the Ada route in the first
place.

How to measure the overall situation? Difficult of course.
Ada Core Technologies sees a rapid growth in its business,
and the future is looking bright. Now is this at the
expense of other vendors? Well part of it is of course,
that is the nature of competition, but on the other hand,
the other vendors are finding their Ada business healthy
as well -- go ask them :-)

So from where we sit, we see Ada has having a steady, long,
and bright future. We do not count on the wishful thinking
that everyone will drop VB on PC's and adopt Ada (and we
don't think this will happen even if all sorts of wondrous
"visual Ada" stuff were to appear). On the other hand, the
niche that Ada occupies -- large scale high quality
software -- is a pretty important niche and not one that
is going to go away in a hurry.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[dennison]

In article <36E690FA.4B9C@sandia.gov>,
  gjdodri@sandia.gov wrote:
> A few weeks ago someone in this newsgroup mentioned that
> Ada is a $100M industry.  If this number is reasonable,
> then assuming a loaded salary of $120K per year, there are
> only about 830 full time Ada developers.
>
> which had over 15,000 in attendance.  I also attended the
> SigAda conference in St Louis in the Fall of 1997, which
> had less than 400 in attendance.  I understand that the

So nearly %50 of all the Ada developers in the world went to St. Louis for
SigAda? I doubt it.

> its economy of use.  In fact, I am the local Ada evangelist
> and successfully convinced a group of 18 developers to use
> Ada on a new project.  This involved teaching a beginning

That's %2 you had on your project alone!

Somehow, I think your math isn't quite right. Either $100M isn't right, or the
extrapolation you made to # of developers is wrong.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[Corey Ashford]

dennison@telepath.com wrote:
> 
> In article <36E690FA.4B9C@sandia.gov>,
>   gjdodri@sandia.gov wrote:
> > A few weeks ago someone in this newsgroup mentioned that
> > Ada is a $100M industry.  If this number is reasonable,
> > then assuming a loaded salary of $120K per year, there are
> > only about 830 full time Ada developers.
> >
> > which had over 15,000 in attendance.  I also attended the
> > SigAda conference in St Louis in the Fall of 1997, which
> > had less than 400 in attendance.  I understand that the
> 
> So nearly %50 of all the Ada developers in the world went to St. Louis for
> SigAda? I doubt it.
> 
> > its economy of use.  In fact, I am the local Ada evangelist
> > and successfully convinced a group of 18 developers to use
> > Ada on a new project.  This involved teaching a beginning
> 
> That's %2 you had on your project alone!
> 
> Somehow, I think your math isn't quite right. Either $100M isn't right, or the
> extrapolation you made to # of developers is wrong.
> 
> T.E.D.
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

Perhaps the $100M figure comes from the amount of money spent on tools
per year, not on the salaries of those who use the tools.

- Corey

Re: The future of Ada

[Larry Kilgallen]

In article <36E690FA.4B9C@sandia.gov>, Gordon Dodrill <gjdodri@sandia.gov> writes:
> A few weeks ago someone in this newsgroup mentioned that 
> Ada is a $100M industry.  If this number is reasonable, 
> then assuming a loaded salary of $120K per year, there are
> only about 830 full time Ada developers.

Wouldn't that be 830 people working full time on Ada compilers
and ancillary tools ?  That includes marketeers, but it certainly
does not include customers.

> Ten months into the project, the project leader announced
> very abruptly that Ada would be scrapped, C++ would be used,
> and there would be a six month slip in the project to permit
> training in C++ and rewriting the  completed Ada code.  His 
> reason - "There may not be any Ada programmers to do 
> maintenance several years from now, but we will always be 
> able to get C++ programmers."

Certainly one can look to other languages like Fortran and Cobol
where all programmers who knew the language suddenly disappeared
as soon as Visual C++ was released.  The same is likely to happen
for C++ programmers as soon as Java predominates.  I believe they
all joined the Mother Ship hiding behind that comet, or was it the
Borg who carted them away...

Counting on hiring people who know only one language and also
_cannot_be_trained_ seems like a risky way to run a business.
Even if the language they know is the one to be used, hiring
the untrainable is not a swift move.

> I am obviously frustrated.  How can I continue to promote 
> the use of Ada when the numbers mentioned in the first two 
> paragraphs above indicate a lack of growth in Ada compared
> to the other languages?  Any thoughts, either positive or
> negative, will be appreciated.

Obviously there are more than 830 people working on C++ compilers.
In fact, there may be more than 830 C++ compilers.  Certainly one
important aspect of marketing is product differentiation.  Surely
one must pause to contemplate a "standard" language that leaves
so much room for differentiation.

The metric in computing, as in many other endeavors, should be
how successful you are at doing it your way, rather than how many
other people are doing it your way.

As to why managers might make decisions on any other basis,
the UPN television stations are now broadcasting throughout
the US weekly showings of "Dilbert".

Larry Kilgallen

Re: The future of Ada

[dennison]

In article <1999Mar10.123912.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:

> The metric in computing, as in many other endeavors, should be
> how successful you are at doing it your way, rather than how many
> other people are doing it your way.

Bingo. Suppose C++ is the industry standard (a debatable point). Ask your
boss if he wants to go for the standard everything and have an "average"
environment, or does he want to try to be *better* than the competition?

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[dewar]

In article <36E690FA.4B9C@sandia.gov>,
  gjdodri@sandia.gov wrote
:
> A few weeks ago someone in this newsgroup mentioned that
> Ada is a $100M industry.  If this number is reasonable,
> then assuming a loaded salary of $120K per year, there
> are only about 830 full time Ada developers.

No, no, no! You have it completely wrong. The $100M
industry is the market for Ada tools and compilers, not
for programs written in Ada.

So what your calculation says is that there are some 830 or
so people involved in the production of Ada tools and
compilers.

THat's a goodly number, and enough to sustain what is
(believe me, we are competing furiously every day :-)
a vital and competitive industry.

But the market for Ada applications is orders of magnitude
larger. Indeed looking just at commercial users of GNAT,
which itself only commands a segment of the market, the
total number exceeds your 830 by a significant factor!

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[Nick Roberts]

I have been in the exact same position myself, and I (now) know precisely
what to do.  Whoever is the mutual superior of yourself and the project
leader, you must convince this person that: (a) in your professional
judgement, the project IS NOT POSSIBLE in C++; (b) the project leader is
incompetent in making the decision to switch to C++.  This is, of course,
unfortunate if you are/were on friendly terms with him/her; but he/she has
plainly not hesitated in undermining your position (in a big way), so you
should have no hesitation in returning the compliment.  You must do this
right now.

I emphasise the "is not possible" because I know well that a manager will
not be convinced in the slightest by "is not the best way" or the like, but
will be convinced by an absolute "it WILL not work".  Whether this is
actually strictly true or not is immaterial (and you must not show it).  You
and I both know that abandoning Ada is a daft idea, but don't waste your
time trying to argue this; again, just simply say that C++ won't work at all
(invent a reason, if necessary).

As for the future availability of Ada programmers, tell the aforementioned
superior that there is no such thing as "C++ programmers" and "Ada
programmers".  It is a complete myth.  There are only good programmers and
bad programmers.  The good programmers can always be trained to use Ada; the
bad programmers are not to be employed.  This is, of course, not very far
from the truth, anyway (you've already demonstrated the trainability of 18).

And then, to be absolutely frank, if this doesn't work, you can always be
looking for another job.  There may well be another suitable employer who
would be more appreciative of your superior judgement and skills.

Best of luck.

-------------------------------------
Nick Roberts
-------------------------------------

Re: The future of Ada

[Larry Kilgallen]

In article <7c7coa$nvt$4@plug.news.pipex.net>, "Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> I emphasise the "is not possible" because I know well that a manager will
> not be convinced in the slightest by "is not the best way" or the like, but
> will be convinced by an absolute "it WILL not work".  Whether this is
> actually strictly true or not is immaterial (and you must not show it).

Depending on your organization, an equivalently strong statement to
"it WILL not work" is "it WILL not be delivered on time".

Larry Kilgallen

Re: The future of Ada

[Richard D Riehle]

In article <1999Mar11.080820.1@eisner>,
	kilgallen@eisner.decus.org (Larry Kilgallen) wrote:

>Depending on your organization, an equivalently strong statement to
>"it WILL not work" is "it WILL not be delivered on time".

 There is another argument in favor of Ada that is beginning to 
 manifest itself in organizations converting to C++: employee
 turnover.  

 It seems that, once the Ada programmers are trained in C++ (we are now
 doing some of that training), they are more able to present that skill
 to other employers.  In fact, a large number of Ada programmers
 who learn C++ register with a "brain-transplant specialist" (recruiter)
 in search of greener pastures.  Then they need to be replaced.

 If DoD contractors were more thoughtful about this, they would realize
 that Ada is a good language choice to prevent employee turnover. It is
 really important to retain people with a knowledge of the application.
 And consider the cost of getting security clearances for new hires!  In
 the long run, Ada is far more cost effective than C++ for DoD software.
 The problem is that the people making the decision fail to evaluate all
 the total costs.  The popularity of C++ is exactly the wrong reason for
 choosing it on a DoD weapon system.

 Richard Riehle
 http://www.adaworks.com
 

Re: The future of Ada

[Stanley R. Allen]

Richard D Riehle wrote:
> 
>  There is another argument in favor of Ada that is beginning to
>  manifest itself in organizations converting to C++: employee
>  turnover.
> 
>  It seems that, once the Ada programmers are trained in C++ (we are now
>  doing some of that training), they are more able to present that skill
>  to other employers.  In fact, a large number of Ada programmers
>  who learn C++ register with a "brain-transplant specialist" (recruiter)
>  in search of greener pastures.  Then they need to be replaced.
> 

This is a morbid contention because it implies that Ada people are
"stuck" at their jobs.  It's also not 100% valid, as our own Ada shop
has sustained the loss of a number of our best Ada developers to *other*
Ada shops which hire them for huge dollars.  A couple of years ago (it
may still be true), good Ada programmers were getting tip-top dollars
for contracting.

-- 
Stanley Allen
mailto:srallen@hti.com

Re: The future of Ada

[kirk]

In article <36E86FC0.C8EBDC5A@hso.link.com>, "Stanley says...
>
 
..
>Ada shops which hire them for huge dollars.  A couple of years ago (it
>may still be true), good Ada programmers were getting tip-top dollars
>for contracting.
 
Those must be some ultra-secrete Ada programming positions, 
since from what one sees out there in the public, Ada jobs 
are the lowest paying of all. Even a VB programmer makes more
than an Ada programmer. With 15 years, Ada programmers are 
offered a lousy $50,000 a year in those defense contractors
places, while a fresh college grad with a 2 months visual-anything, 
can easily earn more than that at any run-of-the-mill commercial shop.

So, I have no clue what do people talk about when they say 
that Ada programmers make top dollars. If they were, you'll find
people jumping on Ada, but people are jumping on Java 
and visual-*. 

Kirk.

Re: The future of Ada

[Mike Silva]

kirk@*.*.com wrote in message <7ca1lq$4fm@drn.newsguy.com>...

>... With 15 years, Ada programmers are
>offered a lousy $50,000 a year in those defense contractors
>places...

While I don't know specifically what 15 year Ada programmers make, I do know
that *any* competent programmer with 15 years of experience will make a good
deal more than that, if simply by the expedient of learning or dusting off
another, more "commercial" language.  Since good experienced programmers can
migrate to new languages fairly easily there should never develop a large
gap between the pay scales of different languages.

Mike

Re: The future of Ada

[Jerry Petrey]

kirk@*.*.com wrote:
> 
> In article <36E86FC0.C8EBDC5A@hso.link.com>, "Stanley says...
> >
> 
> ..
> >Ada shops which hire them for huge dollars.  A couple of years ago (it
> >may still be true), good Ada programmers were getting tip-top dollars
> >for contracting.
> 
> Those must be some ultra-secrete Ada programming positions,
> since from what one sees out there in the public, Ada jobs
> are the lowest paying of all. Even a VB programmer makes more
> than an Ada programmer. With 15 years, Ada programmers are
> offered a lousy $50,000 a year in those defense contractors
> places, while a fresh college grad with a 2 months visual-anything,
> can easily earn more than that at any run-of-the-mill commercial shop.
> 
> So, I have no clue what do people talk about when they say
> that Ada programmers make top dollars. If they were, you'll find
> people jumping on Ada, but people are jumping on Java
> and visual-*.
> 
> Kirk.

-- 

Either the people you refer to are not worth any more than that or they
don't know what they are worth.  Most direct positions for experienced
Ada software engineers are paying in the 75 - 80K range and I rarely
see a contract position for under 100K per year (and many well above
that).  I have worked for defense contractors for many years and I see
the Ada opportunities getting better and better - and expanding outside
of
the defense area.

If you don't care to believe this, that's fine. It supports me quite
well
and I am very happy to stick with Ada.


Jerry
=====================================================================
=  Jerry Petrey - Consultant Software Engineer  - Member Team Ada   =
=                 Lockheed Martin                 Member Team Forth =
=====================================================================

Re: The future of Ada

[Richard D Riehle]

In article <36E86FC0.C8EBDC5A@hso.link.com>,
	"Stanley R. Allen" <s_allen@hso.link.com> wrote:

>Richard D Riehle wrote:
>> 
>>  There is another argument in favor of Ada that is beginning to
>>  manifest itself in organizations converting to C++: employee
>>  turnover.

>This is a morbid contention because it implies that Ada people are
>"stuck" at their jobs.  It's also not 100% valid, as our own Ada shop
>has sustained the loss of a number of our best Ada developers to *other*
>Ada shops which hire them for huge dollars.  A couple of years ago (it
>may still be true), good Ada programmers were getting tip-top dollars
>for contracting.

I love the use of "morbid" in your reply.  I agree that not all Ada 
programmers are not "stuck" at their jobs.  Even though my thesis
may be slightly exaggerated, or skewed because of my small sample
size, the phenonemon I described actually does occur.  

Richard Riehle
richard@adaworks.com
http://www.adaworks.com

Re: The future of Ada

[Stanley R. Allen]

Richard D Riehle wrote:
> 
>  I agree that not all Ada
> programmers are not "stuck" at their jobs.  Even though my thesis
> may be slightly exaggerated, or skewed because of my small sample
> size, the phenonemon I described actually does occur.
> 

True enough.  I remember consulting with a DoD contractor in Colorado which
decided to drop Ada to train everyone in C++, and found that all of their
freshly-trained programmers were ripe for headhunters; the long-distance
company MCI was booming, their local-area offices were hiring, and could offer
tremendous salary boosts to these developers.

When they described this situation to me, I recommended that they use and
train everyone in Ada to reduce turnover!  (This was a number of years back,
before it bacame clear that we were having a hard enough time keeping our own
Ada people).

-- 
Stanley Allen
mailto:srallen@hti.com

Re: The future of Ada

[Marin David Condic]

Stanley R. Allen wrote:
> 
> This is a morbid contention because it implies that Ada people are
> "stuck" at their jobs.  It's also not 100% valid, as our own Ada shop
> has sustained the loss of a number of our best Ada developers to *other*
> Ada shops which hire them for huge dollars.  A couple of years ago (it
> may still be true), good Ada programmers were getting tip-top dollars
> for contracting.
> 
I think that there might be a general trend recently which has created a
shortage of software developers. Consider the explosion of the Internet
lately and the incredible demand this has created for people who know
how to set up web pages. Companies aren't even able to get enough
qualified college graduates, so they are hiring out of high schools just
about anybody who can recognize Netscape when it starts up. This is O.K.
with me since it makes my skills just that much more valuable. 

Now if only I could figure out how to persuade my company that I'm a
software engineer and need to earn an "industry average" software
engineer's salary, rather than an aerospace engineer earning an
"industry average" aerospace engineer's salary.... ;-)

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Re: The future of Ada

[Chris Morgan]

Richard D Riehle <laoXhai@ix.netcom.com> writes:

>  There is another argument in favor of Ada that is beginning to 
>  manifest itself in organizations converting to C++: employee
>  turnover.  
> 
>  It seems that, once the Ada programmers are trained in C++ (we are now
>  doing some of that training), they are more able to present that skill
>  to other employers.  In fact, a large number of Ada programmers
>  who learn C++ register with a "brain-transplant specialist" (recruiter)
>  in search of greener pastures.  Then they need to be replaced.
> 
>  If DoD contractors were more thoughtful about this, they would realize
>  that Ada is a good language choice to prevent employee turnover. It is
>  really important to retain people with a knowledge of the application.
>  And consider the cost of getting security clearances for new hires!  In
>  the long run, Ada is far more cost effective than C++ for DoD software.
>  The problem is that the people making the decision fail to evaluate all
>  the total costs.  The popularity of C++ is exactly the wrong reason for
>  choosing it on a DoD weapon system.

I'm sorry Richard but this reasoning absolutely disgusts me. In fact
it disgusts me so much I feel like writing to all the C++/Java
recruiting agencies explaining how to steal all the worlds best Ada
programmers from defence companies. That might sort out the good, the
bad and the ugly in the defence market. We are not cannon fodder to be
kept away from information that might help us, we deserve as green a
pasture as the next man.

You seem to be saying "keep hold of staff by keeping them from having
a marketable skill". People can see through such tactics. Even if they
work in 100% Ada at the office, how can you stop them developing e.g.
killer Perl skills at home and going to be a webmaster for a bank? You
can't. You have to keep hold of staff by making them want to work at
your company (money, equity participation, technology, management
attitude, any number of factors). In fact you should be able to hire
C++ victims and convert them to Ada.

I worked on a huge Ada project where some of the people got to do C++
and some didn't. It caused a lot of resentment because they failed to
make any effort to improve the lot of the Ada programmers once it
became clear they were paying less than the going rate for
programmers. In fact the management showed some contempt for the mass
of us Ada programmers which were their prime asset. The benefits were
average, the hours long, the technology mostly backwards, yet I liked
it (I got to use GNAT for money). If they had simply paid anything
close to the market rate they could have kept hold of a lot of us, but
they didn't. I would have preferred to continue to work in Ada even at
a small salary disadvantage, but not for a 25-50% one, defence
projects are hard enough work as it is.

I'm not interested in working for a company that pays a lot less than
the going rate for good programmers whatever the language. I would be
even less likely to work for a company that had the attitude you are
recommending. I want them to like using Ada for better reasons than
that. As it turns out, the company in question has had a revelation
and is now writing to all its ex-employees trying to tempt them back.

Sincerely,

Chris
-- 
Chris Morgan <mihalis at ix.netcom.com                http://mihalis.net
 "We're going to start selling Linux to single-party users very
 soon. Q: It's going to be on the menu? A: Yes. You'll go to Dell, 
 pull down "operating system," and click "Linux."         - Michael Dell

Re: The future of Ada

[Richard D Riehle]

In article <87g17axtv2.fsf@mihalis.ix.netcom.com>,
	Chris Morgan <mihalis@ix.netcom.com> wrote:

>Richard D Riehle <laoXhai@ix.netcom.com> writes:
>
>>  There is another argument in favor of Ada that is beginning to 
>>  manifest itself in organizations converting to C++: employee
>>  turnover.  
>
>I'm sorry Richard but this reasoning absolutely disgusts me. 

 Well, Chris, it has upset others besides you.  

    ...

>We are not cannon fodder to be
>kept away from information that might help us, we deserve as green a
>pasture as the next man.

 Did not mean suggest than anyone is "cannon fodder."  On the other
 hand, DoD contractors are not known for their generosity.  For many,
 when you are no longer "billable" you are superfluous.  Sometimes you
 are, indeed, regarded as "fodder."
  
>You seem to be saying "keep hold of staff by keeping them from having
>a marketable skill". 

 I am saying that, training people in skills for some other marketplace
 is a good way to encourage them to seek opportunities in that other
 marketplace.  There is rarely a good technical reason to abandon 
 Ada in favor of C++. Doing so does open new career opportunities for
 the programmers.  The resulting employee turnover is inevitable. That
 might not be a bad thing.  It will happen.  An employer must understand
 this.  If you stay with Ada, the probability of such turnover, at least
 from this cause, is diminished.  

>People can see through such tactics. Even if they
>work in 100% Ada at the office, how can you stop them developing e.g.
>killer Perl skills at home and going to be a webmaster for a bank? You
>can't. 

 Absolutely true.  There are some self-starters out there.  They are
 "inner directed" and will develop new skills on their own.  Some will
 take these new skills into the marketplace in search of new jobs. Others
 will write some "killer app" and become entrepreneurs.  These kinds
 of people will never be stopped - I hope. 

>You have to keep hold of staff by making them want to work at
>your company (money, equity participation, technology, management
>attitude, any number of factors). 

 These are certainly factors in personnel retention.  If you keep 
 your people happy, most will want to stay with you.  But many
 people can "resist anything except temptation."  And the temptation
 to see whether it is possible to improve your lot with newly
 acquired programming language skills is an on-going temptation.  
 Employee turnover in software is not rare.

> In fact you should be able to hire C++ victims and convert them to Ada.

 I would not characterize C++ programmers as "victims."  I do understand
 what you mean by the sentence.  It is not clear how this relates to
 the issue of employee turnover.  

>I worked on a huge Ada project where some of the people got to do C++
>and some didn't. It caused a lot of resentment because they failed to
>make any effort to improve the lot of the Ada programmers once it
>became clear they were paying less than the going rate for
>programmers. 

 Exactly.  This returns to the employee turnover issue.  The going
 rate for programmers varies all over the place.  At present, some 
 DoD contractors and sub-contractors are below the high end of the
 compensation rates.  Here in Silicon Valley, programmers are sometimes
 given a salary and stock (at minimum stock options).  This is rarely
 the case for large DoD contractors.  

>In fact the management showed some contempt for the mass
>of us Ada programmers which were their prime asset. The benefits were
>average, the hours long, the technology mostly backwards, yet I liked
>it (I got to use GNAT for money). If they had simply paid anything
>close to the market rate they could have kept hold of a lot of us, but
>they didn't. I would have preferred to continue to work in Ada even at
>a small salary disadvantage, but not for a 25-50% one, defence
>projects are hard enough work as it is.

 OK.  Now, take those dissatisfied programmers and teach them a set of
 skills that makes them even more attractive in the marketplace.  Do
 you seriously expect them to ignore those outside opportunities.  At
 present, DoD budgets are tight, competitive bidding demands cutting
 salaries to the lowest margins,  and software is still not given the
 respect we give the hardware engineering.  It is very difficult for
 a DoD contractor to match market rates.  This is one reason why there
 is so much emphasis on COTS software, a trend that will eventually
 come back to haunt us.

>I'm not interested in working for a company that pays a lot less than
>the going rate for good programmers whatever the language. I would be
>even less likely to work for a company that had the attitude you are
>recommending. I want them to like using Ada for better reasons than
>that. As it turns out, the company in question has had a revelation
>and is now writing to all its ex-employees trying to tempt them back.

Glad to hear the attempt at re-hire from the "company in question." 
I too would like them to select Ada for "better reasons."  But management
will rarely make decisions on the basis of better technology.  Such
decisions are made for largely economic reasons.  The economics will be 
manifested in many forms.  The reasons are often limited to the cost of
development tools, cost of hiring, and the cost of retention.  

The DoD gives no incentive for software productivity, no incentive for
software reuse, no incentive for future maintainbility.  Without these
incentives, stated in economic language, there is every incentive to 
take a short-range view of language selection.  Choosing Ada requires
a long-range view of the software process.  It requires enlightened
managers.  It requires program managers who understand how Ada will
benefit their mission.  There are some of these.  I personally know some
of the enlightened managers.  I wish there more.

So, Chris, I understand your concern with my contention that employee
retention is a factor in language choice.  Unfortunately, it is.  It
would be nice if it were otherwise.

Richard Riehle
richard@adaworks.com
http://www.adaworks.com


>Sincerely,
>
>Chris
>-- 
>Chris Morgan <mihalis at ix.netcom.com                http://mihalis.net
> "We're going to start selling Linux to single-party users very
> soon. Q: It's going to be on the menu? A: Yes. You'll go to Dell, 
> pull down "operating system," and click "Linux."         - Michael Dell

 

Re: The future of Ada

[Chris Morgan]

Richard D Riehle <laoXhai@ix.netcom.com> writes:

>  Did not mean suggest than anyone is "cannon fodder."  On the other
>  hand, DoD contractors are not known for their generosity.  For many,
>  when you are no longer "billable" you are superfluous.  Sometimes you
>  are, indeed, regarded as "fodder."

I used to put up with it, but now I don't have to, nor do most able
programmers. 

>   
> >You seem to be saying "keep hold of staff by keeping them from having
> >a marketable skill". 
> 
>  I am saying that, training people in skills for some other marketplace
>  is a good way to encourage them to seek opportunities in that other
>  marketplace.  There is rarely a good technical reason to abandon 
>  Ada in favor of C++. Doing so does open new career opportunities for
>  the programmers.  The resulting employee turnover is inevitable. That
>  might not be a bad thing.  It will happen.  An employer must understand
>  this.  If you stay with Ada, the probability of such turnover, at least
>  from this cause, is diminished.  

Stay with Ada for good reasons by all means, but stay with it even in
part because you think it creates a programming ghetto and you can pay
your staff less than they could get elsewhere and you're just fooling
yourself - acting so dishonourably will be bad for you too in the long
run. I can apply for 100 programming jobs in one evening at
hotjobs.com and so I would hope any self-respecting programmer
realises how laughable such attempts to short change them are
becoming.

> 
> >People can see through such tactics. Even if they
> >work in 100% Ada at the office, how can you stop them developing e.g.
> >killer Perl skills at home and going to be a webmaster for a bank? You
> >can't. 
> 
>  Absolutely true.  There are some self-starters out there.  They are
>  "inner directed" and will develop new skills on their own.  Some will
>  take these new skills into the marketplace in search of new jobs. Others
>  will write some "killer app" and become entrepreneurs.  These kinds
>  of people will never be stopped - I hope. 

Self-starting is now easier than ever before. Cheap computers, free
software, the Internet. DoD contractors that act on this advice
deserve to go bust.

> 
> >You have to keep hold of staff by making them want to work at
> >your company (money, equity participation, technology, management
> >attitude, any number of factors). 
> 
>  These are certainly factors in personnel retention.  If you keep 
>  your people happy, most will want to stay with you.  But many
>  people can "resist anything except temptation."  And the temptation
>  to see whether it is possible to improve your lot with newly
>  acquired programming language skills is an on-going temptation.  
>  Employee turnover in software is not rare.

It's very rare when you pay a reasonable rate and respect your
staff. I realise that a defence focussed company cannot compete with
compensation packages in the banking world, but if it can't hold its
own against other engineering firms, it's doing something wrong, and
if pay slips so much the staff feel humiliated, it is doomed, no
matter what tricks they play with technology.

> 
> > In fact you should be able to hire C++ victims and convert them to Ada.
> 
>  I would not characterize C++ programmers as "victims."  I do understand
>  what you mean by the sentence.  It is not clear how this relates to
>  the issue of employee turnover.  

It's possible to create a high-quality software environment with good
long term prospects that would be like manna from heaven to people
who've left Ada and gone into battle with the mountains of garbage C++
code spewing out of most in-house programming shops. I don't think ACT
employees work there to get fabulously wealthy.

> 
> >I worked on a huge Ada project where some of the people got to do C++
> >and some didn't. It caused a lot of resentment because they failed to
> >make any effort to improve the lot of the Ada programmers once it
> >became clear they were paying less than the going rate for
> >programmers. 
> 
>  Exactly.  This returns to the employee turnover issue.  The going
>  rate for programmers varies all over the place.  At present, some 
>  DoD contractors and sub-contractors are below the high end of the
>  compensation rates.  Here in Silicon Valley, programmers are sometimes
>  given a salary and stock (at minimum stock options).  This is rarely
>  the case for large DoD contractors.  

In London you can hire some very good programmers for X pounds a
year. No stock options, no bonus. If you are a London based defence
company paying 0.75X at best, you're in the weeds, forget it.

> 
> >In fact the management showed some contempt for the mass
> >of us Ada programmers which were their prime asset. The benefits were
> >average, the hours long, the technology mostly backwards, yet I liked
> >it (I got to use GNAT for money). If they had simply paid anything
> >close to the market rate they could have kept hold of a lot of us, but
> >they didn't. I would have preferred to continue to work in Ada even at
> >a small salary disadvantage, but not for a 25-50% one, defence
> >projects are hard enough work as it is.
> 
>  OK.  Now, take those dissatisfied programmers and teach them a set of
>  skills that makes them even more attractive in the marketplace.  Do
>  you seriously expect them to ignore those outside opportunities.  At
>  present, DoD budgets are tight, competitive bidding demands cutting
>  salaries to the lowest margins,  and software is still not given the
>  respect we give the hardware engineering.  It is very difficult for
>  a DoD contractor to match market rates.  This is one reason why there
>  is so much emphasis on COTS software, a trend that will eventually
>  come back to haunt us.

I agree with this - the whole situation is disgusting. I'm not
insulted to hear about it, I'm insulted by the situation. The best
thing programmers can do to get some respect for their skills is to
get what the market will bear for them. If the DoD wants to pay
peanuts, they can have monkeys. If they whine about loyalty perhaps
they shouldn't have abandoned the Ada effort in the first place.

> Glad to hear the attempt at re-hire from the "company in question." 
> I too would like them to select Ada for "better reasons."  But management
> will rarely make decisions on the basis of better technology.  Such
> decisions are made for largely economic reasons.  The economics will be 
> manifested in many forms.  The reasons are often limited to the cost of
> development tools, cost of hiring, and the cost of retention.  


Actually the UK MoD still prefers Ada, and my old firm still believes
in it, but in my view they don't realise they've already bled to
death. 

> 
> The DoD gives no incentive for software productivity, no incentive for
> software reuse, no incentive for future maintainbility.  Without these
> incentives, stated in economic language, there is every incentive to 
> take a short-range view of language selection.  Choosing Ada requires
> a long-range view of the software process.  It requires enlightened
> managers.  It requires program managers who understand how Ada will
> benefit their mission.  There are some of these.  I personally know some
> of the enlightened managers.  I wish there more.

Hopefully the decision makers at the DoD will have to explain why they
are reinventing the Tower of Babel problem that they originally
identified as costing them so much money first time around. Hopefully
they will realise that the lowest sticker price is not always the best
long-term choice. Hopefully they will eventually make procurement
rules with teeth. Until then I'm staying away.

> 
> So, Chris, I understand your concern with my contention that employee
> retention is a factor in language choice.  Unfortunately, it is.  It
> would be nice if it were otherwise.

This is like saying "I recommend tax evasion to my clients, well,
there's a lot of it about". Sorry but I have to stick to my original
point, it's really terrible to hear people say that they should use
Ada to stop staff turnover. I know people who tried it and they lost
the farm and I have no sympathy with them. Any firm acting like that
should expect a more elightened, modern outfit to come in out of the
blue and eat their lunch. 

This is one of those topics where the more I write the less calm I
get, so I really apologise for any offense, but this strikes
uncomfortably close to home. I had several years of career death for
my unauthorised Ada flag waving and I'm no longer inclined to be the
eternal good guy because I love the language.

Chris
-- 
Chris Morgan <mihalis at ix.netcom.com                http://mihalis.net
 "We're going to start selling Linux to single-party users very
 soon. Q: It's going to be on the menu? A: Yes. You'll go to Dell, 
 pull down "operating system," and click "Linux."         - Michael Dell

Re: The future of Ada

[steve]

In article <87g17axtv2.fsf@mihalis.ix.netcom.com>, Chris says...
>
 
>they didn't. I would have preferred to continue to work in Ada even at
>a small salary disadvantage, but not for a 25-50% one, defence
>projects are hard enough work as it is.

Someone also mentioned in this news group that Ada programmers 
get paid less than the rest. This is another proof of the fact.  
I also found the same thing, that Ada jobs pay less.

Any one knows why Ada positions pay less than the rest? It must be becuase
goverment related jobs (where Ada is used) pay less than commerical ones, any
other reasons? How to improve this situation?

Steve.
 

Re: The future of Ada

[Joseph P Vlietstra]

steve@nopsam.com wrote:

> In article <87g17axtv2.fsf@mihalis.ix.netcom.com>, Chris says...
> >
>
> >they didn't. I would have preferred to continue to work in Ada even at
> >a small salary disadvantage, but not for a 25-50% one, defence
> >projects are hard enough work as it is.
>
> Someone also mentioned in this news group that Ada programmers
> get paid less than the rest. This is another proof of the fact.
> I also found the same thing, that Ada jobs pay less.

Well I'm doing fine.   Ada has helped, and continues to help, my career.
Even though the mandate is gone, I selected Ada over C for my project.
This was a no-brainer decision -- we're writing embedded software for use in
a satellite, a perfect match for Ada.  But I also decided that all of the
support
software should also be written in Ada.  My reasoning for this decision was
pretty weak -- I wanted to use the support software effort as an Ada training
camp for the satellite software effort and was willing to pay the "extra cost".

As the readers of this newsgroup can probably guess, there was no extra cost
to develop the support software in Ada.  In fact, I have an embarrassingly high
positive cost variance (underrun).  As all project managers know, it's more fun
to write a variance report for an underrun than an overrun.

Since Ada detects many defects at compile-time, fewer defects remain to be
detected at inspection and unit test.  (We also use Ada-ASSURED prior to
inspection to reduce style defects.)  This means I have fewer defects to report
in our organizational defect database.  So when our director of software
engineering briefs our CEO on software defect rates, our project looks great.
In other words, using Ada means our project doesn't get any "help" from
senior management.

Re: The future of Ada

[Mark D. McKinney]

[-- Attachment #1: Type: text/plain, Size: 372 bytes --]


This is certainly a problem if you are an hourly contractor 
as it dramatically reduces income.

One major reason not to use ada is that it may save money ;) .

-- 
--===============================================
-- Mark D. McKinney
-- Software Engineer
-- 4422 Chase Park Court
-- Annandale, Va 22003
-- (703) 916-7959
--===============================================

[-- Attachment #2: Card for Mark D. McKinney --]
[-- Type: text/x-vcard, Size: 243 bytes --]

begin:vcard 
n:McKinney`;Mark
tel;home:703-916-7959
x-mozilla-html:FALSE
version:2.1
email;internet:mark.mckinney@wdn.com
adr;quoted-printable:;;4422 Chase PArk Court=0D=0A		;Annandale;Va;22003;USA
x-mozilla-cpt:;0
fn:Mark McKinney`
end:vcard

Re: The future of Ada

[Chris Morgan]

steve@nopsam.com writes:

> In article <87g17axtv2.fsf@mihalis.ix.netcom.com>, Chris says...
> >
>  
> >they didn't. I would have preferred to continue to work in Ada even at
> >a small salary disadvantage, but not for a 25-50% one, defence
> >projects are hard enough work as it is.
> 
> Someone also mentioned in this news group that Ada programmers 
> get paid less than the rest. This is another proof of the fact.  
> I also found the same thing, that Ada jobs pay less.
> 
> Any one knows why Ada positions pay less than the rest? It must be becuase
> goverment related jobs (where Ada is used) pay less than commerical ones, any
> other reasons? How to improve this situation?

Some Ada jobs pay really well, but there are some that do not. In fact
even within the defence industry there is wide variance. I was talking
about one specific company in Britain and I wouldn't like people to
extrapolate my statements to the entire rest of the Ada industry.

Thanks,

Chris
-- 
Chris Morgan <mihalis at ix.netcom.com                http://mihalis.net
 "We're going to start selling Linux to single-party users very
 soon. Q: It's going to be on the menu? A: Yes. You'll go to Dell, 
 pull down "operating system," and click "Linux."         - Michael Dell

Re: The future of Ada

[robert_dewar]

In article <7cc579$clq@drn.newsguy.com>,
  steve@nopsam.com wrote:
> Someone also mentioned in this news group that Ada
> programmers  get paid less than the rest. This is another
> proof of the fact.

Hmmmm .. if you regard unsubstantiated statements in news
groups as proof, then I am sure you can prove a lot of
interesting things -- you might try the ufo groups :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[Scott Ingram]

Larry Kilgallen wrote:
> 
> In article <7c7coa$nvt$4@plug.news.pipex.net>, "Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:
> 
> > I emphasise the "is not possible" because I know well that a manager will
> > not be convinced in the slightest by "is not the best way" or the like, but
> > will be convinced by an absolute "it WILL not work".  Whether this is
> > actually strictly true or not is immaterial (and you must not show it).
> 
> Depending on your organization, an equivalently strong statement to
> "it WILL not work" is "it WILL not be delivered on time".
> 
> Larry Kilgallen

Unfortunately, this probably will not work for Gordon--as the program
manager has already inserted a "six month slip" just for the
conversion.  It might seem obvious to CLA readers that this "six month
slip" is only the first of many, and I personally don't like explaining
any slips at all...but a program that can tolerate six months may have
an entirely different perspective.

-- 
Scott Ingram
Sonar Processing and Analysis Laboratory
Johns Hopkins University Applied Physics Laboratory

Re: The future of Ada

[Marin David Condic]

Scott Ingram wrote:
> 
> Unfortunately, this probably will not work for Gordon--as the program
> manager has already inserted a "six month slip" just for the
> conversion.  It might seem obvious to CLA readers that this "six month
> slip" is only the first of many, and I personally don't like explaining
> any slips at all...but a program that can tolerate six months may have
> an entirely different perspective.
> 
Yeah, but it is a 6 month slip that is completely unnecessary. The
argument that it is a risk mitigation just plain doesn't wash. You can
pretty much assume that you'll have a safe supply of Ada programmers for
- say - the next 5 years? In 5 years, you look again and if it looks
like the last Ada programmer on the planet is about to die, you pay him
to re-code it in C++ (or whatever!). Yeah, you've got verification
costs, but we're still talking about spending money now that you might
not ever have to spend - and doing so for very little risk mitigation.
If its a DoD system, then its even sillier, because in 5 years, if the
last Ada programmer augers in, you'll get the DoD to pay for the
conversion. In the end, it just plain won't cost that much to
custom-train some Ada programmers to maintain the system - certainly not
as much as this 6 month slip will cost, and you probably won't ever have
to spend that money.

We've got a very similar situation here, where we committed to the
Motorola M68040 ten or so years ago only to find out years later that
Motorola wasn't going to supply us with Mil Spec chips anymore. Guess
what? Somebody is going to have to pay us to convert the box to a new
chip. Actually, you're much more at risk long term for changes in
hardware technology rather than software technology. As long as you've
got the same hardware and a compiler, you can very cheaply keep someone
maintaining it. (Care to hear about our guys who are maintaining some
_very_ old systems in an obscure assembler language because the program
can't afford a hardware upgrade?) But let a critical hardware supplier
bail out on you and you're back to a total redesign of the system. It
happens and you just have to eat the cost. And it happens a _lot_ more
often than discovering that you can't find/train someone to maintain
some old code because it is in an obscure language.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

    "Software engineers are, in many ways, similar to normal people"

        --  Scott Adams

Re: The future of Ada

[Scott Ingram]

Marin David Condic wrote:
> 
> Yeah, but it is a 6 month slip that is completely unnecessary. The
> argument that it is a risk mitigation just plain doesn't wash. You can

Exactly!!        
-- 
Scott Ingram
Sonar Processing and Analysis Laboratory
Johns Hopkins University Applied Physics Laboratory

Re: The future of Ada

[Gunther Dragoski]

Marin David Condic wrote:

>
>
> We've got a very similar situation here, where we committed to the
> Motorola M68040 ten or so years ago only to find out years later that
> Motorola wasn't going to supply us with Mil Spec chips anymore.

I would think that wouldn't be too big of an issue with the use of industrial

components today. As a matter of fact Motorola still supports the 68040
up to 40 Mhz. Companies such as Thomson & Chip Supply can screen these
from -40 to +105 deg C. They also offer these services for PowerPC 603e
(check their roadmap website) in case you need to jump to next generation
embedded processor as 68K family is dead. Of course the real question is
how long the 603e will be supported before the G3 becomes the norm.

> . Actually, you're much more at risk long term for changes in
> hardware technology rather than software technology. As long as you've
> got the same hardware and a compiler, you can very cheaply keep someone
> maintaining it.

I agree here if you are using a higher order language (such as ADA) but keep
in mind that the processor upgrades due indeed result in software risks. For
example
if you upgrade from 68040 to lets say 603e processor how do you handle the L1

cache's. I find that timing analysis , task scheduling and code verification
to be complex
unless I turn off the caches. Its hard enough tracing 68040 code withs its
single , smaller
cache but trying dealing with both instruction and data caches of 16Kb.

> (Care to hear about our guys who are maintaining some
> _very_ old systems in an obscure assembler language because the program
> can't afford a hardware upgrade?)

Not really (just kidding !) I have been doing that for the last 5 years on a
20 year
old obscure assembler.  :)) However what I find is that the Software upgrade
and
certification is the prohibitive factor not the H/W design itself. Its cyclic
, every 2.5
years or so the same question keeps getting asked , how much to upgrade to a
68K
processor and guess what I pull out the same original detailed quote I did 10
years ago.
When they see the S/W conversion costs they turn and walk away (see you in
2.5 years)
thinking that somehow miraclously the cost will be reduced when they come
back to ask
the same question.


G.D.
Space Systems Engineering

Re: The future of Ada

[Chris Morgan]

Gunther Dragoski <gunther.dragoski@nospam.vf.space.com> writes:

> I would think that wouldn't be too big of an issue with the use of
> industrial components today. As a matter of fact Motorola still
> supports the 68040 up to 40 Mhz. Companies such as Thomson & Chip
> Supply can screen these from -40 to +105 deg C. They also offer
> these services for PowerPC 603e (check their roadmap website) in
> case you need to jump to next generation embedded processor as 68K
> family is dead. 

Hmmm, guess the Motorola Coldfire "DragonBall" (68k based) cpu in my
Palm V must just be my imagination then!

By the way, has anyone ported GNAT to the Palm yet?

Chris

-- 
Chris Morgan <mihalis at ix.netcom.com                http://mihalis.net
 "We're going to start selling Linux to single-party users very
 soon. Q: It's going to be on the menu? A: Yes. You'll go to Dell, 
 pull down "operating system," and click "Linux."         - Michael Dell

Re: The future of Ada

[Dino Gianisis]

The last time the Motorola rep talked to me the Coldfire instruction set
was not compatible with 68K ! Must have been his imagination at the time
also !!!!. I dont know what the hell you're using but the 68K does not
support
any RISC instructions according to Motorola !!! But then again with a
palmtop
the imagination can run as free as possible I guess !!!.

Chris Morgan wrote:

> Gunther Dragoski <gunther.dragoski@nospam.vf.space.com> writes:
>
> > I would think that wouldn't be too big of an issue with the use of
> > industrial components today. As a matter of fact Motorola still
> > supports the 68040 up to 40 Mhz. Companies such as Thomson & Chip
> > Supply can screen these from -40 to +105 deg C. They also offer
> > these services for PowerPC 603e (check their roadmap website) in
> > case you need to jump to next generation embedded processor as 68K
> > family is dead.
>
> Hmmm, guess the Motorola Coldfire "DragonBall" (68k based) cpu in my
> Palm V must just be my imagination then!
>
> By the way, has anyone ported GNAT to the Palm yet?
>
> Chris
>
> --
> Chris Morgan <mihalis at ix.netcom.com                http://mihalis.net
>  "We're going to start selling Linux to single-party users very
>  soon. Q: It's going to be on the menu? A: Yes. You'll go to Dell,
>  pull down "operating system," and click "Linux."         - Michael Dell

Re: The future of Ada

[Olivier Devuns]

   > Hmmm, guess the Motorola Coldfire "DragonBall" (68k based) cpu in my
   > Palm V must just be my imagination then!
   >
   > By the way, has anyone ported GNAT to the Palm yet?

I think "dragonball" is the MC68328, i.e a 68EC000 core with
on-chip peripherals including LCD drivers, etc. Coldfire is a wholly
different beast which I would describe as a "RISCified" 68k. 

-- 
Olivier Devuns -- devuns@sd.aonix.com  |          Aonix
  "If NT is the answer, you didn't     |      San Diego, CA
     understand the question."         |  http://www.aonix.com

Re: The future of Ada

[Chris Morgan]

devuns@sd.aonix.REMOVETHIS.com (Olivier Devuns) writes:

> I think "dragonball" is the MC68328, i.e a 68EC000 core with
> on-chip peripherals including LCD drivers, etc. Coldfire is a wholly
> different beast which I would describe as a "RISCified" 68k. 

My mistake regarding the Coldfire stuff then, but it's a DragonBall in
my palm and it's a modified gcc 68k cross-compiler that's used to
build apps on Unix for it.

Chris
-- 
Chris Morgan <mihalis at ix.netcom.com                http://mihalis.net
 "We're going to start selling Linux to single-party users very
 soon. Q: It's going to be on the menu? A: Yes. You'll go to Dell, 
 pull down "operating system," and click "Linux."         - Michael Dell

Re: The future of Ada

[Marin David Condic]

Larry Kilgallen wrote:
> 
> In article <7c7coa$nvt$4@plug.news.pipex.net>, "Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:
> 
> > I emphasise the "is not possible" because I know well that a manager will
> > not be convinced in the slightest by "is not the best way" or the like, but
> > will be convinced by an absolute "it WILL not work".  Whether this is
> > actually strictly true or not is immaterial (and you must not show it).
> 
> Depending on your organization, an equivalently strong statement to
> "it WILL not work" is "it WILL not be delivered on time".
> 
Shooting schedules is probably one of the most persuasive arguments. The
case for this is easy to make. Historically, C/C++ spends much more time
in integration and debugging because of the unsafe constructs and lack
of compile time checks. What is worse is that you can document
significantly higher numbers of errors escaping into the field -
something that could easily bankrupt a company when the warranty costs
skyrocket. Software bugs found in the field once just about put Pitney
Bowes out of business. ("If you code it in C++ you're putting the entire
business at risk!!!" :-)

There are any number of reports on this. One of my favorites was a study
done at Lucent Technologies on the nature of the bugs discovered in
their large applications. (Wish I still had the URL...) We went through
the study informally here to see if we could gain insight into our own
bugs. (We have amazingly few, and I have metrics which show it steadily
declining since the adoption of Ada & some other tools.) The conclusion
we came to was that the overwhelming number of bug types found in
Lucent's software _could not happen_ in Ada because of compile time
checks. Lucent opted for various programmer training and code review
options to eliminate the common errors. They naturally only _reduce_ the
errors in a very costly & time consuming manner. It's always cheaper to
let the compiler find problems than to try to inspect the problems out
of the system after the fact.

Actually, I'm pretty amazed that someone would look at a system that is
near complete and decide to go back to square one & re-code it in a new
language for fear that one day there won't be any programmers who can
maintain the system. Re-coding the system in a new language is always
something that you can stall off until it becomes essential - which may
never happen. So you for sure spend the money today rather than maybe
never spend it. Spending it ten years from now is much cheaper because
of the time value of money. Pretty bone-headed, if you ask me. ;-)

-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

    "Software engineers are, in many ways, similar to normal people"

        --  Scott Adams

Re: The future of Ada

[Mike Silva]

Marin David Condic wrote in message <36E7E108.246E90BE@pwfl.com>...
>Larry Kilgallen wrote:
>
>There are any number of reports on this. One of my favorites was a study
>done at Lucent Technologies on the nature of the bugs discovered in
>their large applications. (Wish I still had the URL...)

Is it this one?

http://www.lucent.com/ideas2/perspectives/bltj/

(click on CURRENT -- it's the first paper presented)

If not there are some others in their archives.

Mike

Re: The future of Ada

[Marin David Condic]

Mike Silva wrote:
> 
> Is it this one?
> 
> http://www.lucent.com/ideas2/perspectives/bltj/
> 
> (click on CURRENT -- it's the first paper presented)
> 
> If not there are some others in their archives.
> 
Yes. That's the article. Thanks. I don't know how I lost the URL in the
first place. We considered the article to be pretty valuable in helping
us determine how effectively we are eliminating our own bugs.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Re: The future of Ada

[Larry Kilgallen]

In article <36ED5753.8C89C5D@pwfl.com>, Marin David Condic <condicma@bogon.pwfl.com> writes:
> Mike Silva wrote:
>> 
>> Is it this one?
>> 
>> http://www.lucent.com/ideas2/perspectives/bltj/
>> 
>> (click on CURRENT -- it's the first paper presented)
>> 
>> If not there are some others in their archives.
>> 
> Yes. That's the article. Thanks. I don't know how I lost the URL in the
> first place. We considered the article to be pretty valuable in helping
> us determine how effectively we are eliminating our own bugs.

I looked there and cannot find a paper that seems to match.
Could someone post the exact title, and maybe even the
exact URL (http://www.lucent.com/ideas2/perspectives/bltj/
seems to be the root of their frames).  I looked at:

http://www.lucent.com/ideas2/perspectives/bltj/jul-sep1998/jul-sep1998.html

without finding it.

Larry Kilgallen

Re: The future of Ada

[Mike Silva]

The problem appears to be that the current issue has changed from April-June
1998 (!) to July-Sept. 1998 (!), but the April-June issue isn't yet in the
archives.  The article I was referring to is "A Software Fault Prevention
Approach in Coding and Root Cause Analysis" by Yu.  I've got a printout but
I didn't save the .PDF file.  I imagine the issue will show up in the
archives before too long.

Mike

Larry Kilgallen wrote in message <1999Mar21.115908.1@eisner>...
>In article <36ED5753.8C89C5D@pwfl.com>, Marin David Condic
<condicma@bogon.pwfl.com> writes:
>> Mike Silva wrote:
>>>
>>> Is it this one?
>>>
>>> http://www.lucent.com/ideas2/perspectives/bltj/
>>>
>>> (click on CURRENT -- it's the first paper presented)
>>>
>>> If not there are some others in their archives.
>>>
>> Yes. That's the article. Thanks. I don't know how I lost the URL in the
>> first place. We considered the article to be pretty valuable in helping
>> us determine how effectively we are eliminating our own bugs.
>
>I looked there and cannot find a paper that seems to match.
>Could someone post the exact title, and maybe even the
>exact URL (http://www.lucent.com/ideas2/perspectives/bltj/
>seems to be the root of their frames).  I looked at:
>
>http://www.lucent.com/ideas2/perspectives/bltj/jul-sep1998/jul-sep1998.html
>
>without finding it.
>
>Larry Kilgallen

Re: The future of Ada

[Gisle S�lensminde]

In article <7d5qro$bb0$1@its.hooked.net>, Mike Silva wrote:
>The problem appears to be that the current issue has changed from April-June
>1998 (!) to July-Sept. 1998 (!), but the April-June issue isn't yet in the
>archives.  The article I was referring to is "A Software Fault Prevention
>Approach in Coding and Root Cause Analysis" by Yu.  I've got a printout but
>I didn't save the .PDF file.  I imagine the issue will show up in the
>archives before too long.
>

If you goes to the archives and, and then select to sort by autor, 
you will find it on the bottom of the page. (On Yu)
It looks like Bell Labs picks the stuff from some database via a Java 
applet, so I can't give an URL directly to it.

--
Gisle S�lensminde ( gisle@ii.uib.no )   

Re: The future of Ada

[Marin David Condic]

Gisle S�lensminde wrote:
> If you goes to the archives and, and then select to sort by autor,
> you will find it on the bottom of the page. (On Yu)
> It looks like Bell Labs picks the stuff from some database via a Java
> applet, so I can't give an URL directly to it.
> 
O.K. After a little digging & experimentation, I found where to get the
article from this web page. In the Archive section find the article
entitled:

    An Empirical Study of Software Faults Preventable at a Personal
Level in a Very
    Large Software Development Environment

Immediately under the author is a link to "Wireless" - go down this
link. Toward the bottom of this page, you'll see the article appear
again. Now at that point the "Download the Paper in Acrobat PDF Format"
link actually gets you the file.

It was an interesting article & made a pretty good case for why Bell
Labs ought to switch to Ada - although they didn't know that was what
they were doing. Hope this helps...

MDC

-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Re: The future of Ada

[Marin David Condic]

Gisle S�lensminde wrote:
> 

> If you goes to the archives and, and then select to sort by autor,
> you will find it on the bottom of the page. (On Yu)
> It looks like Bell Labs picks the stuff from some database via a Java
> applet, so I can't give an URL directly to it.
> 
I kept getting Java script errors when I tried selecting to sort by
author. I'm beginning to believe that this whole Java thing was dreampt
up by the Marketing Department of Cirrus Cybernetics Corporation - you
spend so much time coping with the superficial design flaws that you
never notice the fundamental design flaws! ;-)

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Re: The future of Ada

[Chris Morgan]

Marin David Condic <condicma@bogon.pwfl.com> writes:

> I kept getting Java script errors when I tried selecting to sort by
> author. I'm beginning to believe that this whole Java thing was dreampt
> up by the Marketing Department of Cirrus Cybernetics Corporation - you
> spend so much time coping with the superficial design flaws that you
> never notice the fundamental design flaws! ;-)

"Share and enjoy"!

Turning off JavaScript improves most web-browsing. Note that Java is
unrelated to JavaScript except in marketing terms.
-- 
Chris Morgan <mihalis at ix.netcom.com                http://mihalis.net
     "I don't have time to read a 1200 page book. 
      I am afraid to even let one in my house." 
                                     - Philip Greenspun 

Re: The future of Ada

[Marin David Condic]

Larry Kilgallen wrote:
> I looked there and cannot find a paper that seems to match.
> Could someone post the exact title, and maybe even the
> exact URL (http://www.lucent.com/ideas2/perspectives/bltj/
> seems to be the root of their frames).  I looked at:
> 
> http://www.lucent.com/ideas2/perspectives/bltj/jul-sep1998/jul-sep1998.html
> 
> without finding it.
> 
> Larry Kilgallen

If I remember correctly, the article is entitled:

An Empirical Study of Software Faults Preventable at a Personal Level
in a Very Large Software Development Environment 
     Weider D. Yu, Alvin Barshefsky, and Steel T. Huang 

Its possible it is under some other title (having to do with the 5ESS
thing), but the author was the same.

This title is in the "Archive" section of the web page. When I click on
it though, I get some pointless message about "This site is enhanced for
Netscape 3.0 and greater....blah blah blah" No sign of the article
itself. I suspect the folks at Bell Labs are having some technical
difficulty.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Re: The future of Ada

[R. Rabeau]

I'm really interested too, so does anyone know where this file is located ?

Larry Kilgallen wrote:

> In article <36ED5753.8C89C5D@pwfl.com>, Marin David Condic <condicma@bogon.pwfl.com> writes:
> > Mike Silva wrote:
> >>
> >> Is it this one?
> >>
> >> http://www.lucent.com/ideas2/perspectives/bltj/
> >>
> >> (click on CURRENT -- it's the first paper presented)
> >>
> >> If not there are some others in their archives.
> >>
> > Yes. That's the article. Thanks. I don't know how I lost the URL in the
> > first place. We considered the article to be pretty valuable in helping
> > us determine how effectively we are eliminating our own bugs.
>
> I looked there and cannot find a paper that seems to match.
> Could someone post the exact title, and maybe even the
> exact URL (http://www.lucent.com/ideas2/perspectives/bltj/
> seems to be the root of their frames).  I looked at:
>
> http://www.lucent.com/ideas2/perspectives/bltj/jul-sep1998/jul-sep1998.html
>
> without finding it.
>
> Larry Kilgallen

Re: The future of Ada

[Mike Silva]

OK, I've finally got it figured out.  Go to:

http://www.lucent.com/ideas2/perspectives/bltj/apr-jun1998/apr-jun1998.html

and it's the first article (by Yu).  There is also another article by Yu in
the archives; since there seems to be some confusion in this thread about
which article is being discussed, you'll probably want to look at both of
them.

Mike

R. Rabeau wrote in message <36FBDCC9.D6FC4EEA@worldnet.fr>...
>I'm really interested too, so does anyone know where this file is located ?
>
>Larry Kilgallen wrote:
>
>> In article <36ED5753.8C89C5D@pwfl.com>, Marin David Condic
<condicma@bogon.pwfl.com> writes:
>> > Mike Silva wrote:
>> >>
>> >> Is it this one?
>> >>
>> >> http://www.lucent.com/ideas2/perspectives/bltj/
>> >>

Re: The future of Ada

[Steve Whalen]

Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
: In article <7c7coa$nvt$4@plug.news.pipex.net>, "Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

: > I emphasise the "is not possible" because I know well that a manager will
: > not be convinced in the slightest by "is not the best way" or the like, but
: > will be convinced by an absolute "it WILL not work".  Whether this is
: > actually strictly true or not is immaterial (and you must not show it).

: Depending on your organization, an equivalently strong statement to
: "it WILL not work" is "it WILL not be delivered on time".

: Larry Kilgallen

I might add another useful alternative to "it will not work" (besides 
"will not deliver on time") can be "it will not meet customer expectations
or requirements".

I agree that you're almost certainly justified in making a "will not
deliver on time / with acceptable quality" statement to this manager.

You _may_ also be justified in making the "will not work" statement,
based on my observations of the success/failure rate of C++ projects
in many organizations.  If your organization is one of the few
that has a history of delivering successful C++ projects, I would
avoid making this statement.

Depending on the local political situation, here's an approach that
could be helpful over the long run (if not for this project, for later
projects). Of course don't do this if you think you could lose your
job over it.

1) verbally discuss this with the decision maker, respectfully asking
   them to reverse the decision, making the predictions I discuss below.

2) Discuss this with the "customer" for the system, if there is one.
   Let them know about the memo you're going to write. They may have
   the power and desire to intercede (most will _not_ want to).

3) Write a nice, polite, non-technical, one page memo to the manager:

   a) do NOT challenge the decision or ask for it's reversal

   b) DO copy everyone who matters, as high up in the organization as
      you can (i.e. if they would know your name if they met you in
      the hallway, copy them). Include the "customer" organization(s) 
      if appropriate.

   c) include only a summary of the history of the project, note the
      six-month slip already introduced, the prediction that the
      project will be much later than it needs to be / lower in
      quality than it needs to be / more expensive to maintain
      or reduced customer satisfaction, etc. 

   d) Make sure you only say things you are sure _will_ come to pass.

   e) i.e. write a nice, polite "I told you so" memo, NOW.

Managers hate having this kind of memo floating around waiting to
bite them in the ass when the predictions come true. It _can_ also
help them to crystalize their thinking to know someone is willing
to put their technical predictions on the line & in writing this way.
Maybe this manager will reverse his/herself.  

At minimum, when your predictions come true, you probably won't have
this trouble on your next project.

I would _not_ advocate this as a normal tactic, but on something as
important as this, in what seems to be a somewhat disfunctional
organization....

Steve
-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}

Re: The future of Ada

[Al Christians]

Nick Roberts wrote:
> 
> you must convince this person that: (a) in your professional
> judgement, the project IS NOT POSSIBLE in C++; 
>  ...
>  ...
> I emphasise the "is not possible" because I know well that a manager will
> not be convinced in the slightest by "is not the best way" or the like, but
> will be convinced by an absolute "it WILL not work".  Whether this is
> actually strictly true or not is immaterial (and you must not show it).  

This intentional dishonesty, although based on good intentions, would 
be a violation of the ACM Code of Ethics. 

Al

Re: The future of Ada

[Michael Garrett]

Here's my impression: ( Actually its an opinion )

>Ten months into the project, the project leader announced
>very abruptly that Ada would be scrapped, C++ would be used,
>and there would be a six month slip in the project to permit
>training in C++ and rewriting the  completed Ada code.  His
>reason - "There may not be any Ada programmers to do
>maintenance several years from now, but we will always be
>able to get C++ programmers."
( He did not say software engineers )



This person is frustrated. He / She obviously thinks that Ada is delaying
the project probably due to the upfront design that is required in Ada.
 actually required in any language but I'll get to that.. ) I am just
learning Ada, and it is frustrating sometimes to realize that I can not just
sit down and code something, even to try it out. Leaning Ada has taught me
alot about how little I know about software engineering.  Having weak type
checking and very little type support in a language, fosters the code it now
fix it in validation mentality. ( It sounds like I'm condeming some
language, but I'm not. If the process works, the software will most likely
work, And be delivered on schedule ).

As a manager of Medical Device Developement, I would not want it any other
way. But in most companies that lack large scale or safety critical software
development experience, the percieved pain of not seeing some cluged up
prototype ( which will probably end up in the
system ) is enough to make this type of rash decision happen. What needs to
be addressed is not the programming language. The language is a small tool
that is used in a portion of the development process. It is used to execute
the implementation of a design.
Hopefully, the language tools i.e. compiler will catch as many problems as
possible before the code is released.

My suggestion, is to analyze the design process itself. If this project was
moving at record breaking speed, this person would not be frustrated, he /
she would be putting out press releases on the use of Ada, with his / her
smiling face on the cover shot.

>I am obviously frustrated.  How can I continue to promote
>the use of Ada when the numbers mentioned in the first two
>paragraphs above indicate a lack of growth in Ada compared
>to the other languages?  Any thoughts, either positive or
>negative, will be appreciated.


The numbers in this case do not signify much. This person supported you when
you first chose Ada. Did he / she go through the training courses ? Maybe
this person knows C and the Ada Learning curve is too steep while C++ looks
like C and is more accessible.

Ada will be around for a while, along with the tools. Any good software
engineer can learn and use Ada.

Process, Process, Process Process.................Repeat After
Me...................

If none of this is true, you are the victim of a political move, in order to
achieve notoriety and a promotion. I'm frustrated too.....

Michael C. Garrett
Vice President of Research and Development
Medical Research Laboratories
www.mrlinc.com











>
>Gordon Dodrill
>Sandia National Laboratories - Albuquerque, New Mexico

Re: The future of Ada

[vershokv]

In article <Oxxg0hEb#GA.207@nih2naad.prod2.compuserve.com>, "Michael says...
 
>Leaning Ada has taught me
>alot about how little I know about software engineering.  

Actually this is true with me too. Ada forced me to also think about what 
I am doing, i.e. in a language where one can mix apples
and oranges, one does not need to think much about if they are assigning
apples to oranges at the time, but in Ada, the compiler will complain, and
so the programmer must stop to think.

This I believe the main reason why programmers in general do not like Ada. 
Ada forces one to think about what they are doing to get a program to compile
cleanly.

Your typical programmers enjoy running the program, they do not enjoy 
compiling them. They enjoy running the program even if it crashes every
5 seconds rather than having to deal with the compiler whining on them.

I am always amazed how many programmers get frustrated if the program takes
one more hour to compile clean, yet, they give no thought to spending days
debugging something in C or C++, something that the Ada compiler could 
probably have found for them in seconds.


Vershokv

Re: The future of Ada

[John McCabe]

"Michael Garrett" <michaelgarrett@csi.com> wrote:

>I am just learning Ada, and it is frustrating sometimes to realize that I
>can not just sit down and code something, even to try it out.

I can't understand where you got that idea from. I find with Ada I can
just sit down and code something, and most times, if the language
allows what I've written, what the compiler produces does what I want.

I could never say that about using C.

>The numbers in this case do not signify much. This person supported you when
>you first chose Ada. Did he / she go through the training courses ? Maybe
>this person knows C and the Ada Learning curve is too steep while C++ looks
>like C and is more accessible.

Maybe this person has decided that he/she should learn C++ because
then they can get more money elsewhere.



Best Regards
John McCabe <john@assen.demon.co.uk>

Re: The future of Ada

[Mike Silva]

John McCabe wrote in message <36fbd229.1390755@news.demon.co.uk>...
>"Michael Garrett" <michaelgarrett@csi.com> wrote:
>
>>I am just learning Ada, and it is frustrating sometimes to realize that I
>>can not just sit down and code something, even to try it out.
>
>I can't understand where you got that idea from. I find with Ada I can
>just sit down and code something, and most times, if the language
>allows what I've written, what the compiler produces does what I want.
>
>I could never say that about using C.


My experience in learning Ada is the same as Michael's -- Ada will not
tolerate off-the-cuff programming, where you're only thinking a few lines or
a few functions ahead.  I come from 'C', a language that is always beguiling
you with "well, you probably shouldn't do that, but -I'll- never tell".  As
hard as you try to be disciplined in such a language, it's easy to slip in a
little implicit conversion here, do a quick-and-dirty cast there, toss in a
few #defines, and at the end of the day you feel like you've written code
that already could stand a little cleanup, only that hardly ever happens.
Ada, OTOH, is constantly rapping my knuckles, which annoys me at the time,
but when I'm done I'm much less likely to have code that has that "look at
this again later" feel to it.  Of course, as I get better at Ada's explicit
and implicit rules the knuckle-rapping will diminish, but that
code-done-right feeling will still be there.  This is one of the main
reasons I set out to learn Ada, and I'm already seeing the benefits, but
along with the newfound rewards I'm also still feeling the aches and pains
of my new programming exercise regimen.

Mike

Re: The future of Ada

[west]

In article <36fcbe32.0@news1.jps.net>, "Mike says...
 
>
>My experience in learning Ada is the same as Michael's -- Ada will not
>tolerate off-the-cuff programming, where you're only thinking a few lines or
>a few functions ahead.  I come from 'C', a language that is always beguiling
>you with "well, you probably shouldn't do that, but -I'll- never tell". 

...snip..
 
Very few people will argue than C or C++ are better than Ada.

But nowadays, the Big one is Java. It is not C or C++.

Ada programmers like to put C/C++ down, becuase it is easy to do so
(due to obviouse weaknesses in these languages). But it is much harder
to try to knock Java down, which is really becomming the main language
of use out there now.

I've seen a report that shows that by the end of this year, there will be
more Java programmers than C++.

Java is being used everywhere now. There are even webServers and application
servers written in Java. Show me one web server written in Ada.

Why is that? 
  
Ada has been around for 20 years, while Java for only 4.5 years.
Ada is almost non-existant in the commerical world. Java is taking the
commerical world by storm. 
 
Why is that?  How come a language like Ada has been standing still
for 20 years in terms of its use in the commerical world, while C/C++/Java 
and even Perl are being used by almost everyone else? 

West.

Re: The future of Ada

[John McCabe]

west@nospam wrote:

>Java is being used everywhere now. There are even webServers and application
>servers written in Java. Show me one web server written in Ada.

Show me one mission or safety critical web-server!

>
>Why is that? 
  
>Ada has been around for 20 years, while Java for only 4.5 years.
>Ada is almost non-existant in the commerical world. Java is taking the
>commerical world by storm. 
 
>Why is that?  How come a language like Ada has been standing still
>for 20 years in terms of its use in the commerical world, while C/C++/Java 
>and even Perl are being used by almost everyone else? 

Java would appear to be benefitting from looking a lot like the
languages it is decended from (C/C++). It's a lot easier and safer
than either of those as far as I can make out, but in particular Java
was really developed for a specialist market - GUIs and web apps. Show
me an embedded real-time system that has been built in Java?



Best Regards
John McCabe <john@assen.demon.co.uk>

Re: The future of Ada

[west]

In article <36fd1870.2422302@news.demon.co.uk>, john@assen.demon.co.uk.nospam
says...

>
>west@nospam wrote:
>
>>Java is being used everywhere now. There are even webServers and application
>>servers written in Java. Show me one web server written in Ada.
>

>Show me one mission or safety critical web-server!
>
 
offcourse the main known webservers out there are in C/C++ (java has
been around for only 4 years or so now). But still, there are 2 java
servers out there that I know of. (there are non in Ada) :
 
1. Sun Java web server. 
http://wwwwswest2.sun.com/software/jwebserver/index.html

2. Jigsaw  http://www.w3.org/Jigsaw/
"Jigsaw is W3C's leading-edge Web server platform, providing a 
sample HTTP 1.1 implementation and a variety of other features 
on top of an advanced architecture implemented in Java."

Many of the current commerical webserver also provide large amount of support
for Java build into them (NetDynamics, Netscape EnterpriseServer, etc..).
 
Any webServer nowadays that does not have strong server-side support for 
Java will not have chance in making it.

Also, the java servlet API is becomming the most used API for writting
server-side applications/cgi's (or servelts) in Java. Ada is completly 
absent when it comes to any thing related to webservers (you'll think 
that is Ada strongest point, since web servers are large complex, and 
many are multi-threads applications), and also Ada is absent in the 
web/internet are in general.

By the way, I am not putting the Ada language down here. Ada as a 
language is very good. But it is irrelevent when it comes to the 
commerical software industry.  

West.

Re: The future of Ada

[John McCabe]

west@nospam wrote:


>>Show me one mission or safety critical web-server!


>1. Sun Java web server. 
>http://wwwwswest2.sun.com/software/jwebserver/index.html
>
>2. Jigsaw  http://www.w3.org/Jigsaw/
>"Jigsaw is W3C's leading-edge Web server platform, providing a 
>sample HTTP 1.1 implementation and a variety of other features 
>on top of an advanced architecture implemented in Java."

And they're mission/safety critical are they? How many Java systems
are used to control commercial aircraft, military aircraft, ship
command systems, spacecraft?



Best Regards
John McCabe <john@assen.demon.co.uk>

Re: The future of Ada

[s.shering]

Dear John,

In article <36fe5bae.16269389@news.demon.co.uk>,
  john@assen.demon.co.uk.nospam (John McCabe) wrote:
> west@nospam wrote:

> >>Show me one mission or safety critical web-server!
> And they're mission/safety critical are they? How many Java systems
> are used to control commercial aircraft, military aircraft, ship
> command systems, spacecraft?

None, I hope, because JavaSoft's license specifically excludes the use of
their software in such applications.

Steve Shering
vqSoft

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[Larry Kilgallen]

In article <36fd1870.2422302@news.demon.co.uk>, john@assen.demon.co.uk.nospam (John McCabe) writes:

> Java would appear to be benefitting from looking a lot like the
> languages it is decended from (C/C++). It's a lot easier and safer
> than either of those as far as I can make out, but in particular Java
> was really developed for a specialist market - GUIs and web apps. Show
> me an embedded real-time system that has been built in Java?

Interest in Java may have developed because of that specialist
market, but Sun Microsystems' Chief Science Officer addressing
the RSA conference this past January indicated the Web use was
just a diversion from the purpose for which Java was developed,
to provide a safer language than C.  He indicated interest in
compiled (not bytecode) Java, but from what I have seen the
great groundswell of interest in Java is not headed in that
direction at all, but is much more due to the "write once,
debug everywhere" use of the language.

So while Java as a general language may be of interest and may
be the intent of the originators, the hoopla seems to be all
centered around the JVM and web applications.

Larry Kilgallen

Re: The future of Ada

[mjsilva]

In article <7di6r6$bhd@drn.newsguy.com>,
  west@nospam wrote:
> In article <36fcbe32.0@news1.jps.net>, "Mike says...
>
> >
> >My experience in learning Ada is the same as Michael's -- Ada will not
> >tolerate off-the-cuff programming, where you're only thinking a few lines or
> >a few functions ahead.  I come from 'C', a language that is always beguiling
> >you with "well, you probably shouldn't do that, but -I'll- never tell".
>
> ...snip..
>
> Very few people will argue than C or C++ are better than Ada.
>
> But nowadays, the Big one is Java. It is not C or C++.
>
> Ada programmers like to put C/C++ down, becuase it is easy to do so

I truly don't see how you could take what I wrote as a putdown of C/C++.  I
thought I was clear in describing how I, in learning Ada from a C background,
found the extra discipline Ada imposes to be both frustrating and beneficial.
I could have come from a number of other languages and had the same
experience.  I am specifically not an Ada programmer, I am a C programmer
learning Ada, who recognizes that the C language allows (does not force, but
allows) some weak programming practices.

You, however, have chosen to twist what I wrote to serve as an excuse for Yet
Another Java Flag-waving Post.	This is especially ironic because Java also
imposes extra discipline on somebody coming from a C background, and thus my
words could also have been written about Java.	What is even more ironic, to
the point of being ludicrous, is that a Java programmer would criticize
anybody for "putting C/C++ down" (which I -didn't- do), since the Java
community seems to regularly work itself into hysterics over the failures of
C/C++.	"Java Great, Everything Else Bad, C/C++ Really Really Horrible" seems
to be the message of the noisiest Java backers.

Perhaps instead of telling us how Java will take over the world (a look at
dice.com shows 3 times as many C/C++ offerings as Java...), why don't -you-
tell us why you choose Java over Ada.  Have you even looked seriously at Ada?
I can tell you that for my applications (embedded real-time systems), Ada is a
much better fit than Java.

Mike

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[west]

In article <7diro7$1jo$1@nnrp1.dejanews.com>, mjsilva@my-dejanews.com says...
>
 
>Perhaps instead of telling us how Java will take over the world (a look at
>dice.com shows 3 times as many C/C++ offerings as Java...), 

And it shows also 200 as many times C/C++ offerings as Ada..

I also do not need dice to tell me how popular java is becomming.
Almost everywhere I look around here, I see more and more projects
being started using Java. Large companies are moving to Java. Offcourse
C/C++ are still being used, but not as many new projects are being started
in C/C++ as before now that Java has arrived. 

>why don't -you-
>tell us why you choose Java over Ada.

First, I did not choose Java over Ada. The market did.

Second, Java comes with packages and API's to do almost anything 
you want. These are standard packages available on any platform. 
This allows me to use Java to write any sort of application very 
easily. The Java platform is very rich platform, I can use Java
to do many many more things than with Ada. Ada lacks so many standard
libraries and API's to be used effectively in the real commerical world.

Look at what one can do with Java:

(this does not even count that the basic core Java packages come with
more data structures and utilites to do usefull stuff than the Ada
standard libraries come with)

1. the SQL package for JDBC access.
2. the OMG packages for corba IDL stuff.
3. the SWING packages for GUI, Net/URL packages for easy networking.
4. Java Beans for writing reusable compononts.
5. Java 2D, Java 3D api's for animations and graphics, 
6. JNDI (java naming and directory interface packages) "providing Java 
   applications with a unified interface to multiple naming and directory
   services in the enterprise."
7. standard package for access communication serial ports. "contains support 
   for RS232 serial ports and IEEE 1284 parallel ports."
8. JMAPI packages to " provide a universal Java management foundation 
   which allows developers to rapidly provide Java management solutions 
for the consumer market, enterprise computing and telecommunications   
datacommunications markets."
9. Java Mail packages. "The JavaMail API provides a set of abstract 
   classes that model a mail system. The API provides a platform 
   independent and protocol independent framework to build Java based 
   mail and messaging applications."
10. "The The JavaTM Media Framework (JMF) 1.0 API specifies a simple, 
    unified architecture, messaging protocol, and programming interface 
    for media playback."
11. JCE packages. "The JavaTM Cryptography Extension (JCE) 1.2 
    provides a framework and implementations for encryption, key 
    generation and key agreement, and Message Authentication Code 
    (MAC) algorithms. Support for encryption includes symmetric, 
    asymmetric, block, and stream ciphers. The software also 
    supports secure streams and sealed objects. 
12. "JavaServer PagesTM (JSP) provides an easy way to access 
    server-side components from Web pages -- thereby separating the 
    presentation of dynamic content from the generation of that content."
13. JMS packages. "Enterprise messaging provides a reliable, 
    flexible service for the asynchronous exchange of critical 
    business data and events throughout an enterprise. JMS adds to 
    this a common API and provider framework that enables the 
    development of portable, message based Java applications."
14. JTA API. "specifies standard Java interfaces between a transaction 
    manager and the parties involved in a distributed transaction 
    system: the resource manager, the application server, and 
    the transactional applications. 
15. JTS. "Java Transaction Service (JTS) specifies the implementation 
    of a Transaction Manager which supports the JavaTM Transaction 
    API (JTA) 1.0 Specification at the high-level and implements 
    the Java mapping of the OMG Object Transaction Service (OTS) 1.1
    Specification at the low-level."
16. Java TV API.   
    The Java TV API is being designed to provide access to the 
    functionality unique to a digital television receiver. 
    This functionality includes: 
                          audio/video streaming 
                          conditional access 
                          access to in-band and out-of-band data channels 
                          access to service information data 
                          tuner control for channel changing 
                          on-screen graphics control 

17. JDM, "The Java Dynamic ManagementTM Kit (DMK) provides 
    developers with the tools and management services to create effective 
    and dynamic agents for network, system, application, and service
    management efficiently."
18. "The Java Smart Card API is a platform-independent layer that 
    lies between the Java Wallet (or any other Java application) and 
    provides interfaces to PC/SC, Native code, and Java drivers."
19. JTAPI. "The Java Telephony API (JTAPI) is a portable, object-oriented 
    application programming interface for Java-based computer-telephony
    applications."
20. XML and Java. Although I don't know much about this, but it seems I see
    Java more mentioned with XML than any other language. There are more
    XML parsors written in Java than anything else. And there is allot
    of activities in doing a java API related to XML stuff. So, I would
    not be surprised if next version of JDK will java some sort of XML related
    packages in it.

Show the Ada packages that I can use to do the above.

THere are also  more and more API and java packages out there (commerical 
and non-commerical) for Java. But I think you get the point now.

>  Have you even looked seriously at Ada?

Oh yes. you can look at Ada as long as you want. But when it comes to
writing commerical applications with it in the real world, Ada does not
not have the needed libraries and packages to do the work, and so it falls
short.

>I can tell you that for my applications (embedded real-time systems), Ada is a
>much better fit than Java.

May be. I dont know. but yes Ada could not get out of this very limited 
market (military, embedded real-time) for 20 years. We are talking about
commerical/business stuff here. Where Java is becoming the main
language of use, and Ada is non-existant.

But even for embedded stuff, Java is becomming more used there also, 
check http://java.sun.com/products/embeddedjava/index.html
"The EmbeddedJava Application Environment is for embedded
devices with dedicated functionality and severely limited memory."

"Sun has announced its joint initiatives with NTT DoCoMo and 
Symbian, to incorporate JavaTM and JiniTM technologies in wireless 
information devices."

"Palo Alto, Calif. - March 2, 1999 - Sun Microsystems, Inc. today
announced that Aplix, Microware, Tektronix and Wind River
Systems have been licensed or have signed a letter of intent to
license EmbeddedJavaTM technology." 

Java for real-time, check also
http://wwwwswest2.sun.com/smi/Press/sunflash/9903/sunflash.990301.3.html
"IBM Leads Industry Experts to Define JavaTM Technology
Specifications for Real-Time Extensions"

It is not how good a language is. It is what you can do with it in the
real world that matters. 

West.

Re: The future of Ada

[mjsilva]

In article <7dj8vi$2qi@drn.newsguy.com>,
  west@nospam wrote:
> In article <7diro7$1jo$1@nnrp1.dejanews.com>, mjsilva@my-dejanews.com says...
>
> >Perhaps instead of telling us how Java will take over the world (a look at
> >dice.com shows 3 times as many C/C++ offerings as Java...),
>
> And it shows also 200 as many times C/C++ offerings as Ada..

We are quite aware that the Ada world is much smaller than either the Java or
C/C++ worlds.  The difference is that you are the one who interrupted this
thread with an off-topic claim:

>But nowadays, the Big one is Java. It is not C or C++.

<list snipped>
> Oh yes. you can look at Ada as long as you want. But when it comes to
> writing commerical applications with it in the real world, Ada does not
> not have the needed libraries and packages to do the work, and so it falls
> short.

Being both an Ada newcomer and an embedded developer, I have no idea of the
level of Ada support for your list.  Perhaps some others will choose to
respond if they think it would be informative.	If you feel that Java is the
right tool for your applications then I'm delighted.  Ada is clearly a better
tool for *my* applications.  What I don't understand, and what I resent, is
the compulsion by many Java supporters to turn any discussion, on any topic,
into a Java press release.

>
> >I can tell you that for my applications (embedded real-time systems), Ada is
a
> >much better fit than Java.
>
> May be. I dont know. but yes Ada could not get out of this very limited
> market (military, embedded real-time) for 20 years. We are talking about
> commerical/business stuff here.

No, actually my message wasn't talking about commercial/business stuff at all.
But, yes, Ada does seem stuck, and a lot of us think that is a sad state of
affairs.

I don't see much need to carry on this discussion, so I won't respond any more
on this topic.

Mike








-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[Chad R. Meiners]

<west@nospam> wrote in message news:7dj8vi$2qi@drn.newsguy.com...
> In article <7diro7$1jo$1@nnrp1.dejanews.com>, mjsilva@my-dejanews.com
says...

  <snip>

> First, I did not choose Java over Ada. The market did.

This statement is a fear uncertainity, and doubt tactic.  Choosing a
language
because it is popular with the market is not a choice at all.  It is
surrendering
to the will of others.

> Second, Java comes with packages and API's to do almost anything
> you want. These are standard packages available on any platform.
> This allows me to use Java to write any sort of application very
> easily. The Java platform is very rich platform, I can use Java
> to do many many more things than with Ada. Ada lacks so many standard
> libraries and API's to be used effectively in the real commerical world.

Remember that if you are commiting to Java then you are commiting to Sun's
standard.  Sun can change its standard on a whim.  Such a standard is not
really a standard.  Ada offers a very well thought out standard that will
not
change at a moments notice.  Also Ada can interface to any standard library
you want.  It can even be compiled to the JVM.  So you cannot claim Ada
lacks
this libraries since they can be accessed through Ada.

> Look at what one can do with Java:
>
> (this does not even count that the basic core Java packages come with
> more data structures and utilites to do usefull stuff than the Ada
> standard libraries come with)

Am I sure that you can find most of what you are looking for is avaliable
through
the Ada resource sites.

> 1. the SQL package for JDBC access.
> 2. the OMG packages for corba IDL stuff.
> 3. the SWING packages for GUI, Net/URL packages for easy networking.
> 4. Java Beans for writing reusable compononts.
> 5. Java 2D, Java 3D api's for animations and graphics,
> 6. JNDI (java naming and directory interface packages) "providing Java
>    applications with a unified interface to multiple naming and directory
>    services in the enterprise."
> 7. standard package for access communication serial ports. "contains
support
>    for RS232 serial ports and IEEE 1284 parallel ports."
> 8. JMAPI packages to " provide a universal Java management foundation
>    which allows developers to rapidly provide Java management solutions
> for the consumer market, enterprise computing and telecommunications
> datacommunications markets."
> 9. Java Mail packages. "The JavaMail API provides a set of abstract
>    classes that model a mail system. The API provides a platform
>    independent and protocol independent framework to build Java based
>    mail and messaging applications."
> 10. "The The JavaTM Media Framework (JMF) 1.0 API specifies a simple,
>     unified architecture, messaging protocol, and programming interface
>     for media playback."
> 11. JCE packages. "The JavaTM Cryptography Extension (JCE) 1.2
>     provides a framework and implementations for encryption, key
>     generation and key agreement, and Message Authentication Code
>     (MAC) algorithms. Support for encryption includes symmetric,
>     asymmetric, block, and stream ciphers. The software also
>     supports secure streams and sealed objects.
> 12. "JavaServer PagesTM (JSP) provides an easy way to access
>     server-side components from Web pages -- thereby separating the
>     presentation of dynamic content from the generation of that content."
> 13. JMS packages. "Enterprise messaging provides a reliable,
>     flexible service for the asynchronous exchange of critical
>     business data and events throughout an enterprise. JMS adds to
>     this a common API and provider framework that enables the
>     development of portable, message based Java applications."
> 14. JTA API. "specifies standard Java interfaces between a transaction
>     manager and the parties involved in a distributed transaction
>     system: the resource manager, the application server, and
>     the transactional applications.
> 15. JTS. "Java Transaction Service (JTS) specifies the implementation
>     of a Transaction Manager which supports the JavaTM Transaction
>     API (JTA) 1.0 Specification at the high-level and implements
>     the Java mapping of the OMG Object Transaction Service (OTS) 1.1
>     Specification at the low-level."
> 16. Java TV API.
>     The Java TV API is being designed to provide access to the
>     functionality unique to a digital television receiver.
>     This functionality includes:
>                           audio/video streaming
>                           conditional access
>                           access to in-band and out-of-band data channels
>                           access to service information data
>                           tuner control for channel changing
>                           on-screen graphics control
>
> 17. JDM, "The Java Dynamic ManagementTM Kit (DMK) provides
>     developers with the tools and management services to create effective
>     and dynamic agents for network, system, application, and service
>     management efficiently."
> 18. "The Java Smart Card API is a platform-independent layer that
>     lies between the Java Wallet (or any other Java application) and
>     provides interfaces to PC/SC, Native code, and Java drivers."
> 19. JTAPI. "The Java Telephony API (JTAPI) is a portable, object-oriented
>     application programming interface for Java-based computer-telephony
>     applications."
> 20. XML and Java. Although I don't know much about this, but it seems I
see
>     Java more mentioned with XML than any other language. There are more
>     XML parsors written in Java than anything else. And there is allot
>     of activities in doing a java API related to XML stuff. So, I would
>     not be surprised if next version of JDK will java some sort of XML
related
>     packages in it.
>
> Show the Ada packages that I can use to do the above.

Let's see ...  Oh yes!  The packages that allow you to interface to the JVM.
Also remember that Ada provides generics and packages to allow reuseable
components.  I see no problems with implementing any of the 20 items in the
list.
Alot of them already have packages that do the equivalent.

> THere are also  more and more API and java packages out there (commerical
> and non-commerical) for Java. But I think you get the point now.
>
> >  Have you even looked seriously at Ada?
>
> Oh yes. you can look at Ada as long as you want. But when it comes to
> writing commerical applications with it in the real world, Ada does not
> not have the needed libraries and packages to do the work, and so it falls
> short.

So you have not used Ada then?  That might explain why you forgot about
generics.

> >I can tell you that for my applications (embedded real-time systems), Ada
is a
> >much better fit than Java.
>
> May be. I dont know. but yes Ada could not get out of this very limited
> market (military, embedded real-time) for 20 years. We are talking about
> commerical/business stuff here. Where Java is becoming the main
> language of use, and Ada is non-existant.
>
> But even for embedded stuff, Java is becomming more used there also,
> check http://java.sun.com/products/embeddedjava/index.html
> "The EmbeddedJava Application Environment is for embedded
> devices with dedicated functionality and severely limited memory."
>
> "Sun has announced its joint initiatives with NTT DoCoMo and
> Symbian, to incorporate JavaTM and JiniTM technologies in wireless
> information devices."
>
> "Palo Alto, Calif. - March 2, 1999 - Sun Microsystems, Inc. today
> announced that Aplix, Microware, Tektronix and Wind River
> Systems have been licensed or have signed a letter of intent to
> license EmbeddedJavaTM technology."
>
> Java for real-time, check also
> http://wwwwswest2.sun.com/smi/Press/sunflash/9903/sunflash.990301.3.html
> "IBM Leads Industry Experts to Define JavaTM Technology
> Specifications for Real-Time Extensions"

So Java can now run on pagers?  I am impressed.

> It is not how good a language is. It is what you can do with it in the
> real world that matters.

This last statement is meaningly FUD.

> West.
>

Chad R. Meiners

Re: The future of Ada

[Aidan Skinner]

On 27 Mar 1999 10:45:06 -0800, west@nospam <west@nospam> wrote:

>Second, Java comes with packages and API's to do almost anything 

I'm working on these for Ada. 

(warning, trumpet blowing begins here)

>Look at what one can do with Java:

List snipped to include only bits which are intended for
implementation in Ada either as part of my library set (either
implemented or planned) or as part of another project that I know
about.

>(this does not even count that the basic core Java packages come with
>more data structures and utilites to do usefull stuff than the Ada
>standard libraries come with)

My gliba.data-structures.* hierachy currently has binary search trees
(unbalanced), single and double linked lists, queues and
stacks. Balanced binary search trees and b-trees will be added
soon. honest. ;)

>2. the OMG packages for corba IDL stuff.

There's a number of Ada ORBs available, and there is work going on to
provide a binding to the free ORBit ORB.

>3. the SWING packages for GUI, Net/URL packages for easy networking.

GtkAda for GUI. Gliba.ARPA.* for news, mail, http and ftp.

>4. Java Beans for writing reusable compononts.

Ada for writing reusable components. ;)

>9. Java Mail packages. "The JavaMail API provides a set of abstract 
>   classes that model a mail system. The API provides a platform 
>   independent and protocol independent framework to build Java based 
>   mail and messaging applications."

cf 3.

>11. JCE packages. "The JavaTM Cryptography Extension (JCE) 1.2 
>    provides a framework and implementations for encryption, key 
>    generation and key agreement, and Message Authentication Code 
>    (MAC) algorithms. Support for encryption includes symmetric, 
>    asymmetric, block, and stream ciphers. The software also 
>    supports secure streams and sealed objects. 

Gliba.Cryptography.* will eventually suppourt (at least) OpenPGP
encryption/signatures, and anything else that I can get my hands on
without having to pay for it.

>13. JMS packages. "Enterprise messaging provides a reliable, 
>    flexible service for the asynchronous exchange of critical 
>    business data and events throughout an enterprise. JMS adds to 
>    this a common API and provider framework that enables the 
>    development of portable, message based Java applications."

Isn't this just a message que? or CORBA? or any number of other things?

>20. XML and Java. Although I don't know much about this, but it seems I see
>    Java more mentioned with XML than any other language. There are more

There's a free XML parser for Ada as part of GtkAda.

>Show the Ada packages that I can use to do the above.

http://www.skinner.demon.co.uk/aidan/programming/gliba/

for a basic, beta (0.0.4), bare-bones, highly unstable (as far as
interfaces go, the code itself is AFAIK fine), badly documented
version. Version 1.0.0 should be out sometime during Q3. I
hope. Depening how much help I get. Signifcant improvements are being
made on a daily basis and there's a stable URL for the latest source
tarball (nightly build) at:

http://www.skinner.demon.co.uk/aidan/programming/gliba/gliba.latest.tar.gz

>THere are also  more and more API and java packages out there (commerical 
>and non-commerical) for Java. But I think you get the point now.

well, gliba is under the same licence as GNAT (ie. I ripped the
headers from the gnat runtime and modified them), so you can use it in
your propriety applications so long as you don't modify the library
(and if you do modify the library you have to let people have the
source of the modified library, but that's all).

>>  Have you even looked seriously at Ada?
>
>Oh yes. you can look at Ada as long as you want. But when it comes to
>writing commerical applications with it in the real world, Ada does not
>not have the needed libraries and packages to do the work, and so it falls

This is, however, being worked on.

</trumpet blowing>

- Aidan
-- 
"Every time I see her I want to geek..."
"I say geek. If she runs then it was never meant to be. But if you talk
about routers, TCP/IP and programming and she stays, she's yours until the
counter flips" 

Re: The future of Ada

[Steve Quinlan]

Aidan Skinner wrote:

> On 27 Mar 1999 10:45:06 -0800, west@nospam <west@nospam> wrote:
>
> >Second, Java comes with packages and API's to do almost anything
>
> I'm working on these for Ada.
>
>

But,  you are only working on a subset, the work you are doing is not part of a
compiler with support, and what is there is only advertised as working on Linux.
I know, they SHOULD work with little modification elsewhere. Great for freeware
users, bad for what we was being talked about here -- level of penetration of
Ada in the general commercial marketplace.

The very fact that Java is so new, yet has all these great libraries and that
Ada has been around for years and has no such libraries, is the very point of
the indictment. The fact that Ada's response is a lone individual developing
freeware versions for Linux, whereas Java comes with supported standard
libraries on many platforms is the very point of the indictement.  Freeware is
great, but companies committing their projects to a language are by and large
not going to use unsupported freeware.

I think what you are doing is good, but to trumpet it as an "equalizer" between
Ada and Java in terms of library funtionality is a bit much.

                             Steve

Re: The future of Ada

[robert_dewar]

In article <36FFAC73.F8B69D31@nospam.lmco.com>,
  Steve Quinlan <steven.quinlan@nospam.lmco.com> wrote:

> Freeware is
> great, but companies committing their projects to a
> language are by and large
> not going to use unsupported freeware.

Yes, that's often true. Note that it is important to
distinguish between freeware -- software that is available
at no cost, typically with no guaranteed support, and
free software -- that is freely usable by licensed users.
Free software may or may not cost $$$ and may or may not
come with guaranteed support, but the important issue is
what can be done with it, not what it costs.

People may find it interesting to visit www.opensource.org


> I think what you are doing is good, but to trumpet it as
> an "equalizer" between
> Ada and Java in terms of library funtionality is a bit
> much.

Indeed, but then on the other hand, there are actually lots
of available libraries and bindings for Ada, if you look
around you will find equivalents for most of the Java
libraries already existing and already in use.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[SpamSpamSpam]

robert_dewar@my-dejanews.com wrote:

> People may find it interesting to visit www.opensource.org
>

People might also like to visit:

    http://www.gnu.org/philosophy/free-sw.html

and remember that all versions of GNAT, both the "public" and "commercial"
versions are free software, being
covered by the GPL and protecting your right to redistribute.

Re: The future of Ada

[bourguet]

In article <370075B2.63D03A21@spam.com>,
  spamwithchipsplease@spam.com wrote:
> robert_dewar@my-dejanews.com wrote:
>
> > People may find it interesting to visit www.opensource.org
> >
>
> People might also like to visit:
>
>     http://www.gnu.org/philosophy/free-sw.html
>
> and remember that all versions of GNAT, both the "public" and "commercial"
> versions are free software, being
> covered by the GPL and protecting your right to redistribute.

Right, not obligation :-)

This mean "if you have such a program, you may redistribute it"
not "if you know such program exists, you may get it".

-- Jean-Marc, who still like paying customer of ACT who do beta testing so
that he can get a free debugged compiler...

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[SpamSpamSpam]

bourguet@my-dejanews.com wrote:

> Right, not obligation :-)
>

Nothing like stating the obvious!

> This mean "if you have such a program, you may redistribute it"
> not "if you know such program exists, you may get it".

Actually, the second part, following your argument should be ....not "if you
havesuch a program, you are required to redistribute it."

but then not really adding much is it ? especially as the "obligation to
distribute" was
not mentioned or claimed. 8-]

Re: The future of Ada

[robert_dewar]

In article <370075B2.63D03A21@spam.com>,
  spamwithchipsplease@spam.com wrote:
> robert_dewar@my-dejanews.com wrote:

>     http://www.gnu.org/philosophy/free-sw.html

Yes, indeed, a good reference, and one that clearly
describes the use of the word "free" (and warns against
the use of the word freeware as a synonym).

> and remember that all versions of GNAT, both the "public"
> and "commercial" versions are free software, being
> covered by the GPL and protecting your right to
> redistribute.

Absolutely! We are one of the relatively small number of
companies that is dedicated to making all our products
available as open source software using the GPL.

Indeed this is one of our strong selling points to our
supported customers. We recently negotiated a deal with
one customer, and there was a large section on providing
for source escrow. We pointed out that this entire section
was completely unnecessary with open source software, since
they already had the sources!

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[SpamSpamSpam]

robert_dewar@my-dejanews.com wrote:

> In article <370075B2.63D03A21@spam.com>,
>   spamwithchipsplease@spam.com wrote:
> > robert_dewar@my-dejanews.com wrote:
>
> >     http://www.gnu.org/philosophy/free-sw.html
>
> Yes, indeed, a good reference, and one that clearly
> describes the use of the word "free" (and warns against
> the use of the word freeware as a synonym).
>

Great ! I'd like to code branch! going include a compile switch
called"-sloppy" which allows an implicit "with" where ever "use" appears
and an
implicit "all" where ever "access" appears. Obvious as its a code branch I
don't want to go from the 3.11p but from the newer 3.12a, otherwise I'd
have
to implement as well as debug all the new goodies in 3.12a.  Now where to
obtain
3.12a ... should I contact sales@gnat.com ?? I'm on a pretty tight budget
;-)

Re: The future of Ada

[Stephen Thomas]

SpamSpamSpam wrote:
> Great ! I'd like to code branch! [ ... ] Now where to obtain
> 3.12a ... should I contact sales@gnat.com ?? I'm on a pretty tight budget
> ;-)

Confucius he say: do not conflate development model with distribution
model.

Keep well,

Stephen Thomas

Re: The future of Ada

[dewar]

In article <3700B60A.328AA9E0@spam.com>,
  spamwithchipsplease@spam.com wrote:

> Great ! I'd like to code branch! going include a compile
> switch called"-sloppy" which allows an implicit "with"
> where ever "use" appears and an implicit "all" where ever
> "access" appears. Obvious as its a code branch I don't
> want to go from the 3.11p but from the newer 3.12a,
> otherwise I'd have to implement as well as debug all the
> new goodies in 3.12a.

There is no version 3.12a. The current release of GNAT
Professional is 3.12b2, and the public release 3.11p is
essentially the same code base, so if you want to play with
GNAT sources, 3.11p is indeed the place to work from.

As is the case with EGCS, there is development going on
that is not yet released. You will of course have to merge
your changes in with new releases as we release them. This
will be true unless your "improvement" is something that
we agree to incorporate into the mainstream sources. I
doubt me that your very dubious "sloppy" switch would
qualify :-)

But several people have contributed useful components (e.g.
Robert Eachus provided the random number generation
routines and the COBOL-style editing routines), and these
are now a fully maintained part of the GNAT sources.

Robert Dewar
Ada Core Technologies

P.S. I suggest that if you really want people to take you
seriously, you be willing to at least say who you are, and
provide an appropriate email address:

spamwithchipsplease@spam.com

does not sound like a very serious address :-)

P.P.S. If you really do want to try your "sloppy"
suggestion, I would recommend you use some unused -gnat?
switch, you will find it much less work, and it will be
more consistent.

Give it a try, it is quite a realistic project. It is the
kind of thing that would take an hour of so of work if you
know what you are doing, but you can quite reasonably
expect to spend a week or so, to climb the learning curve.
Places to look are switch.adb, opt.ads, par-ch10.adb. It
can be done by just modifying these three files, though it
would be a bit neater to insert the circuitry in
sem-ch10.adb (though a bit more work).

You might also want to join Mike Feldman's gnatlist where
people exchange implementation ideas.




-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[SpamSpamSpam]

dewar@gnat.com wrote:

> There is no version 3.12a. The current release of GNAT
> Professional is 3.12b2, and the public release 3.11p is
> essentially the same code base, so if you want to play with
> GNAT sources, 3.11p is indeed the place to work from.

I thought we'd previously agreed that 3.11b2 was the "commerical"version on
which the header files had been changed to 3.11p, and that
the next beta release was to be 3.12a ? I'd hate to trawl back
through dejanews to confirm this, so I take your word on this. Ques:
whats the current "beta" and current "wave" ?

> As is the case with EGCS, there is development going on
> that is not yet released. You will of course have to merge
> your changes in with new releases as we release them.

No, going to call my version "millenium" and set up a supportcompany called
"Instance Coffee's Quicker LTD" :-). Then I'm
going to release it in a flurry of press releases making all sorts of
claims for its ability to run on paper.

Ofcourse, I'm going to have to find a way to protect my greatest
company ASSET which of course ( bar my customers ) is not my
linux box, or office or phone, but my KNOWLEDGE of
"millenium". To this end I'm going to restrict as much as possible
external knowledge, to the point even of employing those who
make a significant contribution. The last thing I want ( as I'm going
to make a living from it) is for other "support" companies (such as
Rational, Greenhills ?) to pick it up and run.

> P.S. I suggest that if you really want people to take you
> seriously, you be willing to at least say who you are, and
> provide an appropriate email address:

Robert,

My identity is given away by the static node addresses from
which I post.  My "demon" account ( You need to be over
18 and optionally pop a happy pill to read it though ) gives
my personal email to those who root around. I make my
living in the Ada development world, and its a small
world for dealing in opinion.

> P.P.S. If you really do want to try your "sloppy"
> suggestion, I would recommend you use some unused -gnat?
> switch, you will find it much less work, and it will be
> more consistent.

I sure you have a list of (better and more worthy) additions toAda95 which
could come alive under "-gnat2K" :-)

> Give it a try, it is quite a realistic project.

Thanks for the encouragement and pointers. I shall undertake itas a "home
project" on 3.11p, the learning curve is the
problem, but I hope the payback in Ada95 knowledge from studying
the front end will be worth the time investment, and demonstrated by the
implementation of a dubious switch :(

Que: "Sympathy for the Devil" lyrics.

Re: The future of Ada

[robert_dewar]

In article <3701DACE.CD6A89DC@spam.com>,
  spamwithchipsplease@spam.com wrote:
> dewar@gnat.com wrote:
> > I thought we'd previously agreed that 3.11b2 was the
> "commerical"version on
> which the header files had been changed to 3.11p, and
> that
> the next beta release was to be 3.12a ?

Well I have no idea on what *you* agreed :-)

I am just telling you the current situation. The next
release (not a beta release, but a full release of
GNAT Professional) will be 3.12a. If there are no problems
with this release, 3.12p will be based on it, if, as
happened with 3.11, there are minor glitches, we may need
a 3.12a1 or 3.12a2 before we cut 3.12p. But I repeat 3.12a
is NOT yet released.

> I'd hate to trawl back
> through dejanews to confirm this, so I take your word on
this.

> Ques:
> whats the current "beta"

There is no formal beta release at the current time


> and current "wave" ?

We make new internal versions every day!


> > As is the case with EGCS, there is development going on
> > that is not yet released. You will of course have to
> > merge
> > your changes in with new releases as we release them.

> No, going to call my version "millenium"

<<frivolous stuff clipped>>

It is hard to tell if you are serious :-)

> > P.P.S. If you really do want to try your "sloppy"
> > suggestion, I would recommend you use some unused
-gnat?
> > switch, you will find it much less work, and it will be
> > more consistent.
>
> I sure you have a list of (better and more worthy)
> additions toAda95 which
> could come alive under "-gnat2K" :-)
>
> > Give it a try, it is quite a realistic project.
>
> Thanks for the encouragement and pointers. I shall
> undertake itas a "home
> project" on 3.11p, the learning curve is the
> problem, but I hope the payback in Ada95 knowledge from
> studying
> the front end will be worth the time investment, and
> demonstrated by the
> implementation of a dubious switch :(

You will find the front end well documented, and quite
easy to get into. The compiler course here at NYU works
by having students make modifications of this general
level of difficulty as one of the projects for the course
(for example, someone added a C-like construct

    (condition) ? expression : expression

:-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[Robert I. Eachus]

dewar@gnat.com wrote:

> But several people have contributed useful components (e.g.
> Robert Eachus provided the random number generation
> routines and the COBOL-style editing routines), and these
> are now a fully maintained part of the GNAT sources.
 
   Thanks for the nice words, but I can't take all the credit.  The code
you have is based on the Ada Technologly Insertion Program work Dave
Emery, Ben Brosgol, and I did for AJPO.  Yes, I did write most of the
code for those two parts of a much larger code library.  Dave and Ben
both wrote significant parts and we were all involved in design and
testing.  If you want to find some of the other code, lots of it now OBE
since it was for Ada 83, and a lot of those features are now in Ada 95,
look for ADAR in the public domain libraries.

   Incidently, as far as I am concerned that was one of the most
productive ATIPs the AJPO ever sponsored.  A lot of the work we did on
that contract had a significant influence on the design of Ada 95, and
in a few cases we  expected Ada 95 vendors to make free with the code. 
(Which is why it was released as public domain with no copyright.)

Re: The future of Ada

[Matthew Heaney]

SpamSpamSpam <spam@spam.com> writes:

> robert_dewar@my-dejanews.com wrote:
> 
> > People may find it interesting to visit www.opensource.org
> >
> 
> People might also like to visit:
> 
>     http://www.gnu.org/philosophy/free-sw.html
> 


People might also like to surf over to:

<http://www.acm.org/archives/patterns.html>

I have converted every example in the GoF Design Patterns book to Ada95,
and have now started documenting concurrency idioms.

You can subscribe to the patterns list by sending the message (body)

subscribe patterns <your full name>


to the ACM mailing-list server.

<mailto:listserv@acm.org>

Re: The future of Ada

[Jerry van Dijk]

Matthew Heaney (matthew_heaney@acm.org) wrote:

: People might also like to surf over to:
: <http://www.acm.org/archives/patterns.html>
: You can subscribe to the patterns list by sending the message (body)
: subscribe patterns <your full name>
: to the ACM mailing-list server.
: <mailto:listserv@acm.org>

Matthew, please... we know that by now... :-)

--
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | jdijk@acm.org
-- see http://stad.dsl.nl/~jvandyk

Re: The future of Ada

[Aidan Skinner]

On Mon, 29 Mar 1999 11:38:11 -0500, Steve Quinlan
<steven.quinlan@nospam.lmco.com> wrote: 

>Aidan Skinner wrote:
>
>> On 27 Mar 1999 10:45:06 -0800, west@nospam <west@nospam> wrote:
>>
>> >Second, Java comes with packages and API's to do almost anything
>>
>> I'm working on these for Ada.

>But,  you are only working on a subset, the work you are doing is not part of

At the moment yes, but hopefully it'll expand to the point where
there's most of the useful/relevant bits.

>compiler with support, and what is there is only advertised as working on Linu

No, but if people want suppourt contracts for it, then they could
always talk to me. ;) </wildly optimistic>

>I know, they SHOULD work with little modification elsewhere. Great for freewar

Currently all of Gliba.* should compile cleanly on any OS where
there's an Ada compiler. Any Linux specific portions will almost
inevitably be those using Florist, so even then porting them will be a
case of having a version of Florist with (at least) the necessary bits working.

>users, bad for what we was being talked about here -- level of penetration of
>Ada in the general commercial marketplace.

Depends, the copyright Gliba is under means that other people can
provide commercial suppourt if they want it too, and any body can use
the librarys in their propreity apps without problems.

>The very fact that Java is so new, yet has all these great libraries and that

Java has these librarys because Sun sat down and thought "what do we
need to provide to ensure massive market penetration in a short time?"
and then paid for people to develop them. Ada hasn't, AFAIK, ever been
concertedly marketed like this or even had the level of financial
backing that Java has had since it's launch.

>I think what you are doing is good, but to trumpet it as an "equalizer" betwee
>Ada and Java in terms of library funtionality is a bit much.

Hey, it might work. ;)

- Aidan
-- 
"Every time I see her I want to geek..."
"I say geek. If she runs then it was never meant to be. But if you talk
about routers, TCP/IP and programming and she stays, she's yours until the
counter flips" 

Re: The future of Ada

[Ed Falis]

> On Mon, 29 Mar 1999 11:38:11 -0500, Steve Quinlan
> <steven.quinlan@nospam.lmco.com> wrote: 

> >I think what you are doing is good, but to trumpet it as an "equalizer" betwee
> >Ada and Java in terms of library funtionality is a bit much.
> 

What about the fact that you can get access to any Java class from native Ada applications using the AdaJNI product that we sell and support?  I have full access to all 
of Java 2.  And if I wish to access some 3rd party facilities the product does completely "hands off" binding generation.  This does, however, fire up a JVM from the 
native application.

And if I want to run the complete application on a JVM, rather than splitting it, I can use the Ada -> JBC generator we also provide with most of our native products, 
which includes a complete JDK 1.1 binding at the moment (Java 2 to come).

And ACT is either very close or ready to provide their JBC compiler and bindings as well.

So, there are a number of "equalizers" in terms of class libraries, provided you're still willing to run the JVM for part of your application.  Then there's all the other good 
Ada stuff for when you don't.  And I still haven't seen anything better for real-time applications, especially as that get larger.

- Ed Falis
Aonix

Re: The future of Ada

[west]

In article <7diro7$1jo$1@nnrp1.dejanews.com>, mjsilva@my-dejanews.com says...
>
 
>I can tell you that for my applications (embedded real-time systems), Ada is a
>much better fit than Java.
>
>Mike

Then how come the rest of the world are moving to Java even in the
area of embedded systems?
 
Check an article titled "Java driving a revolution in Embedded Systems"
by John Waters, in Strategic Platforms spring 99 magazine. The whole edition
is on Embedded Systems, and it is all about Java. Ada is not even mentioned.

Some quotes

"You can put out a higher quality product in less time. Our clients are
moving to Java technology in a major way". Larry Podmolik, Chief technical
officer, strategic Technology Resources.

"Licensing the EmbeddedJava and PersonalJava environment is an
important step forward building TI's offering on the software
side of that question". Gilies Delfassy, Geneal Manager, TI wireless
communications.

"The embedded systems market is big business and getting bigger. 
EmbeddedJava technology is enabling advanced that were barely
imagined a few years ago".
N. Iravani
Group manager, Market development, Sun.

On Java technology in industrial automation "As Sun continues to move
with java-based technologies in industrial automation, leading
automation system vendors will be able to achieve sensor to boardroom
capabilities. And they'll do it using a completely networked, Object based
architecture that takes advantage of emvedded java technology". Kevyn
Renner, group manager, worldwide industrial automation development, Sun.


"Geoworks is helping to broaden the 'run anywhere' part of the java WORA
mission", David Grannan, President and CEO, Geoworks corp.

"Developers turn to personalJava and EmbeddedJava to complement
real-time operating systems in devices". Tony Reveaux.

So, is java kicking Ada out of embedded systems also? Where is Ada
reponse to Java taking over the embedded market?  

West.

Re: The future of Ada

[Larry Kilgallen]

In article <7dv54d$6vg@drn.newsguy.com>, west@nospam writes:
> In article <7diro7$1jo$1@nnrp1.dejanews.com>, mjsilva@my-dejanews.com says...
>>
>  
>>I can tell you that for my applications (embedded real-time systems), Ada is a
>>much better fit than Java.
>>
>>Mike
> 
> Then how come the rest of the world are moving to Java even in the
> area of embedded systems?
>  
> Check an article titled "Java driving a revolution in Embedded Systems"
> by John Waters, in Strategic Platforms spring 99 magazine. The whole edition
> is on Embedded Systems, and it is all about Java. Ada is not even mentioned.
> 
> Some quotes

It seems to me that quotes at best provde that some individuals are
taking position X.  Only surveys can prove "the rest of the world" is
taking position X.

The nature of trade publications is to seek out sources whose comments
bolster the already-chosen thrust of the article.

Larry Kilgallen

Re: The future of Ada

[Steve Doiel]

>Then how come the rest of the world are moving to Java even in the
>area of embedded systems?
>


Does anyone remember Turbo Prolog?

I distinctly remember reading articles (from more than one source) a number
of years
ago (more than I would like to count) about how in 5 years everyone would be
programming
in Prolog.

My answer back then: Learn Prolog, evaluate it, use it if you think it's the
best tool for the job.

Java?

My answer now: Learn Java, evaluate it, use it if you think its the best
tool for the job.

BTW: You'll get the same response from me regardless of what language you
ask about.

My language of choice for non-GUI applications: Ada

SteveD

Re: The future of Ada

[dennison]

In article <37042ff8.0@news.pacifier.com>,
  "Steve Doiel" <nospam_steved@pacifier.com> wrote:

> My language of choice for non-GUI applications: Ada

Actually, for Motif applications I'd choose UIL/Ada. With UIL doing most of
the setup work, you don't need too many Motif calls; typically few enough
that its easy to create the bindings to them yourself. Also, it turns out
registering widget names with MRM is one of the really nifty uses of 'image.

Really the only problem with Ada and GUI's is getting bindings, and the
typical un-adalike interface they tend to provide. I'm sure we'll get several
replies from thick binding implementors saying how they have "solved" that
problem too.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[Tom Moran]

>Really the only problem with Ada and GUI's is getting bindings, and the
>typical un-adalike interface they tend to provide. I'm sure we'll get several
>replies from thick binding implementors saying how they have "solved" that
>problem too.
  Not to disappoint ;)  Windows is so big I'm not sure "solved" is a
word that applies.  For instance CLAW 1.2 (www.rrsoftware.com) is 120K
SLOC and we're still adding to it - and trying to keep anything that
big understandable is non-trivial.  Even the demo version is a 250K
(source) download.  Windex
(http://www.erols.com/leakstan/Stephe/index.html) is smaller, but also
growing.

Re: The future of Ada

[kewick]

In article <3705261c.5306195@news.pacbell.net>, tmoran@bix.com says...
 
>For instance CLAW 1.2 (www.rrsoftware.com) 

hi,

when will CLAW become open source/GPL type software like with GNAT? that
will help in its wide spread use. 

Kewick.

Re: The future of Ada

[Tom Moran]

>when will CLAW become open source/GPL
You'll have to ask RR Software, since they own it.  Its source is
already available: the demo version is freely downloadable, and
customers of the full-up version get source.  
  If you mean, when will RR Software find sufficient other sources of
money that they can give away CLAW, and continue to work adding to it,
for free, I haven't a clue.  Perhaps you can suggest something, or
send them a large check. ;)
  I believe Windex is GPLed, but of course it hasn't yet had the man
hours invested and thus is less complete, but if you're not in a
hurry, or want to help develop it.....
  If you want to make your own GPLed thick binding, our TriAda paper
on considerations and approaches for a Windows binding is available
for free (in both usages of the term)  at the www.rrsoftware.com site.

Re: The future of Ada

[Stephen Leake]

tmoran@bix.com (Tom Moran) writes:

>   I believe Windex is GPLed, but of course it hasn't yet had the man
> hours invested and thus is less complete, but if you're not in a
> hurry, or want to help develop it.....

At the moment, Windex is under the Ada Community License, first used
on the Ada Booch components. But the next release (availabel Real Soon
Now) will use the Gnat modified GPL, since that seems to be more
widely understood.

-- Stephe

Re: The future of Ada

[Tom Moran]

>when will CLAW become open source/GPL type software like with GNAT? that
>will help in its wide spread use. 
  On further thought, I think it would be even better if someone would
make a thick binding for Java - preferably one with a close (ie,
portably interchangeable with) design similarity to, say, CLAW, to the
extent that's possible and reasonable.

Re: The future of Ada

[robert_dewar]

In article <7di6r6$bhd@drn.newsguy.com>,
  west@nospam wrote:
> In article <36fcbe32.0@news1.jps.net>, "Mike says...
> But nowadays, the Big one is Java. It is not C or C++.
>
> Ada programmers like to put C/C++ down, becuase it is
> easy to do so (due to obviouse weaknesses in these
> languages). But it is much harder to try to knock Java
> down, which is really becomming the main language
> of use out there now.

This is simply not the case, very little large scale
application programming is being done in Java today.
There is a lot of experimentation going on, but there
have been a number of spectacular failures (e.g. Corel),
and it is far from clear that Java can deliver in the
large scale application area.

Hype does not replace actual work :-)

If anyone can point to multi-million line Java programs,
feel free to do so! Even examples at the few hundreds of
thousands of lines would be of interest ...


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[Aidan Skinner]

On 27 Mar 1999 01:02:30 -0800, west@nospam <west@nospam> wrote:

>But nowadays, the Big one is Java. It is not C or C++.

Java is still slow to be executed, and I certainly wouldn't want to
write anything that it is time critical in an interpreted language
(which is effectively what bytecode is, albiet with a very fast
interpreter). Also I seem to remember somebody telling me something
about problems with writing device drivers in Java, but i can't
remember the specifics of it (I don't do hardware ;>).

>Java is being used everywhere now. There are even webServers and application
>servers written in Java. Show me one web server written in Ada.
>
>Why is that? 

Coz I've been busy doing other CoolStuff that's distracted me from
writing the small webserving {front|back}end that I need for another
project. Be with you in about 6 months probably. ;)

- Aidan (who will now quietly slip off and runaway from the ensuing flamewar)
-- 
"Every time I see her I want to geek..."
"I say geek. If she runs then it was never meant to be. But if you talk
about routers, TCP/IP and programming and she stays, she's yours until the
counter flips" 

Re: The future of Ada

[Tom Moran]

I've seen not a single TV ad for bulldozers, and lots for Toyota cars.
The most popular vehicle in the US is a Toyota Camry.  Clearly nobody
in their right mind would bother with bulldozers (or jet planes or jet
skis etc) - only Camrys and their close cousins need be considered for
transport.  Right?
(Not a Camry driver.)

Re: The future of Ada

[Aidan Skinner]

On Fri, 26 Mar 1999 18:32:49 GMT, John McCabe <john@assen.demon.co.uk.nospam> 
wrote:

>I can't understand where you got that idea from. I find with Ada I can
>just sit down and code something, and most times, if the language
>allows what I've written, what the compiler produces does what I want.

I'm a firm believer that (good) Ada code Means what it Says and Says
what it Means. This can't be said for C* (even for good C*).

- Aidan
-- 
"Every time I see her I want to geek..."
"I say geek. If she runs then it was never meant to be. But if you talk
about routers, TCP/IP and programming and she stays, she's yours until the
counter flips" 

Re: The future of Ada

[David Botton]

I agree, Even when I can't use Ada for the final product I very often
prototype in Ada since it offers many abstractions not found in Java and
C++. The problem here is a lack of familiarity with the tools at hand,
not the language.

David Botton


John McCabe wrote:
> 
> "Michael Garrett" <michaelgarrett@csi.com> wrote:
> 
> >I am just learning Ada, and it is frustrating sometimes to realize that I
> >can not just sit down and code something, even to try it out.
> 
> I can't understand where you got that idea from. I find with Ada I can
> just sit down and code something, and most times, if the language
> allows what I've written, what the compiler produces does what I want.
> 
> I could never say that about using C.
>

Re: The future of Ada

[Tucker Taft]

Gordon Dodrill wrote:
> 
> A few weeks ago someone in this newsgroup mentioned that
> Ada is a $100M industry.  If this number is reasonable,
> then assuming a loaded salary of $120K per year, there are
> only about 830 full time Ada developers.

The $100M number refers to the Ada *tools* market.
If you figure an average serious Ada developer spends $5K/year
on tools, then that comes out to 20,000 Ada developers.
In other words, the Ada application development market is orders of
magnitude larger than the Ada tools market.

> ...
> Ten months into the project, the project leader announced
> very abruptly that Ada would be scrapped, C++ would be used,
> and there would be a six month slip in the project to permit
> training in C++ and rewriting the  completed Ada code.  His
> reason - "There may not be any Ada programmers to do
> maintenance several years from now, but we will always be
> able to get C++ programmers."
> 
> I am obviously frustrated.  How can I continue to promote
> the use of Ada when the numbers mentioned in the first two
> paragraphs above indicate a lack of growth in Ada compared
> to the other languages?  Any thoughts, either positive or
> negative, will be appreciated.

The number of serious Ada developers is in the 10s of
thousands, the number of developers with Ada experience
is in the 100s of thousands.

In any case, you will never sell Ada on the availability of
"Ada" programmers.  However, hiring based strictly
on specific programming langauge experience is a big mistake.
If a programmer can be truly successful in C++, then chances
are they can be extremely successful in Ada.  It is significantly
easier to succeed using Ada, even given the need to learn the
language as part of building or maintaining the system.  
An Ada compiler helps significantly in the training process,
because it is so good at finding "silly" mistakes, and pointing
out inconsistencies.  Compilers for other languages are often
of little or no help in training, and leave the programmer with
plenty of "silly" mistakes to dig out through long and painful
debugging sessions.

But I presume you know all of this.  You need to explain this
to your management as well.  Ada is a tool, not a religion.
It is a much better tool than most other languages for creating
reliable systems.  Good programmers can be trained in the use
of this tool, just like any other.  And in fact, Ada comes with
a ready made training tool -- the compiler.

> Gordon Dodrill
> Sandia National Laboratories - Albuquerque, New Mexico

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: The future of Ada

[Tucker Taft]

Tucker Taft wrote:
> ...
> Ada is a tool, not a religion.
> It is a much better tool than most other languages for creating
> reliable systems.  Good programmers can be trained in the use
> of this tool, just like any other.  And in fact, Ada comes with
> a ready made training tool -- the compiler.

I might add that I was speaking with a large defense contractor
recently about their use of Ada, and we determined that almost
everyone in the room had learned Ada "on the job."  And this 
included the Ada "experts" in the company.

Ada might be the ideal programming language for learning on
the job.  The bottom line is to hire good people, and give
them the best possible tools.  Don't let your "new hires" determine
what tools you use.  Choose the tools that produce the highest
quality results on schedule and within budget.  
You will profit both in the short term and in the long term.

> > Gordon Dodrill
> > Sandia National Laboratories - Albuquerque, New Mexico
> 
> --
> -Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
> Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
> AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: The future of Ada

[Andreas Winckler]

Gordon Dodrill wrote:
> Any thoughts, either positive or negative, will be appreciated.

An experience that I've made in our company is that the superior re-use
capabilities of Ada allows us to use most of once written code again and
again for many years. Note that to use means to SELL it again and again
for good money!

Greetings,

AW
-- 
------------------------------------------------------------------------
Andreas Winckler                             Tel: (+49) (7541) 282 - 462
Department: MHS                              Fax: (+49) (7541) 282 - 299
FREQUENTIS Network Systems GmbH              http://www.frqnet.de
------------------------------------------------------------------------

Re: The future of Ada

[Gordon Dodrill]

Gordon Dodrill wrote:

   [snip]
> I am obviously frustrated.  How can I continue to promote
> the use of Ada when the numbers mentioned in the first two
> paragraphs above indicate a lack of growth in Ada compared
> to the other languages?  Any thoughts, either positive or
> negative, will be appreciated.

I want to thank you for all of the responses to my request.

As expected, there is a lot of support for the use of Ada in
this newsgroup.  I agree that a good programmer can learn the
essentials of any language rather quickly so that the 
availability of maintenance programmers is not a real issue.
However, we are still forced to go with the project leader's
decision.

Even though the larger project has dropped Ada, there is a 
smaller (about 5 persons) project that is still committed to 
the use of Ada.  About 70% of my time is commited to this 
project, so we still have a foot in the door for the future, 
and I will continue to campaign for Ada.

Thank you for clearing up the fact that the $100M figure was
the total for the development of Ada tools, and does not 
include developers time.

Gordon Dodrill
Sandia National Laboratories - Albuquerque, New Mexico

Re: The future of Ada

[robert_dewar]

In article <36E96E42.26AD@sandia.gov>,
  gjdodri@sandia.gov wrote:
> Gordon Dodrill wrote:
>
> Even though the larger project has dropped Ada, there is
> a  smaller (about 5 persons) project that is still
> committed to  the use of Ada.  About 70% of my time is
> commited to this  project, so we still have a foot in the
> door for the future, and I will continue to campaign for
> Ada.

So, Gordon, the tactic is clear, make sure this smaller
project is a super success :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: The future of Ada

[Larry Kilgallen]

In article <36E96E42.26AD@sandia.gov>, Gordon Dodrill <gjdodri@sandia.gov> writes:

> However, we are still forced to go with the project leader's
> decision.

There must be a decision-making process in any environment, and
the one that hurts you now may be of help if you get assigned
as project leader of something that might otherwise avoid Ada.

> Even though the larger project has dropped Ada, there is a 
> smaller (about 5 persons) project that is still committed to 
> the use of Ada.  About 70% of my time is commited to this 
> project, so we still have a foot in the door for the future, 
> and I will continue to campaign for Ada.

You have an excellent opportunity for such a campaign, if you
can bring the smaller project in on time and under budget. If
the larger group had not tried C++, there would be no basis for
comparison.

Larry Kilgallen

Re: The future of Ada

[Nick Roberts]

Gordon Dodrill wrote in message <36E96E42.26AD@sandia.gov>...
[...]
|Even though the larger project has dropped Ada, there is a
|smaller (about 5 persons) project that is still committed to
|the use of Ada.  About 70% of my time is commited to this
|project, so we still have a foot in the door for the future,
|and I will continue to campaign for Ada.


This should turn out to be an excellent development.  I think I can see what
will happen, and I don't think it will turn out to be any exaggeration.  The
big C++ project will suffer almost indefinite slippage, a sea of
unmanageable bugs, and a staff turnover of gathering speed.  The smaller Ada
project, on the other hand, will come in on time, on budget, and within
spec.

Of couse, unfortunately, by the time it does, the project manager who made
the decision to switch to C++ on the bigger project will have long gone, and
your objection to it in the first place will get conveniently forgotten.
But I am not a cynic, and with a little luck you will be put in charge of a
larger project, for which Ada will be (allowed to be) selected as the (main)
language.  I certainly hope so.

[...]
|Gordon Dodrill
|Sandia National Laboratories - Albuquerque, New Mexico

Best of luck.

-------------------------------------
Nick Roberts
-------------------------------------

Re: The future of Ada

[Marin David Condic]

Nick Roberts wrote:
> This should turn out to be an excellent development.  I think I can see what
> will happen, and I don't think it will turn out to be any exaggeration.  The
> big C++ project will suffer almost indefinite slippage, a sea of
> unmanageable bugs, and a staff turnover of gathering speed.  The smaller Ada
> project, on the other hand, will come in on time, on budget, and within
> spec.
> 
>
One must be careful here. Language selection alone doesn't determine
success or failure of a project. There are lots of systems coded in C++
that are working just fine. There are also systems developed with Ada
that fail miserably. While I believe that Ada reduces the probability of
over-budget/shot-schedule conditions on a project, it still needs to be
used intelligently in conjunction with other technical/managerial assets
in order to see the benefit. OTOH, if a project realizes that C++ has
potential risks and they plan well for it, they might produce a
successful product as well. I'm convinced that Ada would achieve the
result at a lower cost, but you've got to throw in a lot of "ifs" along
the way.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Re: The future of Ada

[Corey Ashford]

Gordon Dodrill wrote:
[snip]
> 
> Thank you for clearing up the fact that the $100M figure was
> the total for the development of Ada tools, and does not
> include developers time.
[snip]

I think you may still have misunderstood it.  $100M is not the
amount of money spent on developing Ada tools, it's how much
is spent by customers buying the tools.

- Corey

Re: The Future of Ada

[Edward V. Berard]

In article <1990Aug15.151935.8848@sctc.com>, endrizzi@sctc.com (Michael Endrizzi ) writes:
> 
> This is why the survival of Ada is at stake:
> 
> 	1)Control
> 	2)Cost
> 	3)Complexity
> 
> 1)Control: Programmers and our associated egos like to be in control 
> of our destinys. On paper, Ada is a powerful tool that automates
> many of the manual checks (recompilation, type checking) that
> other languages lack. By using this tool, we give up control.

This is an interesting observation. While I will admit that there
may be some things which are easier to accomplish in C (and, of
course, many things which are easier to accomplish in Ada), Ada
provides you with all the control that C offers you -- and, very
probably, much more. Just as an inexperienced C programmer might
believe that some things are impossible -- or incredibly difficult
-- in C, so would an inexperienced Ada programmmer think that
some things were "impossible" in Ada.

> And when that tool
> doesn't work right, it's like being in a speeding car with
> not steering wheel driving in the mountains.

I very much agree.
 
> C/Unix on the other hand is a hackers tool. If this don't
> work right...well we all know how easy it is to flip a
> few bits here and there to make it work.

As someone who uses both C and Ada, and knows quite a few
"C hackers," I think you are indulging in fantasy. I have
seen plenty of C programs which destroyed not only themselves,
but also their surrounding environment because the programmer
"flipped a few bits here and there." Incompetence is
programming language independent.
 
> 2)Cost: Quality Ada environments are expensive and resource hogs.
> You can't just sit at home and hack into the night on your
> Mac/PC. You must have your $100,000 Rational with 200 Gigs
> of storage parked in your basement to get a true Ada high.
> I know on our system, I must balance elegance with "will
> the damn thing even compile, fit on our disks, crowd out
> other users, etc".

Years ago I wrote an article about the problems with
validated Ada compilers. The average quality at the time (5 years
ago) was not all that great, but there were still some superstars.
Today, with over 50 vendors particpating, the quality has
improved noticeably.

	I _am_ at home at night programming (not "hacking") on my
	Mac with Ada, and using 2 different validated Ada compilers
	for the Mac OS. I am currently attempting to write code
	which deliberately breaks the Ada compilers I am using,
	and I am having nowhere near the problems you are having.
	(I might add that I am also _not_ using the same compiler
	vendor you are using.)

> C/Unix on the other hand is basically free. GCC is probably
> one of the highest quality C products and it is free. Unix
> comes standard on some systems.  Compile times, storage
> requirements are reasonable in a multi-user environment.

Please don't get sucked into the classic apples and oranges
comparison of C and Ada systems:

	1. If the most ardent Ada hater will grant that Ada
	   provides far more capabilities than does C. (In
	   fact, they often use this as an argument against
	   Ada.)

	2. C compiler vendors do not have to (re)validate their
	   compilers. Validation does cost.

	3. The marketplace for C compilers is greater than the
	   marketplace for Ada compilers. The size of the market
	   does indeed influence the cost of the product. (You,
	   of course, know that C is almost 10 years older than
	   Ada.)

 
> 3)Complexity: On paper Ada is addictive, elegant,  true
> solution to multi-person life-cycle software engineering.
> In reality, I know of only 2 products that are usable:
> 
> 	1) Rational
> 	2) DEC

As I said before, your experience is limited. I happen to
like both of the systems above, but others are at least
acceptable.

When I was teaching C, I used to have to assure some students
that all C compilers were not incredibly buggy, and that not
all C compilers generated huge object files. I explained to
them that there were many C compiler vendors, and that quality
varied widely. Even with a programming language which has
been around for nearly 2 decades, new vendors constantly
repeat the mistakes of the past.

> Unix was/is/will always be a disaster
> This then goes back to the cost issue.  

No comment.
 
				-- Ed


----------------------------------------------------------------------------
Edward V. Berard                                | Phone: (301) 353-9652
Berard Software Engineering, Inc.               | FAX:   (301) 353-9272
18620 Mateney Road                              | E-Mail: eberard@bse.com
Germantown, Maryland 20874                      | 
----------------------------------------------------------------------------

Re: The Future of Ada

[Michael Endrizzi]

eberard@bse.com (Edward V. Berard) writes:

>course, many things which are easier to accomplish in Ada), Ada
>provides you with all the control that C offers you -- and, very
>probably, much more. Just as an inexperienced C programmer might

I disagree for a different reason. In C, the user is responsible
for system build. In Ada, the library and assoc tools are
responsible for system build. If the library is corrupt, if the
tools don't work, you have lost control to the Ada environment.
This is not true with C.

Also, you are provided with a package that is shut tight
with limited private types and is a central module used by
the whole system. You need to have visibility to some 
data object in that package. Proper software engineering
would require you to create a new routine. Reality says,
"If you cause a recompilation of the whole system, you will
piss off 20 programmers who are trying to work on a stable
system".  C let's you hack it in. You gain control. 

I'm NOT advocating this approach. I see it happen all the
time and I get the willys.  I'm just saying it is an
advantage (puke ugh gag).

>"C hackers," I think you are indulging in fantasy. I have
>seen plenty of C programs which destroyed not only themselves,

You misread my statement. I agree with you completely.

>Please don't get sucked into the classic apples and oranges
>comparison of C and Ada systems:

I don't think that I am. I am trying to convince my company
to switch from a glorified assembler "C" to a real software
engineering tool. I have to compare the advantages/disadvantages
of the two.  Right now I don't have any advantages to show them.


For those of you who don't know Ed, if you ever meet him ask
him for a reference for some literary material. He will quote
you book, paragraph, page, section, author, year, etc.  Never
would play poker with that man.


			Dreez

=================================================================
=================================================================
               Michael J. Endrizzi
	Secure Computing Technology Corp.
	   1210 W. County Road E #100
	      Arden Hills, Mn. 55112
	        endrizzi@sctc.com
	          (612) 482-7425
	
*Disclaimer: The opinions expressed above are not of my employer
             but of the American people.
=================================================================
=================================================================

The Future of Ada

[Michael Endrizzi]

I walked into my current job an Ada addict. The people I work with
are all pretty much C/Unix hacks, so I thought I had the world
at my beckon. I watched and laughed in horror as they passed
untyped pointers, randomly recompiled modules because they
"knew" which ones were out of date, used pointer arithmetic
because C bit-fields did not align properly, etc, etc.

Reality hit.

I won't mention the name of the vendor in this column, but we
purchased a moderately priced Unix Ada environment.  Word had
it that this package was "OK" but not great.  No such luck.
I am living in a nightmare of internal compiler errors and 
inconsistent data base errors.

This is why the survival of Ada is at stake:

	1)Control
	2)Cost
	3)Complexity

1)Control: Programmers and our associated egos like to be in control 
of our destinys. On paper, Ada is a powerful tool that automates
many of the manual checks (recompilation, type checking) that
other languages lack. By using this tool, we give up control.
Big egos don't like to give up control. And when that tool
doesn't work right, it's like being in a speeding car with
not steering wheel driving in the mountains.

C/Unix on the other hand is a hackers tool. If this don't
work right...well we all know how easy it is to flip a
few bits here and there to make it work.

2)Cost: Quality Ada environments are expensive and resource hogs.
You can't just sit at home and hack into the night on your
Mac/PC. You must have your $100,000 Rational with 200 Gigs
of storage parked in your basement to get a true Ada high.
I know on our system, I must balance elegance with "will
the damn thing even compile, fit on our disks, crowd out
other users, etc".

C/Unix on the other hand is basically free. GCC is probably
one of the highest quality C products and it is free. Unix
comes standard on some systems.  Compile times, storage
requirements are reasonable in a multi-user environment.

3)Complexity: On paper Ada is addictive, elegant,  true
solution to multi-person life-cycle software engineering.
In reality, I know of only 2 products that are usable:

	1) Rational
	2) DEC

(there might be others, but these are the ones most
talked about and I am familiar with).  Ada merges several
technologies --multi-user database, parallel processing,
software engineering, compilers, user interfaces, etc.
The only way to support the integration of these technologies
is to have a platform that allows them to talk to one another.
The platform must either be customized (Rational) or of
high quality (DEC/VMS).  Unix was/is/will always be a disaster
This then goes back to the cost issue.  

Also, very few vendors are able to master these technologies.
Either they  are too small to afford it or the egos are so
damn huge in the individual fields that they can't bring the
team together to build a quality product.


I am done rambling. I learned my lesson. Ada taught me many
great concepts and but also the realities of life.

		au revoir Ada, :-(   (sniffle,sniffle)

			Dreez


=================================================================
=================================================================
               Michael J. Endrizzi
	Secure Computing Technology Corp.
	   1210 W. County Road E #100
	      Arden Hills, Mn. 55112
	        endrizzi@sctc.com
	          (612) 482-7425
	
*Disclaimer: The opinions expressed above are not of my employer
             but of the American people.
=================================================================
=================================================================

Re: The Future of Ada

[Jerry Callen]

In article <1990Aug15.151935.8848@sctc.com> endrizzi@sctc.com (Michael Endrizzi ) writes:
>This is why the survival of Ada is at stake:
>
>	1)Control
>	2)Cost
>	3)Complexity
>
>1)Control: Programmers and our associated egos like to be in control 
>of our destinys. On paper, Ada is a powerful tool that automates
>many of the manual checks (recompilation, type checking) that
>other languages lack. By using this tool, we give up control.
>Big egos don't like to give up control. And when that tool
>doesn't work right, it's like being in a speeding car with
>not steering wheel driving in the mountains.

I don't really view type checking as a loss of control; rather, as you
pointed out, it automates an otherwise tedious part of my job. The
ability to override the checking is there when you really need it, via
unchecked_conversion, pragma interface, and (if you're lucky enough
to be using a system supports it) machine code insertions. My ego has
survived, and no one has ever accused me of having a small ego! :-)

It _is_ really annoying when the tools let you down. In my experience,
though, this happens pretty rarely, and I'd rather put up with the few
failures than live without the conveniences.

>C/Unix on the other hand is a hackers tool. If this don't
>work right...well we all know how easy it is to flip a
>few bits here and there to make it work.

Actually, Ada/Unix can be a hacker's tool, too. At least, that's how _I_
often treat it. Judicious use of the overrides I mentioned above allow
me to dig as deep a hole for myself as I wish. :-)

>2)Cost: Quality Ada environments are expensive and resource hogs.

Sigh. Some myths never die. I'm currently using Ada on an Opus PM8000
(Moto 88K board in a stock AT clone). Ada compilations zip right along;
I can recompile about 100 medium-sized units (averaging a few hundred lines
each) in about 10 minutes. I share this machine with several other users also
doing Ada compilations. You'ld have to put a gun to my head to get me to move
onto a VAX/VMS system and off this little PC (hey, this is _unix_, not VMS!).

>C/Unix on the other hand is basically free. GCC is probably
>one of the highest quality C products and it is free.

No argument here. Gada, anyone?

>Unix comes standard on some systems.  Compile times, storage
>requirements are reasonable in a multi-user environment.

See above.

>3)Complexity: On paper Ada is addictive, elegant,  true
>solution to multi-person life-cycle software engineering.
>In reality, I know of only 2 products that are usable:
>
>	1) Rational
>	2) DEC
>
>(there might be others, but these are the ones most
>talked about and I am familiar with). 

I have biases I'd rather not reveal, but I think this list could be
expanded. I'm reasonably happy with the system I'm using right now.
(Actually, I don't much like some of the internals, but...)
I have been happy with another system that actually has a more complex
(but, surprisingly, much more usable) library system.

>The platform must either be customized (Rational) or of
>high quality (DEC/VMS).  Unix was/is/will always be a disaster

Hey! You knockin' Unix, buster? Themz fightin' words! :-)

Nearly ALL of my Ada experience (aside from some unpleasantness involving
large bluish machines...) has been on Unix. I love it.

>Also, very few vendors are able to master these technologies.
>Either they  are too small to afford it or the egos are so
>damn huge in the individual fields that they can't bring the
>team together to build a quality product.

Lots of truth to these words. Anyone who tries to tell you that an Ada
compiler isn't more complex than a C compiler may also try to sell you
a bridge.

But some vendors _are_ doing it, or at least coming close. The technology
is maturing. I think there was a tendency on the part of early Ada implementors
to produce over-engineered systems that were, in fact, fragile resource hogs.
But the shake-out is happening; the surviving vendors keep refining their
products, and the compilers get better and better. Unfortunately, the bad
first impressions linger, and not everyone burned by a bad compiler is willing
to put up the bucks for a newer, better compiler.

>I am done rambling. I learned my lesson. Ada taught me many
>great concepts and but also the realities of life.
>
>		au revoir Ada, :-(   (sniffle,sniffle)

Aw, shucks, don't give up on the old gal yet! :-) 

-- Jerry Callen
   jcallen@encore.com

Re: The Future of Ada

[Steve Vestal]

>In article <12490@encore.Encore.COM> jcallen@Encore.COM (Jerry Callen) writes:
>   [ massive quantities of stuff deleted ]
>   No argument here. Gada, anyone?

I heard a Gnu Ada rumor awhile ago.  Does anyone have any reliable information
about this?

Steve Vestal
Mail: Honeywell S&RC MN65-2100, 3660 Technology Drive, Minneapolis MN 55418 
Phone: (612) 782-7049                    Internet: vestal@src.honeywell.com