Re: Ada in command / control systems

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2019-03-04 08:03, Maciej Sobczak wrote:

> The fact that you can have blocks implemented in some other formalism whenever needed, instead of fighting with the tool, only gives more credibility to modeling.

Rather incompleteness and/or lack of usability.

> Ironically, you do it with Ada, too, when you rely on components (OSs, DBs, middleware, etc.) written in a sane language like C (sorry, could not resist :-) ).

Nothing of these could not be written in Ada in a better and safer way. 
Simulink is a different case. And remember that the starting point of 
the discussion was not merits of a given language. Ada and C share same 
paradigm. C and Simulink is a paradigm change.

> Actually, Ada would be dead already if this possibilities did not exist. Same with modeling.

It would not be Ada if it could not this.

>> Simulink is an example of why this does not work on larger scale. You
>> can have a small subcomponent in Simulink, but all falls apart once you
>> move to larger components and their interplay.
> 
> Still I don't see how this is worse from source code. Things seem to fall apart no matter what we try to stick together. Maybe we're just bad at engineering software.

Everything has its limits, the difference is where these limits are.

>> My suspicion is that
>> there cannot be such thing as a unified model language, in some strong
>> fundamental way.
> 
> I agree here. So let's mix different modeling formalisms when needed. How about a Simulink model that refers to s-functions implemented by generating code from some other modeling tool, like SCADE? There is no need for a unified language if every team member can have their own, right?

You have a huge system integration problems caused by language 
impedance, which becomes impossible when you have to connect models from 
different paradigms. You must break out of one model go to a reasonable 
language and then re-enter into yet another model.

Better. This debunks the whole argument about pseudo-requirements. How 
can you write requirements in a model language bounds of which 
applicability and the role in the whole system is unknown? You must have 
another set of requirements at least to tell which parts of the system 
to be modeled in which modeling language and then what about all the 
places in-between?

> (Yes, it's that bad.)
> 
>> I have crashed compilers, too.
>>
>> Yes, but you do not start patching the object code. Assembler insertions
>> are extremely rare. s-functions is a norm
> 
> You are mixing arguments. Before you have argued that your modeling tool crashed when you have hacked its files by hand (which is hardly an argument against modeling).

The original problem was not crashing but maintainability. It was 
impossible to modify the diagram and fix errors in it. Crashing came later.

> Now you don't like s-functions (which everybody uses elsewhere, see the other posts about Python code in GNAT). Please don't mix these things, so I can debunk them one by one.

Python in GPS is a GPS issue. I don't use Python, I use Ada. The point 
was that you could not use Simulink for most of elementary programming 
tasks. Whatever Python can, Ada can better.

>> you have to break out of the
>> model abstraction and write a lot around it in order to make that puny
>> model work.
> 
> Which is a norm in this industry. All high-level languages rely on modules implemented in other (presumably low-level) languages. Python would not exist if everybody expected it to be functionally closed, instead, everybody is happy with Python calling C functions below it. Same with modeling.

You compare dynamically typed interpreters with domain-specific 
languages. I compare general purpose languages with domain-specific 
ones. Nothing is broken when you call C from Ada, except for special 
cases which illustrate the point. E.g. if you used C for handling Ada 
exceptions or Ada's protected types. Then you would face model breaking 
and all consequences of. And no, this is not normal practice to do. 
Otherwise you are within the model.

>> Companies cannot claim
>> software free of any liability anymore.
> 
> Which is very interesting and I even applaud it. But here we are talking about tools. And it is a long established tradition to verify final software products in a way that recognizes or bypasses tool deficiencies. That is, the safety of airplane does not depend on Simulink crashing or not. In this scheme (and I don't see this scheme going away) the tool vendor does not take any liability for plane crashing.

MathWorks does not sell planes. In this scenario if a vendor (e.g. 
Airbus) will be made liable, if tools will offer no legal protection, it 
will likely reconsider deployment of these. Presently tools play a huge 
role in avoiding liability.

>> Even giants like Facebook and
>> Amazon get charged.
> 
> Because they make final software (tool vendors don't). And as long as these companies believe that modeling allows them to get their stuff released faster, they will use modeling, with all its deficiencies. And tool vendors will do their best to keep this show going.

They do not believe, they know for sure that certain tools are an easy 
path to certification. And my observation is that the West moves away 
from legalism. Whatever law and norms may say, people and companies are 
made liable. So the safety might be imaginary.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de