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

[mark_lundquist@my-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?

Is your statement based on actual experience with Ada bindings to X?

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...

> Bindings and support for Gtk are a good thing, but at the end of the
day
> what I and others in a similar situation really want to do is to
build the
> clever stuff in Ada then hand it over for integration with someone
elses
> GUI, produced using whatever is cheapest and easiest.

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

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?

Fair enough, but then how about leaving the discussion of Ada GUI
bindings to people who _do_ care about writing them?  To offer
something you don't give a rip about as an example of an area where you
would yield to the idea of Ada being less suitable than other languages
seems a bit disingenuous... :-)

>
> I don't care if the trivial stuff is written in C, C++, Java or
anything
> else

There's a sense in which GUIs might be considered "trivial", but that
sense isn't particularly relevant to the discussion at hand.  GUIs are
neither unimportant to the product, nor are they especially easy to
program.  Here again, I suspect that by the word "trivial" you mean
that they are uninteresting to you personally...

Last year I delivered a project in C.  This was a software licensing
component that wrapped an interface to a commercial license-management
product and added additional semantics (while hiding unnecessary
features of that interface).  This was in many ways a trivial project.
Because of the nature of the project, how and where and by whom the
component was going to be integrated etc., I wasn't able to implement
it in Ada.  But man, did I wish that I could!  It really would have
been quicker, easier, and more convenient, in spite of the fact that
the designers of that commercial licensing product certainly
do "expect" you to code to their C interface.

Note that my real-life example confirms your broader point -- that
sometimes Ada is not the most suitable language -- but falsifies the
notion that this has anything to do with ease and convenience of
coding.  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.

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.

> but I do care about integration costs, particularly if they are so
> painful that I have to implement experiment critical code in a
language I
> consider inappropriate in order to reduce them.

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?

>
> So, the thing that would make the biggest impact on the uptake of Ada
in my
> environment at the moment is being able to mix and match Ada with C++
> seamlessly, using whichever fitted the problem most cost effectively.
>

I'm betting that cultural and organizational factors have more to do
with your situation than you are letting on, as much or more so than do
technical factors... whaddya say?

> [...]
>
> We could then use the youngest, cheapest staff for the C++ hacking

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...

> and when
> they'd had time to learn what real software engineering was all about
they
> could move on to doing the important stuff in Ada.

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...

Anyway Kevin, I think your perspective is a little bit sick and
twisted :-) :-) First, the idea that parts of the programming product
are unimportant, and secondly the idea that C(++) is "good enough" for
the unimportant parts, while somehow it's not good enough for your
important parts!

Best regards,
-- mark



Sent via Deja.com
http://www.deja.com/