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: border2.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: "G.B." Newsgroups: comp.lang.ada Subject: Re: Things that OO programming lacks Date: Mon, 17 Nov 2014 19:23:10 +0100 Organization: A noiseless patient Spider Message-ID: References: <87389olqie.fsf@ixod.org> <10d9w.55626$8w1.22302@fx12.iad> <150er0b62wsh3$.1xabmp81w5kdw.dlg@40tude.net> <1azsoc77wjhmi$.1grmnnlq033tz.dlg@40tude.net> <5yzci4a8snfg.1dfsqjyvneeym$.dlg@40tude.net> Reply-To: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 17 Nov 2014 18:22:55 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="b96887e80893c84a90c3007226ca0d1c"; logging-data="22553"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19jWHaw1rAA589s7nZLlNUZj3ahH1+QLDI=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: Cancel-Lock: sha1:QhDj4AaBjBeWKqRKJevN4n49+BU= Xref: number.nntp.giganews.com comp.lang.ada:190790 Date: 2014-11-17T19:23:10+01:00 List-Id: 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", ...). 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 is always up to the programmer to map program entities to the outer > world's meanings. A change of program text, back and fro, is effective in creating an outer world that is measurably different each time, accordingly. So, yes, the programmer needs to be able to match source entities to effects in the outer world, and describe the relationship. >> 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. >> 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". If Obj_1 and Obj_2 are not, and cannot be in the same dynamic scope because of conflicting requirements, then this states their relationship explicitly. Yes, one could program some emulation of a co-existence check, such as a registry of objects. But this only works around the problem (of not having expressive language). (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. ;-) >> 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.