Re: What's stopping you from using Ada for your next commercial project?

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 9 Mar, 21:43, Simon Wright <si...@pushface.org> wrote:

> > 3. Availability of reasonably robust and up to date compilers.
> > Unfortunately things are very bad for Ada in this regard - compilers
> > are either bug-ridden or outdated.
>
> Speaking only of GCC, is this actually any different for Ada vs C or
> C++? (and the outdated ones have their own bugs ...)

Well, my experience with the C and C++ support in the GCC family is
very positive. In fact, I have never (like in "not even once")
encountered a situation where the g++ would surprise me or crash in
front of my eyes. It has its own issues that relate more to the target
language (like the ability to create inconsistent binary from
mismanaged source files) or to its evolution strategy (like breaking
ABI almost every release), but really, it has never surprised me with
bugs coming from its own implementation.
This is much different with GNAT, which is unfortunately so bug-ridden
as to really slow down the development work. The difference is even
more frustrating if we compare the kind of code that I used in these
languages - that is, very advanced or even outright experimental code
in C++ vs. tutorial-level examples in Ada.
I have submitted several bug reports for GNAT on my own and if you
search the archives of this group you will find my (almost) regular
rants about that.

For the practical example - I have just announced the availability of
YAMI4 v. 1.3.0, which involved quite a bit of Ada development. I have
decided to use three different versions of GNAT to ensure that the
code compiles properly for the widest audience. The result - it was
not possible. The compilers either crashed or produced code with
runtime errors. This forced me to introduce *very* ugly workarounds,
which, ironically, resulted in additional compiler warnings on another
version. That is, I had to agree to have compiler warnings on version
X only to compile the code at all on version Y.

If you need some numbers to back these observations, just download the
YAMI4 source package and do this:

$ find . -name '*.ad[bs]' | xargs grep workaround

there are 57 entries.

I estimate that this additional effort was somewhere between 33% and
50% of the whole work.

The YAMI4 project contains also code in C++, Java, Python and (most
recently) C#, so it might be a good platform for comparisons. From
these, only Python proved to be problematic on 64-bit platforms due to
internal interpreter bugs. C++, Java and C# did not exhibit *any*
problems related to compilers or runtime libraries.

I write all this because I try to be frank and honest - even though it
does not look very well for Ada. These are important factors to take
into account when choosing the technology for the next project
(whether commercial or not), because obviously the additional effort
is not negligible.

Having said this I must add that I really hope that things will
improve in the future and this is why I was willing to make this
investment. However, do not expect every company out there to do the
same, as obviously the decision dynamics are usually different.

What are the alternatives for small companies that want to use Ada?
I don't know, really. I have approached Aonix (now Atego), but they
have apparently frozen 15 years ago and stopped responding when I
mentioned that I need Ada 2005 features. Rational is out of question
if its price range is as described in another post. SofCheck might be
a viable solution - but then the price difference (reminder: g++ costs
0$) is another factor to take into account.

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