Re: Things that OO programming lacks

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

On Sat, 15 Nov 2014 20:46:54 +0100, Georg Bauhaus wrote:

> On 14.11.14 17:32, Dmitry A. Kazakov wrote:
>>  But, again, what would be better?
> 
>>> Better? A mode of expressing what we know beyond our objects,
>>> in dedicated language:
> 
> I mean our objects, not OO objects. This is about expressing notions.

There is no "our objects" in non-object-oriented paradigms.

>>> For example, "connections" may refer to order of calls in time,
>>> and to "flow" caused by "data".
>>
>> For example Ada.Streams show us "connecting patterns".
> 
> Ada.Streams doesn't show much, since some connections are implicit.
> Which is the point. "Open" would be a hint at the object to/from
> which data will flow, but you'd still have questions if a different
> task object somehow has access to the stream.

Again, what paradigm are you talking about? Task is an object in OO. In
other paradigms there no such thing. E.g. in the procedural paradigm there
will be a set of subprograms to start, stop implicit tasks, proxy data
types like task ID, but never an explicit task object.

> You look at the task's definition,

And this is where you must start. Since the task is not an object, how a
task is spelled in your paradigm?

>>> Another important example is events.
>>
>> I didn't list event-driven ...  nobody should seriously consider
>> it as useful.
> 
> GUI...  Suppose it could be made less of a burden to program
> any advanced multithreaded GUI, adding controls and interactions.

GUI frameworks you are talking about are not written or interfaced in a
data-driven language (DDL). They are in OOPLs. The event-driven
architecture of such applications /= the programming paradigm, which is
still OO and partially procedural. 

When GUI applications are written in a DDL they are disaster, example:
LabView.

 > I want a program text to tell its readers what is supposed to happen
> in certain situations.  I want that information to be explicitly
> stated directly in source text, without inference, with the help
> of dedicated visible language features.

This is what *any* programming language does. Its text (program) describes
behavior (in some computational environment). What you probably missed is
that the behavior is *always* described in the language terms. Thus
"happens" and "situation" are the language domain terms, not the reality
terms. If you accept that, your statement is a truism. If you mean the
reality, the statement is just meaningless. Only God speaks the language
which computational environment is the reality.

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

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