Re: Things that OO programming lacks

["G.B." <bauhaus@futureapps.invalid>]

On 16.11.14 11:18, Dmitry A. Kazakov wrote:

>> I mean our objects, not OO objects. This is about expressing notions.
>
> There is no "our objects" in non-object-oriented paradigms.

[...](*)

To establish a paradigm of something that does not exist yet
seems premature.

What does exist, though, is a problem of expressive incompleteness.


Here is the situation:
there always are questions about what the heck happened
as a consequence of the execution of a program, e.g. failure.
The questions are formulated in a language used by companies,
by heads of departments, by customers, by lawyers etc. These
need to be answered, and the answer will, at some stage,
involve the programmer. A good PL will provide for answers
with the help of dedicated source text. That's the idea.
If you find that a truism, I wonder why nothing changes,
but in any case, it won't stop scrutinizing the facts.
(The idea is thus not to start with some paradigm at
the level of finished formalism.)

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.


>> If Obj_1 and Obj_2 are objects, then I would like the language
>> to have syntax, say "(*)", for
>>
>>      Obj_1 (*) Obj_2
>>
>> which would *not* be a function call.
>
> Then these are not objects. The only thing you can do with objects is to
> use the operations of. This is called typing.

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.
Is this reason enough to say that other interpretations
are impossible? In particular, they could reflect the
intention of introducing (*).

(ow would any paradigm have been created if its creators would
have had to start from the paradigm?

__
(*) Objects are inevitably part of thinking when programming,
even before all OO-related notional strictures applied to
the word. Engineers would never arrive at anything new if they
just re-iterated learned procedures.