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:a6b:7708:: with SMTP id n8mr3333360iom.36.1551300378255; Wed, 27 Feb 2019 12:46:18 -0800 (PST) X-Received: by 2002:a05:6830:1458:: with SMTP id w24mr3455051otp.303.1551300377938; Wed, 27 Feb 2019 12:46:17 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!y22no40889ita.0!news-out.google.com!d79ni57itc.0!nntp.google.com!y22no40884ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 27 Feb 2019 12:46:17 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=165.225.72.126; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S NNTP-Posting-Host: 165.225.72.126 References: <2199b15b-d704-403f-a6c4-00fab29792d5@googlegroups.com> <72738cc8-3f65-4cc1-8c61-b1166cb5e3c2@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada in command / control systems From: Maciej Sobczak Injection-Date: Wed, 27 Feb 2019 20:46:18 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 4681 X-Received-Body-CRC: 1854678049 Xref: reader01.eternal-september.org comp.lang.ada:55708 Date: 2019-02-27T12:46:17-08:00 List-Id: > > In what way it is not scalable? >=20 > You have a model running a simple loop: read all inputs, calculate,=20 > write all outputs. If you have events, many loops, input/outputs that=20 > come and go, you are in deep trouble. If you have 10k inputs all=20 > asynchronous? I agree with these examples, they would be very challenging for Simulink. B= ut I did not refer to Simulink specifically, but to the MBD as a general ap= proach. There is no reason to limit MBD to "a model running a simple loop" = only. > Add here lack of any modularity and abstraction. Here I disagree. Even if we stick to Simulink (which was never intended), o= perators can nested and higher-level modules can be easily created. > It is OK=20 > when fancy blocks and edges fit into one screen. What about two? What is= =20 > when they do not fit into ten football fields? What if your source code does not fit into one screen? It's the same proble= m and has similar solutions. At least on diagrams, lines going over the football field can be continuous= , which makes them somewhat easier to follow. This has no equivalent in sou= rce code and if you have the same signal referred by N places in source, th= ere is no visual clue that they are related at all. > >> The software designed this way is not verifiable, non-testable. >=20 > How do you merge or decide if two graphs are equivalent? This has nothing to do with testability. It's the configuration management = thing and I agree that graphical tools are at disadvantage here and I very = much prefer to diff and patch text than diagrams. Nobody seems to care, tho= ugh and it has to be admitted that tool vendors, on their part, are catchin= g up in this regard, too; newer tool versions become more and more passable= in this area. > So, for the sake of argument, let's consider Ada program a requirement=20 > and Ada compiler a generator of object code (which Ada compiler indeed is= ). >=20 > I claim that Ada is an infinitely better requirement language than=20 > Simulink blocks. You are almost correct, except you have mixed levels. Simulink blocks are c= onsidered low-level requirements and Ada source code is further below it in= the hierarchy. So it cannot be better. It can be better than something at = the same level, for example C source code. But it cannot be better than som= ething higher, because you cannot replace one with another. However, it is reasonable to treat package specs (especially with contracts= ) as low-level requirements, which are then fulfilled at the implementation= level by package body sources. Now your claim would be interesting - and I= would actually agree. I have actually promoted such idea on one of the Lin= kedIn groups. But nobody cares. Get ready for MBD. > It is like with all other entitlements. When you run out of other=20 > people's money the party ends... But you have noted yourself that other domains are happy to bleed to keep f= inancing this mess. So the party goes on. --=20 Maciej Sobczak * http://www.inspirel.com