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.yTvCNOh9TRCAIcX40YItlQ.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada in command / control systems Date: Thu, 28 Feb 2019 18:43:58 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <2199b15b-d704-403f-a6c4-00fab29792d5@googlegroups.com> <72738cc8-3f65-4cc1-8c61-b1166cb5e3c2@googlegroups.com> <9807ec3a-4c34-4641-acfa-e9cf22de95ce@googlegroups.com> NNTP-Posting-Host: yTvCNOh9TRCAIcX40YItlQ.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 X-Mozilla-News-Host: news://news.aioe.org X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:55719 Date: 2019-02-28T18:43:58+01:00 List-Id: On 2019-02-28 14:12, Maciej Sobczak wrote: > >> You can build blocks out of blocks. In terms of software development >> this is trivial aggregation. Modern languages have a lot more under the >> belt. > > And a lot of coding and design standards saying what not to use. :-) > >> How about user-defined types of edges? [...] > > This is thinking in terms of solution, not in terms of a problem. > Why would I care about features that are borrowed from code-based programming languages in a model-based tool, without a particular problem to solve? How would I pass a complex input to a block, a matrix, user credentials? >> Groups of edges used >> together? How about parametrized blocks? Substitutability of blocks upon >> connection with other blocks and polymorphism of blocks and edges? >> Interfaces of blocks constraining implementations of? > > I don't see any reason why a model-based tool should not have them. But I also don't see any reason to have them unless I have a problem where they are needed. The problem is software decomposition and reuse. Simulink's is an ultra low-level language, lower than assembler, IMO. All its constructs are used literally. >> The biggest >> problem was missing edges. If a block misses an input how to find the >> block providing it among thousands of blocks? > > Which is exactly the same problem as with source code. If the information is missing, you have to figure out where to get it from (among thousands of source modules, of course, no less). That is why the general purpose languages support modules, packages scoping, visibility and lots of other means Simulink does not have. It was a long way from global variables and gotos to the techniques used in modern language. Simulink is in the square one. >> Instead we took the internal representation of the diagram. It was a >> file with sections describing blocks, edges and their connections. So we >> edited that file directly! > > Yes, Tcl makes it possible. Which might be actually a proof that model-based approach can be a safe choice if such a rescue option exists. Any approach would be safe from this point view. > Having said that, I have also seen a tool that used XML as an underlying format, where everything was "linked" by means of UUID identifiers, woven as attributes in absolutely every entity. I think that character-wise, these UUIDs made a majority of the file content. Even though it was formally still a text file, modifications by hand were just impossible. So, it all depends on the tool vendor. But this is certainly something to look into at tool evaluation time. Yes, you need a finer measure instrument to judge complexity. >> When the patched file got loaded, it was >> rendered as an utter mess of overlapping blocks and edges leaving >> nowhere, piercing the diagram like cosmic rays. Naturally our manual >> editing destroyed the layout! The automatic rearranging tool indignantly >> crashed when faced proud results of our creativity. The diagram worked >> but nobody could see it. > > Interesting story about a particular low-quality tool, saying nothing whatsoever about the approach as a whole. You mean Simulink has a better diagnostics? The diagnostics is as good as the language is. Ada has better diagnostics than C because of the language properties. >> OK, but if you have a block of N inputs and M outputs which is supposed >> to implement some part of controller activity. In order to test it, you >> must know what kind of analytical function it represents. > > And in what way is it worse from source code? I can have specifications and can decompose a problem into testable units. Methods used in control, like process identification, are very different. If you don't believe in OO analysis you would agree that there is more than one method to model reality. The general purpose language offers much more freedom of modeling the problem space entities through language constructs than the domain-specific ones. >> In my view the level is determined not by artifacts of software design >> process but by the abstraction level > > Yes, and this is determined by the fact that you can provide *various* lower-level implementations/refinements of higher-level requirements, thus leaving some space for engineering work and decision making on the way. As long as models don't constrain the underlying implementation (source) in a way that would make them 1:1 equivalent, they are considered to be higher-level than source. That is not enough to be higher level. The variance must have some meaning to the problem space and to the implementation. Otherwise you could always reverse roles of the meta and object languages. This (abstraction inversion) happens all the time, e.g. when an application level protocol is used as a transport etc. > Yes, and it didn't go anywhere. > Or maybe the enterprise folks, who where fond of UML at that time are now all gone "agile". But in general, OOA&D is still alive and kicking, especially in the industrial applications. In my experience OOA&D is dead and buried. None of our customers mentioned in for more than a decade. As for "agile", yes, it is still a hype. Though it degraded to rather a formality, void of its original malice. If you have nightly builds, you are "agile" and everybody is happy. > Yes, let's fasten our seatbelts. But in the context of this discussion, this is not a rival, it is *another*, *additional* reason to forget about hand-coded sources. It's not like MBD will lose. It's really one more reason for companies not to write source code. The source code will lose, because there will be even more ways not to write it. But the point is that source code is still there. They only pretend that there is none and reality check is around the corner. >> Yes, for a while. But you and I have suspicion that this is not really >> sustainable. > > In a sense you are right, it's all pile of shit. But still, there is no coming back. People are really determined to invent all kind of necessary shit, as long as it saves them from writing code. And this is what bothers me. They can keep on inventing more and more bizarre forms of "non-code" to write, that will not make it work. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de