Re: Ada in command / control systems

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

On 2019-03-08 08:19, Maciej Sobczak wrote:
>> A model is an object representing another object usually from another
>> space so, that the former has the features of interest of the latter.
> 
> So is this good or bad?

It is how it is.

>>> Whether there is a code generation involved is a secondary issue.
>>
>> It was your thesis that people want to avoid writing code, which I agree
>> with. Remove that and the bureaucratic incentives, and nobody would ever
>> use it.
> 
> Not really. I see it being used both ways. There are two interesting cases to consider:
> 
> 1. You want to save your programmers from writing code. Generating code from models is a possible way to do it.

If you have adequate software models, you could. Unfortunately there are 
no better models of this kind than the constructs offered by 
higher-level programming languages. Nothing of that is relevant to 
Simulink, which is to model a narrow class physical objects.

> 2. You want to (or are obliged to) introduce something in between the high-level requirements and the actual implementation, for validation of design assumptions.

Why introducing another language between the language of requirements 
and the language of software implementation could validate anything?

> There is no need to generate code to achieve this, but if the domain is appropriate, why not.

There always is. Any language translates into some code. You want to say 
that there is no any material or usable code to generate from that. 
Well, I would agree. The language of requirements generates code in the 
heads of people reading the requirements. So long the code is immaterial 
all this is more or less literary exercise.

> I don't see why using a notation that focuses for example on state transitions cannot work for expressing some aspects of the software system. Maybe we have a terminology mismatch here.

Because "some aspects" is not enough. In order to design software the 
language must express all important aspects.

> ... nothing forces me to use Simulink to cover the whole system. I can use it to model some chosen aspect or function, using some other notation for expressing design at a different level or perspective.

Then it is not software design in capital letters, just an 
implementation of some minor sub-component. We could spare all that 
model-based software design nonsense talk for managers.

> I might want to pick the language that is more effective with regard to team competencies and the problem at hand. That is, by using a different language/notation engineers can avoid some types of problems. You know, - the same argument that Ada is better than C might also work between Simulink and C. And if Simulink (or whatever else) can prevent coders from making array overruns or memory leaks, then this is the added value.

It is very very old idea, you know. It was in the air long before Ada 
Let's have a [domain-]specific language for each problem. E.g. LISP was 
considered a language to manipulate lists. SNOBOL was for string 
processing. FORTRAN for scientific calculations. COBOL for business 
software. JCL for batch processing etc. The idea proved to be wrong, 
which is why PL/1 and Ada were designed. It is still a wrong idea, just 
every new generation is damned to repeat errors of their fathers.

> And what if software development is actually not needed to achieve the project's goals? Maybe, you know, it's our affinity to source code that suggests us that whatever we need to do, there must be software development involved? Our perception can be distorted by our personal passions - if the only thing you know is a hammer... this kind of thing. But what if we are just wrong?

I don't see how it could be otherwise. The factors precluding 
abstraction the code away are:

1. Complexity of the software
2. Size of the software
3. Diversity of the target hardware

> Writing source code for fun is not necessarily what the customer wants to pay for.

If there is a programmable system, there must be a program.

> What if my client wants something that can be done in Simulink? The argument that Simulink cannot be used for software development is then irrelevant, even if software development itself could be (and perhaps frequently is) abused to do the work.

We discussed that already. There are simply no projects which could be 
designed solely in Simulink. A typical customer would require a HTTP 
server, cloud, integration with the ERP, data logging and reporting, 
software upgrade service and so on. Simulink is about 1% of things to be 
done.

>> BTW, the customers I know do not deploy the code generated by the
>> real-time workshop. The code (in C) is manually rewritten and reviewed.
>> Yes, one must have the worst from both worlds!
> 
> Yes. Still, there can be added value here: the simulations allowed to validate the design ideas. Then the coding follows the path that is already verified to be safe.

Simulink is used to build a model of the physical process and/or of 
control. Real-time workshop implements a numeric approximation of these 
models in C.

Yes, engineers can use Simulink models to communicate their ideas. 
However it also limits possible implementations, because there are 
things outside these models and also things in the models that cannot be 
faithfully implemented by a discrete machine in finite time.

>> Any extra layer of languages increases complexity
>> exponentially.
> 
> I disagree. The extra layer can guide the choices at another layer, thus reducing the space at that other layer.

If you are not satisfied with the language, why introducing a new one 
leaving the first in place? The only valid reason is mathematical 
impossibility to have a single language, like in the case of Ada and 
SPARK. That is not the case for the pair Ada/Simulink. I believe if 
somebody invested half of time invested in Simulink one could come up 
with a numeric Ada library, which would be easier to use than Simulink, 
even for engineers.

There is no need to invent reasons. It is much simpler. Nobody ever 
evaluates tools and languages. They just take what they know and what 
they have heard of. More the better. For each real or imaginary problem 
there must be a tool to buy. If the tool is crap, let's install another 
one on top of it.

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