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:a5d:9b95:: with SMTP id r21mr11095884iom.38.1551683016984; Sun, 03 Mar 2019 23:03:36 -0800 (PST) X-Received: by 2002:a05:6830:134b:: with SMTP id r11mr11860973otq.213.1551683016767; Sun, 03 Mar 2019 23:03:36 -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!y42no383724ita.0!news-out.google.com!v188ni775itb.0!nntp.google.com!y42no383720ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 3 Mar 2019 23:03:36 -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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6a0fe4c2-a8e6-4d15-8cbf-f5a85ba0cd86@googlegroups.com> Subject: Re: Ada in command / control systems From: Maciej Sobczak Injection-Date: Mon, 04 Mar 2019 07:03:36 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:55777 Date: 2019-03-03T23:03:36-08:00 List-Id: > Once you let user-defined stuff in, you risk a situation when there=20 > would be no corresponding system of equations or no solution of the=20 > system. Simulink, wisely, does not attempt to resolve this. It admits=20 > defeat allowing so-called s-functions: a piece of code written in a=20 > *sane* language that implements what Simulink cannot (more or less=20 > everything). So much for modeling... Great! Now you can have the best of two worlds instead of being slowed down= by the limitations of any particular approach. Of course, this opens an op= portunity for a turn-key sets of such s-functions, which you can just pick = from the library and drop in your model. So, no, you're not going to write = any of this, everything will be written for you already. FPGA people call t= hese "IP cores" and everybody seems to love them. The fact that you can have blocks implemented in some other formalism whene= ver needed, instead of fighting with the tool, only gives more credibility = to modeling. Ironically, you do it with Ada, too, when you rely on componen= ts (OSs, DBs, middleware, etc.) written in a sane language like C (sorry, c= ould not resist :-) ). Actually, Ada would be dead already if this possibil= ities did not exist. Same with modeling. > Simulink is an example of why this does not work on larger scale. You=20 > can have a small subcomponent in Simulink, but all falls apart once you= =20 > move to larger components and their interplay. Still I don't see how this is worse from source code. Things seem to fall a= part no matter what we try to stick together. Maybe we're just bad at engin= eering software. > My suspicion is that=20 > there cannot be such thing as a unified model language, in some strong=20 > fundamental way. I agree here. So let's mix different modeling formalisms when needed. How a= bout 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 unif= ied language if every team member can have their own, right? (Yes, it's that bad.) > I have crashed compilers, too. >=20 > Yes, but you do not start patching the object code. Assembler insertions= =20 > are extremely rare. s-functions is a norm You are mixing arguments. Before you have argued that your modeling tool cr= ashed when you have hacked its files by hand (which is hardly an argument a= gainst modeling). Now you don't like s-functions (which everybody uses else= where, see the other posts about Python code in GNAT). Please don't mix the= se things, so I can debunk them one by one. > you have to break out of the=20 > model abstraction and write a lot around it in order to make that puny=20 > 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 exi= st if everybody expected it to be functionally closed, instead, everybody i= s happy with Python calling C functions below it. Same with modeling. > Companies cannot claim=20 > software free of any liability anymore. Which is very interesting and I even applaud it. But here we are talking ab= out tools. And it is a long established tradition to verify final software = products in a way that recognizes or bypasses tool deficiencies. That is, t= he 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 ta= ke any liability for plane crashing. > Even giants like Facebook and=20 > 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 fa= ster, they will use modeling, with all its deficiencies. And tool vendors w= ill do their best to keep this show going. > I don't know how the industry is going to refund=20 > these new liabilities. At some point they will have to and the pyramid=20 > will collapse. I'm not such optimist. I don't see it happening any time soon. --=20 Maciej Sobczak * http://www.inspirel.com