• =?UTF-8?B?THXDrXM=?= Marques (27/27) Feb 14 2018 It seems that someone once again rediscovered the benefits of
• psychoticRabbit (18/30) Feb 14 2018 "Flow-Orientation is about tackling complexity at its root cause:
• Mark (7/12) Feb 14 2018 Luna [1], a new programming language that was recently mentioned
• H. S. Teoh (50/61) Feb 14 2018 [...]
• Mark (5/25) Feb 14 2018 It's not a new idea but they've added a visual twist to it - you
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (5/10) Feb 14 2018 Many flow based languages...
• t-t (3/14) Feb 15 2018 does have classes. thanks for the link.

=?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:

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 :-)

psychoticRabbit <meagain meagain.com> writes:

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.

Mark <smarksc gmail.com> writes:

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

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

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

Mark <smarksc gmail.com> writes:

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.

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:

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

t-t <t-t t-t.com> writes:

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.