NOACE- End of the road for Ada?

NOACE- End of the road for Ada?

[Michael Card]

Hello everyone-

It seems that everywhere I look, I see articles about the DoD world 
being anxious to purge Ada from all their systems in favor of C++ and 
Java. For example, see

http://www.cotsjournalonline.com/home/article.php?id=100149

This article references the Navy Open Architecture Computing Environment 
(NOACE- love that acronym) which specifically calls for a move away from 
Ada and requires all new software to be done in C++ or Java ("the C++ 
mandate"?)

My question is this: why are so many in the DoD itself and the 
contractors world opposed to Ada? The projects I have been on that used 
Ada got good results out of it in terms of system performance and 
development schedule. In both of these regards, the results were 
generally better than comparable C/C++ projects. So, was my experience 
unique? Were there great Ada failures (huge cost over-runs, bad 
performance, etc) that left such a bad taste in people's mouths that 
even nice products like modern Ada95 compilers are unwelcome?

Also, as Ada is being abandoned in the aerospace industry, is there 
evidence that it is being picked up elsewhere?

-Mike

Re: NOACE- End of the road for Ada?

[Alexander E. Kopilovich]

Michael Card wrote:

>My question is this: why are so many in the DoD itself and the 
>contractors world opposed to Ada?

Think about China. Guess, which complex and purposeful software is easier to
investigate, modify/adapt, port to other equipment/environment etc. - that is
written in Ada or that in C++ and/or Java?

Imaging yourself being a mainland Chinese and working in some military outfit
and periodicaly receiving USA military software source code (which comes from
the sources certainly unknown to you). What would you prefer in this position
- Ada source code or C++/Java source code?

Then, even for your own (not stolen) code, you'll never have a choice of a
programming language - it will be prescribed to you, and those who choose it
inevitably will look at the world leader and follow it - then you'll get
what the world leader choose... but without many auxiliaries and various
supports that those working for the former have.

Re: NOACE- End of the road for Ada?

[Michael Card]

In article <mailman.7.1110431487.23655.comp.lang.ada@ada-france.org>,
 "Alexander E. Kopilovich" <aek@VB1162.spb.edu> wrote:

> Think about China. Guess, which complex and purposeful software is easier to
> investigate, modify/adapt, port to other equipment/environment etc. - that is
> written in Ada or that in C++ and/or Java?
> 
> Imaging yourself being a mainland Chinese and working in some military outfit
> and periodicaly receiving USA military software source code (which comes from
> the sources certainly unknown to you). What would you prefer in this position
> - Ada source code or C++/Java source code?
> 
> Then, even for your own (not stolen) code, you'll never have a choice of a
> programming language - it will be prescribed to you, and those who choose it
> inevitably will look at the world leader and follow it - then you'll get
> what the world leader choose... but without many auxiliaries and various
> supports that those working for the former have.

Alexander-

Are you postulating here that the US DoD is deliberately choosing 
programming languages that promote obfuscation for the purpose of 
thwarting Chinese intelligence operations? If I have understood you 
correctly, that strikes me as a rather far-fetched premise.

Whenever I have searched for the justification for these decisions, what 
you hear is stuff like "we want to use what everyone in the commercial 
world is using because it's easier to find programmers." It's rather a 
fad-chasing mentality, which seems strange given what we're talking 
about building. I find it hard to believe the use of C/C++ actually 
saves money vs. Ada no matter how many C++ programmers are on 
monster.com. 

Does anyone know of any actual cost data that supports the "fad-du-jour 
language X is cheaper than Ada due to availability of programmers" 
argument?

-Mike

Re: NOACE- End of the road for Ada?

[Frank J. Lhota]

"Alexander E. Kopilovich" <aek@VB1162.spb.edu> wrote in message 
news:mailman.7.1110431487.23655.comp.lang.ada@ada-france.org...
> Michael Card wrote:
>
> Think about China. Guess, which complex and purposeful software is easier 
> to
> investigate, modify/adapt, port to other equipment/environment etc. - that 
> is
> written in Ada or that in C++ and/or Java?

If they were choosing languages on the basis of lack of readability, they 
could choose something worse than C++! :) Perl, for starters?

Here are languages that are even harder to read:

    http://compsoc.dur.ac.uk/whitespace
    http://www.cliff.biffle.org/esoterica/beatnik.html
    http://www.muppetlabs.com/~breadbox/intercal/
    http://www.bigzaphod.org/cow

Re: NOACE- End of the road for Ada?

[Ludovic Brenta]

Or, suppose...

The DoD doesn't want China to use Ada for their own military software,
because this might give them an unfair advantage.  So, they make it
seem like they're massively converting to C++.  If all goes according
to plan, the Chinese spies will ignore and dismiss Ada programs as
obsolete, while the Chinese engineers write their software with
much-reduced efficiency.

Meanwhile, the DoD quietly reuses, enhances, ports, and extends its
large body of battle-tested Ada programs for the next generation of
weapons.

Tell me about far-fetched :)

-- 
Ludovic Brenta.

Re: NOACE- End of the road for Ada?

[Alexander E. Kopilovich]

Michael Card wrote:

> Are you postulating here that the US DoD is deliberately choosing 
> programming languages that promote obfuscation for the purpose of 
> thwarting Chinese intelligence operations?

First, I would not use the word "obfuscation" here, it is much too strong
for the case. What is going is moving the bulk of that software development
to the technologies, which are 1) more affordable for US than for China and
2) conveying less information through source code leakage.

Second, I'm postulating nothing here. I'm just projecting relatively recent
history onto current situation (well, it wasn't China in the past, as you can
guess), and I see some similarities.

Third, thwarting competitor/opponent's intelligence operation is certainly
a significant, but still secondary aim. The primary aim is to maintain
advantageous position for own development forces against the development
forces of (less developed) competitor/opponent.

Re: NOACE- End of the road for Ada?

[svaa]

Michael Card <thehouseofcards@remove.this.part.mac.com> wrote in message news:<thehouseofcards-A7CEC0.21331309032005@news.verizon.net>...
> Hello everyone-
> 
> It seems that everywhere I look, I see articles about the DoD world 
> being anxious to purge Ada from all their systems in favor of C++ and 
> Java. For example, see
> 
> http://www.cotsjournalonline.com/home/article.php?id=100149
> 
> This article references the Navy Open Architecture Computing Environment 
> (NOACE- love that acronym) which specifically calls for a move away from 
> Ada and requires all new software to be done in C++ or Java ("the C++ 
> mandate"?)

Amazing there are no comments about that article, beside a nosense
about USA gov trying to make software code unreadable for China.

Yes, Ada is still running because of inertia, and because of intertia
it still will run for a long time. But it's a fact that there are very
little people interested in Ada, (companies, professional programmers,
students or just curious). The DoD is moving to other languages, and
there are a few big proyects out of DoD, but they eventually will move
into other popular languages.

You shouldn't need to read this article to realice that Ada is almost
irrelevant, and that's the trend.

Why? How Ada has reach that point of irrelevance? what can be done to
change the trend?

Those's are common threads in this forum. Just seach.

Re: NOACE- End of the road for Ada?

[Stephen Leake]

svaa@ciberpiula.net (svaa) writes:

> Yes, Ada is still running because of inertia, and because of intertia
> it still will run for a long time. But it's a fact that there are very
> little people interested in Ada, (companies, professional programmers,
> students or just curious). 

I was just at a talk by Rod Chapman of Praxis Critical Systems; they
sell SPARK and services using SPARK. They are growing, and several
other tool vendors are starting to support SPARK; Ilogix, for one.

SPARK is a statically analyzable subset of Ada; the safety and
security critical fields are beginning to realize that can save them
money.

AdaCore is also growing.

> You shouldn't need to read this article to realice that Ada is almost
> irrelevant, and that's the trend.

Hmm. Perhaps _you_ need to read some _other_ articles :).

> Why? How Ada has reach that point of irrelevance? what can be done to
> change the trend?

Pay attention to what's really going on.

-- 
-- Stephe

Re: NOACE- End of the road for Ada?

[svaa]

Stephen Leake <stephen_leake@acm.org> wrote in message news:<mailman.19.1110679175.23655.comp.lang.ada@ada-france.org>...

Denying reality is not a way to solve problems

> 
> AdaCore is also growing.
> 

So borland does, so sun does, so C++ does, so Java does, so others do.

The fact that AdaCore is growing may only mean that AdaCore is
collecting all potential Ada custumers that doesn't have any other
company. Perhaps AdaCore is growing not because a new Ada golden age,
but at expenses of companies that doesn't work with Ada anymore. The
market of Ada is so small the there is only room for a few companies.
When a company stops developing with Ada, the rest of companies, that
still use Ada, grow a little.

> > You shouldn't need to read this article to realice that Ada is almost
> > irrelevant, and that's the trend.
> 
> Hmm. Perhaps _you_ need to read some _other_ articles :).
> 
> > Why? How Ada has reach that point of irrelevance? what can be done to
> > change the trend?
> 
> Pay attention to what's really going on.

You live in bubble. You should read another articles too. Not only
those that tell that Ada is lingering, but those about Java, about
C++, about C, about PHP about Perl, about Ruby, about pyton...

This look like Esperanto. I played a little with Esperanto. Thanks to
internet Esperanto is growing. So what?. If you live inside esperanto
movement, the Esperanto has a lot of associations, literature etc. You
see esperanto everywhere, and you conclude that esperanto is quite
alive. If you look esperanto from outside, esperanto is irrelevant.

If you program most of time with Ada, work on a company/organization
that works with Ada, you read articles that support Ada, you go to
conferences about Ada, accept good news about Ada, but filter bad news
about Ada. You will conclude that Ada is quite alive.

If you look Ada from outside, you see that Ada is lingering, that it's
difficult to find a job for Ada, and if you find it, 99% will be to
support legacy systems, and probably until they move to another
language. You can find a thousand tools and libraries for any language
and choose. For Ada you must go to half a dozen sites/companies and
take what you find there.

NOACE movement is a good show of what's going on related to Ada. For
each new project in Ada with a big hype in Ada related conferences,
congresses, and websites, you can find 100 projects that are giving up
Ada silently. In demography, more deaths than births is called
negative growth.

Re: NOACE- End of the road for Ada?

[Stephen Leake]

svaa@ciberpiula.net (svaa) writes:

> Stephen Leake <stephen_leake@acm.org> wrote in message news:<mailman.19.1110679175.23655.comp.lang.ada@ada-france.org>...
>
> Denying reality is not a way to solve problems

I did not deny anything, I merely pointed out some sources of
information that you appeared to be unaware of.

>> AdaCore is also growing.
>> 
>
> So borland does, so sun does, so C++ does, so Java does, so others do.

Yes, that's true. So what?

Rod Chapman made an interesting point. Ada has less than 0.1% of the
programmer market. BMW has less than 0.1% of the car market. Is BMW a
failure, or a successful niche player? Ada is a successful niche
player.

> The fact that AdaCore is growing may only mean that AdaCore is
> collecting all potential Ada custumers that doesn't have any other
> company. Perhaps AdaCore is growing not because a new Ada golden age,
> but at expenses of companies that doesn't work with Ada anymore. 

"Perhaps", yes. Do you have any data?

> The market of Ada is so small the there is only room for a few
> companies. When a company stops developing with Ada, the rest of
> companies, that still use Ada, grow a little.

The market for high-end cars is also small.

> You live in bubble. You should read another articles too. Not only
> those that tell that Ada is lingering, but those about Java, about
> C++, about C, about PHP about Perl, about Ruby, about pyton...

I read Dr Dobbs, and The Economist. 

> This look like Esperanto. I played a little with Esperanto. Thanks to
> internet Esperanto is growing. So what?. If you live inside esperanto
> movement, the Esperanto has a lot of associations, literature etc. You
> see esperanto everywhere, and you conclude that esperanto is quite
> alive. If you look esperanto from outside, esperanto is irrelevant.

Hmm. Does "irrelevant" mean "dead"? I don't think so.

If you don't want to join us in our Ada "bubble", fine. But have the
grace to leave us alone :).

> If you program most of time with Ada, 

True for me.

> work on a company/organization that works with Ada, 

Not true for me.

> you read articles that support Ada, you go to conferences about Ada,
> accept good news about Ada, 

I wish I could; where are they?

> but filter bad news about Ada. 

Not true for me.

> You will conclude that Ada is quite alive.

True for me.

There seems to be a problem with your logic.

> If you look Ada from outside, you see that Ada is lingering, that it's
> difficult to find a job for Ada, 

"a job for Ada"? Do you mean "a job that requires Ada knowledge"? 

Any problem that requires programming is potentially "a job for Ada";
those are certainly not hard to find.

Any job that requires a particular programming language is not one I'm
interested in; I'm interested in using the best tool for the job.

If that means I'm in a "bubble", fine.

> and if you find it, 99% will be to support legacy systems, and
> probably until they move to another language. 

Where is your data coming from?

> You can find a thousand tools and libraries for any language and
> choose. For Ada you must go to half a dozen sites/companies and take
> what you find there.

Yes, and it is still the best tool for the job I'm doing.

> NOACE movement is a good show of what's going on related to Ada. For
> each new project in Ada with a big hype in Ada related conferences,
> congresses, and websites, you can find 100 projects that are giving up
> Ada silently. 

Hmm. If they are "silent", how do you find them?

If that statistic were true for the last several years, no Ada company
would be in business now, since no company can lose 99% of its
business several years in a row and survive. That is demonstratably
false; just look at the AdaIC list of Ada compiler companies; it has
been stable for the last several years.

So I conclude your statistic is not true.

> In demography, more deaths than births is called negative growth.

Yes, but you have not presented actual evidence, just your opinion.

-- 
-- Stephe

Re: NOACE- End of the road for Ada?

[Dmitry A. Kazakov]

On Sun, 13 Mar 2005 09:22:26 -0500, Stephen Leake wrote:

> Rod Chapman made an interesting point. Ada has less than 0.1% of the
> programmer market. BMW has less than 0.1% of the car market. Is BMW a
> failure, or a successful niche player? Ada is a successful niche
> player.

I think this is rather an unfortunate analogy. BMW does not produce
universal cars, at least in terms of price and fuel consumption. On the
contrary, Ada was thought as a universal language in all respects. It is
also quite inexpensive now (excluding embedded platforms.) So 0.1% of the
language market should be definitely counted as a failure, especially if we
look at WHAT for "languages" are traded there.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: NOACE- End of the road for Ada?

[Marin David Condic]

I personally think your criticism is well thought out and makes some 
valid points. Irrational exuberance and rose colored glasses will not 
save Ada or make it more relevant. I work in a DoD related field and I 
can see the customers I have packing their bags and moving on to other 
languages. I can try to influence that decision towards Ada, but they 
are not in a position to spit into the wind and utilize a language 
without much following in the general computing world unless there is 
some compelling reason. It is difficult to find compelling reasons to 
offer them when all the economics tend to get stacked against Ada.

That said, let me offer this: It doesn't help to be negative about it, 
nor does it help to spend hours worrying about whether or not someone 
likes you. If one gets stuck in a rut of saying "Its all hopeless!!!" 
then ipso facto, it becomes hopeless. If one sits around all day 
thinking "Why doesn't anyone like me? What can I do to get people to 
like me?" it is similarly self defeating. You'll never get everyone to 
like you and trying will only expend your efforts in a bunch of futile 
dodges. While we're at it, being a Pollyanna about it ("Everything with 
Ada is WONDERFUL in my little pastel colored, unicorn infested, rainbow, 
gumdrop world!") doesn't help either. One denies the obvious problems 
and refuses to take action to make it better.

Some suggestions that might actually help:

1) Do things in Ada that you want to do and ignore those who keep saying 
its going to hell in a handcart. Make as much Ada code as possible. Make 
it as useful as possible. Make it as available as possible. The more Ada 
there is out there, the more likely Ada has a sound future.

2) Quit thinking about making more software technology or remaking 
things that already exist in other languages. Dream up things to make 
out of Ada that aren't already done and that address some bigger need. 
We keep thinking in terms of "Here's this cool app someone wrote in C. 
Let me rewrite it in Ada..." Hint: NOBODY CARES THAT IT IS WRITTEN IN 
ADA OR ANYTHING ELSE. They care that it does some job. Reinventing 
network tools or software development tools or any other batch of stuff 
that programmer-geeks like to build doesn't really help if there are 
thousands of them out there already and you have nothing new & 
innovative to offer. Its also a small market compared to the wider world 
of general computer users. Think about it this way: Build a better 
mousetrap. What about a better office suite? What about a better 
accounting package? What about a better statistics tool? What about a 
better structural analysis tool? What about a better "Simulink"? (I'd 
like to see one - and one that generates Ada instead of C) Make some 
better mousetrap that has usefulness beyond the interest of a few 
programmer-geeks.

3) Think about starting a business that makes some useful product with 
Ada as part of its technology. If Ada has so many advantages, it ought 
to be a competitive edge. If you build some sort of commercial software 
or embedded system or other useful product with Ada as a component, then 
you create a market for Ada tool vendors and a job market for Ada 
programmers. The people who program in C or C++ generally are not so 
concerned about the language, per se. They're busy building some cable 
TV network or computational fluid dynamics analysis tool or automotive 
control & diagnostic computer. They sell that stuff and hence have money 
to spend on stuff like compilers and programmers.

4) Don't worry if the DoD guys want to abandon Ada. Their motivation is 
one of economics (primarily). Make Ada economical and they'll come back. 
It was and is a mistake to rely on them to create the market for Ada. 
Ada has to have a utilization in the greater world and not just rely on 
the DoD. If the DoD contractors find that some commercial sector that is 
doing something similar to what they want to do are using Ada as part of 
their toolset, they'll follow.

Think about this for a minute: Say I'm a DoD contractor and I have an 
application that involves graphics in some regard. They look at what 
guys in the private sector are using - the GUI building tools, the 
graphics libraries, etc., and they go do the same. Why? Because they can 
readily get the tools and readily get the people who know how to use 
them and since it is technology out there in the field, it is low risk 
to their project. If Ada had the same tools and libraries & skilled 
people out there in real-world projects, they'd go for that. But their 
objective is not to use Ada, but to get a graphics job done. If some Ada 
fan(s) were building the world's coolest video games in Ada and making 
money doing so & employing people to do it and generating/licensing the 
technology, wouldn't DoD contractors go follow suit?

In the world I live in, I see a bunch of tools that are variations on 
Simulink for designing plant models & control systems. Pretty much 
across the board, these tools are designed to work in a style akin to 
60's era Fortran programs. They pretty much suck stylistically in that 
they don't support most of the software engineering kinds of features 
we've developed since the 60's. But they basically do a job: Someone can 
model a plant and model a control and test it out on a workstation. Then 
the pressure becomes to use the C code (few if any still output Ada) 
they generate to be the actual control code. That has problems, but 
hopefully you can understand that pressure: the model already exists and 
it already works and there is already a test suite, so why not dump it 
into the control & scab up some more C code around it to run the real 
time control?

I can imagine a MUCH superior design & modeling tool that might utilize 
lots of Ada concepts like packages & tasking and sophisticated data 
types and all sorts of stuff. I can imagine a MUCH superior simulation 
environment that would buy numerous improvements in flowing the design 
into the actual box & testing it with greater efficiency. If such a 
system got built in Ada and generated Ada and was based on Ada concepts 
and IF IT HELPED DO SOMEONE'S JOB BETTER than the existing technology, 
it might worm its way into the control software market. Perhaps finding 
users in the automotive and aerospace industries. It might secure a 
niche for Ada. This would be an example of something that was being 
built for reasons other than just to use Ada or make Ada popular. It 
would be getting built to make a better mousetrap and might have the 
beneficial side effect of promoting more Ada use. That kind of thinking 
might get Ada somewhere.

MDC



svaa wrote:

> Stephen Leake <stephen_leake@acm.org> wrote in message news:<mailman.19.1110679175.23655.comp.lang.ada@ada-france.org>...
> 
> Denying reality is not a way to solve problems
> 
> 
>>AdaCore is also growing.
>>
> 
> 
> So borland does, so sun does, so C++ does, so Java does, so others do.
> 
> The fact that AdaCore is growing may only mean that AdaCore is
> collecting all potential Ada custumers that doesn't have any other
> company. Perhaps AdaCore is growing not because a new Ada golden age,
> but at expenses of companies that doesn't work with Ada anymore. The
> market of Ada is so small the there is only room for a few companies.
> When a company stops developing with Ada, the rest of companies, that
> still use Ada, grow a little.
> 
> 
>>>You shouldn't need to read this article to realice that Ada is almost
>>>irrelevant, and that's the trend.
>>
>>Hmm. Perhaps _you_ need to read some _other_ articles :).
>>
>>
>>>Why? How Ada has reach that point of irrelevance? what can be done to
>>>change the trend?
>>
>>Pay attention to what's really going on.
> 
> 
> You live in bubble. You should read another articles too. Not only
> those that tell that Ada is lingering, but those about Java, about
> C++, about C, about PHP about Perl, about Ruby, about pyton...
> 
> This look like Esperanto. I played a little with Esperanto. Thanks to
> internet Esperanto is growing. So what?. If you live inside esperanto
> movement, the Esperanto has a lot of associations, literature etc. You
> see esperanto everywhere, and you conclude that esperanto is quite
> alive. If you look esperanto from outside, esperanto is irrelevant.
> 
> If you program most of time with Ada, work on a company/organization
> that works with Ada, you read articles that support Ada, you go to
> conferences about Ada, accept good news about Ada, but filter bad news
> about Ada. You will conclude that Ada is quite alive.
> 
> If you look Ada from outside, you see that Ada is lingering, that it's
> difficult to find a job for Ada, and if you find it, 99% will be to
> support legacy systems, and probably until they move to another
> language. You can find a thousand tools and libraries for any language
> and choose. For Ada you must go to half a dozen sites/companies and
> take what you find there.
> 
> NOACE movement is a good show of what's going on related to Ada. For
> each new project in Ada with a big hype in Ada related conferences,
> congresses, and websites, you can find 100 projects that are giving up
> Ada silently. In demography, more deaths than births is called
> negative growth.

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "'Shut up,' he explained."

         --  Ring Lardner
======================================================================

Re: NOACE- End of the road for Ada?

[adaworks]

"Michael Card"
<thehouseofcards@remove.this.part.mac.com> wrote
in message
news:thehouseofcards-A7CEC0.21331309032005@news.verizon.net...
> Hello everyone-
>
> It seems that everywhere I look, I see articles
about the DoD world
> being anxious to purge Ada from all their
systems in favor of C++ and
> Java. For example, see
>
The move toward Java has nothing to do with
whether Java is superior to
Ada. It's not.   Is it easier to learn than Ada?
No.   Is it more efficient
than Ada?  Certainly not.   Is it easier to code
than Ada?  Not at all.
Does it produce better executables?   Not at all.

So why is it taking over the programming landscape
like kudzu or crabgrass
on an Alabama lawn?

I attended a seminar presented by a U.S. Navy
Admiral a couple of years ago
on the subject of software in the Navy.   He
droned on for a while about his
view on this subject and finally came to Ada.  His
opening remarks to this
topic, "And then there was the Ada fiasco!"    In
his comments he noted that
Ada was hard to learn, even after hiring the best
teachers the Navy could find,
there were no good tools available for development
and maintenance, all
the programmers hated it, no one wanted to support
it, everything they did
related to Ada created more trouble than it was
worth.

This perception of Ada throughout much of the
Navy, and throughout much
of the DoD persists.  I work daily with DoD people
who believe Ada was one of
the most idiotic initiatives the DoD ever pursued.
At the school where I teach,
Ada was once required.  Now it is hardly mentioned
(except in some of my
classes).   Sometimes, when I visit the office of
one of my colleagues, I see
old copies of Ada books (most Ada 83) on the
bookshelves.    The only two
languages most people want to acknowledge are Java
and C++, and of those,
Java gets the larger share of attention.

Java, for all its faults, is the current darling
of decision-makers and academics.  Many
of my students find Ada easier to learn after they
have learned Java.    Most of them
hate C++, but the have to learn it to successfully
complete their required class in
computer graphics.   There are almost no
circumstances where they must use Ada,
let alone know anything about it.

I continue to believe that Ada is as good, often
better, as a programming language
than either Java or C++.   But that is not a
widespread belief throughout the DoD.
Rather, the more dominant view is that Ada is now
an old-fashioned language, more
in the category of PL/I, COBOL, old versions of
Fortran, etc.   It is seen as old,
in part because it is regarded as a language of
the early 1980's.   Java is the language
of now.    Ada is the language of then.   For
many, C++ is also the language of then.

There is no large company currently pushing Ada.
There are no substantial financial
resources behind it.   Even the companies that
publish Ada compilers, with the exception
of Ada Core, RR Software, and Irvine Compiler, are
focusing their attention and their
advertsising dollars on other products.

One Navy official said to me a couple of years
ago, "In five years you won't be able to
find anyone supporting Ada."   That was nearly
five years ago, and he was wrong.  But
how wrong was he?   Does IBM take its (Rational)
Ada compiler seriously anymore?

Ada certainly does not deserved the reputation it
has among DoD officials.   But, as long
as the majority of promotional dollars are devoted
to touting the (dubious) benefits of
technologies, even as those technologies are
inferior to Ada for military software,  Ada
will suffer.

Who will champion Ada?   Currently, no one with
influence or power will come forward
to encourage the use of Ada.   Sometimes I speak
with developers who prefer Ada and
still choose C++, not because they prefer it but
because it is the easiest choice to make.
Courage is not a common characteristic of DoD
developers.    To preach too openly
the benefits of Ada in the halls of a contractor's
office or the corridors of a DoD facility
is to risk being branded "some kind of nut."   I
have been called an "Ada bigot," more
times than I can count -- this, in spite of my
continual assertion that we should pick the
right tools for the right job -- and the right
tool is often, but not always, Ada.

Time for lunch.

Richard Riehle

Re: NOACE- End of the road for Ada?

[Peter C. Chapin]

<adaworks@sbcglobal.net> wrote in news:vQ%Yd.19429$OU1.18883
@newssvr21.news.prodigy.com:

> Who will champion Ada?   Currently, no one with
> influence or power will come forward
> to encourage the use of Ada.

I noted with interest that the recent release of KDevelop offers Ada 
support (no doubt due to gnat being a part of gcc). Is Ada gaining favor in 
the open source community? I should think that the availability of a good 
quality, free compiler would be attractive to open source developers.

Some people I talk to say things like, "Ada is that DoD language, and I'm 
not into military stuff." It seems like Ada's association with the DoD has 
not helped it... at least not lately. However, if Ada attracts the 
attention of students and hackers (I'm using the positive meaning of 
"hacker" here), that might be very good for its long term future.

Peter (who is a student thinking about using Ada in a class project)

Re: NOACE- End of the road for Ada?

[Pascal Obry]

"Peter C. Chapin" <pchapin@sover.net> writes:

> I noted with interest that the recent release of KDevelop offers Ada 
> support (no doubt due to gnat being a part of gcc). Is Ada gaining favor in 
> the open source community? I should think that the availability of a good 
> quality, free compiler would be attractive to open source developers.

I hope so too. It seems to be right. Despite what can be read here and there I
found that Ada is used more and more these days. The trafic here in
comp.lang.ada is bigger than what it used to be (5 or 10 years ago). And we
have some great Open Source projects around... All this led me to think that
Ada is on the right tracks...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: NOACE- End of the road for Ada?

[Dr. Adrian Wrigley]

On Sun, 13 Mar 2005 09:22:26 -0500, Stephen Leake wrote:

> Rod Chapman made an interesting point. Ada has less than 0.1% of the
> programmer market. BMW has less than 0.1% of the car market. Is BMW a
> failure, or a successful niche player? Ada is a successful niche
> player.

I found this hard to believe.  So I did a quick scan of data to hand.

Latest annual revenues:

GM   : $193 bn
Daimler/Chrysler $184 bn
Toyota : $176 bn
Ford   : $171 bn
VW     : $115 bn
Honda  : $81 bn
Nissan : $75 bn
Fiat   : $60 bn
Volvo  : $29 bn

BMW    : $58 bn

BMW dollar revenue is around 5.1% of the total revenue of the
listed manufacturers.

0.1% /= 5.1%  (off by a factor of fifty :()

If you count units shipped, you'd probably get a better picture,
and I may have missed some significant manufacturers.
US local market data would look less favourable to BMW though.

Of course in terms of programming languages, number of
programmers, number of programs or value of programs are
all plausible measures.  The value measure, I believe
shows Ada in the best light(?)

With the car market, the largest is only 17%.  I think the
mythical "C/C++" language commands a lot more than that.
-- 
Adrian

Re: NOACE- End of the road for Ada?

[Dr. Adrian Wrigley]

On Sun, 13 Mar 2005 09:22:26 -0500, Stephen Leake wrote:

> svaa@ciberpiula.net (svaa) writes:
...
>> Stephen Leake <stephen_leake@acm.org> wrote in message news:<mailman.19.1110679175.23655.comp.lang.ada@ada-france.org>...
>> NOACE movement is a good show of what's going on related to Ada. For
>> each new project in Ada with a big hype in Ada related conferences,
>> congresses, and websites, you can find 100 projects that are giving up
>> Ada silently. 
> 
> Hmm. If they are "silent", how do you find them?
> 
> If that statistic were true for the last several years, no Ada company
> would be in business now, since no company can lose 99% of its
> business several years in a row and survive. That is demonstratably
> false; just look at the AdaIC list of Ada compiler companies; it has
> been stable for the last several years.
> 
> So I conclude your statistic is not true.

If there had been 1,000 projects, losing 100 projects silently, and
gaining one project (with fanboy fanfare) gives 901 projects remaining.
This could last all of... ten years before anihilation.  It's even
plausible, if you count projects (eg) >5M SLOC.  But it is not a
99% loss each year.

Curiously, in the world of hardware/chip design, the same
debate about VHDL (with Ada's discipline/syntax) vs. Verilog
takes place.  But VHDL has a large (not majority) base.
Nobody seems to worry much about VHDL being a DoD language.
And its fanaticism for precision and reliability isn't seen
as useless, redundant or lacking "power".  But the "new"
upstart in hardware design (amazingly) is "C" (subsetted, tweaked).
(The hope is you can get programmers to design hardware!)

I've always thought that Ada would benefit by being much more
closely associated (even merged) with VHDL.  But (AFAICT) few VHDL
users have ever used Ada, and vice-versa.  Given that they
are nearly identical*, why are no synergies found?

The "Teaching new tricks..." debate shows how *amazingly*
ill-informed people are about the Ada language features.
(people say "do not think it supports generic programming",
'"manually added checks" in C++ would be identically eliminated
to the automatic checks in Ada', 'what's the use of rep. specs, except
to restrict portability(?)' etc.)

Clearly the beliefs and reputation are a major part
in language choice.

The three ways you can make a popular language are:
1)  extend a popular language (C++, F77)
2)  start from scratch with big budget (Java, C#)
3)  fill a big market vacuum with something that works
    (Fortran, C, Cobol, PostScript, Perl <at various times>)

I'm not aware of any popular languages that came about
in any other way.  Ada tried to be 2, 3.  But the market
vacuum was in the eyes of the DoD, not the users/contractors.
Ada has failed to become a popular language (in terms of users),
and now none of these three possibilities can be used to
rectify the situation.

Any language designer/advocate who wants to promote the
Ada ideals would be best trying again (don't start from here!).
For example:

find a popular language and transplant Ada features
  (C99 with tasks, arrays, generics etc? (a real bastard)(too late?)
   takes us back to the infamous "Ada syntax turns people off!)

get a big backer to force a new Ada-inspired language into the market
  (too late for C# or Java, but they could easily have taken
   much more from Ada, if enough of the right persons had been there!)

think up something radical and new in programming, and infuse
it with Ada principles.
  (we had 4GL and Fifth Generation, what next? 6GL? Wikipedia doesn't
   yet have "Sixth-Generation languages" entry!)
  (my personal view is that a decent "visual programming language"
   could find a market vacuum sometime in the next thirty years, and
   is ready to be invented.  Nothing so far has been terribly useful
   or general, so the field has been written off.)
  (any more ideas on this topic?)

back to the original topic... NOACE does seem to be a 
real step backwards.  It looks a lot like a "Java Mandate",
but acknowledges that there will be many exceptions,
which C++ would probably meet.  I think it's very risky, since
newer languages tend to have a shorter lifespan and change
faster than mature languages.  It clearly is motivated by
much more than the technical merits of the language.  But if colleges
switch to teaching "C2#" or "Guam" a decade from
now, they might be stuck with a poor technical solution, serviced by
a declining programmer base.  And if they have to have specialized
variants of Java for their high reliability, sub-microsecond
real-time applications, they risk having a total "language isolate"
on their hands.

Interesting that Boeing doesn't like Ada or C++.  It'd be interesting
to understand why each of these fails to meet their needs.
Particularly since both languages' advocates usually say they are
much more suitable than Java for almost application!

It all seems a bit weird...
-- 
Adrian

* (main differences:
   "library" <-> "with",
   tasks /= processes,
   generics /= generics (sadly!),
   Ada lacks architectures, signals or physical types,
   VHDL lacks tagged types)

Re: NOACE- End of the road for Ada?

[Larry Kilgallen]

In article <pan.2005.03.13.21.50.06.975500@linuxchip.demon.co.uk.uk.uk>, "Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> writes:

> With the car market, the largest is only 17%.  I think the
> mythical "C/C++" language commands a lot more than that.

And presumably the quite real Cobol language even more than that.

I presume we are talking lines of code in production, rather than
copies of compilers sold.

Re: NOACE- End of the road for Ada?

[Michael Card]

In article 
<pan.2005.03.13.23.20.18.926991@linuxchip.demon.co.uk.uk.uk>,
 "Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> wrote:

> On Sun, 13 Mar 2005 09:22:26 -0500, Stephen Leake wrote:
> 
<snip>
> 
> The "Teaching new tricks..." debate shows how *amazingly*
> ill-informed people are about the Ada language features.
> (people say "do not think it supports generic programming",
> '"manually added checks" in C++ would be identically eliminated
> to the automatic checks in Ada', 'what's the use of rep. specs, except
> to restrict portability(?)' etc.)
> 
> Clearly the beliefs and reputation are a major part
> in language choice.
> 
> The three ways you can make a popular language are:
> 1)  extend a popular language (C++, F77)
> 2)  start from scratch with big budget (Java, C#)
> 3)  fill a big market vacuum with something that works
>     (Fortran, C, Cobol, PostScript, Perl <at various times>)
> 
> I'm not aware of any popular languages that came about
> in any other way.  Ada tried to be 2, 3.  But the market
> vacuum was in the eyes of the DoD, not the users/contractors.
> Ada has failed to become a popular language (in terms of users),
> and now none of these three possibilities can be used to
> rectify the situation.
> 
> Any language designer/advocate who wants to promote the
> Ada ideals would be best trying again (don't start from here!).
<snip>
> 
> back to the original topic... NOACE does seem to be a 
> real step backwards.  It looks a lot like a "Java Mandate",
> but acknowledges that there will be many exceptions,
> which C++ would probably meet.  I think it's very risky, since
> newer languages tend to have a shorter lifespan and change
> faster than mature languages.  It clearly is motivated by
> much more than the technical merits of the language.  But if colleges
> switch to teaching "C2#" or "Guam" a decade from
> now, they might be stuck with a poor technical solution, serviced by
> a declining programmer base.  And if they have to have specialized
> variants of Java for their high reliability, sub-microsecond
> real-time applications, they risk having a total "language isolate"
> on their hands.
> 
> Interesting that Boeing doesn't like Ada or C++.  It'd be interesting
> to understand why each of these fails to meet their needs.
> Particularly since both languages' advocates usually say they are
> much more suitable than Java for almost application!
> 
> It all seems a bit weird...

Adrian-

Good post, my experience has been consistent with the experiences cited 
by Richard Riehle in his post on this thread. 

The only rationale I can come up with to explain the Dod's anti-Ada bias 
is that some high-up folks in the Pentagon didn't like it, maybe because 
it was from DISA (I get the feeling DISA is one of the lesser-loved 
branches of the DoD). This distaste for Ada by the services themselves 
(USN, USA, USMC, USAF) would certainly be quickly mirrored by the 
contractors, since the services are the ones paying them, not DISA. So, 
a dislike for DISA mandates on behalf of the armed services ends up 
being reflected in their contractors, who want to "suck up" (not in the 
bad sense) to their customers as much as possible to win contracts.

This is the only explanation I can come up with, because I have never 
seen a study that says "we did this multi-million line job in C++ and 
boy are we glad we did; we saved so much $ vs. past similar jobs we have 
done in Ada". In fact, the studies out there that I am aware of say just 
the opposite.

I am wide open to receiving a C++ cost savings study, however; I just 
haven't been able to find it. If someone can send me link I'd be happy 
to read it and be educated about it. My experience with C/C++ on large 
DoD style projects suggests the usual culprits [memory corruption and 
concurrency problems] make it a more expensive choice than Ada because 
it takes longer to get the bugs out.

-Mike

Re: NOACE- End of the road for Ada?

[Ed Falis]

 From the COTS Journal article:

" The Navy, for example, has crafted its Navy Open Architecture Computing  
Environment (NOACE) to be the standard for all future software systems on  
Navy warships. That includes shipboard weapon systems, such as  
anti-aircraft cannon controls as well as avionics systems aboard naval  
aircraft. The standard calls for all new software to develop in either  
C++ or Java, and makes specific mention of moving away from Ada. They plan  
to continue to use Ada only as required to support legacy systems that  
have already been developed."

I've heard that the NOACE document has not yet been released - that what  
COTS Journal has been making such a big deal about was a leaked draft and  
not the final statement of policy.

Perhaps it's better to wait for the final document to be published?

- Ed

Re: NOACE- End of the road for Ada?

[Jeff C]

Dr. Adrian Wrigley wrote:

> I've always thought that Ada would benefit by being much more
> closely associated (even merged) with VHDL.  But (AFAICT) few VHDL
> users have ever used Ada, and vice-versa.  Given that they
> are nearly identical*, why are no synergies found?

I always like to tease the hardware guys doing VHDL and tell them that 
it is just Ada but without comments or version control and with 
everything done in upper case.

To which they respond that no, VHDL is more like Ada code but without 
the bugs.

...And yes this post is (on both comments) not intended to be taken too 
seriously.. (Of course I can just see the "Ah ha, so you admit you can 
write bugs in Ada posts coming :)

Re: NOACE- End of the road for Ada?

[Dr. Adrian Wrigley]

On Mon, 14 Mar 2005 02:11:33 +0000, Ed Falis wrote:

> Perhaps it's better to wait for the final document to be published?

On the contrary!  One of the reasons for leaks is to allow
outsiders to comment on plans before they are committed to.
If a document is officially released, changing it may be politically
sensitive and/or slow.  Much more convenient to listen to the
backlash from a leaked draft, deny the plans, fix them and
release the "final" document with the bugs fixed.
This makes commenting on leaked drafts a good idea! 

Here in Britain, deliberate leaks seem to be a major part of
government policymaking.  With NOACE however, I think we'd be
whistling in the wind.
-- 
Adrian

Re: NOACE- End of the road for Ada?

[Jared]

I could be wrong about all of this.  I often am.

<adaworks@sbcglobal.net> wrote in news:vQ%Yd.19429$OU1.18883
@newssvr21.news.prodigy.com:
> The move toward Java has nothing to do with
> whether Java is superior to
> Ada. It's not.   Is it easier to learn than Ada?
> No.   Is it more efficient
> than Ada?  Certainly not.   Is it easier to code
> than Ada?  Not at all.
> Does it produce better executables?   Not at all.

This is wrong.  I'm sorry.  I like Ada.  I want to believe it is right, but 
it isn't.

Sun is behind Java.  They've been hyping it.  They've been pushing it.  
They've been doing everything they can to keep it in the press.  That's 
great, and it gives Java a chance to succeed, but that's all it gives it.  
Java really is better, in a marketing sense, and sort of better in a 
conceptual sense.

> So why is it taking over the programming landscape
> like kudzu or crabgrass
> on an Alabama lawn?

Rant abstract: Java is more popular because its syntax better represents 
OO.  If you're bored of that argument, there is another, much shorter one, 
at the first separator.  If you're bored of that one, there's a third one, 
but it isn't very constructive.


Java, as has been pointed out elsewhere on this group, is basically C++ 
with all the bad parts removed and with garbage collection added.  Java is 
comfortable to all the C people, because of its syntax, because of its 
culture, and because it pretends to share the C++ idioms.  Nobody is going 
to switch to a language that feels uncomfortable unless it has some really 
neat gimmick.  (For example, Oz and Piccola have really neat gimmicks.)  In 
a market sense, even without the hype, this makes Java better.

It's worse than that, though.  Java got namespaces mostly right.  It got 
packaging mostly right.  A package isn't a namespace.  It's really tempting 
to identify them, but the real namespaces are the variables.

Why do you think Object.Method syntax is so popular?  What was the big deal 
with the 'use type' clause?  And what are all those Smalltalk people 
yammering about when they talk about sending messages to objects?  The 
variable is the namespace.  The method exists within it.  It isn't in the 
package.  The package isn't really a real thing; it's a variable of 
anonymous type.  The reason that Object.Method and Package.Method are 
indistinguishable it that they are indistinct.

So, for example, suppose I have:

package thing is
  a: integer := 0;
  procedure do_something;
end thing;

...

type thing_type is tagged record
  a: integer := 0;
end record;

procedure do_something (t: in out thing);

thing: thing_type;

There's not much difference when I declare it, except that the latter is 
much more verbose and has to be embedded in a package.  There's no 
difference at all when I use it.  There is a difference when I try to 
extend it, but was anyone paying attention when Dmitry suggested that 
'use' be transitive?

What I mean by getting packaging mostly right should be clear by now.  The 
type (class, or whatever one wants to call it) is the natural unit of 
packaging.  Consider the following common idiom:

package shoes is
  type shoe is tagged record with private;
  ...
end shoes;

With no other types declared in the package.  Wouldn't it just be easier to 
let the type be a package?  That's about all I have to say about that.

So, in conclusion, Java represents a cleaner presentation of OO than Ada.

But that's all it is.  Java's model is not really any better from Ada's; it 
just looks better, or rather, it's presented in a way that people prefer.  
It's just presentation, but presentation is critical.  Many industries 
exist almost entirely on presentation, with substance coming in a distant 
second.

Yes, I know Ada was meant to be legible.  But it has a low signal to noise 
ratio.

Want Ada to be more popular?  Write an alternate syntax.  Play up objects.  
Make them the focus.  Read up on the pi calculus, and compare with 
protected types and streams.  Above all, if something doesn't need to be 
said more than once, it shouldn't be.

For example, see:
http://www.cs.uofs.edu/~beidler/Ada/gnat/win_task-threads.html

The package at that link was the fifth hit for 'pragma import' on Google.  
It contains 'pragma Import (StdCall, foo, "foo")' 18 times and 'pragma 
Import (C, foo, "foo")' twice.  Not one of the StdCall functions is 
renamed.  The sum of the renaming for the C functions is to strip the 
leading underscore.  That's noise.  It makes every single function 
declaration two lines longer than necessary without conveying a single bit 
of information more than, say,

import StdCall "CreateThread" (args).

There are many many great features in the language, but the syntax bogs it 
all down in a ton of noise.

---

Actually, I do have one argument besides the old "the syntax sucks" dead 
horse.  Think about Perl.

Perl was created to solve a problem.  It thrives because it filled a niche, 
and did it well.  Ada didn't have that kind of focus.  The ARG needs to 
find new niches and fill them well.  It needs to defend hard real-time and 
do so quickly, because that's being lost to Java.  A garbage collected 
language!  For real-time systems!

Government contracting isn't a niche.  It's a hog trough; a place to become 
bloated and lazy.

And that's about all I have to say, unless somebody needs a clarification.  
That quite likely; I doubt the previous made much more sense than it did 
the first time I tried to formulate it.

---

Now, you don't have to buy into any of that.  So here's an alternate 
theory, based on the grass analogy.  From an article in a university 
newspaper:

 "One of the more common questions I'm asked is how to control Bermuda 
grass in the lawn. My standard reply is 'asphalt'," says Jerry Goodspeed, 
Utah State University Extension horticulturist. Unfortunately, Bermuda 
grass can grow through asphalt and really thrive.

There you go.  Java is the weed that won't die and Sun (pun not intended) 
is making sure it stays that way.


> I continue to believe that Ada is as good, often
> better, as a programming language
> than either Java or C++.   But that is not a
> widespread belief throughout the DoD.

Myopically focusing on Java and C++ is a good way to ensure that Ada is 
never more than marginally better than either.  There's a lot of research 
going on out there.  For example,
www.cis.upenn.edu/~bcpierce/ papers/tng-lics2003-slides.pdf

Much of this research is geared at making functional and denotational 
languages more efficient.  I have full confidence that the Mozart/Oz people 
will screw up their chance to become the Next Big Thing.  But somebody 
won't, and that could happen tomorrow.

> There is no large company currently pushing Ada.
> There are no substantial financial
> resources behind it.   Even the companies that
> publish Ada compilers, with the exception
> of Ada Core, RR Software, and Irvine Compiler, are
> focusing their attention and their
> advertsising dollars on other products.

Where are the big bucks behind, say, Ruby?  What is Ruby's growth rate, 
compared to Ada's?  What can be learned here?


> Who will champion Ada?

AWS.  APQ, maybe.  Maybe Nick Roberts, if he ever gets anywhere.  The other 
projects.  You.  Maybe me.  We don't need big companies.  We don't need 
money.  We need, if you'll forgive me for putting it this way, the coolness 
factor.

Step 2: ???

Step 3: Profit!

I'm still working on step 2.

Re: NOACE- End of the road for Ada?

[Marin David Condic]

The problem with comparing Ada to other languages and saying "If only we 
change the syntax to look more like other languages, Ada would be more 
popular..." is that you're playing the "Me too!!!" game. I don't think 
that is the way to success because you're letting your competition 
define the whole game.

One can argue endlessly about the relative value of this or that 
syntactic feature, but think about it this way: If you change Ada syntax 
enough to make it look like the "more popular girl" (Java) then it just 
becomes indistinguishable from the more popular girl - except it doesn't 
have her name. For the folks who love Java, Ada can never be enough like 
Java and attempting to make it so will only thwart more productive 
efforts. I think Ada just has to say "What do *I* want to be good at?" 
and concentrate on being the best addresser of that particular market.

If the market is "Embedded/Realtime" then it will take a lot more than 
language features to get there. Ada already has the best collection of 
embedded/realtime language features of any language in widespread use 
and has an almost nonexistant presence in this field. If Ada wants to 
get introspective about what might make her better for this market, I'd 
think she would have to concentrate on stuff external to the language 
proper - like libraries and development tools.

MDC

Jared wrote:
> 
> Want Ada to be more popular?  Write an alternate syntax.  Play up objects.  
> Make them the focus.  Read up on the pi calculus, and compare with 
> protected types and streams.  Above all, if something doesn't need to be 
> said more than once, it shouldn't be.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "'Shut up,' he explained."

         --  Ring Lardner
======================================================================

Re: NOACE- End of the road for Ada?

[Alexander E. Kopilovich]

Marin David Condic wrote:

> ... letting your competition define the whole game.

I like this expression, it is quite good description of a widespread sin.

> One can argue endlessly about the relative value of this or that 
> syntactic feature, but think about it this way: If you change Ada syntax 
> enough to make it look like the "more popular girl" (Java) then it just 
> becomes indistinguishable from the more popular girl - except it doesn't 
> have her name. For the folks who love Java, Ada can never be enough like 
> Java and attempting to make it so will only thwart more productive 
> efforts. I think Ada just has to say "What do *I* want to be good at?" 
> and concentrate on being the best addresser of that particular market.

That's all right, but this metaphor can be explored another way. Ada can
think: "What are the features that people really appreciate in Java? Perhaps
I have some of them no less than Java and possibly even better, but I just
do not pay enough attention to them and do not exhibit them properly.
And perhaps accentuation of those my features is not harmful at all for my
integrity and style, but is just necessary adaptation to today's enviromnent,
needs and viewpoints."

(One feature of this kind comes immediately - it is area of tasking and
synchronization.)

> ... If Ada wants to 
> get introspective about what might make her better for this market, I'd 
> think she would have to concentrate on stuff external to the language 
> proper - like libraries and development tools.

Keeping my eye on Ada over 10 years as a distant observer, I gradually became
convinced that Ada is not (and can't be) particularly good for libraries that
are intended for general use. And that contrary to the popular (here in CLA)
opinion, it isn't native Ada libraries that can attract users to Ada.

First, there will be much more C++ and Java libraries anyway. Second, quite
often the design of application or its components, and not availability of
libraries is the critical thing.

While it is often not too expensive to write a library for specific purpose
or provide bindings to existing C/C++ library, the proper design with Ada 
may be a challenging task. Ada provide many opportunities for design, but if
one isn't a skilled and experienced Ada programmer and the application isn't
too simple, s/he has little chances to make best use of those opportunities.

So it appears that one of the most interesting and powerful sides of Ada
often isn't benefit user, and even becomes a burden instead of being an aid.

Therefore I think that what is needed is not libraries, but open source
generic whole applications or generic complex components, which provide
reusable designs. (But please don't tell me about Design Patterns - they
do not demonstrate _entire_ design... like promoting saints, but not faith.) 

As for development tools... well, just curious, which tools except IDE, GUI
builders and test tools like AUnit you imagine for Ada? That is, do you
imagine any development tools that aren't just adapted for Ada variants of
tools long used for, say, C++?

Re: NOACE- End of the road for Ada?

[adaworks]

"Jared" <nowhere@nowhere.nowhere> wrote in message
news:S39Zd.1389$fO6.3528@news.uswest.net...
>
> Java, as has been pointed out elsewhere on this
group, is basically C++
> with all the bad parts removed and with garbage
collection added.  Java is
> comfortable to all the C people, because of its
syntax, because of its
> culture, and because it pretends to share the
C++ idioms.
>
A strange argument, but a common one.

Ada's syntax is not less comfortable than the
syntax of the C family.  In fact,
I find the C family syntax rather annoying, not
particularly intuitive, and full
of contradictions and work-arounds.

It seems that, once the industry gets used to
doing things the hard way, the
people in that industry come to believe that that
is the natural way.   I am
reminded of old women in Southeast Asia who used
to use short-handled
brooms.   They stooped over them day after day
after day, and many of
them, when introduced to long-handled brooms,
continued to stoop over
those brooms just as they had with short-handled
brooms.

You mentioned Ruby.   Nice language.   Not
type-safe, but at least the
curly braces are gone!

Every time I confront someone in a decision-making
capacity about their
choice of C++ over Ada, and more recently Java
over Ada, the answer
comes down to, "Well, we agree that Ada is
probably better for coding
weapon systems, but we can find more trained C++
programmers than
Ada programmers."

Yes. The decision is made not on the basis of
language quality.  Rather it
is, "We cannot find enough Ada programmers."
Sometimes it is, "No one
wants to program in Ada."   I have not been able
to bring myself to view
these reasons as other than either deranged of
stupid.   Am I going to let
a mechanic who has no experience with a torque
wrench do serious work
on my car just because I am having trouble finding
one who does know
how to use a torque wrench.    Oh, yes.  When I
need open-heart
surgery, I suppose any physician with a set of
sharp scapels, and a
modest knowledge of anesthisology and heart
disease do the job.  After
all, it is too hard to find a good physician
trained in using the right tools.

My worry is that these contractors are building
weapon systems using
inferior tools.   Ada is the torque wrench of
programming languages.
People's lives are at risk.  I find it scary that
the contractors are making
decisions in favor of languages that are
inherently featuring dangerous
constructs, languages that require such care in
their use that, on at least
one major project, they have opted for such a
"safe" subset that they
have practically eliminated the reasons for using
an object-oriented
language in their restrictive rules.

Perhaps expediency does not impact quality.
Perhaps, also we won't
know the answer to that question for many years,
the length of time
it takes to develop certain of our major weapon
systems in progress.
By then, those senior managers who have made the
decisions will
have retired, been promoted out of harm's way, or
moved to some
other job and accountability will have vanished
with them.

Ada has proven itself effective in building weapon
systems.  It has been
shown to be excellent in safety-critical software.
There is no good reason
to ignore its benefits just to follow the hype of
today's popular flavor.
For managers to allow themselves to be intimidated
by a lot of people
who can't get over their need for curly braces is
unconscionable.

"The horror!  The horror!"

Richard Riehle

Re: NOACE- End of the road for Ada?

[Marin David Condic]

Well, there you have to take a look around you to see what people are 
using in a problem domain to help them get to an end product. Sometimes 
there is no Ada equivalent. Sometimes, there may be an Ada equivalent, 
but usually a limited selection and often not nearly so full featured as 
similar C/C++ or other language tools. Pick your problem space and see 
what is in general use there - then develop things for Ada to address 
that, but better.

In my current class of applications, one of the big tools is Simulink. 
That's just one example since we're still talking about embedded systems 
and there are a whole slew of things that go into that sort of 
development. But its stuff like that where Ada often comes up short - or 
at best a weak "Me Too!!!" player.

MDC

Alexander E. Kopilovich wrote:
> 
> As for development tools... well, just curious, which tools except IDE, GUI
> builders and test tools like AUnit you imagine for Ada? That is, do you
> imagine any development tools that aren't just adapted for Ada variants of
> tools long used for, say, C++?
> 
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "'Shut up,' he explained."

         --  Ring Lardner
======================================================================

Re: NOACE- End of the road for Ada?

[Wes Groleau]

Michael Card wrote:
> The only rationale I can come up with to explain the Dod's anti-Ada bias 
> is that some high-up folks in the Pentagon didn't like it, maybe because 
> it was from DISA (I get the feeling DISA is one of the lesser-loved 
> branches of the DoD). This distaste for Ada by the services themselves 
> (USN, USA, USMC, USAF) would certainly be quickly mirrored by the 
> contractors, since the services are the ones paying them, not DISA. So, 

Probably partly right.  My experience, however, leads me to suspect
that part of the problem is some officer who has no clue what 
programming really is, much less software engineering, but he has
been playing with a PC at home for years.  He has managed to do a
few trivial but "COOL" programs at home with C++ or Java and that
plus the popular press has convinced him that Java and C++ are
where it's at.  Then he gets transferred to an acquisition job, ....

I am aware of a situation where a Java hacker working for a
defense contractor had a prototype GUI with practically no
functionality implemented.  Some military officer saw it and
asked how soon it could be delivered.  A few months later,
thousands of lines of Java were given a pretend peer review, ....

-- 
Wes Groleau

Truth often suffers more from the heat of its defenders
than from the arguments of its opposers.
                        -- William Penn

Re: NOACE- End of the road for Ada?

[Alexander E. Kopilovich]

Marin David Condic wrote:

> Well, there you have to take a look around you to see what people are 
> using in a problem domain to help them get to an end product.

Here you assume that everyone who has prudent interest in aiding Ada can see
in one's neighbourhood some software development using Ada in some problem
domain.

This is wrong assumption. Although it is "almost correct" numerically, it is
still fundamentally wrong. And note, that exactly this assumption is a major
difference between Ada world and the worlds of other well-known languages.

> In my current class of applications, one of the big tools is Simulink. 
> That's just one example since we're still talking about embedded systems 
> and there are a whole slew of things that go into that sort of 
> development. But its stuff like that where Ada often comes up short - or 
> at best a weak "Me Too!!!" player.

OK, Simulink. If I understand it properly, Simulink is a package that comes
with MatLab (or there is another Simulink?). Search in Google quickly shows
that there are some products, which support Ada with Simulink (at least those
from universities). Probably you know or even use those products, and came to
conclusion that they all are deficient comparing with Simulink support tools
for C++. 

So how can those deficiences be described generally/summarily ? Are they
buggy, incomplete, poorly documented ? Or they are fundamentally inferior,
being essentially "Ada tools for Simulink" instead of "Simulink tools for
Ada" ?

Re: NOACE- End of the road for Ada?

[Marin David Condic]

Alexander E. Kopilovich wrote:
> 
> Here you assume that everyone who has prudent interest in aiding Ada can see
> in one's neighbourhood some software development using Ada in some problem
> domain.
> 
I think I'm assuming that if you were developing software in any 
language for any particular domain, you'd see a bunch of tools sitting 
around you. Development tools, related libraries, other applications, 
etc. Chances are, if all those tools/libraries/related applications are 
developed in C, work with C or are simply oriented toward C, that you'd 
be fighting against the tide to use - say - Smalltalk. Even something as 
simple as a configuration management tool can discourage development in 
other languages. I've seen some that basically say "If you're tracking C 
code, I'll do this job and that thing and this other spiffy little task, 
but if you're any other language, you get just plain vanilla..."

My point being that if there were similar support structure in some 
problem space that was oriented toward Ada, written in Ada, compatible 
with Ada, etc., it would make Ada the natural choice. One would then be 
spitting into the wind to use something like C.



> 
> OK, Simulink. If I understand it properly, Simulink is a package that comes
> with MatLab (or there is another Simulink?). Search in Google quickly shows
> that there are some products, which support Ada with Simulink (at least those
> from universities). Probably you know or even use those products, and came to
> conclusion that they all are deficient comparing with Simulink support tools
> for C++. 
> 

Q: What does Simulink generate?
A: C

You can fight it, but all the pressure from every angle will be to 
utilize C because that's what Simulink generates.

Add to that the fact that the whole model of the way these sorts of 
tools design & operate is a kind of early vintage Fortran view of the 
universe and even if it *did* generate Ada, you're at best going to get 
Adatran code. How does Ada shine in any way if all you get is a stack of 
global variables and a bunch of subroutines to operate on them? Its 
fundamentally no better than the C you get already - so why spit into 
the wind? You even have to fight against Ada in some ways to make it 
work like Fortran/C so it only makes the job harder.

If there were a Simulink-like thing that was modeled with Ada in mind as 
the target language, it might have significant advantages *to the 
Simulink modeler-guy*. Right now, the guy generating the model has no 
reason to want to use Ada and every reason not to want to. From his 
view, all he sees is the Simulink model and attempting to generate any 
code in any language other than exactly what he is getting now (C) is 
only a pain in the ass and of no particular advantage.

If, OTOH, there was a Simulink-like modeling tool that took advantage of 
Ada-ish concepts - expressed things in terms of Ada constructs, for 
example - then the model builder would a) have the advantage of better 
abstraction, reuse of model components, better up-front consistency 
checks, etc., and b) would start having natural reasons to prefer Ada 
code generation.

This is just one example - and one that isn't elaborated on in great 
detail. Just think of similar things in different problem domains. 
People use CAD/CAM packages for mechanical design. Do they do any kind 
of code generation for modeling purposes? What do they generate? Is 
there some advantage to making the CAD/CAM tool express things in 
Ada-ish ways? (packages? strong typing? tasking? object oriented? etc?)

What about math and statistics packages? What about network 
applications? All these things (and more) have a bunch of surrounding 
tools, software libraries, related applications, etc., and even if Ada 
can play nicely with other languages, it is inherently swimming against 
the tide. If Ada  adopted one of these areas in some respect and built 
up that infrastructure, it would have Coolness Factor by providing 
capabilities not usually seen and would be providing the guy who has a 
job to do with incentives to want to use Ada.

MDC


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "'Shut up,' he explained."

         --  Ring Lardner
======================================================================

Re: NOACE- End of the road for Ada?

[Robert A Duff]

<adaworks@sbcglobal.net> writes:

> "Jared" <nowhere@nowhere.nowhere> wrote in message
> news:S39Zd.1389$fO6.3528@news.uswest.net...
> >
> > Java, as has been pointed out elsewhere on this
> group, is basically C++
> > with all the bad parts removed and with garbage
> collection added.  Java is
> > comfortable to all the C people, because of its
> syntax, because of its
> > culture, and because it pretends to share the
> C++ idioms.
> >
> A strange argument, but a common one.
> 
> Ada's syntax is not less comfortable than the
> syntax of the C family.  In fact,
> I find the C family syntax rather annoying, not
> particularly intuitive, and full
> of contradictions and work-arounds.

Richard,

I think you misunderstand Jared's point.  He's not saying Java syntax is
"better" -- he's saying it's comfortable to folks used to C syntax.
That seems quite likely true.  If you're a C programmer, you're used to
seeing lots of curly braces all over, and you're used to declaring
variables by putting the type name first (int X instead of X: int).
Switching to Java is then comfortable.  Switching to Ada is not -- you
have to get used to "end if" instead of "}" and so forth.

I think that's a big part of the reason Java is so popular -- it gives a
comfortable syntax, plus garbage collection, no confusion between arrays
and pointers, etc.

I happen to be comfortable with Ada syntax, so I find "int X" bass
ackwards.  (But then I also find "package X" backwards; it should be
"X: package".  The most important thing about a declaration (its name)
should come first.  Then what sort of thing it is.  Then more details.)

- Bob

Re: NOACE- End of the road for Ada?

[adaworks]

"Marin David Condic" <nobody@noplace.com> wrote in
message
news:De_Zd.5321$qW.622@newsread3.news.atl.earthlink.net...
>
> What about math and statistics packages?

It would be really cool to have a standard
interface between
Ada and Matlab.

Richard Riehle

Re: NOACE- End of the road for Ada?

[adaworks]

"Robert A Duff" <bobduff@shell01.TheWorld.com>
wrote in message
news:wccoedjs5t4.fsf@shell01.TheWorld.com...
>
> Richard,
>
> I think you misunderstand Jared's point.  He's
not saying Java syntax is
> "better" -- he's saying it's comfortable to
folks used to C syntax.
> That seems quite likely true.  If you're a C
programmer, you're used to
> seeing lots of curly braces all over, and you're
used to declaring
> variables by putting the type name first (int X
instead of X: int).
> Switching to Java is then comfortable.
Switching to Ada is not -- you
> have to get used to "end if" instead of "}" and
so forth.
>
Yes, I understand that.   When I speak Japanese I
have to get used
to the idea that the verb comes at the end of the
sentence.  When
I speak Russian, I have to learn to use the
inflexional case structure
and post-fix grammatical constructs to make myself
understood.  And
when I speak Chinese, the grammar is so subtle,
the tone system so
important that I can easily end up calling my best
friend a fried panda
turd.  (some hyperbole there for effect)

> I think that's a big part of the reason Java is
so popular -- it gives a
> comfortable syntax, plus garbage collection, no
confusion between arrays
> and pointers, etc.
>
Next Quarter I am teaching, once again, a class
called programming
paradigms.  The students enter this class with at
least two Quarters
of Java under their belt -- or elsewhere,
depending on our anatomical
sense of humor.

I jolt them out of their Java thinking by starting
them with functional
programming:  Lisp, Scheme, ML, Haskell, etc.   It
is important that
they learn that Java is only one language, and
only one way of solving
programming problems, and not necessarily the best
way.

Later, they learn more about C++, Ada, and
eventually Smalltalk.  They
even get a taste of Eiffel, C#, and some other
nicely designe languages.One
of my missions in this class is to get them to
understand that it is not
intellectually healthy to know only one
programming language.

> I happen to be comfortable with Ada syntax, so I
find "int X" bass
> ackwards.  (But then I also find "package X"
backwards; it should be
> "X: package".  The most important thing about a
declaration (its name)
> should come first.  Then what sort of thing it
is.  Then more details.)
>
Yes.  I understand.  I have often wished that a
package could be a
first-class object, but one cannot have
everything.   If we were designing
Ada from scratch, we would probably do a lot of
things different. Still,
no one has done all the right things even with
languages developed
subsequent to Ada.   There are so many things I
admire about Eiffel,
but it falls a little short of what I would hope
for.   Still, I would select
Eiffel over most other languages if I did not have
Ada, and sometimes
I would pick it even if I did have Ada.  I can
think of no circumstances
where I would deliberately choose C++.

Richard Riehle

Re: NOACE- End of the road for Ada?

[Alexander E. Kopilovich]

Robert A Duff wrote:

> I think that's a big part of the reason Java is so popular -- it gives a
> comfortable syntax, plus garbage collection, no confusion between arrays
> and pointers, etc.

Well indeed Java can be briefly characterized (from practical viewpoint)
as "relaxed C", with additional remark about Java threads and synchronization.

> ... I also find "package X" backwards; it should be
> "X: package".  The most important thing about a declaration (its name)
> should come first.  Then what sort of thing it is.  Then more details.)

But name isn't always the most important thing in a declaration. For example,
consider Country Profile, where most probably you'll read:

President : George Bush

and the list of characters in a play, where the order will be opposite:

George Bush : President

Re: NOACE- End of the road for Ada?

[Alexander E. Kopilovich]

Marin David Condic wrote:

> Q: What does Simulink generate?
> A: C
>
> You can fight it, but all the pressure from every angle will be to 
> utilize C because that's what Simulink generates.
>
> Add to that the fact that the whole model of the way these sorts of 
> tools design & operate is a kind of early vintage Fortran view of the 
> universe and even if it *did* generate Ada, you're at best going to get 
> Adatran code. How does Ada shine in any way if all you get is a stack of 
> global variables and a bunch of subroutines to operate on them? Its 
> fundamentally no better than the C you get already - so why spit into 
> the wind? You even have to fight against Ada in some ways to make it 
> work like Fortran/C so it only makes the job harder.
>
> If there were a Simulink-like thing that was modeled with Ada in mind as 
> the target language, it might have significant advantages *to the 
> Simulink modeler-guy*. Right now, the guy generating the model has no 
> reason to want to use Ada and every reason not to want to. From his 
> view, all he sees is the Simulink model and attempting to generate any 
> code in any language other than exactly what he is getting now (C) is 
> only a pain in the ass and of no particular advantage.
>
> If, OTOH, there was a Simulink-like modeling tool that took advantage of 
> Ada-ish concepts - expressed things in terms of Ada constructs, for 
> example - then the model builder would a) have the advantage of better 
> abstraction, reuse of model components, better up-front consistency 
> checks, etc., and b) would start having natural reasons to prefer Ada 
> code generation.

Well, this sounds all right, except that it raises a disturbing question:
why that thing was not done already? Or it was done, perhaps several times,
but was not published and used silently and internally only? It seems that
the thing can be really useful and really belongs to one of natural Ada
domains, so it is hard to believe that it was not done... and if it wasn't
then there should be not-too-obvious obstables or resistances. Perhaps there
are some problems with patents, licenses etc.? Or something else?

> People use CAD/CAM packages for mechanical design. Do they do any kind 
> of code generation for modeling purposes? What do they generate? Is 
> there some advantage to making the CAD/CAM tool express things in 
> Ada-ish ways? (packages? strong typing? tasking? object oriented? etc?)

I think that mechanical CAD area isn't good for Ada - mostly because of 
already established practice there. They have their "geometry engines" and
too little remains for Ada.

> What about math and statistics packages?

I don't think that math and statistics are natural domains for Ada...
especially statistics, where APL seems to be the most suitable programming
language.

> What about network applications?

I don't see any particular advantages of Ada for networking.

Re: NOACE- End of the road for Ada?

[Marin David Condic]

adaworks@sbcglobal.net wrote:
> 
> 
> It would be really cool to have a standard interface between Ada and
> Matlab.
> 
Probably, but it would be even MORE cool if there was an entire Ada
equivalent of Matlab, et alia. The whole bundle of stuff produced by The 
Mathworks is pretty cool for the modeling world, but I think it has 
problems when people try to bring it into production. It is very 
tempting to say "Well, now that you've defined the control in the model 
world and conducted a bunch of tests on it, why don't we just compile it 
and take that code into the production box..." But the model world likes 
to play fast and loose with all the things that might cause problems in 
a production world. (For example, everything tends to be just a "real" 
number - not much type checking going on. Or not much support for 
low-level representations of data that might matter when the zeros and 
ones actually connect to the hardware. Or any number of other complaints.)

So people like to just build these models then take the code into 
production, but might it not be BETTER if the modeling tool had 
capabilities aimed at the production world? Might it not be BETTER if a 
modeling tool took into consideration the needs of and proven techniques 
of embedded software development? So if someone designed such a modeling 
tool and incorporated Ada-isms into it and had it generating Ada code, 
and it provided BETTER capabilities to the guy designing models, might 
that not create an interesting marketplace for Ada?

The same kind of thinking could be applied to other problem domains. Its 
not enough just to have a compiler and a few general tools for 
development. For the language to thrive in an environment, the tools for 
that domain must also support the language well. (or perhaps the other 
way around?)

MDC

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "'Shut up,' he explained."

         --  Ring Lardner
======================================================================

Re: NOACE- End of the road for Ada?

[Marin David Condic]

Alexander E. Kopilovich wrote:
> 
> 
> Well, this sounds all right, except that it raises a disturbing question:
> why that thing was not done already? Or it was done, perhaps several times,
> but was not published and used silently and internally only? It seems that
> the thing can be really useful and really belongs to one of natural Ada
> domains, so it is hard to believe that it was not done... and if it wasn't
> then there should be not-too-obvious obstables or resistances. Perhaps there
> are some problems with patents, licenses etc.? Or something else?
> 
I'm not sure what you are referring to here. The style in which the 
Simulink (and other) tools operate?

Keep in mind that the original intent of things like Simulink was NOT to 
go produce software. It wasn't supposed to be a software design language 
like UML. It was intended for describing things like plants and controls 
for those plants. It was a tool that would let you model things like the 
changes in temperatures, pressures, positions, etc of things in a plant 
and then describe a control that would look at those inputs & apply the 
appropriate control laws. It was NOT originally intended to design code 
to go into a control computer and doesn't tend to support modern 
software design methodologies.

The guys doing this job are essentially thinking in terms of signals 
coming in and signals going out. They're more in line with designing 
some electronic circuits. They came up with techniques back in the days 
of Fortran controls that made things work kind of like an electronic 
circuit. It probably never occurred to anybody working in the field that 
even though they were dealing with essentially an analog kind of thing, 
ultimately they were buiilding digital software and that there may be 
techniques in that field that might be helpful in what they were doing.

I can't describe the entire situation or an entire solution in this 
space. I'm merely picking on this as an example of how there is a 
problem domain out there that has built up a bunch of tools around it 
and that the tools are not especially Ada-ish, yet it is a market that 
Ada ought to want to address (embedded systems). If there were more 
Ada-ish tools out there, perhaps it would be a much more natural 
tendency to opt for using Ada in the corresponding embedded control.

> 
> I think that mechanical CAD area isn't good for Ada - mostly because of 
> already established practice there. They have their "geometry engines" and
> too little remains for Ada.
> 
But perhaps there is some aspect of that which could be better addressed 
in some way by an improved tool? If the improved tool (an end product!) 
was in some way significantly better at helping these folks get to their 
ultimate solutions and the tool was oriented towards Ada, might it not 
find some acceptance.

I don't know because I'm not an ME (I only play one at work ;-) and I'm 
not familiar with their tools. But for those who ARE familiar with the 
domain - perhaps they could think of a better mousetrap?

> I don't think that math and statistics are natural domains for Ada...
> especially statistics, where APL seems to be the most suitable programming
> language.
> 
Ada has fantastic math potential - look at the precise definitions of 
mathematical types & operations and the prefabricated mathematical 
functions built in. What makes APL in any way BETTER? Could it be that 
it just simply provides some intrinsic statistical operations? Is there 
some reason Ada cannot provide some (semi)standard library full of 
statistical functions? (Its going to provide some standard vector and 
matrix functions) Is it lack of capability or lack of will?



> 
> I don't see any particular advantages of Ada for networking.
> 
> 
Perhaps because you're not thinking of it in the same way I am. If Ada 
is a better general purpose programming language than is C, wouldn't 
network applications be better built using Ada? The problem is that 
network apps by their nature don't sit out there all alone. There's all 
sorts of related stuff (like an OS, libraries and other network apps 
that must be communicated with) that's already out there in C or C++ or 
Java. Ada comes to the table late. But IF there were a bunch of Ada 
and/or Ada-ish apps, development tools, surrounding infrastructure, 
etc., then wouldn't it be more natural to develop additional apps in Ada?

It might be difficult to introduce Ada into an existing domain, but 
think in these terms: The uses of networks are expanding and there might 
be some new subset of that in which Ada could become dominant. Java was 
new at one time and it carved out a niche for itself with "portable GUI 
apps". Look at things like Bluetooth - its defining a whole new world. 
What if Ada had been the technology behind Bluetooth? But forget the 
past and look to the future. What might some smart network-geek dream up 
and implement in Ada that might create some new capability and for which 
the surrounding tools would all define an Ada niche?

I guess I'm saying that the Ada world has been thinking a little too 
introspectively - seeing Ada just from a software developer's 
perspective rather than seeing software as inherently a means to some 
other end. Take that technology and apply it to developing some kind of 
products BEYOND software development tools and see if it can carve out a 
money-making niche for itself.

Unless somebody uses Ada to develop some real-world, money-making 
product, Ada is forever condemned to being a "hobbyist" language - by 
definition. Maybe we're too used to counting on the DoD to generate 
those projects and give us that revenue so we're not used to thinking 
about where the money comes from to support our favorite language. Those 
days are gone.

MDC


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "'Shut up,' he explained."

         --  Ring Lardner
======================================================================

Re: NOACE- End of the road for Ada?

[Dr. Adrian Wrigley]

On Thu, 17 Mar 2005 07:56:59 +0300, Alexander E. Kopilovich wrote:

> Marin David Condic wrote:
>> What about math and statistics packages?
> 
> I don't think that math and statistics are natural domains for Ada...
> especially statistics, where APL seems to be the most suitable programming
> language.

I strongly think Ada *is* a natural choice for maths/stats/scientific
computing.

You get excellent clarity, robustness and performance.

And Ada generics beat anything I have come across for code reuse
and strong abstrations of interfaces of the kind needed in these fields.

Of course if you want to use a specialized system, Matlab/S Plus/
Mathematica might be natural choice, keeping development time down.
But compared to the usual general-purpose language choices, I
think it is a natural choice.  Is Fortran90/C++/Perl/Java really
any more technically suitable?  I can't really comment on APL.
-- 
Adrian

Re: NOACE- End of the road for Ada?

[Dmitry A. Kazakov]

On Thu, 17 Mar 2005 13:25:25 GMT, Marin David Condic wrote:

> adaworks@sbcglobal.net wrote:
>> 
>> 
>> It would be really cool to have a standard interface between Ada and
>> Matlab.
>> 
> Probably, but it would be even MORE cool if there was an entire Ada
> equivalent of Matlab, et alia. The whole bundle of stuff produced by The 
> Mathworks is pretty cool for the modeling world, but I think it has 
> problems when people try to bring it into production. It is very 
> tempting to say "Well, now that you've defined the control in the model 
> world and conducted a bunch of tests on it, why don't we just compile it 
> and take that code into the production box..." But the model world likes 
> to play fast and loose with all the things that might cause problems in 
> a production world. (For example, everything tends to be just a "real" 
> number - not much type checking going on. Or not much support for 
> low-level representations of data that might matter when the zeros and 
> ones actually connect to the hardware. Or any number of other complaints.)
> 
> So people like to just build these models then take the code into 
> production, but might it not be BETTER if the modeling tool had 
> capabilities aimed at the production world? Might it not be BETTER if a 
> modeling tool took into consideration the needs of and proven techniques 
> of embedded software development? So if someone designed such a modeling 
> tool and incorporated Ada-isms into it and had it generating Ada code, 
> and it provided BETTER capabilities to the guy designing models, might 
> that not create an interesting marketplace for Ada?

It absolutely true.

I can confirm that in the automotive area it would be a great breakthrough,
if something like above existed. Simulink lacks multi-threaded middleware
for deploying the models. Considering a wide range of complex protocols
which need to be supported (from CAN to TCP/IP), clearly there is an abyss
between the code generated by Simulink to the code needed. More to the
point, there is no chance that people drawing diagrams would be able to get
this communication code right. An Ada platform with a middleware taking
care of this mess would be technically unbeatable.

However, there is a problem of acceptance. People want C. Even more they
want C#. Lots of projects are doomed to fail before they change their
minds...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: NOACE- End of the road for Ada?

[Alexander E. Kopilovich]

Dr. Adrian Wrigley wrote:

> >> What about math and statistics packages?
> > 
> > I don't think that math and statistics are natural domains for Ada...
> > especially statistics, where APL seems to be the most suitable programming
> > language.
>
> I strongly think Ada *is* a natural choice for maths/stats/scientific
> computing.

Well, I meant not just "maths/stats/scientific computing", but what I was
asked about - math and statistics packages (that is, libraries for general
use), which is another matter. For mathematics the latter manifests separated
responsibility, which lifts requirements far above the levels where Ada has
advantages vs. C.

> You get excellent clarity, robustness and performance.

Well, I think if you really need clarity in Ada then you probably should not
go outside the limitations of SPARK. Everywhere outside of SPARK you may
eventually need support of an Ada expert - and I think that it will preclude
claims of clarity.

Re: NOACE- End of the road for Ada?

[adaworks]

"Alexander E. Kopilovich" <aek@VB1162.spb.edu>
wrote in message
news:mailman.37.1111031966.23655.comp.lang.ada@ada-france.org...
> But name isn't always the most important thing
in a declaration. For example,
> consider Country Profile, where most probably
you'll read:
>
> President : George Bush
>
Well, the order we use for names
and titles is not necessarily the
natural order.   In Chinese or
Japanese we would say,

  Bush George

or for Mr. Bush,

  Bush Xianshiang (Chinese)
  Bush san (Japanese)

The fuss English speakers make about
the order of words for programming
syntax is artificial for every language,
and not necessarily the way the rest
of the world does it.

Richard Riehle

Re: NOACE- End of the road for Ada?

[Wes Groleau]

adaworks@sbcglobal.net wrote:
> The fuss English speakers make about
> the order of words for programming
> syntax is artificial for every language,
> and not necessarily the way the rest
> of the world does it.

But he makes a good point about not being schizo about it
within a single language.  I'll have to admit I never noticed
the inconsistency of task/package/function/procedure coming before
the name and <type>/constant coming after.

But I did often notice the inconsistency of 'end' being sometimes
_required_ to identify what it was ending, sometimes being _allowed_
to, and sometimes being _forbidden_ to.

-- 
Wes Groleau
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^  A UNIX signature isn't a return address, it's the ASCII equivalent ^
^  of a black velvet clown painting.  It's a rectangle of carets      ^
^  surrounding a quote from a literary giant of weeniedom like        ^
^  Heinlein or Dr. Who.                                               ^
^                                -- Chris Maeda                       ^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Re: NOACE- End of the road for Ada?

[Dmitry A. Kazakov]

On Thu, 17 Mar 2005 22:45:14 -0500, Wes Groleau wrote:

> adaworks@sbcglobal.net wrote:
>> The fuss English speakers make about
>> the order of words for programming
>> syntax is artificial for every language,
>> and not necessarily the way the rest
>> of the world does it.
> 
> But he makes a good point about not being schizo about it
> within a single language.  I'll have to admit I never noticed
> the inconsistency of task/package/function/procedure coming before
> the name and <type>/constant coming after.

Maybe it is because they define non-first class objects. My *empirical*
theory is that Ada has:

X : Type ...;

Class-type X ...;

The second form defines either a 2nd class object or both 2nd class object
and its single 1st class instance.

Exception:

Label : loop ... end loop;

Should be sort of:

loop Label is
   ...
end loop;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: NOACE- End of the road for Ada?

[Marin David Condic]

Dmitry A. Kazakov wrote:
> 
> However, there is a problem of acceptance. People want C. Even more they
> want C#. Lots of projects are doomed to fail before they change their
> minds...
> 
Yeah, but...

The biggest reason that the Simulink modeling crowd wants C is because 
Simulink generates C. The modelers themselves don't really care so long 
as the model executes. But once you've got the C code, the incentive to 
use ANYTHING ELSE for the production control starts asymptotically 
approaching zero.

Matlab/Simulink are the 800 pound gorilla in this market. They tend to 
define what happens even with their competitors. People want to be 
compatible with Simulink so guess what THEY all generate? That's right. 
C code.

If there was an Ada-ish Simulink-like modeling tool that incorporated at 
the design level a number of Ada-isms that helped support the modeling 
effort, it would be far more natural to generate Ada code to run the 
model and then guess what? The incentive to use the Ada code for the 
embedded control target starts becoming unbeatable. But you MUST have a 
BETTER modeling tool - it can't just be a Simulink clone or nobody will 
want to abandon the market leader for your product.

MDC


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "'Shut up,' he explained."

         --  Ring Lardner
======================================================================

Re: NOACE- End of the road for Ada?

[Robert A Duff]

Wes Groleau <groleau+news@freeshell.org> writes:

> But he makes a good point about not being schizo about it
> within a single language.  I'll have to admit I never noticed
> the inconsistency of task/package/function/procedure coming before
> the name and <type>/constant coming after.

We say "type T is array..." and "type T is range..." and so forth,
but we say "task type T is..." rather than "type T is task...".
Strange.

- Bob

Re: NOACE- End of the road for Ada?

[Jean-Pierre Rosen]

Robert A Duff a �crit :

> 
> We say "type T is array..." and "type T is range..." and so forth,
> but we say "task type T is..." rather than "type T is task...".
> Strange.
> 
I think it is the simplest way to have an (almost) common form for the 
singleton and the type case.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: NOACE- End of the road for Ada?

[Alexander E. Kopilovich]

Marin David Condic wrote:

> > ... It seems that
> > the thing can be really useful and really belongs to one of natural Ada
> > domains, so it is hard to believe that it was not done... and if it wasn't
> > then there should be not-too-obvious obstables or resistances. Perhaps there
> > are some problems with patents, licenses etc.? Or something else?
> > 
> I'm not sure what you are referring to here. The style in which the 
> Simulink (and other) tools operate?

It may be anything involved - nomeclature of elements, outlook... given that
Windows taskbar is patented by Microsoft, one may expect anything is that area
these days.

Anyway, it seems curious enough, and probably I'll take a look at that
Simulink. Therefore, if you know some good review of Simulink then please
let me know.

> Ada has fantastic math potential - look at the precise definitions of 
> mathematical types & operations and the prefabricated mathematical 
> functions built in.

I wouldn't call that fantastic - it is just good enough for developing
computational software. But mathematics isn't just numerical computation,
it involves more advanced thinking (even in a case when the final aim is
a computation), and therefore it needs more flexibility than Ada provides.
Ada's degree of flexibility is perhaps exactly right for the purposes of Ada,
but it is isn't very good for mathematics. Perhaps that is difference between
"mathematics" and "math"? -:)

Note that insufficient flexibility may harm readability. And terseness may
either harm or aid readability depending of circumstances.

> What makes APL in any way BETTER?

Several things: 1) it is very terse (and you may recall that mathematicians
generally like terseness in formulaes; in particular, they persistently invent
denotations for that); 2) it provides excellent repertoire of array-wide
operations (including multi-dimensional arrays); 3) it is generally
well-thought from mathematical viewpoint - indeed, one of its explicit
purposes was to provide a mathematical teaching tool.

> Could it be that 
> it just simply provides some intrinsic statistical operations?

No, but it provides very useful and natural intrinsic array-wide operations.

> Is there 
> some reason Ada cannot provide some (semi)standard library full of 
> statistical functions? (Its going to provide some standard vector and 
> matrix functions) Is it lack of capability or lack of will?

Ada certainly can provide such a library, but it will not be much different
for a real end-user (even for a professional statistician) comparing with
C/C++ library with similar contents.

What may be different with APL is that the user can intervene at the source
code level and customize the library (or simply read the source code and
understand some subtleties) - being competent in statistics only, but not
necessary in software engineering.

Re: NOACE- End of the road for Ada?

[Marin David Condic]

Alexander E. Kopilovich wrote:
> 
> Anyway, it seems curious enough, and probably I'll take a look at that
> Simulink. Therefore, if you know some good review of Simulink then please
> let me know.
> 
You might look for The Mathworks website http://www.mathworks.com/ to 
see if they have any examples or tutorials that might help you get a 
feel for the tools they have. Other than googling up "Simulink" I don't 
know of any specific review articles that might help you there.

(Note that you'll find the company I work for on this website 
http://www.mathworks.com/products/connections/company_name.html but I am 
not here representing Belcan or The Mathworks in any way.)

> 
> I wouldn't call that fantastic - it is just good enough for developing
> computational software. But mathematics isn't just numerical computation,
> it involves more advanced thinking (even in a case when the final aim is
> a computation), and therefore it needs more flexibility than Ada provides.
> Ada's degree of flexibility is perhaps exactly right for the purposes of Ada,
> but it is isn't very good for mathematics. Perhaps that is difference between
> "mathematics" and "math"? -:)
> 
I guess it depends on what you're trying to do. If you just want to 
solve a math problem (2 + 2 = ?) then most people don't go write a 
program - they get out a calculator. If your math problems are 
sufficiently complex, people go to what I would consider essentially a 
really complicated calculator - a stats package or a similar 
math-oriented thing like Matlab, etc.

If you have one specific problem that you are solving over and over 
again in your work, I could see that you might not want to go writing an 
Ada program and something like APL (or whatever) might be better for 
reasons of flexibility, notation, I/O, etc.

But if I'm writing software that does some job and that it has a 
significant mathematical component to it (such as say missile launch 
control software that must deal with all sorts of navigation & physics 
things) then Ada is a perfectly wonderful language. I'd like to see it 
have more (semi)standard math libraries for such applications, but at 
least when you need to get into math, there are really nice facilities 
for doing that.


MDC

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "'Shut up,' he explained."

         --  Ring Lardner
======================================================================

Re: NOACE- End of the road for Ada?

[Marin David Condic]

adaworks@sbcglobal.net wrote:
> 
> "The horror!  The horror!"
> 
> Richard Riehle
> 
> 

I appreciate the reference to one of my favorite movies. :-)

Your comments are well thought out (as usual) and I generally agree that 
we do see a lot of bad reasons in DoD contracts for the choices of 
languages. I'd depart slightly in this regard: The guys making those 
decisions usually are much more concerned for the overall success of a 
weapons system program to worry too much about what flavor of nuts and 
bolts are selected to go into constructing various parts involved. 
They're concerned above all with making sure the whole project comes in 
on budget, within schedule and that it passes acceptance tests meeting 
overall objectives. Programming language choices are so far down below 
the noise floor that they just trust the guys doing the job (and hold 
them accountable) for getting it done. Perhaps it ends up taking longer 
and costing more to get it right, but so long as the guys doing the job 
guessed right in making up the schedule, it never really surfaces.

That said, I'd also suggest that its about time we just quit counting on 
the DoD & its contractors for the welfare of Ada. Its a huge 
disappointment that they've chosen to ignore & marginalize their own 
language, but that's what they've done and there isn't much we can do 
about that. They simply don't see the language as having a significant 
following in the "Real World" and they stack up the pluses & minuses and 
come to the conclusion they'd be better off going with what seems to be 
dominant technology in the rest of the industry.

So if we quit relying on them to sustain Ada and go out there into the 
"Real World" and find ways of employing it in potentially new & growing 
technological developments, perhaps one day Ada becomes the dominant 
language in some field. Why don't all the Ada guys who build embedded 
systems think of some new device they might construct & market and use 
Ada as the technology going in to make the zeros and ones? Why don't all 
the Ada guys who build network applications think of some new and cool 
networking capability and go start developing the underlying 
implementation in Ada? Why don't the Ada guys who build financial 
applications think of a better way to address someone's accounting, 
payroll, inventory, etc. needs and build some marketable application in Ada?

Enough of the tools exist already and with sufficient quality and at 
affordable prices that there is not much to hinder using Ada to 
construct some end-product. The guy who buys an automotive diagnostic 
computer doesn't care what language you programmed it in. The guy buying 
  some wireless network remote control home appliance doohickie doesn't 
care if you programmed it in Ada. The guy streamlining his business with 
your automatic inventory management & ordering application doesn't care 
what language you programmed it in. If we build end products like this 
that have some commercial success, people who want to program in Ada 
will find jobs and compiler vendors will have customers to keep them in 
business.

The point being that if we quit worrying about the DoD and quit thinking 
strictly in terms of software development tools (although it is 
important to have them) and START thinking in terms of "How could I 
deploy this technology in building a BETTER end product in my field of 
expertise that might have a marketable future?" we might see Ada find 
some productive niches and we might see more Ada jobs created. Perhaps 
eventually the DoD would come back and rediscover their own language.

MDC


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "'Shut up,' he explained."

         --  Ring Lardner
======================================================================

Re: NOACE- End of the road for Ada?

[adaworks]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:iaf%d.1184$Vi3.903@newsread3.news.atl.earthlink.net...
> adaworks@sbcglobal.net wrote:
> >
> > "The horror!  The horror!"
> >
> I appreciate the reference to one of my favorite movies. :-)
>
The movie lifted the quotation from a book called "Heart of Darkness"
by Joseph Conrad.  If you enjoyed the movie, you'll love the book.

>
> The point being that if we quit worrying about the DoD and quit thinking
> strictly in terms of software development tools (although it is
> important to have them) and START thinking in terms of "How could I
> deploy this technology in building a BETTER end product in my field of
> expertise that might have a marketable future?" we might see Ada find
> some productive niches and we might see more Ada jobs created. Perhaps
> eventually the DoD would come back and rediscover their own language.
>
I agree completely.   The DoD officials involved in the language process have
demonstrated an amazing level of stupidity in this regard, and the contractors
are not much better. It is time for people who understand the benefits of
Ada to simply choose it for their own projects.

Still, I have this nagging feeling.   It comes from the realization that I want
to send our troops to war with the very best tools and equipment;  tools
and equipment that is build using the best software we can provide.  And I
am uncomfortable with the use of the C family of languages for doing
that.  So, for me, it is not so simple.

Richard Riehle

Re: NOACE- End of the road for Ada?

[Marin David Condic]

adaworks@sbcglobal.net wrote:
> 
> The movie lifted the quotation from a book called "Heart of Darkness"
> by Joseph Conrad.  If you enjoyed the movie, you'll love the book.
> 
Read that years ago. I think you can get it from Project Gutenberg.
http://promo.net/pg/


> 
> I agree completely.   The DoD officials involved in the language process have
> demonstrated an amazing level of stupidity in this regard, and the contractors
> are not much better. It is time for people who understand the benefits of
> Ada to simply choose it for their own projects.
> 
That is it. Make something useful out of it and go out and sell it. The 
"better mousetrap" rule still applies, but you've got to go find an end 
user willing to pay to get it.

> Still, I have this nagging feeling.   It comes from the realization that I want
> to send our troops to war with the very best tools and equipment;  tools
> and equipment that is build using the best software we can provide.  And I
> am uncomfortable with the use of the C family of languages for doing
> that.  So, for me, it is not so simple.
> 
I understand, but let's remember that even though it is harder to get 
things right in C/C++, it still can be done. You've got to exercise care 
up front in exactly what sort of code you produce (a lot is done by 
auto-code-generation these days, so hopefully this reduces many of the 
"stupid mistakes".) You've got to test very vigorously (which would be 
demanded of Ada anyway - see DO-178b for examples). It can be done - it 
just typically costs more in terms of catching defects at the back end 
instead of at the front end where it is cheaper to fix.

I wish the DoD, et alia, would see some wisdom in terms of using Ada, 
but like I said, they're driven by lots of different concerns and 
language merits are only one factor. So the object of the game should 
shift from trying to convince people that Technology X is superior to 
simply employing Technology X to build some finished product. Doing so 
successfully will breed more success.

MDC

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "'Shut up,' he explained."

         --  Ring Lardner
======================================================================

Re: NOACE- End of the road for Ada?

[Peter Hermann]

Marin David Condic <nobody@noplace.com> wrote:
> I wish the DoD, et alia, would see some wisdom in terms of using Ada, 
> but like I said, they're driven by lots of different concerns and 

I found a striking Quote of the Day (-:

http://www.csv.ica.uni-stuttgart.de/homes/ph/resources_on_ada.html#quote

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: NOACE- End of the road for Ada?

[jtg]

Alexander E. Kopilovich wrote:
> 
>>What about network applications?
> 
> 
> I don't see any particular advantages of Ada for networking.
> 

Well, many network security issues are caused by buffer overflows.
Maybe network services written in Ada and compiled without -gnatp
would be more secure?