Re: Do we need "Mission-Critical" software? Was: What to Do?

["Kevin Rigotti" <rigotti@atc.dera.gov.uk>]

mark_lundquist@my-deja.com wrote in message <93l410$mt6$1@nnrp1.deja.com>...
>In article <932mi6$r2k$1@trog.dera.gov.uk>,
>  "Kevin Rigotti" <rigotti@atc.dera.gov.uk> wrote:
>> Much as it pains me to say so, Ada is not always the most appropriate
>> language.
>>
>> For example, however good the bindings, toolsets, etc that are
>available it
>> is simply easier and more convenient to write X Windows user
>interfaces in
>> C/C++ because that's what the  designers expected you to do.
>
>Does it follow because "the designers expected" you to code in C for X,
>that it is therefore "easier and more convenient" to do so, "however
>good the bindings... etc."?  That's not at all obvious to me.  Am I
>missing something?


No, it does not follow automatically but in my experience it is often the
case.

>
>Is your statement based on actual experience with Ada bindings to X?
No, just on lots of system integration experience.

The point of my posting was the difficulty of getting compilers to talk to
each other, I only mentioned GUI development as an example of why I want to
do it.


>And even so, "easier and more convenient to write" is not the only
>criterion of fitness, would you not agree?  Probably not even the most
>important criterion...

Of course. This is engineering not law, deciding priorities is part of the
job.

>Your statement here suggests to me that you just are not interested in
>GUIs or GUI programming!  You care about "the clever stuff" :-)

True. I'm an ATC researcher, software is just a means to an end (for me) not
an end in itself.

For the systems I write, the input and output are often sufficiently complex
or verbose that they have to be data files, so any GUI would have been
rather trivial and I just use a simple command line interface.

In other areas, the GUI may well be the "clever stuff". Certainly, a full
colour Controller Working Position display with conflict resolution tools,
map overlays, etc, etc is a very complex beast and on the occasions that
we've needed to build them for real-time simulations we've used the best
programmers we could get.

>You haven't substantiated your claim that programming GUIs in C/C++
>is "cheapest and easiest".  You're just saying, "Who cares, it's only
>the GUI -- just so long as I get to write my clever stuff in Ada",
>right?
Careful. That's not what I said.

If it so happens that the cheapest and easiest solution is C/C++ then it
makes sense to use it, particularly when the "product" is the results of
using the software not the software itself.


>Here again, I suspect that by the word "trivial" you mean
>that they are uninteresting to you personally...

No, I mean trivial. In the cases I'm talking about they genuinely are.

>Hence I would expect that I would probably say the class of
>cases where Ada is less suitable is probably smaller than you would
>probably say it is.

Probably not, actually.
I'm struggling to think of things where I would consider that the Ada
*language* was less suitable, it is more a question of cost and availability
of skills.

I've just finished writing 50k lines of air-miss model that I *chose* to
write in Ada ... I'd hardly have done that if I didn't like it :-)

>On a side note -- I originally implemented this licensing component in
>C++, but the integration issues due to platform differences and
>compiler version dependencies in a multiplatform, shared-library
>environment made this impossible, as far as I could determine.  So I
>had to reimplement it in C, ripping out all the STL and hand-coding the
>collection stuff, etc.
Exactly. That's half the point I was trying to make.
C++ is a real pain in the neck ... but it's not going to go away so we need
to work with it.

>Aren't you letting the tail wag the dog?  You're saying that the
>ability to integrate "seamlessly" from Ada to C/C++ is crucially
>important, otherwise you might be forced to implement your "clever
>stuff" in C/C++ just so you can avoid the cost of cross-language
>interfacing to integrate with the "trivial" part, which somehow can
>only be implemented in C/C++.  If it's so trivial, why would it be so
>unreasonable to implement it in Ada, especially if you already have a
>binding that hides the cross-language level of integration from you to
>begin with?

Yes, I know it sounds daft but it happens.

Remember, the original thread was talking about how to improve the uptake of
Ada and anything that might make it easier to convince sceptics that Ada is
easy to mix and match would help with this.

>You seriously have part of your product that is so unimportant that it
>can be fully entrusted to young cheap C++ hacking?  I find that hard to
>believe...
Software's not the product I produce: the simulation results are.

>C++ hacking leaves no time for learning what real software engineering
>is all about :-)  All time is consumed with chasing down link-time
>errors and debugging run-time errors.  Meanwhile it conditions
>programmers to think that nonsense is normal...
:-)

That's when you need an Ada programmer to walk past with a smug grin :-)

Kevin
--
ATC Systems Group, DERA, St Andrews Road, Malvern, Worcestershire WR14 3PS,
UK
Phone +44 (0)1684 89 69 11, fax +44(0)1684 89 41 09
DERA disclaimers and restrictions apply, details on request