>>I meant not uncertain and/or
>> changing requirements, but worse: unknown domain area and no experts near you.
>
>The risk of such kind of projects is very very high

Yes, of course, but let's be honest - as a rule all that risk is for investors,
not for programmers, and not even for managers. So that risk is taken again
and again -;)

> and the language you use can't do anything with it

Yes, any language can't help here. Except of the lucky case when something
similar was already done (and is accessible) in some language (which most
probably will be C++ -;) .

>I don't know any language which can fix such kind of bad project management.
>As a matter of fact, every day on my work I can see how many problems can present
>the language (C++) in the situation when management is not a strong side of
>a project. It cause additional problems, really very serious problems. The
>problems is ten times bigger when you have many "good C++ programmers" (~100).

All that is true, but now imagine the same bad project management with the
same team using Ada (well, let's assume that all team members went through
1-month Ada training, but on different sites, from different teachers). I guess
that the whole picture will become even more awful, it will be true nightmare,
thanks to Ada powerful features used disorderly.

>They are more ten times bigger when your system full of simultaneous processing
>- such kind of things can't be described on C or ++ the way anybody can manage
>it and catch all bugs in it during 3 years.

Well, tasking/mutithreading is another story. In this area we have unpleasant
choice between Ada, which is probably best at the language level, but probably
needs (costly) support, then C++, which has practically no support for tasking
at the language level, but usually comprehensively connected to the underlying
OS, and then Java, which supports multithreading at the language level, but
otherwise isn't much more controllable then Basic.

>I spent a lot of time with hacking absolutely mad "class hierarchy", "friends",
>bad include effects, macroses etc.

Oh yes. This is unforgettable -;) .
  But perhaps you did not see Ada in trenches... I'm afraid that one (or crowd)
may build with Ada packages and types no less horrible things as with C++ classes.

>On my opinion C++ don't suitable to any _predictable_ development.

C++ without additional tools - perhaps. But those who want predictable development
do use additional tools. It is normal practice for any serious development
using C++, I think. With even not too sophisticated external tools you may
enforce various standards-rules-styles, and prevent many errors and inconsistencies.

> It suitable
>for work when a risk is source of pleasure, something like alpinism.

No, it is an exxagregation. It is true that with C++ we generally allow more
risk in software than with Ada, but this may be justified by the consideration
that other constitutients of our whole real-world application do not introduce
high amount of risk. At the top level, we should manage overall risk; usually
we have no hope to reach competitive results not taking certain level of risk;
so our problem is to distribute that risk propertly among the ingredients of
the whole thing and its operative circumstances. When non-software risks are
high (as it happens in military or, say, medical equipment) then the risks
associated with the software part of the thing must be severely limited - and
here Ada is in place. Otherwise, that is, when non-software risks are relatively
low then we may afford higher risk associated with the software part - and may
decide to use C++, Java, etc., even Perl -;) .

>How it can reduce the risk when nobody knows what he or she gets when mix all
>these "hierarchies" and "threads" and infuse for a couple of monthes in conditions
>very close to a battle?

Well, if there is no real battle around, perhaps some conservation law requires
some imitation? -:)  And if we change the language from C++ to Ada the result
may be as replacing a fight with sticks by the fight with guns -;)


>Sergei Lodyagin
>C++/Ada developer

Alexander Kopilovitch
Too Independent Programmer