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:a05:660c:2c6:: with SMTP id j6mr3829460itd.9.1551216302332; Tue, 26 Feb 2019 13:25:02 -0800 (PST) X-Received: by 2002:a05:6830:134b:: with SMTP id r11mr7254otq.213.1551216302129; Tue, 26 Feb 2019 13:25:02 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.166.215.MISMATCH!y22no4399ita.0!news-out.google.com!v188ni23itb.0!nntp.google.com!y22no4395ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 26 Feb 2019 13:25:01 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=165.225.72.109; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S NNTP-Posting-Host: 165.225.72.109 References: <2199b15b-d704-403f-a6c4-00fab29792d5@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <72738cc8-3f65-4cc1-8c61-b1166cb5e3c2@googlegroups.com> Subject: Re: Ada in command / control systems From: Maciej Sobczak Injection-Date: Tue, 26 Feb 2019 21:25:02 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:55676 Date: 2019-02-26T13:25:01-08:00 List-Id: > > Note also that software engineering world, especially in the industrial= and critical domains, is slowly (?) drifting towards model-based technique= s. >=20 > Hmm, it was that way for 20 years. And for 30 years the ecosystem of programming languages did not make any su= bstantial progress, either. What is bothering me is that these mechanisms, = even though acting slowly, can or already are crossing the threshold of cri= tical mass. > Tools like Simulink reached their limit of handling=20 > complexity of the software. This is an interesting observation. But it assumes that banging out code is= an approach that did not reach such limits. Yet the notion of "big freeze"= means that we have hit some limits one way or another. > It is not scalable, not maintainable etc. In what way it is not scalable? > The software designed this way is not verifiable, non-testable. I disagree. I do not see any fundamental obstacles for testing such softwar= e. There are requirements, there are inputs and there are outputs. There is= nothing missing. > If you use a code generator you basically can skip most of validation if= =20 > the generator is kind of "certified". The trick works because the model= =20 > is not considered code. No, there is no trick. You can generate code from requirements expressed in= other ways, too (and models are considered requirements for this purpose).= There is nothing special in MBD that allows to skip any verification, at l= east with regard to DO-178C, all objectives need to be achieved. > This will end sooner or later. Probably. But the end of MBD will not mean coming back to coding by hand. E= ven if we forget about technical merits, there is just no business incentiv= e to do so. People expect compilers to be free (like in free beer), whereas= the same people still accept being charged for model-based tools. So there= is no coming back. > > I very much prefer properly designed PLC solution than some random crap= disguised as source code, even in the best of languages. >=20 > Good luck with that... I guess there are more buggy programs than dysfunctional PLCs. I'm not sure if there are more bug-free programs than well-working PLCs. No hard data, though, just intuition. :-) --=20 Maciej Sobczak * http://www.inspirel.com