Re: Things that OO programming lacks

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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