It seems that someone once again rediscovered the benefits of component programming, in the context of OOP, but (as usual) without the more mathematical and principled approach of something like ranges and algorithms:

<http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/flow-design-cheat-sheet-ndash-part-i-notation.aspx>

"The purpose of FUs is to process input and produce output. FUs are transformational. However, FUs are not called and do not call other FUs. There is no dependency between FUs. Data just flows into a FU (input) and out of it (output). From where and where to is of no concern to a FU. This way FUs can be concatenated in arbitrary ways: (...) Each FU can accept input from many sources and produce output for many sinks: (...) Connected FUs form a flow with a start and an end. Data is entering a flow at a source, and it´s leaving it through a sink. (...) You could say, Flow-Orientation is about tackling complexity at its root cause: that´s dependencies. “Natural” dependencies are depicted naturally, i.e. implicitly. And whereever possible dependencies are not even created. Functional units don´t know their collaborators within a flow. This is core to Flow-Orientation. That makes for high composability of functional units."

BTW, I just wrote my DConf proposal. I've been experimenting with a different style of not-quite-OOP in a real project and so far I'm really happy with the results. I've been making use of Jean-Louis' openmethods.d library, as well as other D features and techniques. The result is a quite nice balance of simplicity, expressiveness and performance. I'm really looking forward to telling you all about it :-)

On Wednesday, 14 February 2018 at 09:39:20 UTC, Luís Marques wrote:
> It seems that someone once again rediscovered the benefits of component programming, in the context of OOP, but (as usual) without the more mathematical and principled approach of something like ranges and algorithms:
>
> <http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/flow-design-cheat-sheet-ndash-part-i-notation.aspx>
>
> BTW, I just wrote my DConf proposal. I've been experimenting with a different style of not-quite-OOP in a real project and so far I'm really happy with the results. I've been making use of Jean-Louis' openmethods.d library, as well as other D features and techniques. The result is a quite nice balance of simplicity, expressiveness and performance. I'm really looking forward to telling you all about it :-)

"Flow-Orientation is about tackling complexity at its root cause: that´s dependencies."

That's an interesting statement (from that article).

Seems we are getting closer and closer to modelling programming in accordance with how the brain programs itself. Kinda of makes sense really - nature seemed to work this all out a long, long time ago.

Small units. Data just flows in and out. The units don't 'know' each other. Their are no explicit dependencies between the units themselves (hence neuroplasticity).

Instead, what's important, are pathways by which they can communicate (concatenate) their input and output, and the subsequent data flows that arise from that collaboration.

In nature, increasing mass (complexity) arises from simple components.

If only that were so in the world of programming.

On Wednesday, 14 February 2018 at 09:39:20 UTC, Luís Marques wrote:
> It seems that someone once again rediscovered the benefits of component programming, in the context of OOP, but (as usual) without the more mathematical and principled approach of something like ranges and algorithms:
>
> [...]

Luna [1], a new programming language that was recently mentioned on Reddit, also appears to take this "flow-oriented design" approach. It's purely functional, not OO, and I'm curious to see how it evolves.

[1] http://www.luna-lang.org

On Wed, Feb 14, 2018 at 06:43:34PM +0000, Mark via Digitalmars-d wrote:
> On Wednesday, 14 February 2018 at 09:39:20 UTC, Luís Marques wrote:
> > It seems that someone once again rediscovered the benefits of component programming, in the context of OOP, but (as usual) without the more mathematical and principled approach of something like ranges and algorithms:
> > 
> > [...]
> 
> Luna [1], a new programming language that was recently mentioned on Reddit, also appears to take this "flow-oriented design" approach. It's purely functional, not OO, and I'm curious to see how it evolves.
[...]

This so-called "flow-oriented design" is hardly a new idea.  It has been around since Lisp and the Unix command-line. And of course, D ranges benefit greatly from it. :-)

The power of this idiom comes from the way it confers symmetry of API across diverse components.

In the traditional situation, if a library X exports methods foo() and goo(), and another library Y exports methods bar() and car(), then you cannot simply plug Y in where X is used, because their APIs are incompatible, and you need to write proxying code to bridge the "API impedance mismatch" between them.  For sufficiently complex APIs, this is highly non-trivial, and often leads to a lot of boilerplate like proxy objects, shim code, and other such artifacts.

For example, if X calls Y and Y calls Z, and X, Y and Z all have different APIs, then removing Y from between X and Z will require rewriting parts of X so that it will fit with Z's API.  And often this may not even be possible without essentially rewriting the entire subsystem.

However, under the component programming model, both X and Y would be unified under a single, universal API: input and output.  This makes their APIs symmetric: they become interchangeable with each other, from the API point of view.  Now you can insert/remove components in the middle of a pipeline without needing to rewrite everything around them, because the symmetry of the API ensures that the new component(s) will simply "just fit", no matter what order you attach them.

Of course, the limitation of this approach is that it only applies to problems that are amenable to be modelled as a linear pipeline.  For more complex problems that require non-linear algorithms, it will be necessary to use some other kind of API to accomplish what's needed. Though, the linearizable pieces of such algorithms can still benefit from the component / pipeline approach.

But even in non-linear problems, if you can boil down the problem to its barest essentials and unify the APIs of the relevant modules that way, then you can still reap the benefits of having an API that's symmetric across different modules.  One example of this is user-defined numerical types: in languages that support operator overloading, the expression syntax serves as the unifying "API"; as long as your custom numeric type conforms to this API (i.e., it is symmetric w.r.t expression syntax), you can simply just "plug it in" and it will Just Work(tm), for the most part (complications like floating-point idiosyncrasies aside).

Finding this sort of symmetry in API design is a hard problem in general, though.  While almost everyone can agree on "input + output" in the pipeline model, a universal API that encapsulates more complex tasks may not be so obvious. And as long as you can't get everyone to agree to it, it will be difficult to interoperate the respective modules.  This is why API design is very hard. :-)


T

-- 
"Real programmers can write assembly code in any language. :-)" -- Larry Wall

On Wednesday, 14 February 2018 at 19:53:31 UTC, H. S. Teoh wrote:
> On Wed, Feb 14, 2018 at 06:43:34PM +0000, Mark via Digitalmars-d wrote:
>> On Wednesday, 14 February 2018 at 09:39:20 UTC, Luís Marques wrote:
>> > It seems that someone once again rediscovered the benefits of component programming, in the context of OOP, but (as usual) without the more mathematical and principled approach of something like ranges and algorithms:
>> > 
>> > [...]
>> 
>> Luna [1], a new programming language that was recently mentioned on Reddit, also appears to take this "flow-oriented design" approach. It's purely functional, not OO, and I'm curious to see how it evolves.
> [...]
>
> This so-called "flow-oriented design" is hardly a new idea.  It has been around since Lisp and the Unix command-line. And of course, D ranges benefit greatly from it. :-)
>
> T

It's not a new idea but they've added a visual twist to it - you can see the program's data flow graph, manipulate it in various ways, and see how your input changes as it flows through the graph. So that's nice.

On Wednesday, 14 February 2018 at 18:43:34 UTC, Mark wrote:
> Luna [1], a new programming language that was recently mentioned on Reddit, also appears to take this "flow-oriented design" approach. It's purely functional, not OO, and I'm curious to see how it evolves.
>
> [1] http://www.luna-lang.org


Many flow based languages...

https://en.wikipedia.org/wiki/Dataflow

https://en.wikipedia.org/wiki/Max_(software)

https://en.wikipedia.org/wiki/Reactive_programming

On Wednesday, 14 February 2018 at 22:43:21 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 14 February 2018 at 18:43:34 UTC, Mark wrote:
>> Luna [1], a new programming language that was recently mentioned on Reddit, also appears to take this "flow-oriented design" approach. It's purely functional, not OO, and I'm curious to see how it evolves.
>>
>> [1] http://www.luna-lang.org
>
>
> Many flow based languages...
>
> https://en.wikipedia.org/wiki/Dataflow
>
> https://en.wikipedia.org/wiki/Max_(software)
>
> https://en.wikipedia.org/wiki/Reactive_programming

does have classes. thanks for the link.