Re: Things that OO programming lacks

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

On Fri, 14 Nov 2014 16:29:56 +0100, G.B. wrote:

> On 14.11.14 14:35, Dmitry A. Kazakov wrote:
>>> That's the theory. But in practice, having all the hard stuff written
>>> >already just promotes cutting and pasting of a different color. The code
>>> >that*uses*  those classes is normally not reusable. That's what is cutting
>>> >and pasting. It's been shoved down a level or two.
>> Maybe. But, again, what would be better?
> 
> Better? A mode of expressing what we know beyond our objects,
> in dedicated language:
> 
> Since programmers are starting to know more about patterns
> of connecting objects, I suppose something expressing those
> patterns more clearly would be useful.

What objects? There is none, as you thrown OO under the bus...

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

> Another important example is events.

I didn't list event-driven AKA data-driven paradigm in my list of
paradigms, since it is so horrific, that nobody should seriously consider
it as useful.

> Consider a system with many inputs, many outputs, and also
> some treads.

Which are? Remember the paradigms. If you are not going to introduce a new
one, there are no things you listed. In OO there are objects. In the
procedural paradigm there are subprograms (and a fixed set of types). In
functional there are functions. In relational there are relations (and a
fixed set of types). That is.

If you want going data-driven show how it could be done in the first
approximation at least more safer than randomly generated hexadecimal
code... (Saying no word about reuse)

[...]
> To me these look like a poor workarounds, Pre more than the types TK,
> even when they assist the client programmer writing calls of
> subprograms in proper order.

This is meaningless at best. If subprograms cannot be called freely, this
is a bad [procedural] design, per definition of. You should fix your
decomposition, as it evidently goes along wrong lines = couples
subprograms. Subprograms in procedural decomposition meant independent with
well defined interfaces. BTW, from this immediately follows, for example,
that global variables are bad.

> To have language for expressing connections in a program would
> be better.  We only got tools that show graphs of a few arrows,
> as in design diagrams for interfaces and models. But we do not
> really have source text specifically addressing order of events,
> and connections made on the occasion.

Not at all. There are tons of graphical languages having fancy lines all
over the screen. That helps in no way. In fact all of them are greatly less
safe, unmaintainable and inefficient as a bonus.

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