From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED.fn3LatRFkm9/xzEj7F2/NQ.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada in command / control systems Date: Fri, 8 Mar 2019 12:08:44 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <2199b15b-d704-403f-a6c4-00fab29792d5@googlegroups.com> <72738cc8-3f65-4cc1-8c61-b1166cb5e3c2@googlegroups.com> <9807ec3a-4c34-4641-acfa-e9cf22de95ce@googlegroups.com> <51611452-1f49-4d8d-b93d-363cbbee29d0@googlegroups.com> <6a0fe4c2-a8e6-4d15-8cbf-f5a85ba0cd86@googlegroups.com> <1a5fae09-bbbf-4bdb-be8c-6a2e3fd70dfa@googlegroups.com> <1c62f33a-d3a0-4a64-b66f-c82328cfb52a@googlegroups.com> <7e03c9b4-dd18-41a7-8d0b-4f5cea7df0b5@googlegroups.com> NNTP-Posting-Host: fn3LatRFkm9/xzEj7F2/NQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader01.eternal-september.org comp.lang.ada:55809 Date: 2019-03-08T12:08:44+01:00 List-Id: 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