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: Wed, 27 Feb 2019 10:33:07 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <2199b15b-d704-403f-a6c4-00fab29792d5@googlegroups.com> <72738cc8-3f65-4cc1-8c61-b1166cb5e3c2@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:55689 Date: 2019-02-27T10:33:07+01:00 List-Id: On 2019-02-26 22:25, Maciej Sobczak wrote: >>> Note also that software engineering world, especially in the industrial and critical domains, is slowly (?) drifting towards model-based techniques. >> >> Hmm, it was that way for 20 years. > > And for 30 years the ecosystem of programming languages did not make any substantial progress, either. What is bothering me is that these mechanisms, even though acting slowly, can or already are crossing the threshold of critical mass. I have been expecting a collapse for a long time as more and more programmers were required. That should eventually bring the economy down. But it seems that so far things are kept in balance as other parts of the economy are bled to pay for software development. >> Tools like Simulink reached their limit of handling >> 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. I think that problem-specific languages must necessarily have more problems than general purpose ones because of the problem space boundaries. One tinny step out and you are lost. >> It is not scalable, not maintainable etc. > > In what way it is not scalable? You have a model running a simple loop: read all inputs, calculate, write all outputs. If you have events, many loops, input/outputs that come and go, you are in deep trouble. If you have 10k inputs all asynchronous? Add here lack of any modularity and abstraction. It is OK when fancy blocks and edges fit into one screen. What about two? What is when they do not fit into ten football fields? >> The software designed this way is not verifiable, non-testable. > > I disagree. I do not see any fundamental obstacles for testing such software. There are requirements, there are inputs and there are outputs. There is nothing missing. How do you merge or decide if two graphs are equivalent? Complexity escalates as you move from simple text language, to a formatted text language, to a graphical language. >> If you use a code generator you basically can skip most of validation if >> the generator is kind of "certified". The trick works because the model >> 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 least with regard to DO-178C, all objectives need to be achieved. So, for the sake of argument, let's consider Ada program a requirement and Ada compiler a generator of object code (which Ada compiler indeed is). I claim that Ada is an infinitely better requirement language than Simulink blocks. >> This will end sooner or later. > > Probably. But the end of MBD will not mean coming back to coding by hand. Even if we forget about technical merits, there is just no business incentive 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. It is like with all other entitlements. When you run out of other people's money the party ends... > 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. :-) Your intuition is correct, but that is because existing PLCs are incredibly primitive when compared with most simple programs. That ends and ends soon. A typical production line cannot be designed as a bunch of brain-dead PLCs anymore. Individual controllers become interconnected, integrated into larger enterprise subsystems. Management require cloud services, even more outrageously stupid ideas are in the pipeline. When PLC will awake from its vegetative sleep we will see. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de