Re: Things that OO programming lacks

[Georg Bauhaus <bauhaus@futureapps.invalid>]

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.

>> 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.
Which was the point. Sometimes there are no dedicated designators for things
like these properties of the program. (As there are, approximately,
for learning about the order in time of some intended effects from textual
order of accept statements.)

> 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. 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?

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?