Re: Things that OO programming lacks

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

On Mon, 17 Nov 2014 16:17:59 +0100, G.B. wrote:

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

Because nothing can happen. No language can describe the program's meaning.
It is always up to the programmer to map program entities to the outer
world's meanings.

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

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

No, I cannot. For anybody the notation x*y means take x, take y, apply *,
get the result. This is the basic language structure of nouns bound by
verbs.

> Is this reason enough to say that other interpretations
> are impossible?

Like what?

> In particular, they could reflect the intention of introducing (*).

Why anybody liked to introduce (*)?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de