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