Re: Feasibility of using Ada in new development

[Florian Weimer <fw@deneb.enyo.de>]

* Robert Law:

> I would like to start by saying my message is not an attempt to start
> a flame war or anything like that.

At least when I was still reading every message, comp.lang.ada is
unusually civil and not too snobby (unlike some other groups in the
comp.lang.* hierarchy).

> I've been programming for years using everything from COBOL, RPG, C,
> Java, PHP, etc.  I've written a number of business applications,
> usually accounting ones.  (That's the advantage of having more than
> twenty years of experience.)  I'm at the point in my life where I want
> to pursue a dream I've had for years of having my own software
> development company, basically a VAR or ISV.

I have to admit that I have much less experience, and I've never been
a full-time programmer/designer/software engineer, and I still
consider myself an ambitious amateur.

> I want to use a language that meets the following criteria:
>
> 1. It must be reliable.

Reliable in what sense?  There are several things that can make a
language unreliable:

  - The language has lots of unsafe features that are very closely
    related to common operations (think of C pointer arithmetic and
    string processing).

  - The language changes a lot, sometimes in incompatible ways.  There
    are several popular examples, but you won't name any.

  - The standard run-time support library (if it can be separate from
    the library) can have similar problems.

  - There are no high-quality implementations available.

  - The language actively encourages bad style and is bad at dealing
    with program complexity.  Large programs tend to fail apart.

  - It's impossible to get formal certification for software
    implemented in it, for whatever reason.

  - The language deeply affects programmers and their ability to
    interact with other programmers (particularly those using
    different languages) and non-programmers

I don't think Ada has any of these flaws, and GNAT is stable at the
source code level (the ABI is still a bit in flux).

> 2. It must be supported.
> 3. It must be usuable to develop applications in a graphical
> environment.  Basically Motif, GTK, or KDE.

I can't really comment on these two.  GNAT is supported, obviously,
but the support offerings are mainly useful to larger companies with
an Ada development team.

My personal rule, after some experimentation, is that there must be a
GCC front end maintained in the official GCC repository.  Anything
else is just too painful.

It's possible to write Gtk applications using GNAT, but I generally
view GUI work as painful and haven't found very early versions of
GtkAda the definite improvement.

> 4. It must be usuable to develop programs used via a browser. 

Certainly possible, via the CGI interface.  There's also a complete
Ada web server that you can embed into your application, but I haven't
used it.

> 5. It must be able to interface with relational databases either
> through a standard interface or ODBC.

I've done some work using GNAT and PostgreSQL.  The nice thing about
Ada is that you can define a new string type for SQL statements.  This
way, you can discourage manual construction of SQL statements, which
should prevent SQL injection attacks.

(You'd need a static code checker, implemented using ASIS, to make
this really foolproof, though.  ASIS is a standardized interface to
compiler representations of Ada programs.)

> 6. It would be nice if it was somewhat object oriented.  I'm not an
> object oriented purist, but it does have some nice features.  I
> especially like its automatic garbage collection of no lonter used
> variable.

Unfortunately, garbage collection is a bit of a stepchild in the Ada
camp.  Ada, as a language, is quite good at supporting garbage
collection, especially if you don't use machine addresses directly and
avoid certain language features which require that objects are
destroyed at certain point, potentially much later than the last
reference to the object vanished.

There are some kludges to use the Boehm-Demers-Weiser conservative
collector, but I've got a hunch that there are many unresolved issues
(with tasking, for example, or with objects that are always reachable
during the program's lifetime because GNAT explicitly adds pointers to
be able to finalize them at program termination).

Furthermore, this collector discards (almost) all type information, so
it's far more inefficient than it needs to me.  OTOH, it's doubtful
that you can beat it with a custom-written collector which hasn't been
fine-tuned over the years. 8-)

From a reliability perspective, even somewhat inefficient garbage
collection is hard to dismiss (of course, only if you aren't doing
real-time work).  But nevertheless, there isn't any demand for garbage
collection from commercial Ada users (at least that's what the
compiler vendors say, and they should know).

> I do want it to be a language that is efficient yet doesn't give you a
> rope with a noose or a loaded, cocked, gun when you use it.
>
> You can see that I'm leary of C and C++.  I have used them, and
> continue to use them, but I'm not at all sure that I want to use them
> to develop business applicatons.  I'm tired of reading about buffer
> overflows.

During the past 12 months, I've written about 15,000 lines of C++ code
(as I said above, I'm not a full-time programmer), and now I regret
bitterly that I haven't written them in Ada.  The risk of buffer
overflow bugs is quite real, and although I tried to isolate all the
risky marshaling operations, I wasn't completely successful at that.
The marshaling library (actually, there are two of them, one design is
somewhat flawed) also contained one or two bugs which prevented it
from getting the compile-time overflow/underflow checking right.

It was fun to write the programs, but it gives me an uneasy feeling,
partly because the code is not really maintainable (I'm not sure how
many C++ programmers deal with that level of template meta-programming
on a daily basis), but mostly because it's so hard to tell if it's
really safe to use it in a hostile Internet environment.

After that experience, I'm looking at other options besides C++.  The
"scripting languages" are out of the game because some of the
applications involve IP packet processing in (soft) real time.  They
also perform quite a bit of bit fiddling, which results in an
unusually large performance hit when switching to scripting languages.
I benchmarked partial implementations and the results weren't too
encouraging.

Then there's Lisp.  I actually wrote something non-trivial that did
work, but I found support from the free implementations for
programming in the large rather weak, even with my limited code base.
You can probably cope with that when you are guided by an experienced
Lisp programmer, but I'm not that lucky.  Furthermore, decent
performance at bit fiddling means that you have sacrifice run-time
checks, which means that your code isn't that much safer than C++
code. (I like Emacs Lisp a lot, though, and it's really good as a
rapid prototyping environment.)

And Java.  Well, the GNU Java implementation always seems to be one
"year" behind (or whatever you want to call Sun's Java technology
cycle), because the language and in particular the run-time
environment keep changing.  In my experiments, I quickly ran into
compiler and run-time library misfeatures.  This is a bit
disappointing because I don't want to bet the future of my source code
on Sun's generosity.  Writing Java programs turned into an exercise in
twos complement arithmetic.  I really doubt that the resulting code is
maintainable.  However, there are some very nice development tools for
Java, and there is a rich selection of rather well-documented
libraries.

C# is too young to be sure.  There doesn't seem to be a traditional
development environment with native code generation, and the Mono
project doesn't aim for it.  At least C# has unsigned types.
Programming in it probably doesn't give you the feeling that you
should rather use the language to control washing machines, or
describe business logic at a suitable level.

As a result, I'm back to Ada.  I've written some Ada code before,
so what drove me away from Ada?  I think the main points were:

  - It's hard to find industrial-strength libraries for basic building
    blocks.

  - There are bindings to many C libraries, but the quality of the
    bindings varies a lot.  Many important libraries still lack
    bindings, too.

  - There's the reimplementation trap.  Something isn't right unless
    it's implemented in Ada, so you end up reimplementing C libraries
    which are actually quite usable as is (through a binding).

  - Writing Ada code is often a mechanical task, at least compared to
    C++ (template meta-programming! yay!).  This is especially true if
    you have to create a lot of bindings.

  - There's no garbage collection support.  With my programming style,
    I can't avoid the dangerously-looking UNCHECKED_DEALLOCATION.

  - There is no de-facto standard for a container library.  Thanks to
    Ada's built-in array type, things aren't completely hopeless, and
    there is usually some compatibility between different libraries.
    However, a standard container library is in development, it looks
    promising.

  - Perceived productivity is much, much lower.  I should have done
    actual measurements which include debugging time (I chased few
    very nasty bugs in C++ code, some of the directly related to C++'s
    shortcomings), but without that, there's just the subjective
    feeling that I was more creative when I wrote C++ code.

I hope that I've learned something in the meantime and that I'm old
enough avoid most of these mistakes by now.

Hmm, my message paints Ada as the best possible choice, more or less
-- all others are either impossible like Java or just worse.  But this
is only part of the truth.  For someone like me who doesn't implement
GUIs at all, the GNAT environment with its Emacs support easily beats
anything that is available for other programming languages on the GNU
platform (Eclipse being the only possible exception, but it's still
tied to some extent to Sun's proprietary Java implementation, so it
doesn't count fully).  I don't know of any other development
environment that offers precise and complete cross-reference
information from within the editor, even for homographs.  Once set up
correctly, it's easy to jump to definitions, find all references to a
specific record field (and there are no false hits of subprograms that
have the same name).  GNAT's error messages that occur in practice are
very easily understood (with a few exceptions, but you can use Google
for them).  When written in the GNAT/Ada Reference Manual style, Ada
programs look very clean, and they don't leave a bad taste in my mouth
(admittedly, some of my C++ code does, unfortunately).

Hopefully, the experience that C++ does offer shortcuts, but that
these shortcuts come at a price, was just what I needed. 8-)

> I have played around somewhat with Ada but by no means am I an expert.
>  I'm concerned that Ada may be starting to fade into obscurity.  If I
> get my company going (I know its a BIG if), I want to use the language
> for years and not chase after every silver bullet that comes along.

Ada has already faded into obscurity, so it can't get much worse.
Most companies also offering Ada development technology already have
other priorities, except AdaCore of course.

I strongly believe that GNAT will be around for the next decades, like
other GCC technology.  Quite a few large companies have significant
interest in a maintained GNAT version.

The only thing that might happen is that Ada is adopted in the free
software community on a larger scale, but that's not very likely.  But
even the current, small community manages to continuously grow the
pool of freely available high-quality Ada libraries, so this shouldn't
bother you.  (Bit rot of Ada libraries that do not interface directly
with operating systems is rather low anyway, much lower than C++ at
least.)

I'm not sure if my post was helpful to you.  I have to admit I wrote
it mainly for myself, so that I might have a look at it in a year or
two and see if my expectations were met. 8-)