Re: Things that OO programming lacks

[Georg Bauhaus <bauhaus@futureapps.invalid>]

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.

>> 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. You look at the task's
definition, and you still miss the part that caused the I/O disaster.
That's because "connecting" data to the stream can happen anywhere
this stream is visible, and if you do *not* apply C-style discipline,
then the *language* won't help. (Broken record: "bad design, bad
design, bad design, ..." Another broken record: "use int properly,
use int properly, use int properly, ...")

Any competent engineer can write perfectly good programs in
the assembly language he knows, for the machine he knows.
That's beside the point, though, and it hides all the difficulty
that an undefined (before the fact) word like "competent engineer"
must produce.

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

> In relational there are relations (and a
> fixed set of types).

(I learned that in "relational" there are arbitrarily many types
("domains"). Even in some of its restricted SQL incarnations.)

> If you want going data-driven

I don't want to be driven. ;-) Starting from my universe, I notice that
it determines orders which cannot be designed away:

"First the water, then the acid, otherwise it won't be placid!"
"Be sure to open the lid before you add further ingredients,
  then close the lid again."

I need necessary orders to be expressed, not denied for methodological
reasons of a foreign universe. In short, I want a higher level:

- procedural includes assembly power (minus a bit)
- OO includes procedural power (minus a bit)
- ??? includes OO power (minus a bit)  <-- this I want

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.

By analogy, monads are a way of integrating I/O with functionism.
I want something like this in the OO programming world, at the level
of language definition, so that I can answer questions I might
be asked about a program and its effects simply by pointing my finger
at some one line of text.

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.  I would like the language
to have syntax, say "{<#}" or "{#>}", for

   Event_1 {#>}  Obj_1, Obj_2, Obj_3

The cheap language version would start to make these pieces of syntax
mark relationSHIPs first, and then the compiler would check that these
relationships actually exist. If the marks turn into relations, fine,
but that makes relations just a way to formalize specific relationships
behind the scene.