I Was Told There Would be Benefits

[Phillip Brooks]

https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53#.4476pk9xq

[ShaunR]

[hooovahh]

I can't tell who I side with in the comments.  Both crowds have the same arguments of "Well you just haven't researched it enough."  Which I guess means I haven't researched it enough.

[ShaunR]

2 hours ago, hooovahh said:

I can't tell who I side with in the comments.  Both crowds have the same arguments of "Well you just haven't researched it enough."  Which I guess means I haven't researched it enough.

OOP is a philosophical thought experiment that gets more and more complicated as they try to implement it in real situations and cover up the failings with axioms.

Side with me

Edited July 27, 2016 by ShaunR

[mje]

I admittedly haven't touched C++/C# in over a decade beyond some very minor dabbling. When embedded became a focus for me two years ago, I went to C.

As weird as it sounds, I use a lot of object oriented design in my C code. There's no wizardry to object oriented design-- you don't need special language syntax to do it. Having dedicated grammar helps a lot, but it's not like interfaces, encapsulation, or inheritance aren't possible without built in object oriented constructs. Most of my C code is fully encapsulated, my state machines are usually interface based, and I even have the occasional sprinkles of inheritance in there where it's just too darn useful to ignore.

Honestly, the only thing I miss about C++ is the verbosity that becomes necessary in C when you start dealing with functions to support types (methods). Having to explicitly pass the type into each function is awfully repetitive, but it doesn't change anything functionally.

[smithd]

Yep, all the cool kids are doing functional programming now. Over in functional programming land the cake is definitely not a lie.

 

But really, while I get the complaints (and I complained all the time about lvoop stability), lvoop is basically a fancy cluster. Its not that big of a deal, its just a handy tool sometimes.

Edited July 28, 2016 by smithd

[ShaunR]

5 hours ago, smithd said:

Yep, all the cool kids are doing functional programming now. Over in functional programming land the cake is definitely not a lie.

 

But really, while I get the complaints (and I complained all the time about lvoop stability), lvoop is basically a fancy cluster. Its not that big of a deal, its just a handy tool sometimes.

Functional programming still has fat wires-the greatest barrier to reuse. I don't think all the "cool kids" are going over to them because some perceived elegance of the paradigm. Lets also be honest. It's really Javascript & Python we are talking about (because I bet they aren't leaping for joy over Erlang or Lisp  )  and mainly because of  browsers and servers. The trend is for service oriented design and JavaScript is used by the clients and Python by [Linux] servers. 

LVPOOP maybe just a fancy way of hiding a clustersaurus but it brings a lot of dependency baggage with it to fulfill it's OOP role . Where it excels is as an instance scoped variable so it's great for small, self contained state machines where state is local to the instance (like comms authentication) but you are back to all the usual nightmares outside of that.

Edited July 28, 2016 by ShaunR

[eberaud]

I might be lacking imagination, but I achieved results in my LV code that I feel I could never have done without OOP. I have a plugin architecture where all the plugins share a lot of functionalities, which I have coded inside the parent class. Then a "plugin manager" contains an array of all the plugins, only knowing them as "parent class" and never having to worry about which type of child class they are...

[hooovahh]

18 minutes ago, Manudelavega said:

I might be lacking imagination, but I achieved results in my LV code that I feel I could never have done without OOP. 

Oh well you just haven't researched it enough!  (just kidding of course)

I mean you can do plugin architectures without OO but in LabVIEW I can see that being a bit more difficult with needing to enforce or check for types, and all that is involved with adding new types.  Having seen plugin architectures with and without OO in LabVIEW I would say the simple ones tend to be over complicated by adding OO, and the complex ones tend to not scale well without OO.

[ShaunR]

16 hours ago, mje said:

Having to explicitly pass the type into each function is awfully repetitive, but it doesn't change anything functionally.

Then why do it? 

[smithd]

 

11 hours ago, Manudelavega said:

I might be lacking imagination, but I achieved results in my LV code that I feel I could never have done without OOP. I have a plugin architecture where all the plugins share a lot of functionalities, which I have coded inside the parent class. Then a "plugin manager" contains an array of all the plugins, only knowing them as "parent class" and never having to worry about which type of child class they are...

I think the post would better be described as "there are better ways to do this than this crap we invented 30 years ago". While oop is 100x better than plain vi server calls with megaclusters or variants as the parameters, the poster would I think argue that oop is 100x worse than something like the shiny interfaces of golang (I can't find a good simple description of it, but basically you say "type T has methods called A, B, and C. Anyone else in the whole world that has methods A, B, and C is therefore type T, and which doesn't stop it from also being type U, V, etc.").

18 hours ago, ShaunR said:

Functional programming still has fat wires-the greatest barrier to reuse. 

Fat wires? 

Edited July 29, 2016 by smithd

[ShaunR]

6 hours ago, smithd said:

Fat wires? 

When we wire VIs together they are normally simple data types (numeric, strings arrays etc). The wire represents a single data type. When we pass a cluster between VIs we are now passing (potentially) a number of data types (the wire is "fatter"). A cluster or clusters is "fatter" still. At this point, it is anthropomorphic silliness and has no effect on the code. This isn't quite what I mean by "fat" wires since there is something missing from the definition.but it illustrates where the idea comes from..

When we get to LVOOP we are passing objects. In LabVIEW terms, these are clusters too but in addition to that there is also dynamic dispatch.These wires not only transfer data  (the private cluster) but also a behavioural component. In LabVIEW this is hidden under the guise of dynamic dispatch but in other OOP languages they would be the methods and in Javascript (a functional language) we can easily see the nested functions (and oh, my god...the brackets  ).

Moreover. A class can contain other classes so its behaviour can be dependent on a number of previous class behaviours and inputs. So to predict a VIs output from its input becomes extremely difficult and assessment in isolation almost impossible. This is what I mean by "fat" wires. The wires are opaque behaviour modifiers crammed with data and dependent on upstream (or is it downstream?) behavioural results .In other languages they are imaginary but In LabVIEW we actually get to see them and even decide their colours and patterns (cool, huh? ). 

This is why when you wanted the banana, you also needed the gorilla......etc..Fat wires mean dependency.

Edited July 29, 2016 by ShaunR

[smithd]

Ok that makes sense but then you said functional programming has the same issues...as far as I understood it, not worrying about specific types (being able to pattern match, for example, on any input data type which has a numeric x and numeric y, regardless of the other contents of the data type) and being very explicit about its behavior (ie f(x0) ALWAYS = y0) was the point. 

[ShaunR]

23 hours ago, smithd said:

Ok that makes sense but then you said functional programming has the same issues...as far as I understood it, not worrying about specific types (being able to pattern match, for example, on any input data type which has a numeric x and numeric y, regardless of the other contents of the data type) and being very explicit about its behavior (ie f(x0) ALWAYS = y0) was the point. 

It may have been an over generalisation. I was referring particularly to Javascript and python so am not sure if things like object passing and closures are acceptable in all functional languages.

[JKSH]

On 7/27/2016 at 10:53 PM, Phillip Brooks said:

https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53#.4476pk9xq

This article does a good job at narrating the author's journey from being an OOP enthusiast to an FP advocate, and helps us understand his feelings and frustrations. However, it does a poor job at illustrating OOP's actual shortcomings/pitfalls.

Let's have a closer look at the author's arguments.

Inheritance: The Banana Monkey Jungle Problem
This is a strange example.

It's like an OpenG author who decides to reuse some OpenG code (say, Cluster to Array of VData__ogtk.vi) by copying the VI into his project folder, and then is gobsmacked to discover that he needs to copy its subVIs and their subVIs too. This shouldn't be so surprising, should it…?

Anyway, it sounds like his main gripe here is with excessive dependencies (which is influenced by code design too, not just the paradigm), yet his stated solution to this problem is "Contain and Delegate" (a.k.a. composition). Sure, that eliminates the class inheritance hierarchy, but I don't see how that helps reduce dependencies. It feels like he's trying to shoehorn the "You need composition!" message into every problem he listed, just so that he can argue later that inheritance is flawed.

Inheritance: The Diamond Problem
Yes, this is a real issue that can trip up the unwary. However, the author claims that the only viable way to model a diamond relationship is to do away with inheritance ("You need composition!"). He disingenuously ignores the numerous inheritance-friendly solutions that can be found in various languages.

Inheritance: The Fragile Base Class Problem
Yes, this is a real pitfall. This is his most solid point against inheritance.

Inheritance: The Hierarchy Problem
His main point here is, and I quote, "If you look at the real world, you’ll see Containment (or Exclusive Ownership) Hierarchies everywhere. What you won’t find is Categorical Hierarchies…. [which have] no real-world analogy".

I'd like to hear from someone who has implemented a HAL (or someone who's a taxonomist). Would you agree or disagree with the author's claim?

Encapsulation: The Reference Problem
This is another bizarre example.

His logic is akin to, "An LVClass lets you have a DVR as a data member, and it lets you initialize this member by passing an externally-created DVR into its initialization VI. Therefore, an external party can modify LVClass members without using an LVClass method. Therefore, LVClasses don't support encapsulation. Furthermore, attempting to prevent external modification is inefficient (and perhaps impossible). Therefore, the whole concept of encapsulation in OOP is unviable."

This is a huge stretch, IMHO.

Polymorphism
His main point here is, "You don't need OOP to use polymorphism". This is true, but is not a shortcoming.

Also, the author paints a picture of interfaces-vs-inheritance. They are not mutually exclusive; they can be complementary as they serve different use cases.

Edited July 31, 2016 by JKSH

[ShaunR]

13 hours ago, JKSH said:

Inheritance: The Banana Monkey Jungle Problem
This is a strange example.

It's like an OpenG author who decides to reuse some OpenG code (say, Cluster to Array of VData__ogtk.vi) by copying the VI into his project folder, and then is gobsmacked to discover that he needs to copy its subVIs and their subVIs too. This shouldn't be so surprising, should it…?

Anyway, it sounds like his main gripe here is with excessive dependencies (which is influenced by code design too, not just the paradigm), yet his stated solution to this problem is "Contain and Delegate" (a.k.a. composition). Sure, that eliminates the class inheritance hierarchy, but I don't see how that helps reduce dependencies. It feels like he's trying to shoehorn the "You need composition!" message into every problem he listed, just so that he can argue later that inheritance is flawed.

The BMJ problem isn't about dependancy, per se. It's about useless dependency-all the dependencies that aren't needed and just add baggage. In you analogy with openG, it is more like you wanted to use Cluster to Array of VData__ogtk.vi but you don't just need the dependent VIs, you need the error package, the strings package and the variant package even though only one VI is needed from each (I don't know if that particular VI does require those, but I hope you get the point).

This is the same criticism leveled at lvlibs, by the way.

13 hours ago, JKSH said:

Inheritance: The Diamond Problem
Yes, this is a real issue that can trip up the unwary. However, the author claims that the only viable way to model a diamond relationship is to do away with inheritance ("You need composition!"). He disingenuously ignores the numerous inheritance-friendly solutions that can be found in various languages.

They aren't really solutions, They are different implementations of walking a hierarchy. I wouldn't have used this argument because it is an implementation problem with a number of non-equivalent solutions. I refer you back to my previous statement about OOP being a philosophical thought experiment and this is just saying there's many ways of skinning that cat and all are compromises.

You can model this easily in LabVIEW,, by the way, because execution depends on data arriving at the objects/VIs rather than choosing a preferential order of the hierarchy. In fact. You will constantly hear me talking about diamond or bi-pyramidal architectures to maximise resuse and modularity.

What if I said to you that placing a normal VI on an empty diagram is inheritance and you  can override by modifying the data on the wires in the new diagram What would placing multiple VIs on a diagram be? .

13 hours ago, JKSH said:

Encapsulation: The Reference Problem
This is another bizarre example.

His logic is akin to, "An LVClass lets you have a DVR as a data member, and it lets you initialize this member by passing an externally-created DVR into its initialization VI. Therefore, an external party can modify LVClass members without using an LVClass method. Therefore, LVClasses don't support encapsulation. Furthermore, attempting to prevent external modification is inefficient (and perhaps impossible). Therefore, the whole concept of encapsulation in OOP is unviable."

This is a huge stretch, IMHO.

Yeah. I'm not entirely sure here either. I think he has again mistaken an implementation issue for an OOP issue. Objects in most languages are pointers to mutexed structures. They are non portable between languages so I think he is describing a particular issue with his language that perhaps the underlying mutexes etc aren't what they're supposed to be. I don't really know.

13 hours ago, JKSH said:

Polymorphism
His main point here is, "You don't need OOP to use polymorphism". This is true, but is not a shortcoming.

Also, the author paints a picture of interfaces-vs-inheritance. They are not mutually exclusive; they can be complementary as they serve different use cases.

True. But his whole article as about his disillusionment with promises unfulfilled. If you took out dynamic dispatch from LVPOOP (the run-time polymorphism) what are you left with? Errm. classical LabVIEW with an instance scoped cluster ;). In fact the polymorphic VI is the static version of dynamic dispatch and it suffers from the same code bloat and static linking as classes (and why we want VI Macros)

I think here he's just lamenting that it was a bit of marketing hype that everyone fell for - including him.

Edited July 31, 2016 by ShaunR