Re: IBM Acquires Rational Ada

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Marin David Condic wrote:
> Well, yes, of course. You still have to make your case. I've made the case
> with metrics within the realm of digital electronic controls - but that's an
> environment with very specialized needs. I believe the case *could* be made
> in other areas, but Ada has to be bigger than just a compiler that conforms
> to the ARM. If, for example, there were an environment that rivaled MSVC++
> in terms of functionality and did it more reliably and with less obfuscation
> and you had some data to indicate that similar apps can be built faster with
> "Visual Ada" than with MSVC++, would that not start making a case for why
> people should switch?

This is the IDE and libraries case. Yes, improvements there would
create some encouragement for Ada use. I agree that this is certainly
one part of the problem.

> My real point is that the "Ada Mentality" has traditionally concentrated on
> high reliability and lower long-term costs for long-lived systems and that
> this is not necessarily what the vast bulk of developers are buying. Not
> that its a bad thing to have high reliability, etc. 

Getting back to the language (which I think was the suggested issue
earlier), was that the "Ada Mentality" requires you to structure your
programs a bit differently (hence the "frustration"). But here, I think
this is just a matter of becoming familiar with what is there (language
features, generics, standard and public packages etc.)

In response to the quick to market point,
it is still possible to "hack" Ada code to produce quick
results. The problem is only that you end up with ugly disorganized code,
with perhaps a number of Var'Address, Var'Unchecked_Access or GNAT
specific Var'Unrestricted_Access all over the place. But this is no
different than C/C++ when it is hacked together either.

So my point is really that if you want to hack, Ada does let you do
that. It is just as in any other language, you'll also pay the
price for it later ;-)

Getting back now to your point of IDEs and better general purpose
packages (libraries), I agree that there is a lot of work to be
done there still.

For example, you could get near standard conformance on text screens.
Yet, there does not exist any _standard_ curses package. There are
some public versions of bindings, but none of them are
complete or "standard". So even text based applications are
barely accomplished in a portable fashion.  In this sense IMHO,
Ada is still better suited to embedded applications, rather than
the general purpose use that other languages are used for.

But I still believe that there is hope that this may change
over time. I think that the Ada standards need to move beyond
the focus of the embedded market to the business and general
purpose use to improve its acceptability.  Give us a _PROPER_
Ada.Calendar package for a start! (can't determine the day of
the week for example)

> So if Ada as a community or culture or whatever it is, were to shift its
> emphasis and start concentrating on Time To Market, I'd bet we would come up
> with some really successful stuff.
...
> 
> MDC

And if they actually did that (shift emphasis), there would be
less that would need to craft so much from scratch (like a
standard and complete curses binding).

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg