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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Things that OO programming lacks Date: Mon, 17 Nov 2014 22:05:10 +0100 Organization: cbb software GmbH Message-ID: <1dqj0bjtbadcq$.150sjuwku2zbk$.dlg@40tude.net> References: <10d9w.55626$8w1.22302@fx12.iad> <150er0b62wsh3$.1xabmp81w5kdw.dlg@40tude.net> <1azsoc77wjhmi$.1grmnnlq033tz.dlg@40tude.net> <5yzci4a8snfg.1dfsqjyvneeym$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: wfRpp7ltpEWhI2na6kgpfA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:23488 Date: 2014-11-17T22:05:10+01:00 List-Id: On Mon, 17 Nov 2014 19:23:10 +0100, G.B. wrote: > On 17.11.14 18:28, Dmitry A. Kazakov wrote: > >> No language can describe the program's meaning. > > Interestingly, we have a manual that does just that, > WRT some frame of reference, and WRT to a meaning > of "meaning", and even using occasional hints at the > world ("environment", "file", ...). Nope. RM describes language semantics in terms of computational environment. This has nothing to do with the program meaning. Meaning /= behavior. > Also, English can help predicting or explaining what an Ada program > means. Programmers and authors doing this will refer to the source > text, I think? It seems fair, too, to say that "Volatile" conveys > a good idea of what will happen to a storage cell. This > means something. It means exactly nothing in the problem space [without the program designer]. >>> For example, an FSM situation (cf. Niklas' post) that could >>> be bridled by narrowing the error space with the help of >>> new language seems clearly better than trying to find the >>> cause by divide and conquer. >> >> Why is it clear? I don't see it clear. FSM are proven to be extremely >> complex to use, error-prone and unmaintainable. That is because states are >> as uncomposable as events are. If you add new or remove old states you are >> in deep trouble. > > Assuming there is a way to pick important states, > e.g. measured by the fraction of customers affected. > Assuming further that they are textually connected > alongside the FSM definition. > Then, if this additional information helps isolate effects > affecting more customers, e.g. via hooks, the rest can go into > the "others" clauses, or be otherwise listed as not important. > That is, importance of states is not part of the definition of > the FSM, but it results from the definition of the situation > that warrants payed programming in the first place and therefore > should have an influence on the program text. Assuming there is a way to pick important sequences of memory bits starting at the address 0, measured by affected customers. [I love to see how memory dumps would affect our customers!] They are certainly connected to the machine hexadecimal code. Then continue the absurdity you wrote above further... >>> Let's say you can't think of any interpretation of >>> >>> Obj_1 (*) Obj_2 >>> >>> other than in terms of operations of the types of Obj_N. >> >> No, I cannot. For anybody the notation x*y means take x, take y, apply *, >> get the result. > > Say, "(*)" stands for ¡÷. I don't think that many Ada programmers > will then have an idea of how to "apply ¡÷" to those objects, > or indeed, how to interpret "x¡÷y". The arrow needs introduction, > and we are free to make it stand for what we need it to stand for. > > Example: > > "Obj_1 exists while Obj_2 exists". In Ada *every* object exists when named! Try to write an Ada program where you could name a non-existing object. > (I'm expecting at least one occurrence of "Bad design!" now, > but I'm curious about how an existing paradigm, or indeed > a pattern, will resolve those conflicting requirements WRT scopes. ;-) It is no design. [In 60's relationships between names and objects was hotly debated. I vaguely remember some lengthy and quite stupid passages on this subject in ancient books I read thirty or so years ago. Already then in late 80's it was nothing but eyebrows raising.] >>> In particular, they could reflect the intention of introducing (*). >> >> Why anybody liked to introduce (*)? > > The "(*)" can mean a way to formally describe relationships of entities > named in the program and considered important, if by comparison > the relationships are only implicit in the current programming > language. Relationship between *objects*, if computable, is a Boolean-valued *operation*: xRy -> Boolean If not computable or not objects, what are you talking about? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de