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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,763b126bf5276f4c X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.158.31.10.MISMATCH!newsfeed-0.progon.net!progon.net!news-zh.switch.ch!switch.ch!news.belwue.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Communications of ACM: Sir, Please Step Away from the ASR-33! Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <72b8fb96-2b5e-4ef8-8099-39361eeea853@glegroupsg2000goo.googlegroups.com> <878vzbwa61.fsf@hugsarin.sparre-andersen.dk> <8ns4v1Fk2dU1@mid.individual.net> <2vc8dxz8lc3t$.frc39a6lzjvt.dlg@40tude.net> <8ntp4kFo9qU1@mid.individual.net> <9cqhbxmdgs8x.nohduviggb5a$.dlg@40tude.net> <4d19c37f$0$7669$9b4e6d93@newsspool1.arcor-online.net> <1hd23hih9nr3v$.qzcce27pd1u1.dlg@40tude.net> <4d19e020$0$6885$9b4e6d93@newsspool2.arcor-online.net> <1sa8js3de7m9a.1u4v3u0e8fpvy$.dlg@40tude.net> <4d1a0531$0$6980$9b4e6d93@newsspool4.arcor-online.net> <1hok68cs370tc.1lt858ruxu3m5.dlg@40tude.net> <4d1b2fe1$0$7654$9b4e6d93@newsspool1.arcor-online.net> <4d1b629f$0$7653$9b4e6d93@newsspool1.arcor-online.net> Date: Wed, 29 Dec 2010 18:26:41 +0100 Message-ID: <1d9x4ua0ui52i.1i8745gcebazi$.dlg@40tude.net> NNTP-Posting-Date: 29 Dec 2010 18:26:41 CET NNTP-Posting-Host: 56b3d558.newsspool2.arcor-online.net X-Trace: DXC=fh>^NNH34X@0YVY]kmLTlDA9EHlD;3YcB4Fo<]lROoRA8kF On Wed, 29 Dec 2010 17:32:31 +0100, Georg Bauhaus wrote: > On 29.12.10 15:52, Dmitry A. Kazakov wrote: > >>> No, using tools, they will be guided in the direction the >>> tool knows best. Just like an Ada compiler will instruct >>> us to not leave out values in a case distinction. >> >> Ada is capable of this because it has types. It is not because Ada knows >> anything about specific types, but because the programmer can use the type >> system to express constraints the compiler will then check. There is no >> magic knowledge Ada oracle sheds to guide programmers. All information is >> exclusively from the programmer. > > The information in models is man-made, too. Thus the argument of "guidance" is finally ditched? >> Any tool is no different, it is a >> dangerous delusion to believe otherwise. > > There are differences among tools' domains. Right. If the domain of UML is supposed to be "generating Ada code," then, thanks, I prefer GPS. If we are talking about a *real* domain, like designing an application X that does Y, then convince me that UML does it better than Ada and what does prevent Ada from providing same level of support. > The crucial part is that an Ada compiler guides you by > answering the question "Which case distinctions do I > have to change?" (provided you don't use C style "others" > for subtypes typically appearing in case statements). What is "case distinctions"? > Modeling tools will answer different questions. But they will > answer them when answers are more difficult to find using only > Ada source text and human inference. So it is about things like AdaBrowse? I have no question to the source texts. Right mouse click in GPS, then select "references." >This is because, when > modeling, humans have expressed one set of notions. This > set is slightly different from the set expressed in Ada source. Certainly yes, if you compare UML input with its output. But I don't buy this trick. You have to show that the guidance given while connecting blocks is better than the guidance given by Ada compiler when compiling Ada program. It is NOT. >>> Even StP went far to make >>> sure your model was checked in all sorts of directions. >> >> Assembler checks the code in that sorts of direction too. > > Assembly language cannot, for example, *express* IS-A > relations, Ada can (there is syntax for it), UML too, > and more than this. No, UML cannot, it is untyped as Assember. You cannot define a type of blocks and then derive a new type from it, for example, blocks with the number of incoming arrows equal to the number of outgoing arrows multiplied by two. IS-A at the language level is a relationship between two types. UML does not have this. If you are rather talking about the language code you are generating using UML, then Assembler can perfectly express IS-A in that language too, by appropriately initializing appropriate registers. It is Turing complete. You are confusing the meta language with the object one. >>> The compiler is a guide where it "knows the area". >> >> Why this area must be different for an Ada compiler and a UML diagram >> interpreter? > > Ada and UML deal with a different set of objects and notions. > There is some correspondence, but the focus is different. Why Ada cannot focus on what you wanted? >> Why a thing important to the program must >> be external to it? > > The system architecture is such that concurrent processes > communicate via a data store. So the important thing happens > to be external to the program. It is a requirement that I > cannot change. But a model can express the external control > as a system element nevertheless. Nope, it is likewise external to the model. You didn't answer the question: what is the crucial difference between the code in UML (a bunch of blocks) and the code in Ada (a bunch of texts). The semantics of the program (what and if it models anything) is irrelevant, because we assume them doing the *same* thing. Please, do not compare the output of UML with an Ada program. Compare the man-made inputs. >> Why this thing must be external in Ada, but internal in UML? > > An external control can be an element of a UML diagram or > other modes of expression, but not in Ada (not directly). Why? > The set of objects directly expressible in some modeling > language may be larger (or different). Why cannot they be "directly expressible" in Ada? >>> Suppose there is a setup like the following: some external entity >>> acts as a mutex controlling concurrent activities of >>> co-operating "jobs". >> >> Don't use low-level concurrency primitives. Ada has better means for that. > > That's the non-argument I'd like to again ask to avoid: > the setup is given, as is. That's it! The setup seems to be: "have to use UML." I challenge this setup. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de