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: border1.nntp.dca1.giganews.com!nntp.giganews.com!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Things that OO programming lacks Date: Tue, 18 Nov 2014 14:42:21 +0100 Organization: cbb software GmbH Message-ID: <55b6ald1m6ow$.1rho1th3fqrgm.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> <1dqj0bjtbadcq$.150sjuwku2zbk$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: nyHeW7QjJmC1odUjK4LkDA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: number.nntp.giganews.com comp.lang.ada:190828 Date: 2014-11-18T14:42:21+01:00 List-Id: On Tue, 18 Nov 2014 11:14:20 +0100, Georg Bauhaus wrote: > On 17.11.14 22:05, Dmitry A. Kazakov wrote: > >> It means exactly nothing in the problem space [without the program >> designer]. > > It [the source text] means a lot with the program designer present, > also to a reader. Which is the text's important use in the programming > situations described, which is also the reason source text should be > expressive. Still as a *program* it means nothing, but bit shuffling. Any other meaning is in the programmer and customer heads. >>> 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. > > Sure. And even unnamed objects can be known to likely co-exist. The statement > > X := S'(...) + T'(...); > > has two (Ada-wise) unnamed objects. But just names, somewhere in a program, > plus things like calls using the names are not expressive enough for some > quick answers that programmers need to give by referring to the source text. Name them better. > Which was the point. Sometimes there are no dedicated designators for things > like these properties of the program. Which is mere bad design. Important things must have corresponding language entities. E.g. objects, types, operations, modules etc. You must talk about them, in the language. Your point was that object, types, operations, modules might be not enough to maintain this mapping. Which would constitute a new paradigm. Yet, you failed to present anything beyond objects, types, operations, modules. > (As there are, approximately, > for learning about the order in time of some intended effects from textual > order of accept statements.) That is not a language term, so far. And unlikely it would. In order to spell constraints there are correctness provers. Such constraints (like preconditions, post-conditions, invariants) are expressed in a meta-language of the prover, e.g. in SPARK. This is not a new paradigm. You could use a prover in most of paradigms with different chances of success. The best it works with OO, because OO adds a lot of things at which you could hang your constraints on. And, importantly, you cannot fuse prover with the compiler. It is inherently inconsistent. Both language must be kept apart. >> Relationship between *objects*, if computable, is a Boolean-valued >> *operation*: >> >> xRy -> Boolean > > Certainly every computation is Boolean valued operations if you reduce it > to logic. Relation is a logical term. > But since for the reasons you named (when mentioning Post-Turing) > we shy way from Boolean valued operations for everything, why not invent > something that expresses what programmers need to known in order to make > those answers? To which questions? A relation between object is a part of the program behavior expressed in the form of an operation. All answers the programmer wants is in the implementation of the operation. E.g. function ">" (Left, Right : List_Element) return Boolean; Ada already has everything needed to have this. > In particular, I am free to work with the assumption that a relationship > is not just a binary relation, since the latter is determined, invisibly, > by just the objects. Somehow. Can every relationship be expressed *well* > by only producing enough dummy objects to help determine the relationship > of other objects? Is this expressive, or does it add unnecessary complexity > to program design, and to program analysis? I suppose you are confusing relationships between objects with relationships between types and correctness statements. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de