An Ada Advice Inquiry
adaw...@sbcglobal.net
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
ezkcdude
few projects in development.
tmo...@acm.org
seems to be actively developing new reliability tools with Ada, I presume
for new developments, and they seem willing to be public.
Jeffrey R. Carter
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
Randy Brukardt
news:592dnbDWOqzXLqfb...@comcast.com...
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.
Maciej Sobczak
> 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/
Dmitry A. Kazakov
> 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
roderick...@googlemail.com
> 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
Ludovic Brenta
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.
xavier
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.
Grein, Christoph (Fa. ESG)
H/C.
Von: comp.lang....@ada-france.org
[mailto:comp.lang....@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.
adaw...@sbcglobal.net
Thanks.
Richard
<roderick...@googlemail.com> wrote in message
news:1178268426.0...@l77g2000hsb.googlegroups.com...
adaw...@sbcglobal.net
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" <ra...@rrsoftware.com> wrote in message
news:f1eh8r$8o9$1...@jacob-sparre.dk...
adaw...@sbcglobal.net
Thanks. That is very helpful.
Richard
======================================
"Ludovic Brenta" <lud...@ludovic-brenta.org> wrote in message
news:874pmtj...@ludovic-brenta.org...
adaw...@sbcglobal.net
Thank you. This is also very helpful.
Richard
===================================
"xavier" <xav...@ipnnarval.in2p3.fr> wrote in message
news:463B027A...@ipnnarval.in2p3.fr...
adaw...@sbcglobal.net
Can I infer, from your reply, that Eurocopter is also
using Ada?
Richard
========================================
"Grein, Christoph (Fa. ESG)" <Christo...@eurocopter.com> wrote in message
news:mailman.138.117827675...@ada-france.org...
Ludovic Brenta
> 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.
Grein, Christoph (Fa. ESG)
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
Maciej Sobczak
> 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. :-)
Stephen Leake
> 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
Sloan....@gmail.com
for another relatively new SPARK Ada project.
-- Sloan
adaw...@sbcglobal.net
"Stephen Leake" <stephe...@stephe-leake.org> wrote in message
news:uabwku...@stephe-leake.org...
> <adaw...@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?
>
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
Pascal Obry
> "Stephen Leake" <stephe...@stephe-leake.org> wrote in message
> news:uabwku...@stephe-leake.org...
>> <adaw...@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
Michael Bode
> 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
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?
Jeffrey Creem
> "Stephen Leake" <stephe...@stephe-leake.org> wrote in message
> news:uabwku...@stephe-leake.org...
>> <adaw...@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 :)
Jeffrey Creem
> Pascal Obry <pas...@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.
>
particularly expensive in small quantities.
adaw...@sbcglobal.net
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....@web.de> wrote in message news:f1g0f1$jot$1...@online.de...
Michael Bode
> 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.
Michael Bode
> 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).
adaw...@sbcglobal.net
"Jeffrey Creem" <je...@thecreems.com> wrote in message
news:vtfsg4-...@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 :)
>
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
Ed Falis
> 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.
Fionn Mac Cumhaill
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.
Markus E Leypold
<adaw...@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
Markus E Leypold
Michael Bode <m.g....@web.de> writes:
> "Ed Falis" <fa...@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
Markus E Leypold
Jeffrey Creem <je...@thecreems.com> writes:
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
Markus E Leypold
adaw...@sbcglobal.net
"Markus E Leypold" <development-2006-8...@ANDTHATm-e-leypold.de>
wrote in message news:8x4pmtn...@hod.lan.m-e-leypold.de...
>
> <adaw...@sbcglobal.net> writes:
>
>> Is anyone out there really choosing it for new software projects?
>
> Me. (And I'm not talking about hobbyist stuff).
>
of confidentiality, so I don't want to ask you compromise
that. However, some general information would be helpful.
Thanks.
Richard Riehle
Michael Bode
> 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?
Markus E Leypold
Michael Bode <m.g....@web.de> writes:
> "Ed Falis" <fa...@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
Georg Bauhaus
> 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?
Markus E Leypold
Georg Bauhaus <bau...@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
John McCormick
>
> 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
Michael Bode
> 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.
Ludovic Brenta
> 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.
Jeffrey Creem
> 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.
Ed Falis
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.
Ludovic Brenta
> 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.
Michael Bode
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.
Ludovic Brenta
> 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.
Markus E Leypold
Jeffrey Creem <je...@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
Ed Falis
Flexible License Manager - the bane of tech support and customers
everywhere. ;-)
Markus E Leypold
"Ed Falis" <fa...@verizon.net> writes:
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
Markus E Leypold
"Ed Falis" <fa...@verizon.net> writes:
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
Ed Falis
<development-2006-8...@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
Michael Bode
> What horrendous sins did you do to deserve running such software on
> (gasp) Windows?
Using Ada to supersede at least part of that software :-)
Stephen Leake
>> 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
Stephen Leake
> Pascal Obry <pas...@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
adaw...@sbcglobal.net
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" <stephe...@stephe-leake.org> wrote in message
news:u1whuz...@stephe-leake.org...
Michael Bode
> 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".
Maciej Sobczak
> 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/
Maciej Sobczak
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?
Dmitry A. Kazakov
> 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
Larry Kilgallen
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.
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
adaw...@sbcglobal.net
"Larry Kilgallen" <Kilg...@SpamCop.net> wrote in message
news:vFqGwa...@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.
>
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
adaw...@sbcglobal.net
"Maciej Sobczak" <see.my....@gmail.com> wrote in message
news:1178448459....@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.
>
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
Simon Wright
> 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).
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,
adaw...@sbcglobal.net
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" <pas...@obry.net> wrote in message
news:463DF241...@obry.net...
Maciej Sobczak
> 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.
Markus E Leypold
<adaw...@sbcglobal.net> writes:
> "Markus E Leypold" <development-2006-8...@ANDTHATm-e-leypold.de>
> wrote in message news:8x4pmtn...@hod.lan.m-e-leypold.de...
>>
>> <adaw...@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
Martin Krischik
> 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
Maciej Sobczak
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.
Dmitry A. Kazakov
> 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...
Georg Bauhaus
> Georg Bauhaus <bau...@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.
Maciej Sobczak
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.
Dmitry A. Kazakov
> 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.
Martin Krischik
> 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://kris...@users.sourceforge.net
Ada programming at: http://ada.krischik.com
Michael Bode
> 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.
Georg Bauhaus
> Georg Bauhaus <bau...@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.
Maciej Sobczak
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
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?
Justin Gombos
>
>> 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.
Martin Krischik
>> 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
Dmitry A. Kazakov
> 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."
Maciej Sobczak
> 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
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.
Markus E Leypold
Martin Krischik <kris...@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
Markus E Leypold
Justin Gombos <rpbkbq....@uluv.kbq> writes:
> On 2007-05-07, Maciej Sobczak <see.my....@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
Robert A Duff
> On 2007-05-07, Maciej Sobczak <see.my....@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
Ludovic Brenta
> 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.
Justin Gombos
> 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.
Robert A Duff
> On 2007-05-08, Maciej Sobczak <see.my....@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
Robert A Duff
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