Toshitaka Kumano wrote:

>Now we plan to put the system into actual production in coming years,
>but the manager and some system engineers are very dubious that Ada will
>survive, say, in a decade from now, and they consider that maintenance
>problem shall arise, sooner or later, by shortage of various tool chain.
>
>They plan to convert manually the entire sources from Ada83 to C++,
>...
>
>To persuade manager with technical superiority of Ada is of no use here,
>because they understand that to some extent, and they simply concern
>about shortage or soaring price of tools in future.

It is hard to believe that just vague and uncertain concerns about rather far
future can be the real reason for undertaking quite a big and costly work.
Perhaps there are other reasons, which are pushing for that move. For example,
a perspective of an active development phase (surely, that "manual conversion"
will weight at least as a surrogate development) with all its attributes -
more people, more alive status, room for changes, etc. If these my suspicions
are at least partially true then the desire for the move from Ada should be
counteracted using appropriate arguments - those that will stand against
exactly that particular direction of the move, but at the same time permit
fulfillment of true aims. So, I'd like to add my humble proposition to the
Peter Amey's analisys and Stephen Leake's advice.

Tell them (the manager and those dubious system engineers) that their concerns
certainly have some ground, but at the same time are heavily overstated.
That indeed there is a need for major overhaul of the system because the
current trends should be properly (and in good time) reflected. In particular,
precautions should be made against the concerns related to possible problems
with Ada tools in some future. One cannot guarantee that transition to C++ or
other object-oriented language of choice never become a necessity. Therefore
some steps should be made for making such a transition less difficult and
painful. As the current system is programmed in Ada 83, a right plan would be
to instill object-oriented character into the system by moving to Ada 95
(perhaps with corresponding renovating changes in system design), and at the
same time getting rid of too complicated elements of Ada language by imposing
a set of limitations - for example, choosing a subset from the SPARK limitations.

This way the substantial advantages provided by Ada language will be retained,
and at the same time important preparations for a possible future transition
to another (object-oriented) language will be made.

What can be better than precisely balanced approach? -:)





Alexander Kopilovich                      [log in to unmask]
Saint-Petersburg
Russia