I've received a strong signal last week. Three times. Number 11. SIGSEGV to
my JVM running an important app.
Ada should be freed from its traditional, narrow domain of application.
More and more depends on software. Not only aeroplanes and military
equipment must not fail. Software requiring total uptime tends to appear
everywhere, most notably internet. For example the level of disruption that
can be caused by a failure of an email system in a big company nowadays is
more than serious.
There is vaccum in the space of computer languages. C and C++ are stone age
solutions, not even a namespace there, terrible portability, unreadable,
could go on... That's why it has been relatively easy for Sun to plant Java
virtually everywhere, but they are seriously overdoing it. For example I
remember reading about "Java helping to solve embedded software crisis".
They are trying to bloat my handy phone with a JVM, and my PABX also
(google for Java SS7)! Ada would be far more suitable for those
applications, and not only those...
Having said the above, here is my personal list of obstacles I've
encountered trying to practice what I've preached above:
1. Containers (/Collections). Once you are done with Hello_World, and try
to write some real software you really get stuck on this. There are dozens
of libraries varying in scope and quality, but there is no standard, not
even a clear leader. The variety is often killing reuse efforts, because
two pieces of software use different container code, and won't
interoperate. Every self-respecting company / developer has a homegrown
solution. It is really amazing that Ada has a standard for distribuited
computing but not for containers. My experience is that operating on
containers accounts to at least 30% of code, often 80%, so this is a
serious problem. Ada sources would be much better readable / understandable
if they were using common containers. I know that there is ongoing work in
2. Interface to underlying operating system, especially socket programming.
There is FLORIST for POSIX binding but the most important part - socket
connectivity - has big warning that it is by no means complete / stable.
You have to use GNAT.Os_Lib and GNAT.Sockets that do good job for that, but
are not standard. Plus there are at least three other libraries.
3. Openness. I've got the impression that there are millions of lines of
code that could be open sourced. Nobody is nor will be making money on
them. Currently the only big project in Ada that can be examined for
educational purposes is GNAT itself. This is not enough. The availability
of large scale production quality sources in the process of learning the
Ada engineering way is invaluable. So if you can free some code, and won't
loose money on that - do it, for Ada community and for your own good. You
will likely receive valuable feeback - patches, maybe somebody will
implement the functionality you've always wanted to have, but there was no
time. Maybe, in worst case you won't loose anything.
4. Little Ada education at the universites. Lego Mindstorms is cool, but
this is not enough. Of course, training people is an option, sometimes. I
had a 3 month project - develop a system capable of dispatching 100 000
emails per hour (no, not spam) based on Postfix. I wanted it in Ada, but
did it in PERL. Learing Ada would add a month to the task. Having fixed
1-3, there should be no problem to cope with this one too. I am sure that
attracting students to the language would be easy, people like to write
software that doesn't break three times a week.
I am sure Ada can sell well, becuase reliability of software can sell.
People have had enough of BSODs of different sorts already. I am positive
that there are enough people capable of understanding, for example, why it
is important not to use int for storing day count. This is not that hard