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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a02:cd8a:: with SMTP id l10mr10181761jap.10.1552029567857; Thu, 07 Mar 2019 23:19:27 -0800 (PST) X-Received: by 2002:a9d:66c9:: with SMTP id t9mr10162264otm.36.1552029567588; Thu, 07 Mar 2019 23:19:27 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!i2pn.org!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!y22no337334ita.0!news-out.google.com!v188ni538itb.0!nntp.google.com!y42no336885ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 7 Mar 2019 23:19:27 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=165.225.84.74; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S NNTP-Posting-Host: 165.225.84.74 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <7e03c9b4-dd18-41a7-8d0b-4f5cea7df0b5@googlegroups.com> Subject: Re: Ada in command / control systems From: Maciej Sobczak Injection-Date: Fri, 08 Mar 2019 07:19:27 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:55807 Date: 2019-03-07T23:19:27-08:00 List-Id: > A model is an object representing another object usually from another=20 > space so, that the former has the features of interest of the latter. So is this good or bad? > > Whether there is a code generation involved is a secondary issue. >=20 > It was your thesis that people want to avoid writing code, which I agree= =20 > with. Remove that and the bureaucratic incentives, and nobody would ever= =20 > 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 fro= m models is a possible way to do it. 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. There is no need to generate code to achieve this, but if the = domain is appropriate, why not. I've seen both, in their good and bad versions. I'm interested in the good = ones. > The discussion was about the place and whether the paradigm of using a=20 > domain-specific language to express models of the software system (note= =20 > the difference) may work. It cannot. I don't see why it cannot, but we might be using different definitions of "= domain-specific". For me Simulink is not domain-specific. Neither is UML or= state diagrams or whatever. These notations are perspective-specific (and = not every perspective is useful for every system), not domain-specific. I don't see why using a notation that focuses for example on state transiti= ons cannot work for expressing some aspects of the software system. Maybe w= e have a terminology mismatch here. > You ignore here software design. The problem and the point is that the=20 > software systems (and models of) are far more complex than the models of= =20 > physical processes these systems are supposed to control/automate. Tools= =20 > and ideas like Simulink come from the era when it was the opposite. Then= =20 > you had a 8-bit microcontroller with a few soldered in AD/DC converters.= =20 > That was all. You had a nice way to design, test and deploy a control=20 > loop. That time is gone. This is an interesting observation, but nothing forces me to use Simulink t= o cover the whole system. I can use it to model some chosen aspect or funct= ion, using some other notation for expressing design at a different level o= r perspective. > This is not a purpose, it is a desired feature of the code writing=20 > process. The purpose is fulfilled by writing the code. You want to write= =20 > the code in a different language? Fine, but do not tell me you are=20 > writing no code. Good, this is valid observation, but I can still want to do it. The reason = is that different languages might introduce different challenges (who new?)= and I might want to pick the language that is more effective with regard t= o team competencies and the problem at hand. That is, by using a different = language/notation engineers can avoid some types of problems. You know, - t= he 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 a= rray overruns or memory leaks, then this is the added value. You would say it is still writing code (and in this context I would agree).= But managers will say that it is not writing code (and in the context of n= ot writing bugs in C, they would be right, too). In either case, there is a= dded value in not writing bugs in C, so everybody is right here. :-) > No, Simulink is bad when you try to use it where it does not belong,=20 > i.e. for software development. Tool evaluation is an important part of project planning. And what if software development is actually not needed to achieve the proj= ect's goals? Maybe, you know, it's our affinity to source code that suggest= s us that whatever we need to do, there must be software development involv= ed? 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 w= rong? Writing source code for fun is not necessarily what the customer wants to p= ay for. What if my client wants something that can be done in Simulink? The argumen= t that Simulink cannot be used for software development is then irrelevant,= even if software development itself could be (and perhaps frequently is) a= bused to do the work. That is, I can do everything in software, but it does not mean that I shoul= d. > BTW, the customers I know do not deploy the code generated by the=20 > real-time workshop. The code (in C) is manually rewritten and reviewed.= =20 > Yes, one must have the worst from both worlds! Yes. Still, there can be added value here: the simulations allowed to valid= ate the design ideas. Then the coding follows the path that is already veri= fied to be safe. > Any extra layer of languages increases complexity=20 > exponentially. I disagree. The extra layer can guide the choices at another layer, thus re= ducing the space at that other layer. And, if you need to have something at an intermediary level to understand w= hat you are doing, then it means that the complexity is part of the problem= and cannot be reduced. > BTW, if Simulink et al were used as SPARK=20 > is used, I would have no objection. Then, with all the lessons learned from past projects, let's do it. --=20 Maciej Sobczak * http://www.inspirel.com