Functional and dataflow fight against object-oriented programming

Hello World!

I made a couple of posts on twitter about the criticism of object-oriented programming. Let me summarize my point in a structured article.

I understood recently the programmers expressing concerns about object-oriented programming are actually talking about by reference passing of data, and the complications it introduces. They are not criticizing the actual object-orientation, the modularization of code or object-oriented polymorphism, and often it's not even about the dreaded, brittle inheritance hierarchies. It's really mostly about references. When data is passed by reference you can never understand what is the exact state of your application at any moment, a problem made even worse by multi-threading.

Many decades ago, when we had a couple of KB of memory to work with, managing that memory with pointers and references made a lot of sense. We don't live in that world anymore. Memory is cheap now. Why do we still wear the mental shackles trying to optimize it, kidding ourselves that we can, with so many abstraction layers between us and the hardware.

Functional languages are different, and the misconception is that they are somehow fighting against object-oriented programming. They are rather an answer to ubiquitous passing data by reference. It is a historical accident that almost all OO languages pass almost all objects by reference.

In a by-value functional dataflow world objects are simply a different manifestation of types, used as inputs or returned as outputs from pure functions, with references only found on and limited to the edges of your application. The benefit of dataflow is you don't need to care about classes, because they behave exactly like any other type of data i.e. they flow by-value. If nothing or almost nothing flows by-reference, you get most of the way there for free.

Because classes and types feel and smell the same, the distinction is simply not that useful.

OK, so functional programming is mostly about by value flow, agreed?... Yes, we add first class functions, and function composition, and closures etc. but it's actually about by value flow of data. Good! Oh, BTW immutable data is a natural by-product of by value dataflow.

In 2018 I wrote:

"Trying to figure out why dataflow, graphical programming feels so different to many people coming from procedural, text based background and finally figured out that it's a combination of two paradigms that exist in the world: procedural and functional. In fact the more I study these two fundamentally different approaches to programming the more I realize that graphical dataflow takes the best of both worlds, allowing you to mix and match the functional and procedural style, sprinkle in some OOP, some memory access and whatever you need, not breaking the mold. I have been saying this for a long time and I still believe it's true - graphical dataflow is the future of programming. The question of adoption is having teachers capable of explaining the hybrid nature of it. Does that make sense?"

I put forward that all benefits and selling points of functional programming, like immutable data, pure functions, first class functions etc. would be most naturally expressed in a dataflow oriented language. "Threading" macros in Clojure introduced as a basic language construct seem to support this theory. However every implementation of dataflow is different. I am thinking here specifically about the LabVIEW implementation, which is by far the closest to what I view as correct.

OO still needs to be used to achieve polymorphism in LabVIEW but only because first class support for passing functions around is not yet there.

Polymorphism is achieved in Clojure (Lisp) by handling functions as first class citizens, enabling higher order functions (functions which accept other functions as arguments), closures (functions which create and return other functions), lambdas (anonymous, unnamed functions created inline without ceremony). They enable a level of reusability achievable with OO languages only through a substantial amount of ceremony and boilerplate code, obfuscating the solution to the problem we are working on. This was and is also one of the main complaints about Java and LabVIEW.

LabVIEW needs to support functions as first class types, enable passing them around by value, evaluating them on demand, partially applying arguments and doing all that directly in code, enabling lambdas.

One step in the right direction for LabVIEW are Malleable VIs. Having a design which adapts in edit-time to the types you want to use, but otherwise remains generic would is a game changer, making LabVIEW editing as dynamic to write as Clojure and as type safe as Haskell. We still need to work on Malleable VIs to make them more stable and higher performance.

We could also have a discussion of making a dataflow language open-source, but that is a story for another time.

To summarize, I believe dataflow is the best way to express the integration of functional, reference based OO and multi-threaded code. The best and most complete implementation of dataflow programming is done in LabVIEW, and we still have room for improvement.

The whole world is embracing the principles driving functional programming e.g. immutable history of commits in GIT, block-chain technology, immutable databases, by value dataflow cloud deployment configurations etc. Lets do the same.

I do recommend everyone learning or at least looking at Clojure and LabVIEW. It will make you a better programmer :)

Below is a link to the presentation I gave during 2019 LabVIEW Architect summit. You might like it.