An Ada Advice Inquiry

An Ada Advice Inquiry

[adaworks]

I recently received an inquiry from a colleague I have
not seen in many years.   He is currently in a position
where he is asked to advise a client about whether to
choose Ada or C++ for a project.   He is not a language
junkie because his expertise is a very different level of
software engineering, but he is a highly intelligent and
capable consulting engineer.

Perhaps that's why he inquired of me.   :-)

One of the concerns is whether anyone else is choosing to
use Ada for new projects.   He does not want to be the
only one to make such a choice.  It is well-known that
there are a lot of Ada software products being maintained,
but is anyone choosing it for new projects?   Good question,
I answer.

So. What do I tell him?   At one time, I could contact the
AJPO and ask this question.   Although they were never
very good at providing complete information, they did have
some knowledge of where Ada was being used for new
projects.   Now, there is no place to look for that information.

It presents a little dilemma.   If no one else is using Ada for
new projects, he can wonder why he should be the alone
in his decision.    If every other consultant, manager, or
program director asks the same question, and gets no
information about others choosing Ada, no one will want
to make that choice.

Is anyone choosing Ada for new projects?  What kind of
projects?   Can we collect information about them and
create a catalog of them in the adaic.com website?    If
not, why not?

The compiler publishers know who is buying their compilers,
but they don't want to compromise customer confidentiality.
The programmers are afraid of losing their jobs if they tell
anyone what they are doing.  Everyone who can provide the
information is afraid to do so.   When I was actively consulting
on Ada, I was often told, by my client, not to tell anyone they
were using Ada.   So.  We keep the secret.    The secret keeps
Ada a secret.    And Ada begins to wane because no one
wants to reveal their decision to use it.

Is this a recipe for killing any incentive for choosing the language
for future projects?   What do I tell my old friend?   Should he
take the risk of using Ada even without the knowledge that anyone
else is using it for real projects?    Hmmmmm.   Is anyone out there
really choosing it for new software projects?

Richard Riehle 

Re: An Ada Advice Inquiry

[ezkcdude]

I'm thinking about using Ada, but it is very scary when you see very
few projects in development.

On May 3, 10:01 pm, <adawo...@sbcglobal.net> wrote:
> I recently received an inquiry from a colleague I have
> not seen in many years.   He is currently in a position
> where he is asked to advise a client about whether to
> choose Ada or C++ for a project.   He is not a language
> junkie because his expertise is a very different level of
> software engineering, but he is a highly intelligent and
> capable consulting engineer.
>
> Perhaps that's why he inquired of me.   :-)
>
> One of the concerns is whether anyone else is choosing to
> use Ada for new projects.   He does not want to be the
> only one to make such a choice.  It is well-known that
> there are a lot of Ada software products being maintained,
> but is anyone choosing it for new projects?   Good question,
> I answer.
>
> So. What do I tell him?   At one time, I could contact the
> AJPO and ask this question.   Although they were never
> very good at providing complete information, they did have
> some knowledge of where Ada was being used for new
> projects.   Now, there is no place to look for that information.
>
> It presents a little dilemma.   If no one else is using Ada for
> new projects, he can wonder why he should be the alone
> in his decision.    If every other consultant, manager, or
> program director asks the same question, and gets no
> information about others choosing Ada, no one will want
> to make that choice.
>
> Is anyone choosing Ada for new projects?  What kind of
> projects?   Can we collect information about them and
> create a catalog of them in the adaic.com website?    If
> not, why not?
>
> The compiler publishers know who is buying their compilers,
> but they don't want to compromise customer confidentiality.
> The programmers are afraid of losing their jobs if they tell
> anyone what they are doing.  Everyone who can provide the
> information is afraid to do so.   When I was actively consulting
> on Ada, I was often told, by my client, not to tell anyone they
> were using Ada.   So.  We keep the secret.    The secret keeps
> Ada a secret.    And Ada begins to wane because no one
> wants to reveal their decision to use it.
>
> Is this a recipe for killing any incentive for choosing the language
> for future projects?   What do I tell my old friend?   Should he
> take the risk of using Ada even without the knowledge that anyone
> else is using it for real projects?    Hmmmmm.   Is anyone out there
> really choosing it for new software projects?
>
> Richard Riehle

Re: An Ada Advice Inquiry

[tmoran]

> The compiler publishers know who is buying their compilers,
  I don't know if it would be considered a compiler company, but Praxis
seems to be actively developing new reliability tools with Ada, I presume
for new developments, and they seem willing to be public.

Re: An Ada Advice Inquiry

[Randy Brukardt]

<tmoran@acm.org> wrote in message
news:592dnbDWOqzXLqfbnZ2dnUVZ_h-vnZ2d@comcast.com...
> > The compiler publishers know who is buying their compilers,
>   I don't know if it would be considered a compiler company, but Praxis
> seems to be actively developing new reliability tools with Ada, I presume
> for new developments, and they seem willing to be public.

Speaking of Praxis, they just had an announcement on a new air traffic
control system (in the UK) that is programmed in Ada. You can find a link to
it on the news page at www.adaic.com (it's too late for me to go look it up
right now).

                               Randy.

Re: An Ada Advice Inquiry

[roderick.chapman]

On May 4, 6:47 am, "Randy Brukardt" <r...@rrsoftware.com> wrote:
> Speaking of Praxis, they just had an announcement on a new air traffic
> control system (in the UK) that is programmed in Ada.

Indeed - iFacts is very large, new, and using Ada (and SPARK of
course...)
Check out out press release here:
  http://www.praxis-his.com/news/radarMar2007.asp

We _won_ this project by bidding Correctness by Construction, Formal
Methods,
Ada, SPARK etc. etc, against some very stuff competition.
 - Rod

Re: An Ada Advice Inquiry

[adaworks]

Rod,

Thanks.

Richard
<roderick.chapman@googlemail.com> wrote in message 
news:1178268426.023944.289630@l77g2000hsb.googlegroups.com...
> On May 4, 6:47 am, "Randy Brukardt" <r...@rrsoftware.com> wrote:
>> Speaking of Praxis, they just had an announcement on a new air traffic
>> control system (in the UK) that is programmed in Ada.
>
> Indeed - iFacts is very large, new, and using Ada (and SPARK of
> course...)
> Check out out press release here:
>  http://www.praxis-his.com/news/radarMar2007.asp
>
> We _won_ this project by bidding Correctness by Construction, Formal
> Methods,
> Ada, SPARK etc. etc, against some very stuff competition.
> - Rod
> 

Re: An Ada Advice Inquiry

[Fionn Mac Cumhaill]

On Fri, 4 May 2007 04:17:05 -0800, <adaworks@sbcglobal.net> wrote:

>Rod,
>
>Thanks.
>
>Richard
><roderick.chapman@googlemail.com> wrote in message 
>news:1178268426.023944.289630@l77g2000hsb.googlegroups.com...
>> On May 4, 6:47 am, "Randy Brukardt" <r...@rrsoftware.com> wrote:
>>> Speaking of Praxis, they just had an announcement on a new air traffic
>>> control system (in the UK) that is programmed in Ada.
>>
>> Indeed - iFacts is very large, new, and using Ada (and SPARK of
>> course...)
>> Check out out press release here:
>>  http://www.praxis-his.com/news/radarMar2007.asp
>>
>> We _won_ this project by bidding Correctness by Construction, Formal
>> Methods,
>> Ada, SPARK etc. etc, against some very stuff competition.
>> - Rod
>> 
>

I just started a new project where I work, and I'm using Ada. It's
about as different from an air traffic control system as you can get.
I'm going to be using Ada to interrogate a MySQL database and push the
resulting reports to a web server on our in-house network. I'm running
a 2-person shop, and the other guy only does Crystal Reports, so I
need all the help I can get from my programming language. I don't want
to waste time and effort on fighting both C and SQL. Ada and I can
gang up on SQL and beat it into submission.

Re: An Ada Advice Inquiry

[Maciej Sobczak]

On 5 Maj, 04:35, Fionn Mac Cumhaill <invisi...@hiding.from.spam>
wrote:

> I don't want
> to waste time and effort on fighting both C and SQL.

In what way is Ada superior in the context of accessing SQL databases?

--
Maciej Sobczak
http://www.msobczak.com/

Re: An Ada Advice Inquiry

[Sloan.Kohler]

Also see http://www.praxis-his.com/sparkada/pdfs/praxis_rockwell_final_pr.pdf
for another relatively new SPARK Ada project.

-- Sloan

Re: An Ada Advice Inquiry

[adaworks]

Excellent!

Also, I have begun to receive email about Ada projects
from people who are using it.  I will need to respect
confidentiality, but it is helpful.

Richard
===================================
"Randy Brukardt" <randy@rrsoftware.com> wrote in message 
news:f1eh8r$8o9$1@jacob-sparre.dk...
> <tmoran@acm.org> wrote in message
> news:592dnbDWOqzXLqfbnZ2dnUVZ_h-vnZ2d@comcast.com...
>> > The compiler publishers know who is buying their compilers,
>>   I don't know if it would be considered a compiler company, but Praxis
>> seems to be actively developing new reliability tools with Ada, I presume
>> for new developments, and they seem willing to be public.
>
> Speaking of Praxis, they just had an announcement on a new air traffic
> control system (in the UK) that is programmed in Ada. You can find a link to
> it on the news page at www.adaic.com (it's too late for me to go look it up
> right now).
>
>                               Randy.
>
> 

Re: An Ada Advice Inquiry

[Jeffrey R. Carter]

adaworks@sbcglobal.net wrote:
 >
 > Perhaps that's why he inquired of me.   :-)

I'm sure it is.

I'm working for a fairly new, small company on its only, and new, 
project, in Ada, of course.

-- 
Jeff Carter
"Mr. President, we must not allow a mine-shaft gap!"
Dr. Strangelove
33

Re: An Ada Advice Inquiry

[Maciej Sobczak]

On 4 Maj, 05:01, <adawo...@sbcglobal.net> wrote:
> I recently received an inquiry from a colleague I have
> not seen in many years.   He is currently in a position
> where he is asked to advise a client about whether to
> choose Ada or C++ for a project.

Good question.

> He is not a language
> junkie

And it would be very bad if his decisions were made on such
foundations only (I assume the project is not a home-made-just-for-fun
project).
His concerns should be (arbitrary order):

1. Objective of the project.
2. Availability of tools (+price).
3. Availability of workforce (+their price).
4. Cost of training, if necessary.
5. Community support (yes, it's much more important than the support
from vendors).
6. History of previuos projects.
7. Opportunity for reuse of stuff that already exists.
...

And so on.

> Is anyone choosing Ada for new projects?

Not where I work (CERN - at least I can be public with it, there are
no stupid secrets here), which is telling something. If you cannot get
Ada rolling in the nuclear research facility, then in my opinion it's
quite strong argument that the subject is "not easy".

I think that there are only two types of teams where Ada can be
successful:

1. Small team of dedicated junkies (no training cost, etc.) that have
enough energy to reinvent the necessary wheels. They will succeed,
because with the level of competence that such junkies already have
they can succeed with anything, anyway.

2. Larger and already established teams with proven history of
successful Ada projects. Such a team has enough inertia to plow over
any potential problem. And of course, they have already reinvented all
the wheels while working on previous projects, which is a big bonus.

In other words: if you don't have only dedicated Ada junkies on board
and this is a new project, Ada is not the best choice.

--
Maciej Sobczak
http://www.msobczak.com/

Re: An Ada Advice Inquiry

[Dmitry A. Kazakov]

On 4 May 2007 01:04:24 -0700, Maciej Sobczak wrote:

> In other words: if you don't have only dedicated Ada junkies on board
> and this is a new project, Ada is not the best choice.

Which is a universally true statement. All work in the world is done by
dedicated junkies...

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

Re: An Ada Advice Inquiry

[Ludovic Brenta]

At Barco Avionics, all our products use Ada: both the ones we evolve
from existing ones, and the new ones.  We have no plans to change
that.

The web site, unfortunately, doesn't tout that:
http://www.barco.com/aerospace/

-- 
Ludovic Brenta.

AW: An Ada Advice Inquiry

[Grein, Christoph (Fa. ESG)]

Nice to hear. I guess these CDUs are the ones that are used in Tiger
H/C.

Von: comp.lang.ada-bounces@ada-france.org
[mailto:comp.lang.ada-bounces@ada-france.org] Im Auftrag von Ludovic
Brenta

At Barco Avionics, all our products use Ada: both the ones we evolve
from existing ones, and the new ones.  We have no plans to change
that.


Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt

CONFIDENTIALITY NOTICE 

This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. 
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. 
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message. 

Re: AW: An Ada Advice Inquiry

[Ludovic Brenta]

Christoph Grein writes:
> Nice to hear. I guess these CDUs are the ones that are used in Tiger
> H/C.

Yes.  That's one of our first products, we call it the CDMS-1TG, and
most of it is programmed in Ada (there is also some C in the keyboard
microcontroller).

-- 
Ludovic Brenta.

Re: An Ada Advice Inquiry

[adaworks]

Chris,

Can I infer, from your reply, that Eurocopter is also
using Ada?

Richard
========================================
"Grein, Christoph (Fa. ESG)" <Christoph.Grein@eurocopter.com> wrote in message 
news:mailman.138.1178276753.18371.comp.lang.ada@ada-france.org...
> Nice to hear. I guess these CDUs are the ones that are used in Tiger
> H/C.
>
> Von: comp.lang.ada-bounces@ada-france.org
> [mailto:comp.lang.ada-bounces@ada-france.org] Im Auftrag von Ludovic
> Brenta
>
> At Barco Avionics, all our products use Ada: both the ones we evolve
> from existing ones, and the new ones.  We have no plans to change
> that.
>
>
> Eurocopter Deutschland GmbH
> Sitz der Gesellschaft/Registered Office: Donauwoerth
> Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
> Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz 
> Bertling
> Geschaeftsfuehrung/Board of Management:
> Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf 
> Barnscheidt
>
> CONFIDENTIALITY NOTICE
>
> This communication and the information it contains is intended for the 
> addressee(s) named above and for no other persons or organizations. It is 
> confidential and may be legally privileged and protected by law. The 
> unauthorized use, copying or disclosure of this communication or any part of 
> it is prohibited and may be unlawful.
> If you have received this communication in error, kindly notify us by return 
> e-mail and discard and/or delete the communication. Thank you very much.
> It is possible for e-mails to be intercepted or affected by viruses. Whilst we 
> maintain virus checks on our e-mails, we accept no liability for viruses or 
> other material which might be introduced with this message. 

AW: An Ada Advice Inquiry

[Grein, Christoph (Fa. ESG)]

For Tiger, NH90, two different flight simulators for Tiger (delivered) and a new simulator for NH90.

Christoph


Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt

CONFIDENTIALITY NOTICE 

This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. 
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. 
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message. 
-----Ursprüngliche Nachricht-----
Von: Richard

Chris,

Can I infer, from your reply, that Eurocopter is also
using Ada?

Re: An Ada Advice Inquiry

[adaworks]

Ludovic,

Thanks.   That is very helpful.

Richard

======================================
"Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message 
news:874pmtj6qk.fsf@ludovic-brenta.org...
> At Barco Avionics, all our products use Ada: both the ones we evolve
> from existing ones, and the new ones.  We have no plans to change
> that.
>
> The web site, unfortunately, doesn't tout that:
> http://www.barco.com/aerospace/
>
> -- 
> Ludovic Brenta. 

Re: An Ada Advice Inquiry

[Markus E Leypold]

<adaworks@sbcglobal.net> writes:

> Is anyone out there really choosing it for new software projects?

Me. (And I'm not talking about hobbyist stuff).

Regards -- Markus

Re: An Ada Advice Inquiry

[adaworks]

"Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
wrote in message news:8x4pmtndtj.fsf@hod.lan.m-e-leypold.de...
>
> <adaworks@sbcglobal.net> writes:
>
>> Is anyone out there really choosing it for new software projects?
>
> Me. (And I'm not talking about hobbyist stuff).
>
Any chance of details?   I realize that there is often an issue
of confidentiality, so I don't want to ask you compromise
that.    However, some general information would be helpful.

Thanks.

Richard Riehle 

Re: An Ada Advice Inquiry

[Markus E Leypold]

<adaworks@sbcglobal.net> writes:

> "Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
> wrote in message news:8x4pmtndtj.fsf@hod.lan.m-e-leypold.de...
>>
>> <adaworks@sbcglobal.net> writes:
>>
>>> Is anyone out there really choosing it for new software projects?
>>
>> Me. (And I'm not talking about hobbyist stuff).
>>
> Any chance of details?   I realize that there is often an issue
> of confidentiality, so I don't want to ask you compromise
> that.    However, some general information would be helpful.

I'll consider it. It's not so much confidentiality, but rather the
point that I've not made the best experiences with using Ada for that
kind of program (or mentioning Ada when bidding on a contract). Part
of my suggestions in c.l.a. that Ada hast lost its ecological niche
stem from considerations what could have gone better with that
project.

But as soon as I go into talking about that, people here will come and
try to disprove me, forcing me to go deeper and deeper into details --
and at the same time opening myself up to allegations (a) that I
wouldn't know Ada good enough, (b) that my process would be all wrong
and (c) that I wouldn't know my tools -- allegations that can never be
disproved in usenet and are rather hurtful to what I consider my
professional standing.

So I'll think about it, but I don't care to brand my product as a
failure (it works very well for my customer, though).

By the way, the same applies to any attempt "to discuss" anything on
usenet: I can hardly argue, i.e. that C++ is inferior, w/o being
accused by somebody (typically Hyman Rosen) that I don't have a clue
and that I would be "confused".

Then, next time I know, a prospective client for a C++ project will
google for me and find those postings: And guess what -- the attitude
will not be one of "he knows what he's talking about, so he sees the
disadvantages of C++", but rather "he seems to have a problem with X,
so probably he's not the best man for this project".

As honourable as your attempt to gather information via usenet is: I
doubt you get significant data this way: I gues it is rather risky for
anyone with a professional reputation to loose, to participate in
discussions of the merits or dismerits of languages or operating
systems (except perhaps by really researching some kind of scientific
study with enough sources to bolster any claim, but then usenet is not
the audience to publish it).

(And against the trolls you always end with egg in your face anyway,
 since they got more time and never commit to a single claim that
 could be proven, disproven or even discussed to the end in a
 scholastic manner. The "but-what-about" style of argument is rather
 typical for that.)

Don't hesitate to write to me by personal mail, if you want to get
some more information on the project in question, but I'll almost
certainly ask for confidentiality in that case, not for the clients
sake, but for my own.

Regards -- Markus

Re: An Ada Advice Inquiry

[xavier]

Hi,

I'm working in a research physic laboratory. We use Ada for our new 
acquisition system (Narval). The system is a set of process coordinated 
at low speed by annex E of Ada 95. For hight speed data transfert we use 
socket and unix fifo.

At the start of the project only our local particule accelerator used 
it, but now we have the responsibility of the data flow of an european 
detector named AGATA (220 Kg of very pure germanium, 180 detectors, 7000 
channels). The system will have to handle about 13,5 GBytes/s out of the 
electronics boards down to many CPU farms, the system will have to 
process them and store data at 100 MBytes/s. Others physic teams also 
use it now for their experiments.

If somebody wants more information just email me.

Cordially, xavier grave
PS: I also work on an OS written in Ada, but this is for fun, not (for 
the moment :) ) a project supported by my laboratory.

Re: An Ada Advice Inquiry

[Maciej Sobczak]

On 4 Maj, 11:52, xavier <xav...@ipnnarval.in2p3.fr> wrote:

> I'm working in a research physic laboratory. We use Ada

It's good to know that some European physics facility uses Ada -
that's an interesting point to make.
Greetings from CERN.

> If somebody wants more information just email me.

Sure. :-)

--
Maciej Sobczak
http://www.msobczak.com/

Re: An Ada Advice Inquiry

[adaworks]

Xavier,

Thank you.  This is also very helpful.

Richard
===================================
"xavier" <xavier@ipnnarval.in2p3.fr> wrote in message 
news:463B027A.5040009@ipnnarval.in2p3.fr...
> Hi,
>
> I'm working in a research physic laboratory. We use Ada for our new 
> acquisition system (Narval). The system is a set of process coordinated at low 
> speed by annex E of Ada 95. For hight speed data transfert we use socket and 
> unix fifo.
>
> At the start of the project only our local particule accelerator used it, but 
> now we have the responsibility of the data flow of an european detector named 
> AGATA (220 Kg of very pure germanium, 180 detectors, 7000 channels). The 
> system will have to handle about 13,5 GBytes/s out of the electronics boards 
> down to many CPU farms, the system will have to process them and store data at 
> 100 MBytes/s. Others physic teams also use it now for their experiments.
>
> If somebody wants more information just email me.
>
> Cordially, xavier grave
> PS: I also work on an OS written in Ada, but this is for fun, not (for the 
> moment :) ) a project supported by my laboratory. 

Re: An Ada Advice Inquiry

[Stephen Leake]

<adaworks@sbcglobal.net> writes:

> One of the concerns is whether anyone else is choosing to
> use Ada for new projects.   He does not want to be the
> only one to make such a choice.  It is well-known that
> there are a lot of Ada software products being maintained,
> but is anyone choosing it for new projects?   Good question,
> I answer.

Why is this a concern?

I can understand needing to be able to rely on Ada compilers/tools
being available in the future, and on being able to find people
trained in Ada.

It might be that those correlate with new projects.

But as you point out, it is difficult to tell if there are new
projects being started in Ada. Is it easier to tell if there are new
projects being started in C++?

I don't think the information in either case is exhaustive or
reliable.

Ada is clearly a better language; I routinely get a factor of 2-4 in
productivity improvement in Ada vs C++. So for me, the choice of C++
vs Ada should only be made on the quality of support from the compiler
company, and the quality of available third-party packages that will
be useful in your particular projects.

User feedback on compiler companies would be a good measure. Any
compiler company should be willing to provide that.

Getting an evaluation copy of a compiler, and using the associated
customer support for a trial project, is the best way to evaluate a
company.

Surveying available third party packages is harder. I have not even
tried in my field; hard real-time satellite simulation.

-- 
-- Stephe

Re: An Ada Advice Inquiry

[adaworks]

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
news:uabwku1tj.fsf@stephe-leake.org...
> <adaworks@sbcglobal.net> writes:
>
>> One of the concerns is whether anyone else is choosing to
>> use Ada for new projects.   He does not want to be the
>> only one to make such a choice.  It is well-known that
>> there are a lot of Ada software products being maintained,
>> but is anyone choosing it for new projects?   Good question,
>> I answer.
>
> Why is this a concern?
>
It is a concern because of the appearance of diminishing usage
of the language.  He sees C++ magazines, books, articles, and
information without even seeking it.   As noted in another thread,
the Cohen book  is out-of-print and will not be reprinted or
updated.    Few other books are available for the new Ada,
at this writing

Anyone who wants to start a new project also wants to know that
there is going to be support over the long haul.

> I can understand needing to be able to rely on Ada compilers/tools
> being available in the future, and on being able to find people
> trained in Ada.
>
> Surveying available third party packages is harder. I have not even
> tried in my field; hard real-time satellite simulation.
>
Is your organization creating satellite software in Ada?  Are you at
liberty to identify what company you are with and what kind of
satellites you are developing using Ada for the software?

I need to prepare my reply to my colleague today, but I can always
send follow-up information early next week.

Richard 

Re: An Ada Advice Inquiry

[Pascal Obry]

adaworks@sbcglobal.net a �crit :
> "Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
> news:uabwku1tj.fsf@stephe-leake.org...
>> <adaworks@sbcglobal.net> writes:
>>
>>> One of the concerns is whether anyone else is choosing to
>>> use Ada for new projects.   He does not want to be the
>>> only one to make such a choice.  It is well-known that
>>> there are a lot of Ada software products being maintained,
>>> but is anyone choosing it for new projects?   Good question,
>>> I answer.
>> Why is this a concern?
>>
> It is a concern because of the appearance of diminishing usage
> of the language.  He sees C++ magazines, books, articles, and

Well that's chicken and eggs problem. Somebody has to start... In fact
with all the responses you get using Ada will just be another new
project using Ada :)

Frankly I 100% agree with Stephen. Ada gives a big advantage against the
concurrence, why not use it just for that. An better question to me
whould be : who is providing compilers, tools and support for Ada? Looks
like the Ada market is fine to me.

Pascal.

-- 

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

Re: An Ada Advice Inquiry

[Michael Bode]

Pascal Obry <pascal@obry.net> writes:

> Frankly I 100% agree with Stephen. Ada gives a big advantage against the
> concurrence, why not use it just for that. An better question to me
> whould be : who is providing compilers, tools and support for Ada? Looks
> like the Ada market is fine to me.

Wanted: affordable cross platform (i.e. Windows + Linux) Ada
development system. No licensing restrictions for software produced
with said development system.

My company will start selling diode lasers with a new touch panel HMI
that was programmed in Ada later this year. It was fun to work on this
project, but I have to use fairly old versions of the compiler & libs
because newer ones are either too expensive or not viable because of
licensing restrictions.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: An Ada Advice Inquiry

[Ed Falis]

> My company will start selling diode lasers with a new touch panel HMI
> that was programmed in Ada later this year. It was fun to work on this
> project, but I have to use fairly old versions of the compiler & libs
> because newer ones are either too expensive or not viable because of
> licensing restrictions.
>

So make your own licensing less restrictive and you won't have that  
problem, will you?

Re: An Ada Advice Inquiry

[Michael Bode]

"Ed Falis" <falis@verizon.net> writes:

> So make your own licensing less restrictive and you won't have that
> problem, will you?

There are two answers to this question: 

a) this is not my decision. I actually like the GPL. But since this is
c.l.a and not soc.free.software I'd say that LGPL would work better to
support the use of Ada.

b) what if I would make my licensing as unrestrictive as the BSD
license?

I really don't want to bash certain compiler vendors. Everyone can do
what he likes: the compiler vendor can choose the licensing as he
likes, the compiler user can buy the licensing scheme he likes and
there's always the possibility to use another language like C[++|#],
Java, what else. 

Since there are threads like this on a regular basis (the last one was
"What's wrong with Ada?" I wonder if there might be a correlation
between the popularity of a language and the tools + licenses it
has. 

I note that the answer to my initial question ("Wanted:...") was not
the name or website of a tools vendor but to change my
requirements. If I would s/Ada/Java/ or s/Ada/C/ in that question, I
bet I'd get a few URLs as a reply.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: An Ada Advice Inquiry

[Markus E Leypold]

Michael Bode <m.g.bode@web.de> writes:

> "Ed Falis" <falis@verizon.net> writes:
>
>> So make your own licensing less restrictive and you won't have that
>> problem, will you?
>
> There are two answers to this question: 

Oh no! Now all of "them" -- the "GPL is more free than BSD", "Think
about the users", "If you don't want GPL, just cough up some K$ and
buy a commercial ...", "If you can't afford it, you're are not to be
taken serious", "how can you expect vendor X to give you HIS TOOLS for
free, if you don't want to give your work for free", "you have another
problem altogether, you should ..." -- will be coming out of the
woodwork again. I'm completely on your side here (and I even would
like to bash certain compiler vendors).

>
> a) this is not my decision. I actually like the GPL. But since this is
> c.l.a and not soc.free.software I'd say that LGPL would work better to
> support the use of Ada.

> b) what if I would make my licensing as unrestrictive as the BSD
> license?

Less free, you know ;-).

> I really don't want to bash certain compiler vendors. Everyone can do
> what he likes: the compiler vendor can choose the licensing as he
> likes, the compiler user can buy the licensing scheme he likes and

And everyone of them has to live with the consequences :-). Some of
them, though, want to have their cake and eat it, like being so
understanding about certain vendors, but at the same time mourn for
the lost future of Ada. 

> there's always the possibility to use another language like C[++|#],
> Java, what else. 

> Since there are threads like this on a regular basis (the last one was
> "What's wrong with Ada?" I wonder if there might be a correlation
> between the popularity of a language and the tools + licenses it
> has. 

Certainly. :-)).

> I note that the answer to my initial question ("Wanted:...") was not
> the name or website of a tools vendor but to change my
> requirements. 

And that is telling. 

> If I would s/Ada/Java/ or s/Ada/C/ in that question, I
> bet I'd get a few URLs as a reply.

...

Regards -- Markus

Re: An Ada Advice Inquiry

[Ed Falis]

On Fri, 04 May 2007 16:22:06 -0400, Michael Bode <m.g.bode@web.de> wrote:

> a) this is not my decision.

So what can I say?  Your decision-makers have a warped view of the  
relative value of their own IP compared to that of others?  I've seen it  
often enough in 30 years in this business, and it generally leads to an  
unsuccessful business outcome because most of us are not all that much  
smarter than each other, and because the same ideas tend to arise all over  
the globe around the same time.  IP is a very illusive and elusive  
competitive advantage (not to mention one of the most risky).

Or do they figure they deserve free beer in their supply chain so they can  
charge Champagne prices to their own customers?  I just don't get the  
mindset.

Re: An Ada Advice Inquiry

[Markus E Leypold]

"Ed Falis" <falis@verizon.net> writes:

> On Fri, 04 May 2007 16:22:06 -0400, Michael Bode <m.g.bode@web.de> wrote:
>
>> a) this is not my decision.
>
> So what can I say?  Your decision-makers have a warped view of the
> relative value of their own IP compared to that of others?  I've seen
> it  often enough in 30 years in this business, and it generally leads
> to an  unsuccessful business outcome because most of us are not all
> that much  smarter than each other, and because the same ideas tend to
> arise all over  the globe around the same time.  IP is a very illusive
> and elusive  competitive advantage (not to mention one of the most
> risky).
>
> Or do they figure they deserve free beer in their supply chain so they
> can  charge Champagne prices to their own customers?  I just don't get
> the  mindset.


They are probably not selling the compiler.

Regards -- Markus

Re: An Ada Advice Inquiry

[Michael Bode]

"Ed Falis" <falis@verizon.net> writes:

> Or do they figure they deserve free beer in their supply chain so they
> can charge Champagne prices to their own customers?  I just don't get
> the  mindset.

That's not the question. The questions is if the merits of Ada
relative to other languages justify the price difference between the
Ada tool set and the tool sets for other languages. 

I have have bit of trouble illustrating this point. Let's say an Ada
tool set with which you can write cross platform CSS code for Linux
and Windows costs you 28_000ￜ. Then compare that to a
Java/C/C++/Python tool set which meets the same requirements. I'd like
to refer to some price lists in the 500ￜ to 1000ￜ range which I would
call 'affordable'. My trouble is I can get all this for 0ￜ.

And if you ask: no, I don't want to write an engine control system for
Eurofighter in Java. I don't want to write one at all. Maybe I'm not
in the right target group for Ada?

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: An Ada Advice Inquiry

[Markus E Leypold]

Michael Bode <m.g.bode@web.de> writes:

> "Ed Falis" <falis@verizon.net> writes:
>
>> Or do they figure they deserve free beer in their supply chain so they
>> can charge Champagne prices to their own customers?  I just don't get
>> the  mindset.
>
> That's not the question. The questions is if the merits of Ada
> relative to other languages justify the price difference between the
> Ada tool set and the tool sets for other languages. 
>
> I have have bit of trouble illustrating this point. Let's say an Ada
> tool set with which you can write cross platform CSS code for Linux
> and Windows costs you 28_000ￜ. Then compare that to a
> Java/C/C++/Python tool set which meets the same requirements. I'd like
> to refer to some price lists in the 500ￜ to 1000ￜ range which I would
> call 'affordable'. My trouble is I can get all this for 0ￜ.
>
> And if you ask: no, I don't want to write an engine control system for
> Eurofighter in Java. I don't want to write one at all. Maybe I'm not
> in the right target group for Ada?

That is the suspicion I've been entertaining for some time. We've been
having so many discussions about why not everybody would be using Ada
etc., but at the end (if there was one) it often boiled down to the
target group question: If you're not doing development for aerospace
or traffic control (where you can afford the prices or the price is
just a tiny part of the overall costs) and/or you're don't have a
higly formal development process (also expensive, so the compiler
price doesn't matter in comparison), you're not in the target group.

If that were so, the of course the answer to "why isn't everybody
using Ada?" is rather easy: Not everybody is developing for aerospace
or defense. 

The factors that made C big and once made Trubo Pascal big where
availability and affordability and a whole generation of programmers
getting socialized into the corresponding toolset. Ada is perhaps not
playing in that league at the moment. In my opinion there is no sense
in mourning for the lost future of Ada, but at the same time being
happy with the rather narrowly circumscribed target group. I've
repeated that often enough, so I think I will stop here.

Regards -- Markus

Re: An Ada Advice Inquiry

[Georg Bauhaus]

On Sat, 2007-05-05 at 11:59 +0200, Michael Bode wrote:

> I have have bit of trouble illustrating this point. Let's say an Ada
> tool set with which you can write cross platform CSS code for Linux
> and Windows costs you 28_000€. Then compare that to a
> Java/C/C++/Python tool set which meets the same requirements. I'd like
> to refer to some price lists in the 500€ to 1000€ range which I would
> call 'affordable'. My trouble is I can get all this for 0€.

Ada's competition doesn't exactly charge 0€ but a little to much
more the moment you buy support. *But*, many Python or Java "buyers"
don't buy support, because it isn't needed for a particular
business case. (You prefer working a few hours around infrequent
implementation bugs because cost(time) < cost(support)).

Enough people have expressed they could live with a next
to no support Ada solution. This matches the typical
Java, C#, or Python case.

A way out for Ada small shops might be to get organized 
and join efforts to become selectable for Ada vendors
on some suitable terms. Not sure if any of the vendors will
like the idea.

Would we have Java used everywhere if SUN charged the same
sums from everyone that larger Ada customers can pay?

Re: An Ada Advice Inquiry

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Sat, 2007-05-05 at 11:59 +0200, Michael Bode wrote:
>
>> I have have bit of trouble illustrating this point. Let's say an Ada
>> tool set with which you can write cross platform CSS code for Linux
>> and Windows costs you 28_000ￜ. Then compare that to a
>> Java/C/C++/Python tool set which meets the same requirements. I'd like
>> to refer to some price lists in the 500ￜ to 1000ￜ range which I would
>> call 'affordable'. My trouble is I can get all this for 0ￜ.
>
> Ada's competition doesn't exactly charge 0ￜ but a little to much
> more the moment you buy support. *But*, many Python or Java "buyers"
> don't buy support, because it isn't needed for a particular
> business case. (You prefer working a few hours around infrequent
> implementation bugs because cost(time) < cost(support)).

Exactly.

The Java version distributed without support is identical to the
version for which you can buy support, though.

> Enough people have expressed they could live with a next
> to no support Ada solution. This matches the typical
> Java, C#, or Python case.


> A way out for Ada small shops might be to get organized 
> and join efforts to become selectable for Ada vendors
> on some suitable terms. 

They could also sponsor FSF Gnat, including development to a stable
baseline.

> Not sure if any of the vendors will like the idea.

No.

> Would we have Java used everywhere if SUN charged the same
> sums from everyone that larger Ada customers can pay?

Regards -- Markus

Re: An Ada Advice Inquiry

[Michael Bode]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> Enough people have expressed they could live with a next
> to no support Ada solution. This matches the typical
> Java, C#, or Python case.

Exactly my point. And this doesn't have to be a 0ￜ solution,
IMHO. Just a version at a less-than-astronomical price with
less-than-stellar support. Just like all the other kids get.

> A way out for Ada small shops might be to get organized 
> and join efforts to become selectable for Ada vendors
> on some suitable terms. Not sure if any of the vendors will
> like the idea.

I doubt it.

> Would we have Java used everywhere if SUN charged the same
> sums from everyone that larger Ada customers can pay?

No way.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: An Ada Advice Inquiry

[Georg Bauhaus]

On Sat, 2007-05-05 at 14:30 +0200, Michael Bode wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:

> > A way out for Ada small shops might be to get organized 
> > and join efforts to become selectable for Ada vendors
> > on some suitable terms. Not sure if any of the vendors will
> > like the idea.
> 
> I doubt it.

Still, I wouldn't dismiss the idea so soon. It might need a small
amount of paper work to get a cooperation going on the
customers' side, and perhaps an informal negotiation
of a probationary period with a vendor. But if this setup turns
out to be viable for both you and the vendor, why not?

I recall that at least one vendor considers the Ada information
flow between employees at the customer site (trivial, repeated
questions can be answered by a knowledgeable Ada person in house);
if this flow of Ada knowledge can be demonstrated to be part
of the cooperation (even though implemented using eMail or some
other form of tele work communication) there might be a business
opportunity for both sides.

Re: An Ada Advice Inquiry

[Michael Bode]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> Still, I wouldn't dismiss the idea so soon. It might need a small
> amount of paper work to get a cooperation going on the
> customers' side, and perhaps an informal negotiation
> of a probationary period with a vendor. But if this setup turns
> out to be viable for both you and the vendor, why not?

You could found a cooperative, buy a commercial GPLed-with-Exception
Compiler and Libs and send copies to every member of the
cooperative. I doubt the vendor would like the idea.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: An Ada Advice Inquiry

[Georg Bauhaus]

On Mon, 2007-05-07 at 20:17 +0200, Michael Bode wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
> > Still, I wouldn't dismiss the idea so soon. It might need a small
> > amount of paper work to get a cooperation going on the
> > customers' side, and perhaps an informal negotiation
> > of a probationary period with a vendor. But if this setup turns
> > out to be viable for both you and the vendor, why not?
> 
> You could found a cooperative, buy a commercial GPLed-with-Exception
> Compiler and Libs and send copies to every member of the
> cooperative. I doubt the vendor would like the idea.

The idea is different. Shops * Programmers >= 5, Shops <= 3,
are interested in an Ada compiler for Windows and Linux.
These prospective customers confirm they won't be bothering
the vendor with questions (just like with MS or with a no-support
use of Python or Java). "To bother" is typically defined
in a conversation between a vendor and a customer.
Representatives of Vendor, and Shops * Programmers put their
names on a contract.

One clause might read something like, "Customer names
One (1) Representative who might ask a question a month.
Vendor will try to answer at Vendor's discretion."
This would be a more than you get from MS, for example.

For a maker of said compilers, it must be reasonable to
sell copies of their product. So

  type Customer is limited private;

must have a reasonable interface and hence includes

  function Trust(ID: Customer) return Positive;
  -- or else no deal

Not that unusual, I'd say, and hence worth a try. You need
to find Shops run by trustworthy personnel.

Re: An Ada Advice Inquiry

[Jeffrey Creem]

Michael Bode wrote:
> Pascal Obry <pascal@obry.net> writes:
> 
>> Frankly I 100% agree with Stephen. Ada gives a big advantage against the
>> concurrence, why not use it just for that. An better question to me
>> whould be : who is providing compilers, tools and support for Ada? Looks
>> like the Ada market is fine to me.
> 
> Wanted: affordable cross platform (i.e. Windows + Linux) Ada
> development system. No licensing restrictions for software produced
> with said development system.
> 
> My company will start selling diode lasers with a new touch panel HMI
> that was programmed in Ada later this year. It was fun to work on this
> project, but I have to use fairly old versions of the compiler & libs
> because newer ones are either too expensive or not viable because of
> licensing restrictions.
> 
Last time I checked it certainly did not seem like the Aonix tools were 
particularly expensive in small quantities.

Re: An Ada Advice Inquiry

[Michael Bode]

Jeffrey Creem <jeff@thecreems.com> writes:

> Last time I checked it certainly did not seem like the Aonix tools
> were particularly expensive in small quantities.

Can I write a cross platform GUI app in ObjectAda? From their data
sheets it seems like they provide Win32, MFC and Java bindings for
Windows and Motif(!) bindings for Linux (as an option).

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: An Ada Advice Inquiry

[Markus E Leypold]

Jeffrey Creem <jeff@thecreems.com> writes:

> Michael Bode wrote:
>> Pascal Obry <pascal@obry.net> writes:
>>
>>> Frankly I 100% agree with Stephen. Ada gives a big advantage against the
>>> concurrence, why not use it just for that. An better question to me
>>> whould be : who is providing compilers, tools and support for Ada? Looks
>>> like the Ada market is fine to me.
>> Wanted: affordable cross platform (i.e. Windows + Linux) Ada
>> development system. No licensing restrictions for software produced
>> with said development system.
>> My company will start selling diode lasers with a new touch panel HMI
>> that was programmed in Ada later this year. It was fun to work on this
>> project, but I have to use fairly old versions of the compiler & libs
>> because newer ones are either too expensive or not viable because of
>> licensing restrictions.
>>
> Last time I checked it certainly did not seem like the Aonix tools
> were particularly expensive in small quantities.

Last time I checked they were to expensive to develop an embedded
appliance with them (in small quantities) and then keep the compiler
around for 10 years for maintainance (which every sane customer will
reuqire). AFAIR they still have that minimum 5 seat clause (a bit much
for the 9 years of maintainance).


Regards -- Markus

Re: An Ada Advice Inquiry

[Jeffrey Creem]

Markus E Leypold wrote:

> Last time I checked they were to expensive to develop an embedded
> appliance with them (in small quantities) and then keep the compiler
> around for 10 years for maintainance (which every sane customer will
> reuqire). AFAIR they still have that minimum 5 seat clause (a bit much
> for the 9 years of maintainance).
> 
> 
> Regards -- Markus
> 
> 

While I agree it is nice to keep maintenance around for that time, this 
is probably another example of the different bar people set when they 
use Ada.

The US Gov't had/has this thing called JTA (Joint Technical 
Architecture) that lists a bunch of standards you sort of have to use.

If you pick Ada, it had to be a certified compiler. If you pick C, it 
(basically) had to be the case that there were some {} in your code 
because that proved you were  using C.

In this case, we will tell people they should/must pay for 9 years of 
maintenance, which will be too expensive. So, the person will go off, 
select (as a contrived example) visual studio 6, not consider 
maintenance and end up with a product which will not be supported 2 
years out.

The whole maintenance thing is largely a sham. I've dealt with a lot of 
compiler (multi language) and OS vendors over the years. Sure in plenty 
of cases I've had bugs that they have solved...But in just about as many 
cases, I've either needed to find a workaround or use either the full 
source code or source code snippets to fix their problems for them and 
then send it back to them so it can appear in a future version.

Just about the worst thing you can do if you really care about long term 
support is pick any tool that requires some automated method for license 
enforcement (dongle, flexlm, etc). 10 years out, you can pretty much bet 
that even if the vendor wanted to support you, they would no longer know 
how and you can end up with a dead tool.

If I were spending money and micromanaging a development contractor, I'd 
be a lot more interested in making sure they pick a tool suite that will 
not fail 100% when the license server dies. Compiler bugs that pop up 
after 5 years of service almost certainly can be worked around...Node 
locked license servers..maybe not.

Re: An Ada Advice Inquiry

[Ed Falis]

On Sat, 05 May 2007 08:41:53 -0400, Jeffrey Creem <jeff@thecreems.com>  
wrote:

> If I were spending money and micromanaging a development contractor, I'd  
> be a lot more interested in making sure they pick a tool suite that will  
> not fail 100% when the license server dies. Compiler bugs that pop up  
> after 5 years of service almost certainly can be worked around...Node  
> locked license servers..maybe not.


I've always felt there must be an especially warm corner in hell reserved  
for the inventor(s) of flexlm.

Re: An Ada Advice Inquiry

[Ludovic Brenta]

Ed Falis writes:
> I've always felt there must be an especially warm corner in hell
> reserved for the inventor(s) of flexlm.

Amen.  What does "flex" LM mean anyway?  If it's a joke, I'm not
amused.

-- 
Ludovic Brenta.

Re: An Ada Advice Inquiry

[Michael Bode]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Ed Falis writes:
>> I've always felt there must be an especially warm corner in hell
>> reserved for the inventor(s) of flexlm.
>
> Amen.  What does "flex" LM mean anyway?  If it's a joke, I'm not
> amused.

Have you ever had the displeasure to use the Siemens authorisation
software AuthorsW? We have been advised to disable the virus checker
on all machines running Siemens software because the Siemens
authorisation software could die in the presence of a virus checker
and take our licenses with it. This happened already once.

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: An Ada Advice Inquiry

[Ludovic Brenta]

Michael Bode writes:
> Ludovic Brenta writes:
>
>> Ed Falis writes:
>>> I've always felt there must be an especially warm corner in hell
>>> reserved for the inventor(s) of flexlm.
>>
>> Amen.  What does "flex" LM mean anyway?  If it's a joke, I'm not
>> amused.
>
> Have you ever had the displeasure to use the Siemens authorisation
> software AuthorsW? We have been advised to disable the virus checker
> on all machines running Siemens software because the Siemens
> authorisation software could die in the presence of a virus checker
> and take our licenses with it. This happened already once.

Luckily, most of the software I use is on Unix, where no virus
checkers are necessary for lack of viruses.

What horrendous sins did you do to deserve running such software on
(gasp) Windows?

-- 
Ludovic Brenta.

Re: An Ada Advice Inquiry

[Michael Bode]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> What horrendous sins did you do to deserve running such software on
> (gasp) Windows?

Using Ada to supersede at least part of that software :-)

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

Re: An Ada Advice Inquiry

[Ed Falis]

On Sat, 05 May 2007 09:31:20 -0400, Ludovic Brenta  
<ludovic@ludovic-brenta.org> wrote:

> Ed Falis writes:
>> I've always felt there must be an especially warm corner in hell
>> reserved for the inventor(s) of flexlm.
>
> Amen.  What does "flex" LM mean anyway?  If it's a joke, I'm not
> amused.
>

Flexible License Manager - the bane of tech support and customers  
everywhere.  ;-)

Re: An Ada Advice Inquiry

[Markus E Leypold]

"Ed Falis" <falis@verizon.net> writes:

> On Sat, 05 May 2007 09:31:20 -0400, Ludovic Brenta
> <ludovic@ludovic-brenta.org> wrote:
>
>> Ed Falis writes:
>>> I've always felt there must be an especially warm corner in hell
>>> reserved for the inventor(s) of flexlm.
>>
>> Amen.  What does "flex" LM mean anyway?  If it's a joke, I'm not
>> amused.
>>
>
> Flexible License Manager - the bane of tech support and customers
> everywhere.  ;-)

What, what, what. It's creating employment opportunities! Nothing to
spit upon these days!

(It's more the bane of those paying for the tech support :-).

Regards -- Markus

Re: An Ada Advice Inquiry

[Markus E Leypold]

"Ed Falis" <falis@verizon.net> writes:

> On Sat, 05 May 2007 08:41:53 -0400, Jeffrey Creem <jeff@thecreems.com>
> wrote:
>
>> If I were spending money and micromanaging a development contractor,
>> I'd  be a lot more interested in making sure they pick a tool suite
>> that will  not fail 100% when the license server dies. Compiler bugs
>> that pop up  after 5 years of service almost certainly can be worked
>> around...Node  locked license servers..maybe not.
>
>
> I've always felt there must be an especially warm corner in hell
> reserved  for the inventor(s) of flexlm.

But, excuse me, the flexlm user are only protecting their rights and
the flexlm developers are only serving a market. And it's a ethically
rather less contested market than the defense industry, which has a
good press here :-|.

It's not that you don't know beforehand when you're buying software
which is being "managed" with flexlm. 

Regards -- Markus

Re: An Ada Advice Inquiry

[Ed Falis]

On Sat, 05 May 2007 10:13:51 -0400, Markus E Leypold  
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote:

> It's not that you don't know beforehand when you're buying software
> which is being "managed" with flexlm.

"Wah-Wah ..."

- G. Harrison

Re: An Ada Advice Inquiry

[Markus E Leypold]

Jeffrey Creem <jeff@thecreems.com> writes:

> Markus E Leypold wrote:
>
>> Last time I checked they were to expensive to develop an embedded
>> appliance with them (in small quantities) and then keep the compiler
>> around for 10 years for maintainance (which every sane customer will
>> reuqire). AFAIR they still have that minimum 5 seat clause (a bit much
>> for the 9 years of maintainance).
>> Regards -- Markus
>>
>
> While I agree it is nice to keep maintenance around for that time,
> this is probably another example of the different bar people set when
> they use Ada.

No. not really. If you develop bespoke software, you'll gave to give
some amount of maintenance afterwards regardless of the language. For
one thing, the customer will demand some commitment how long you'll
fix bugs and how long you'll support him when migrating to new
versions of his platform (i.e. from Win 2000 to Vista). In most
jurisdictions you also cannot avoid to give some kind of warranty
(i.e. if the software stops working after some time because there is a
bug in the database index handling, you're for it: Fix it, or pay
somebody else fixing it for your customers. You can get sued for
this). 10 years is an intervall you better plan for and often demanded
by customers, because they themselves base products (or production of
products) on the software and expect you software to work for the time
they are building that product line.

Usually the level of (badly paid) maintenance activity will drop some
time after deploying the software in question. With many languages
just keeping the development infrastructure available is not very
expensive. It is with Ada.

<...>

> In this case, we will tell people they should/must pay for 9 years of
> maintenance, which will be too expensive. So, the person will go off,
> select (as a contrived example) visual studio 6, not consider
> maintenance and end up with a product which will not be supported 2
> years out.

Well -- that's why I never would select vs6. I'd select a command line
compiler and a traditional make based system for maintenance, because
that is much more probable to stay around for some time and because it
suffices for re-building the program. Furthermore migrating from one
C-compiler to another is not trivial, but it can be done. One should
always keep a fallback option (and that also applies to libraries
which opens a whole other can of worms).

> The whole maintenance thing is largely a sham. I've dealt with a lot
> of compiler (multi language) and OS vendors over the years. Sure in

I don't care wether it's a sham. What counts, is, how much will it
cost to me to have a compiler of that kind on a then-current platform
5 years in the future (like Vista 2012 :-). As an example:

  - Gcc => will it run on Vista 2012? Certainly. There has been much
    commitment of that kind in the past and I'll expect it to continue
    in the future. As an emergency fallback I can always buy a C
    compiler from MS, Borland or Comeau.

  - Similar arguments could be made for Java: I've always had the
    choice of at least 2-3 distributions on every platform.

  - Gnat => Well -- there is the sad history of the public releases
    from ACT and then there is FSF Gnat (integrated in Gcc). FSF Gnat
    has not really taken off in the last 2 years, so there is a risk
    it will not be around in 2012. The GPL releases from AdaCore are
    not identical to what they serve to paying customers and seem to
    be rather more beta. So the only certain choice will be to shell
    out 1x000 a year. Aonix will not be a fallback, since libraries
    written for Gnat won't compile with Aonix (GtkAda AFAIR, perhaps
    that changed).

What does look more reliable to you and which choice would incur the
most financial risk WRT the costs of maintenance?

> plenty of cases I've had bugs that they have solved...But in just
> about as many cases, I've either needed to find a workaround or use
> either the full source code or source code snippets to fix their
> problems for them and then send it back to them so it can appear in a
> future version.

It always struck me as strange that you have to PAY a product vendor
just for being allowed to report them their bugs.

> Just about the worst thing you can do if you really care about long
> term support is pick any tool that requires some automated method for
> license enforcement (dongle, flexlm, etc). 10 years out, you can
> pretty much bet that even if the vendor wanted to support you, they
> would no longer know how and you can end up with a dead tool.

Yes, I know. I (that is, my customer) have already had this kind of
experience (and it sucks the more, the cheaper the tool was at the
beginning).

> If I were spending money and micromanaging a development contractor,
> I'd be a lot more interested in making sure they pick a tool suite
> that will not fail 100% when the license server dies. 

> Compiler bugs that pop up after 5 years of service almost certainly
> can be worked around...Node locked license servers..maybe not.

I completely agree. Still, the development (maintenance) environment
also is a moving target, so if the customer comes in 5 years from now
and wants a binary that runs on Windows Vista 2012 and the Gnat
tasking runtime has this little bug which makes it fail utterly on the
massively parallel multicore processors of the next decade (or
whatever), what do you do then? Generally speaking, one doesn't need a
tool that not only runs in 5 years from now, but a tool which runs on
the then-current platforms.

Regards -- Markus

Re: An Ada Advice Inquiry

[adaworks]

Michael,

Wow!  Sounds great.

For some reason we don't hear enough about these on-going
successes in Ada.

Good luck in your coming sales cycle.

Richard
===============================================
"Michael Bode" <m.g.bode@web.de> wrote in message news:f1g0f1$jot$1@online.de...
> Pascal Obry <pascal@obry.net> writes:
>
>> Frankly I 100% agree with Stephen. Ada gives a big advantage against the
>> concurrence, why not use it just for that. An better question to me
>> whould be : who is providing compilers, tools and support for Ada? Looks
>> like the Ada market is fine to me.
>
> Wanted: affordable cross platform (i.e. Windows + Linux) Ada
> development system. No licensing restrictions for software produced
> with said development system.
>
> My company will start selling diode lasers with a new touch panel HMI
> that was programmed in Ada later this year. It was fun to work on this
> project, but I have to use fairly old versions of the compiler & libs
> because newer ones are either too expensive or not viable because of
> licensing restrictions.
>
> -- 
> No intelligent man has any respect for an unjust law.
> He simply follows the eleventh commandment.
> -- R.A. Heinlein 

Re: An Ada Advice Inquiry

[Stephen Leake]

Michael Bode <m.g.bode@web.de> writes:

> Pascal Obry <pascal@obry.net> writes:
>
>> Frankly I 100% agree with Stephen. Ada gives a big advantage against the
>> concurrence, why not use it just for that. An better question to me
>> whould be : who is providing compilers, tools and support for Ada? Looks
>> like the Ada market is fine to me.
>
> Wanted: affordable cross platform (i.e. Windows + Linux) Ada
> development system. No licensing restrictions for software produced
> with said development system.

You need to better define "affordable". I'm assuming from tone of
later posts that the GNAT Professional fee is "not affordable". But
for my project, that is easily affordable.

-- 
-- Stephe

Re: An Ada Advice Inquiry

[Michael Bode]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> You need to better define "affordable". I'm assuming from tone of
> later posts that the GNAT Professional fee is "not affordable". But
> for my project, that is easily affordable.

Unfortunately we don't have NASA's budget. My definition of
"affordable" would be comparable to the price of other commercial
development tools for typical desktop PC software. Think Visual
Studio, Delphi, or even LabView. I don't even ask for "comparable to
the price of Sun JDK + Netbeans".

-- 
No intelligent man has any respect for an unjust law. 
He simply follows the eleventh commandment.
-- R.A. Heinlein

GNAT Professional machine code listings (was: An Ada Advice Inquiry)

[Larry Kilgallen]

In article <uwszmygs0.fsf@stephe-leake.org>, Stephen Leake <stephen_leake@stephe-leake.org> writes:
> Michael Bode <m.g.bode@web.de> writes:
> 
>> Pascal Obry <pascal@obry.net> writes:
>>
>>> Frankly I 100% agree with Stephen. Ada gives a big advantage against the
>>> concurrence, why not use it just for that. An better question to me
>>> whould be : who is providing compilers, tools and support for Ada? Looks
>>> like the Ada market is fine to me.
>>
>> Wanted: affordable cross platform (i.e. Windows + Linux) Ada
>> development system. No licensing restrictions for software produced
>> with said development system.
> 
> You need to better define "affordable". I'm assuming from tone of
> later posts that the GNAT Professional fee is "not affordable". But
> for my project, that is easily affordable.

The last I read in this newsgroup. ACT was inexorably opposed to the
generation of machine code listing files.  For us this makes their
offering a non-starter.  We need to be able to have a customer for
our commercial product send back a stack dump from a production release
of the software.  Then we need to be able to use that information to
see exactly which instruction went south.  That makes GNAT Pro
a non-starter as I see it.

Yes, it is extremely rare for something to go wrong in this fashion
with software written in Ada, but when/if it does we need to be able
to address the problem without asking the customer for too many details
about their environment (for which they may be quite secretive).

As an example of an unanticipated problem in our Ada code, some
sites turn out to have mistakenly converted an indexed file to a
sequential file.  When our Ada software tried to read that file
according to the index things went South.  Fixing the software
to give a clear message in that case is straightforward.  Getting
sufficient information back from the customer (and in some cases
through their official information release process) can be quite
a problem, so having the exact addresses of instructions in the
code for the version they are running is crucial.

Re: GNAT Professional machine code listings

[Simon Wright]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> The last I read in this newsgroup. ACT was inexorably opposed to the
> generation of machine code listing files.  For us this makes their
> offering a non-starter.  We need to be able to have a customer for
> our commercial product send back a stack dump from a production
> release of the software.  Then we need to be able to use that
> information to see exactly which instruction went south.  That makes
> GNAT Pro a non-starter as I see it.

A colleague in a similar situation (and more used to deep tracing than
I've had to be) had a lot of success using a disassembly (via objdump,
I think) of a GNAT powerpc-wrs-vxworks executable. The code we supply
is stripped (objcopy --strip-debug, I think) but so long as we keep
the unstripped executable all is well!

His problem was to determine exactly which component of a record
assignment was causing the Constraint_Error.

But in any case you have always been able to generate machine code
listings using the -S flag. OK, the .s files end up in the library
where the .o files would normally go, which can be confusing! (this is
with GNAT 3.16a1, don't know what later versions do).

Re: GNAT Professional machine code listings (was: An Ada Advice Inquiry)

[adaworks]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message 
news:vFqGwaGsZMZN@eisner.encompasserve.org...
>
> The last I read in this newsgroup. ACT was inexorably opposed to the
> generation of machine code listing files.  For us this makes their
> offering a non-starter.  We need to be able to have a customer for
> our commercial product send back a stack dump from a production release
> of the software.  Then we need to be able to use that information to
> see exactly which instruction went south.  That makes GNAT Pro
> a non-starter as I see it.
>
I remember the HP 64000 (now probably obsolete) that allowed us
to emulate the MIL-STD 1750 at the instruction set level. We could
watch the entire program run side-by-side with the source code and
traceback from breakpoints.   This allowed detailed inspection of
the code at a very detailed level.    I think inspection is still a good
approach for at least part of the program evaluation process.  For
embedded systems, such as those on the 1750, it was especially
helpful.

I still like to be able to see the underlying executable in at least
an Assembler format.    I recall that the TLD compiler allowed
this, as well.   Hmmmmmm.  TLD.   Does anyone remember
Terry Dunbar and his compiler for the 1750?

Richard Riehle 

Re: An Ada Advice Inquiry

[Jeffrey Creem]

adaworks@sbcglobal.net wrote:
> "Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
> news:uabwku1tj.fsf@stephe-leake.org...
>> <adaworks@sbcglobal.net> writes:
>>
>>> One of the concerns is whether anyone else is choosing to
>>> use Ada for new projects.   He does not want to be the
>>> only one to make such a choice.  It is well-known that
>>> there are a lot of Ada software products being maintained,
>>> but is anyone choosing it for new projects?   Good question,
>>> I answer.
>> Why is this a concern?
>>
> It is a concern because of the appearance of diminishing usage
> of the language.  He sees C++ magazines, books, articles, and
> information without even seeking it.   As noted in another thread,
> the Cohen book  is out-of-print and will not be reprinted or
> updated.    Few other books are available for the new Ada,
> at this writing
> 

It is a valid concern but as I like to point out, I believe C++ as 
pretty much peaked as well. Java, C#, Ruby, Python and PHP and others 
are all taking various portions of the market.

One of the state schools in the area just dropped C++ as the primary 
teach language (still offered)...

The best evidence that C++ is on its way out is that now in many DoD 
contractors, they just assume that all projects should be C++. By the 
time the DoD contractors start using something, you can be pretty much 
bank on it being obsolete :)

Re: An Ada Advice Inquiry

[adaworks]

"Jeffrey Creem" <jeff@thecreems.com> wrote in message 
news:vtfsg4-9si.ln1@newserver.thecreems.com...
>
> The best evidence that C++ is on its way out is that now in many DoD 
> contractors, they just assume that all projects should be C++. By the time the 
> DoD contractors start using something, you can be pretty much bank on it being 
> obsolete :)
>
At the school where I am now teaching (Naval Postgraduate School) the
decision has been made to use Python as the first programming language.
We will still require students to learn C,C++, and Java, but that is all.  In
one of my classes, I still require them to learn Ada.

The sign on my my office door reads, "C++ is its own virus."  Sometimes
when I write a paper for publication I use Ada or Eiffel when I need to
illustrate some point with code.    For example, my paper on "Desiginng
Software to Tolerances"  will use both Ada and Eiffel examples and
appear in the July issue of Software Engineering Notes (an ACM
publication.)

Richard Riehle 

Re: An Ada Advice Inquiry

[John McCormick]

On May 4, 2:59 pm, Jeffrey Creem <j...@thecreems.com> wrote:
>
> One of the state schools in the area just dropped C++ as the primary
> teach language (still offered)...

My state school, the University of Northern Iowa, has just decided to
drop Java and return to Ada in the first year courses.  The faculty
nearly unanamously agreed that our students learned more about
computer science with Ada than Java.  It is not unusual for a school
to drop a language, it is unusual to return to something that worked
rather than move on to the latest fad.

John

Re: An Ada Advice Inquiry

[Ludovic Brenta]

John McCormick writes:
> My state school, the University of Northern Iowa, has just decided
> to drop Java and return to Ada in the first year courses.  The
> faculty nearly unanamously agreed that our students learned more
> about computer science with Ada than Java.  It is not unusual for a
> school to drop a language, it is unusual to return to something that
> worked rather than move on to the latest fad.

I'm really happy to learn this.  I presume you've been quite
instrumental in bringing common sense to a faculty in dire need of it.
Congratulations!

-- 
Ludovic Brenta.

Re: An Ada Advice Inquiry

[Stephen Leake]

<adaworks@sbcglobal.net> writes:

>> I can understand needing to be able to rely on Ada compilers/tools
>> being available in the future, and on being able to find people
>> trained in Ada.
>>
>> Surveying available third party packages is harder. I have not even
>> tried in my field; hard real-time satellite simulation.
>>
> Is your organization creating satellite software in Ada?  

Unfortunately, no. They keep claiming they want to improve
productivity, but they don't seem to believe that choosing a language
is an option.

> Are you at liberty to identify what company you are with 

NASA Goddard Space Flight Center.

> and what kind of satellites you are developing using Ada for the
> software?

My team uses Ada; we develop simulators for testing satellite software
before launch. 

I hope that eventually, enough people will have rotated thru my team
that some flight software team will seriously consider using Ada. It
could happen!

-- 
-- Stephe

Re: An Ada Advice Inquiry

[adaworks]

Stephen,

Thanks.  I think the Ariane V mishap has created a lot
of misunderstanding regarding Ada.   It did not help that
some people, in an effort to promote alternative language
options,  published incorrect explanations of what happened,
and false hopes about what could have been done differently.

As of now, Ariane V seems to be doing just fine.  Anyone
know differently?

People making engineering decisions need to understand the
difference between using the right toolset correctly, versus using
the wrong toolset.    For this kind of project, Ada is likely to
be the right language tool, but we continue to see people making
decisions in favor of inferior languages such as C++.

I don't know what idiot decided to use C++ instead of Ada on
JSF.   That was a decision of monumental stupidity.   I guess we
have to put up with this kind of thing when ignorance is so widespread
about the options.

Richard Riehle

=============================================
"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
news:u1whuzvhm.fsf@stephe-leake.org...
> <adaworks@sbcglobal.net> writes:
>
>>> I can understand needing to be able to rely on Ada compilers/tools
>>> being available in the future, and on being able to find people
>>> trained in Ada.
>>>
>>> Surveying available third party packages is harder. I have not even
>>> tried in my field; hard real-time satellite simulation.
>>>
>> Is your organization creating satellite software in Ada?
>
> Unfortunately, no. They keep claiming they want to improve
> productivity, but they don't seem to believe that choosing a language
> is an option.
>
>> Are you at liberty to identify what company you are with
>
> NASA Goddard Space Flight Center.
>
>> and what kind of satellites you are developing using Ada for the
>> software?
>
> My team uses Ada; we develop simulators for testing satellite software
> before launch.
>
> I hope that eventually, enough people will have rotated thru my team
> that some flight software team will seriously consider using Ada. It
> could happen!
>
> -- 
> -- Stephe 

Re: An Ada Advice Inquiry

[Maciej Sobczak]

On 6 Maj, 07:00, <adawo...@sbcglobal.net> wrote:

> we continue to see people making
> decisions in favor of inferior languages such as C++.

Of course, and don't expect it to change anytime soon.

There is one thing that I miss in this discussion. You asked for
"advice" on comp.lang.ada. What "answer" do you expect *here*?
It's just about the same useful as asking on comp.lang.perl whether it
makes sense to start a new project in Perl. Go and try.

If your (or your friend's) list of choices is Ada and C++, then for a
reasonably non-biased set of answers you should probably also ask on
comp.lang.c++.moderated and then build your advices on a union of what
you get from both camps.
Otherwise you are just going to make lots of bubbles without any
constructive conclusion.

This is, at least, my very humble opinion.

--
Maciej Sobczak
http://www.msobczak.com/

Re: An Ada Advice Inquiry

[Dmitry A. Kazakov]

On 6 May 2007 03:47:39 -0700, Maciej Sobczak wrote:

> On 6 Maj, 07:00, <adawo...@sbcglobal.net> wrote:
> 
>> we continue to see people making
>> decisions in favor of inferior languages such as C++.
> 
> Of course, and don't expect it to change anytime soon.
> 
> There is one thing that I miss in this discussion. You asked for
> "advice" on comp.lang.ada. What "answer" do you expect *here*?
> It's just about the same useful as asking on comp.lang.perl whether it
> makes sense to start a new project in Perl. Go and try.
> 
> If your (or your friend's) list of choices is Ada and C++, then for a
> reasonably non-biased set of answers you should probably also ask on
> comp.lang.c++.moderated and then build your advices on a union of what
> you get from both camps.

Risking to appear cynical ... probably, a choice has been made, and one is
looking for a justification of the choice? In that case it would be silly
to search for counter arguments? I wouldn't expect that from people
choosing C++. After all, how else, could it become so popular? So, why Ada
people should? (:-))

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

Re: An Ada Advice Inquiry

[Pascal Obry]

Dmitry, Maciej,

I think you've just completely missed the question!

Richard is looking for proof that new projects are choosing Ada, of
course this question belongs here. Go to comp.lang.perl and ask there if
there is new Ada projects! Frankly sometimes I feel that some people are
making things lot more complex than they are :(

Pascal.

-- 

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

Re: An Ada Advice Inquiry

[adaworks]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:1178448459.256329.28590@n76g2000hsh.googlegroups.com...
> On 6 Maj, 07:00, <adawo...@sbcglobal.net> wrote:
>
>> we continue to see people making
>> decisions in favor of inferior languages such as C++.
>
> Of course, and don't expect it to change anytime soon.
>
> There is one thing that I miss in this discussion. You asked for
> "advice" on comp.lang.ada. What "answer" do you expect *here*?
> It's just about the same useful as asking on comp.lang.perl whether it
> makes sense to start a new project in Perl. Go and try.
>
My original inquiry was about whether any new projects are being
started in Ada.    I think the C++ people would be unlikely to have
an answer to that question.

What I have learned, from contributions to me inbox and comments
in this forum, is that a great many new projects are being started in
Ada.   As usual, quite a few of my correspondents have asked not
to be quoted/cited.

I have also had some "buyer's remorse" messages.   That is, more than
a few of those email messages have said how disappointed they are
with the decision to use C++ instead of Ada.  The C++ decision has
not been as sucessful as they had hoped, and there is some wishful
thinking that they would have been better to have stayed with Ada.
Now that the code is written in C++, they have to live with the agony
of C++ while longing for the ecstasy of Ada.       I suppose the
"grass is always greener" effect is a human trait that will endure for
as long as humans inhabit the planet.

I did send another email to my colleague yesterday summarizing the
comments from this forum and from the contributions to my inbox.
This morning (Sunday), I received a few more messages with similar
information.   Again, I have been asked not to cite or attribute any
of the information specific people.  Some of these contributors are
not corporate officers with official authorization to speak about the
projects they are doing.   Rather, they are worker-bees who are
speaking for themselves, and revealing information that might get
them fired.   Therefore, I am stripping attribution from those kind
of messages before providing it to my colleague, the person who
originally made the inquiry of me.

As to the suggestion that I make this inquiry of the C++ forums,
my experience is that the vast number of C++ users are woefully
ignorant about Ada.  This is certainly the case where I am currently
employed.   On the other hand, C++ is so obnoxiously ubiquitous
that a person who uses Ada cannot avoid C, C++, or Java.  In my
own case, I have to use C++, teach it in my classroom, and endure
its messiness on a regular basis.    The more I see of it, the more I
learn of it, and the more deeply I am required to spend time with
it, the more I realize how much better Ada is for most things.

That being said, I also have come to like Python for a lot of my
day-to-day programming.  Ada is not perfect for every project.
There are other languages that have great virtue for different kinds
of projects.   However, as nearly as I can tell, at this point in the
world of programming, C++ has outlived its usefulness for most
of the tasks for which it was once used.   It has become the close
equivalent of an object-oriented Assembler, forcing a lot of
programmers to focus on low-level concerns that ought to be
a marginal aspect of modern software engineering.

Richard Riehle 

Re: An Ada Advice Inquiry

[Pascal Obry]

Richard,

Any chance to have a summary here ? Not with the name of the
projects/companies as many have asked not to be disclosed but something
like nb answers, nb new projects in Ada, projects not using Ada
anymore... something like this could be useful.

Thanks,
Pascal.

-- 

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

Re: An Ada Advice Inquiry

[adaworks]

Pascal,

I have been considering something like that.   However,
it is important that, in preparing such a summary, I honor
the requests for restraint and confidentiality.

So, before posting such a summary, I will want to make sure
that I am within the bounds of propriety in conforming with
the requests for anonymity.   Also, some of those comments
are continuing to come in.

I am hoping I will hear from even more people on this issue.
In particular, I would like to hear from some of the compiler
and Ada tool publishers.   They are ones who have the most
knowledge about such things.  However, having been in the
field as a consultant to organizations using Ada in my former
life, I know that those publishers are also constrained by
what they are allowed to reveal.

Richard Riehle


"Pascal Obry" <pascal@obry.net> wrote in message 
news:463DF241.2030402@obry.net...
>
> Richard,
>
> Any chance to have a summary here ? Not with the name of the
> projects/companies as many have asked not to be disclosed but something
> like nb answers, nb new projects in Ada, projects not using Ada
> anymore... something like this could be useful.
>
> Thanks,
> Pascal.
>
> -- 
>
> --|------------------------------------------------------
> --| Pascal Obry                           Team-Ada Member
> --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
> --|------------------------------------------------------
> --|              http://www.obry.net
> --| "The best way to travel is by means of imagination"
> --|
> --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 

Re: An Ada Advice Inquiry

[Maciej Sobczak]

On 6 Maj, 17:47, <adawo...@sbcglobal.net> wrote:

> My original inquiry was about whether any new projects are being
> started in Ada.

That's right - I therefore apologise for the harsh tone of my previous
post.

> I think the C++ people would be unlikely to have
> an answer to that question.

They might, however, tell you how their experiences changed over the
last decade. The truth is that C++ earned its bad reputation some
years ago and today using these old slogans over and over is as useful
as saying that Ada is useful only for US defense industry.

> What I have learned, from contributions to me inbox and comments
> in this forum, is that a great many new projects are being started in
> Ada.

Which is a good news. Still, what is missing is publicity. You say
that nobody is aware of Ada (and so nobody wants to start new Ada
projects) and at the same time that there are many secret projects
started in it. It doesn't make much sense.

> As usual, quite a few of my correspondents have asked not
> to be quoted/cited.

And that's why these guys will write their next project in Java. Or
Groovy.

> I have also had some "buyer's remorse" messages.   That is, more than
> a few of those email messages have said how disappointed they are
> with the decision to use C++ instead of Ada.  The C++ decision has
> not been as sucessful as they had hoped, and there is some wishful
> thinking that they would have been better to have stayed with Ada.

"Stayed" - so these are Ada guys who switched to C++? Why?
If they already had Ada experience and the necessary inertia in the
organization, why they have switched? They should not.
It doesn't make much sense to bash C++ if these people are not
successful after the forced switch. This will happen in any direction.
Take some experienced C++ team, force them to switch to Ada and you
will hear the same complaints. I'm a C++ programmer and I've tried to
write some things in Ada - now I can complain about Ada as long as you
are willing to listen.
The past experience of the team is probably more important than
anything else when choosing the technology for the next project.

I think that you are not getting any balanced feedback.

> Now that the code is written in C++, they have to live with the agony
> of C++ while longing for the ecstasy of Ada.

I can imagine the contrary. It's a matter of where you come from.

> As to the suggestion that I make this inquiry of the C++ forums,
> my experience is that the vast number of C++ users are woefully
> ignorant about Ada.

This is, unfortunately, very true. And from my own perspective I can
tell that C++ programmers can benefit from learning Ada.
But note that learning != switching.
Sorry: learning /= switching. ;-)

> On the other hand, C++ is so obnoxiously ubiquitous
> that a person who uses Ada cannot avoid C, C++, or Java.

Are you sure that people who "cannot avoid" something have the same
experiences as those who are "dedicated users" of something?
I think that the difference is fundamental and significantly
influences the feedback that you can get from them.

> Ada is not perfect for every project.
> There are other languages that have great virtue for different kinds
> of projects.   However, as nearly as I can tell, at this point in the
> world of programming, C++ has outlived its usefulness for most
> of the tasks for which it was once used.

I'm afraid it's not yet dead and the recent (well, upcoming) standard
moves it forward much more than Ada did in its last standard
iteration. This means that the choice between C++ and Ada might be
even more difficult for you in the future.

> It has become the close
> equivalent of an object-oriented Assembler, forcing a lot of
> programmers to focus on low-level concerns that ought to be
> a marginal aspect of modern software engineering.

I think that this is exactly where you miss that last couple of years.
I really don't remember when was the last time I cared about low-level
concerns in C++. Unless I had to (that is, it was actually the goal),
but then nothing was obstructing my goals neither.

Our experiences are apparently different.

--
Maciej Sobczak
http://www.msobczak.com/

Re: An Ada Advice Inquiry

[Martin Krischik]

Maciej Sobczak schrieb:

> I think that this is exactly where you miss that last couple of years.
> I really don't remember when was the last time I cared about low-level
> concerns in C++. Unless I had to (that is, it was actually the goal),
> but then nothing was obstructing my goals neither.

I remember that last time very vividly - when the C++ compiler I was 
using thought that an int& and a unsigned& could be converted freely 
using a temporary on the stack.

Martin

Re: An Ada Advice Inquiry

[Maciej Sobczak]

On 7 Maj, 09:07, Martin Krischik <krisc...@users.sourceforge.net>
wrote:

> > I really don't remember when was the last time I cared about low-level
> > concerns in C++. Unless I had to (that is, it was actually the goal),
> > but then nothing was obstructing my goals neither.
>
> I remember that last time very vividly - when the C++ compiler I was
> using thought that an int& and a unsigned& could be converted freely
> using a temporary on the stack.

This is forbidden by the standard (non-const refs cannot be bound to
temporaries).

I have just checked with quite an old compiler. It complained about
impossible conversion.
What crap you were using? MSVC++6.0, probably?

I believe you entirely that you had this problem - but today, at least
three generations of compilers later, it's hardly a convincing
argument.

Note that we are talking about starting a *new project*. New projects
have the beautiful property of not being bound to legacy toolsets and
today you can get essentially free C++ compilers that from the
practical point of view are 100% standard compliant.
If the project is really starting afresh, then there are even more
reasons not to dismiss C++ on the basis of some bad experiences you
had with the stone age compilers.

--
Maciej Sobczak
http://www.msobczak.com/

Re: An Ada Advice Inquiry

[Dmitry A. Kazakov]

On 7 May 2007 01:50:20 -0700, Maciej Sobczak wrote:

> What crap you were using? MSVC++6.0, probably?
>
> I believe you entirely that you had this problem - but today, at least
> three generations of compilers later, it's hardly a convincing
> argument.

Huh, have you seen Borland Builder 2006?
 
> Note that we are talking about starting a *new project*. New projects
> have the beautiful property of not being bound to legacy toolsets and
> today you can get essentially free C++ compilers that from the
> practical point of view are 100% standard compliant.

Recently we enjoyed mixing Visual Studio 2005 and Borland Builder 2006. It
was insightful...

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

Re: An Ada Advice Inquiry

[Maciej Sobczak]

On 7 Maj, 11:40, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > I believe you entirely that you had this problem - but today, at least
> > three generations of compilers later, it's hardly a convincing
> > argument.
>
> Huh, have you seen Borland Builder 2006?

No, but I've heard very bad stories about it and I wonder why the hell
there is still any market for this. Do we really talk about *new
projects*, or continuation of legacy code with vendor lock-in?

What about MSVC++8.0? g++4? Intel? Comeau?

> Recently we enjoyed mixing Visual Studio 2005 and Borland Builder 2006. It
> was insightful...

I can imagine - mixing one C++ compiler with something that is not a C+
+ compiler must hurt.
Still, almost every reasonable platform can be targeted with just two
compilers: recent MSVC++ and recent g++. I've never had any serious
issues here, apart from the fact that MSVC++ does not implement C99
additions. But formally, it doesn't have to - it's a strictly C++98
compiler.

The difference between Ada and C++ is that with C++ we have a set of
compilers to choose from, so nobody is forcing you to use the worst
one (unless you got locked-in, but then it's only your fault).
With Ada there is a set of versions of GNAT that are "somewhere"
between Ada95 and Ada2005, where the exact meaning of "somewhere" is
to be discovered by the user.

--
Maciej Sobczak
http://www.msobczak.com/

Re: An Ada Advice Inquiry

[Dmitry A. Kazakov]

On 7 May 2007 06:00:30 -0700, Maciej Sobczak wrote:

> On 7 Maj, 11:40, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> I believe you entirely that you had this problem - but today, at least
>>> three generations of compilers later, it's hardly a convincing
>>> argument.
>>
>> Huh, have you seen Borland Builder 2006?
> 
> No, but I've heard very bad stories about it and I wonder why the hell
> there is still any market for this.

Yes, because it was a customer requirement and because there are fancy
libraries one believed of being able to use with Borland. This again is
about how languages and compilers get chosen, in practise.

> Do we really talk about *new
> projects*, or continuation of legacy code with vendor lock-in?

It is always a continuation, new projects are made by old people living in
the old world.

> What about MSVC++8.0? g++4? Intel? Comeau?

We are using the first.

> The difference between Ada and C++ is that with C++ we have a set of
> compilers to choose from, so nobody is forcing you to use the worst
> one (unless you got locked-in, but then it's only your fault).

The choices between compilers are motivated by everything but the quality
of. It has the same pattern as with the language choice. No chance to
convince customer to scrap Borland, even less to switch to Ada.

> With Ada there is a set of versions of GNAT that are "somewhere"
> between Ada95 and Ada2005, where the exact meaning of "somewhere" is
> to be discovered by the user.

That is a transitional state.

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

Re: An Ada Advice Inquiry

[Maciej Sobczak]

On 7 Maj, 15:58, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> >> Huh, have you seen Borland Builder 2006?
>
> > No, but I've heard very bad stories about it and I wonder why the hell
> > there is still any market for this.
>
> Yes, because it was a customer requirement

In which case it doesn't make sense to discuss about which choice is
better, right? :-)
And if you accept the offer, you take the full responsibility for all
the pain you get later. Don't blame the language if you are force to
use crappy tools.
Let's talk about new projects where we are the only drivers.

> and because there are fancy
> libraries one believed of being able to use with Borland. This again is
> about how languages and compilers get chosen, in practise.

Right. But again, don't complain about the language (which is a
general concept) if you get lost in the vendor lock-in as a result of
choosing non-standard solutions. Complain about Borland, not about C+
+.

> > Do we really talk about *new
> > projects*, or continuation of legacy code with vendor lock-in?
>
> It is always a continuation, new projects are made by old people living in
> the old world.

I don't agree. The world was not yet invented entirely.

> > What about MSVC++8.0? g++4? Intel? Comeau?
>
> We are using the first.

OK. They are all comparable.

> > The difference between Ada and C++ is that with C++ we have a set of
> > compilers to choose from, so nobody is forcing you to use the worst
> > one (unless you got locked-in, but then it's only your fault).
>
> The choices between compilers are motivated by everything but the quality
> of. It has the same pattern as with the language choice. No chance to
> convince customer to scrap Borland, even less to switch to Ada.

Then, again, if it's the customer who is driving the choice of tools,
there is no sense talking about which choice is better. It's just
inconclusive.

> > With Ada there is a set of versions of GNAT that are "somewhere"
> > between Ada95 and Ada2005, where the exact meaning of "somewhere" is
> > to be discovered by the user.
>
> That is a transitional state.

Of course - just like with C++ compilers a couple of years ago. They
are just in different phases of the transition. Note that it's a
periodic phenomenon with ~10 years period. ;-)

--
Maciej Sobczak
http://www.msobczak.com/

Re: An Ada Advice Inquiry

[Dmitry A. Kazakov]

On 7 May 2007 14:07:03 -0700, Maciej Sobczak wrote:

> Complain about Borland, not about C++.

I do complain about C++, because it is not only Borland, it is also me who
is using C++. (:-))

> Then, again, if it's the customer who is driving the choice of tools,
> there is no sense talking about which choice is better. It's just
> inconclusive.

That is conditional to the definition of "better." 

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

Re: An Ada Advice Inquiry

[Martin Krischik]

Maciej Sobczak wrote:

> The difference between Ada and C++ is that with C++ we have a set of
> compilers to choose from, so nobody is forcing you to use the worst
> one (unless you got locked-in, but then it's only your fault).
> With Ada there is a set of versions of GNAT that are "somewhere"
> between Ada95 and Ada2005, where the exact meaning of "somewhere" is
> to be discovered by the user.

That's unfair. The C++ vendors had since 1998 to implement there features -
that's 9 years. Even there intermediate 2003 update is now 4 years old. The
new Ada standart is only 2 month old. And still AFAIK there is still only
one C++ compiler to support "export".

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: An Ada Advice Inquiry

[Markus E Leypold]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Maciej Sobczak wrote:
>
>> The difference between Ada and C++ is that with C++ we have a set of
>> compilers to choose from, so nobody is forcing you to use the worst
>> one (unless you got locked-in, but then it's only your fault).
>> With Ada there is a set of versions of GNAT that are "somewhere"
>> between Ada95 and Ada2005, where the exact meaning of "somewhere" is
>> to be discovered by the user.
>
> That's unfair. The C++ vendors had since 1998 to implement there features -
> that's 9 years. Even there intermediate 2003 update is now 4 years old. The
> new Ada standart is only 2 month old. And still AFAIK there is still only
> one C++ compiler to support "export".

Not that Gnat in gcc 3.4 still has/had problems with variants and
finalization. That was 11 years after the standard ...

Regards -- Markus

Re: An Ada Advice Inquiry

[Maciej Sobczak]

On 7 Maj, 18:12, Martin Krischik <krisc...@users.sourceforge.net>
wrote:

> > The difference between Ada and C++ is that with C++ we have a set of
> > compilers to choose from, so nobody is forcing you to use the worst
> > one (unless you got locked-in, but then it's only your fault).
> > With Ada there is a set of versions of GNAT that are "somewhere"
> > between Ada95 and Ada2005, where the exact meaning of "somewhere" is
> > to be discovered by the user.
>
> That's unfair.

I know - but it's part of my point that your criticism of C++ is
mostly based on outdated experiences. It is true that C++ compiler
vendors were sloppy with implementing the standard, but it is now
clear that the main players are interested in compliance much more
than ever. The community was putting enough demand and there were some
modern libraries popping up that vendors just couldn't have pretend
any longer that they can compete by providing crippled tools. For some
time it made sense, especially when you got some "framework" or other
crap with the compiler and used it as a combined environment. For
example, as long as you used MFC with MSVC++ or equivalent Borland
pair, nobody cared about standard conformance, because the environment
was conforming to itself - but with the proliferation of new third-
party libraries it could not last any longer.

> The
> new Ada standart is only 2 month old.

Sure. Then - let's see how the situation will look like 2 months after
stamping the next C++ standard, OK?
Hint: many of the yet-to-be-standardized features are already in
experimental versions of g++. I'm ready to bet that this time the
transitional phase for C++ vendors will be *very* short. This is
because of different forces that now shape the C++ landscape.

> And still AFAIK there is still only
> one C++ compiler to support "export".

We've been through this already.
Short version: nobody uses "export" so nobody cares whether it's
supported or not. It looks that this subject is occupying the C++
enemies much more than the actual users of the language. Interesting,
isn't it?

--
Maciej Sobczak
http://www.msobczak.com/

Re: An Ada Advice Inquiry

[Justin Gombos]

On 2007-05-07, Maciej Sobczak <see.my.homepage@gmail.com> wrote:
>
>> The new Ada standart is only 2 month old.
>
> Sure. Then - let's see how the situation will look like 2 months
> after stamping the next C++ standard, OK?

An Ada implementation is considerably more complex.  It takes one man
year to produce a C++ compiler, vs ten man years to produce an Ada
compiler.  

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: An Ada Advice Inquiry

[Maciej Sobczak]

On 8 Maj, 04:42, Justin Gombos <rpbkbq.xax....@uluv.kbq> wrote:

> An Ada implementation is considerably more complex.

This statement is inconsistent with the usual criticism of C++ as the
most difficult to parse, with too many exceptions and self-conflicting
standard.

> It takes one man
> year to produce a C++ compiler

This statement is inconsistent with the usual criticism of C++ as the
language that 9 years after the standard still doesn't have conforming
compilers.

It is also inconsistent with your expectation to get bug-free
certified compilers. If making a C++ compiler is 10 times easier than
the Ada one, then surely C++ compilers are more likely to produce high-
quality code, no?

And so on. Your argument just doesn't hold water.

Apart from that, if you really think that 1m-y is enough to crank up
the C++ compiler, why not start a company and sell one?

--
Maciej Sobczak
http://www.msobczak.com/

Re: An Ada Advice Inquiry

[Justin Gombos]

On 2007-05-08, Maciej Sobczak <see.my.homepage@gmail.com> wrote:
> On 8 Maj, 04:42, Justin Gombos <rpbkbq.xax....@uluv.kbq> wrote:
>
>> An Ada implementation is considerably more complex.
>
> This statement is inconsistent with the usual criticism of C++ as
> the most difficult to parse, with too many exceptions and
> self-conflicting standard.

I would agree that C++ is more difficult to parse, but it's only
inconsistent with one element of the total effort.  The parsing
difficulty is only a marginal factor once you account for more
components of compiler production, like the runtime environment, and
the expressive power of the target language.

>> It takes one man year to produce a C++ compiler
>
> This statement is inconsistent with the usual criticism of C++ as
> the language that 9 years after the standard still doesn't have
> conforming compilers.

There's no inconsistency there, considering all the reasons why a C++
compiler might not conform to a standard beyond the effort of doing
so.  The first excuse that enters my mind is C++ compiler writers have
nowhere near the pressure that Ada compiler writers have to conform to
a standard.  The Ada market is very small, and an Ada compiler that
doesn't conform is nearly worthless.  And you said it yourself: C++ is
a self-conflicting standard.  That doesn't necessarily make the
compiler more complex, unless the authors choose to support multiple
conflicting rules and enable the user to choose between them - but
that's extra work it would be purely voluntary.

> It is also inconsistent with your expectation to get bug-free
> certified compilers. If making a C++ compiler is 10 times easier
> than the Ada one, then surely C++ compilers are more likely to
> produce high- quality code, no?

No.  Products produced using Ada achieve the most significant degree
of reliability not simply because the compiler is more correct, but
because the *language* enables developers to write correct high level
code.  Neglecting compiler induced errors, the C++ language alone
results in 3 times the defect rate of Ada code before the compiler
even touches it.  So the importance of a correct C++ compiler is
insulated by the fact that C++ is not the language of choice for
quality products.  The nature of Ada projects and the expectation of
the end products compell rigid conformance to standards to a much
higher degree.

> Apart from that, if you really think that 1m-y is enough to crank up
> the C++ compiler, why not start a company and sell one?

There are so many out there.  I would rather compete in a market with
less competition.  

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: An Ada Advice Inquiry

[Robert A Duff]

Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:

> On 2007-05-08, Maciej Sobczak <see.my.homepage@gmail.com> wrote:
>> On 8 Maj, 04:42, Justin Gombos <rpbkbq.xax....@uluv.kbq> wrote:
>>
>>> An Ada implementation is considerably more complex.
>>
>> This statement is inconsistent with the usual criticism of C++ as
>> the most difficult to parse, with too many exceptions and
>> self-conflicting standard.
>
> I would agree that C++ is more difficult to parse, but it's only
> inconsistent with one element of the total effort.  The parsing
> difficulty is only a marginal factor...

Yes, I agree that the parsing difficulties with C++ are a minor issue,
compared to other things.  There are well-known techniques (ugly
kludges) for dealing with parsing of C++.  Anyway, the parser is
just a small part of an Ada or C++ compiler.

- Bob

Re: An Ada Advice Inquiry

[Markus E Leypold]

Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:

> On 2007-05-07, Maciej Sobczak <see.my.homepage@gmail.com> wrote:
>>
>>> The new Ada standart is only 2 month old.
>>
>> Sure. Then - let's see how the situation will look like 2 months
>> after stamping the next C++ standard, OK?
>
> An Ada implementation is considerably more complex.  

As evidenced by the fact that the ARM is so much larger than the C++
standard ...?

> It takes one man
> year to produce a C++ compiler, vs ten man years to produce an Ada
> compiler.  

Regards -- Markus

Re: An Ada Advice Inquiry

[Robert A Duff]

Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:

> On 2007-05-07, Maciej Sobczak <see.my.homepage@gmail.com> wrote:
>>
>>> The new Ada standart is only 2 month old.
>>
>> Sure. Then - let's see how the situation will look like 2 months
>> after stamping the next C++ standard, OK?
>
> An Ada implementation is considerably more complex.  It takes one man
> year to produce a C++ compiler, vs ten man years to produce an Ada
> compiler.  

Your estimate for Ada might be in the right ballpark, depending on
level of optimization, number of targets, peripheral tools such
as debuggers and profilers, knowledge of the development team,
etc.  I could probably build a very minimal Ada compiler from
scratch in 5 person years, given a good team.

But your estimate for C++ is way off.  C++ compilers are approximately
the same difficulty as Ada compilers.  I'd say C++ is slightly more
difficult, but I'm not sure about that.

Anyway, we were talking about implementing language revisions,
not entire compilers.  The GNAT implementation of Ada 2005
(which is complete, by the way) was a substantial effort,
but nowhere near 10 person years.  (Of course we started
working on it before the standard was official.)

- Bob

Re: An Ada Advice Inquiry

[Ludovic Brenta]

Robert A Duff writes:
> The GNAT implementation of Ada 2005
> (which is complete, by the way) was a substantial effort,
> but nowhere near 10 person years.  (Of course we started
> working on it before the standard was official.)

I'm still not sure which version of GNAT is the first with complete
support for Amendment 1.  Could you enlighten me?  Also, which version
of GCC has or will have complete support for Amendment 1?

-- 
Ludovic Brenta.

Re: An Ada Advice Inquiry

[Robert A Duff]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Robert A Duff writes:
>> The GNAT implementation of Ada 2005
>> (which is complete, by the way) was a substantial effort,
>> but nowhere near 10 person years.  (Of course we started
>> working on it before the standard was official.)
>
> I'm still not sure which version of GNAT is the first with complete
> support for Amendment 1.  Could you enlighten me?  Also, which version
> of GCC has or will have complete support for Amendment 1?

Sorry, but I can't really enlighten you.  I've only been with AdaCore
for a little over a year, and I don't really know the answer to your
question.  I know that the latest version of GNAT Pro has full support
for Ada 2005 (although there are probably some bugs).  I know that
AdaCore merges all that stuff into the FSF source tree periodically,
as a service to the Ada community, but I don't know any details about
gcc version numbers and the like.

I worked on one of the last Ada 2005 features to be added to GNAT --
AI-318, which is about constructor functions for limited types.  A very
cool feature, I say!

- Bob

Re: An Ada Advice Inquiry

[Martin Krischik]

Maciej Sobczak schrieb:

>> And still AFAIK there is still only
>> one C++ compiler to support "export".
> 
> We've been through this already.
> Short version: nobody uses "export" so nobody cares whether it's
> supported or not. It looks that this subject is occupying the C++
> enemies much more than the actual users of the language. Interesting,
> isn't it?

But isn't that a catch 22 - no one supports it because not one uses it 
because no one supports it. And there is no pressure to change because 
users don't know what they are missing.

When I (forced to) moved from IBM C++ to MSC++ I was shocked about the 
primitive brute force way to instantiate templates in MSC++ which made 
it almost impossible to separate template-interface from template 
implementations. The hole template in one big ugly file - something not 
found in IBM C++ (in fact all IBM C++ templates consisted of three files 
spec, body, inline body).

I am not in favour of export because I am a C++ enemy. I am in favour 
because I have seen the idea behind export in stunning action. Only the 
IBM did not even need an extra keyword to implement the idea behind.

Martin

-- 
Martin Krischik

Re: An Ada Advice Inquiry

[Maciej Sobczak]

On 8 Maj, 08:36, Martin Krischik <krisc...@users.sourceforge.net>
wrote:

> >> And still AFAIK there is still only
> >> one C++ compiler to support "export".
>
> > We've been through this already.
> > Short version: nobody uses "export" so nobody cares whether it's
> > supported or not. It looks that this subject is occupying the C++
> > enemies much more than the actual users of the language. Interesting,
> > isn't it?
>
> But isn't that a catch 22 - no one supports it because not one uses it
> because no one supports it. And there is no pressure to change because
> users don't know what they are missing.

Not really. There were high expectations at the beginning, because
people believed that "export" will allow them to hide (I mean -
literally, in terms of IP protection, not in terms of code structure)
implementation details of their template code. Without "export" the
library vendors have to ship all template code in open text, which
drives some of the managers crazy. After a couple of years, though, it
became clear that "export" does not guarantee this level of
protection, so today the motivation for having this feature is much
smaller.
That's why it's not true that people don't know what they are missing.

People learned to use templates without "export" and those who are
wary of code structure decouple the specification from implementation
with the crude use #include. It works just fine, thank you. It's not
perfect, but solving it doesn't provide any earth shaking benefits.
Note that in Ada (GNAT) the generic body needs to be available in
source form everywhere where it is instantiated.

Most importantly, implementing "export" is expensive (why do you think
only one vendor took the challenge) and there are bigger fishes to fry
- it's much better if vendors spend their cycles implementing some
other, really wanted functionality.

> I am not in favour of export because I am a C++ enemy.

You are not in favour or you are not an enemy? ;-)

Show me a short example of code that shows the benefits.

--
Maciej Sobczak
http://www.msobczak.com/