Retired LabVIEW features?

[Daklu]

---

@Ben wrote:

I miss

The day when someone could concider themselves a good LV developers without having to talk OOPishly.

---

Consider this a gentle kick in the shin...

I do as much LVOOP as anyone and I *strongly* disagree with the notion that you must know OOP to be a "good LV developer."  Object oriented design and programming is about how you look at a problem and break it down into smaller pieces.  It has advantages and disadvantages when compared to other programming paradigms.

I do belive anybody will become a better developer if they take the time to learn a wide variety of techniques.  I also think developers who do not learn LVOOP will be limiting their future opportunities, as more and more existing code is going to be based on it.  But you don't have to flash your OOP membership card to get into the "Good Developers" club, and if anyone says you do feel free to kick them out the door.  They don't belong there.

(A very short and incomplete list of excellent developers who do not OOP:  you, Shaun, and RolfK.)

[crossrulz]

---

Daklu wrote:

(A very short and incomplete list of excellent developers who do not OOP:  you, Shaun, and RolfK.)

---

Most people at the CLA Summit...

[PaulG.]

Would have loved to have been a fly on the wall there. I love OOP, but can't use it or haven't used it often enough to feel really comfortable with it. On one project it was the best thing that ever happened. Right now it would be perfect but I would have to refactor some otherwiswe very well-written legacy code. Would love to hear why so many CLA's don't use it.

[crossrulz]

---

@PaulG. wrote:

Would love to hear why so many CLA's don't use it.

---

Speaking for myself, I just hadn't found a really good excuse to try it.  Still waiting for a new program to give a try with.  After seeing what Aristos had done, a lot of us were quite impressed with what OOP could really do.  Looking back, I really wish I had OOP with certain projects I had done.  I had plans to rewrite all of my instrument drivers with OOP, but alas I changed companies so that might never happen.

[Daklu]

"Most people at the CLA Summit..."

Did you go to the US or Euro summit?  I remember there being a question at the US summit about people using LVOOP and I thought at least half the people there raised their hand.  (Could be I'm misremembering though...)

"Would love to hear why so many CLA's don't use it."

"Speaking for myself, I just hadn't found a really good excuse to try it."

I think that's probably true for most people, not just CLAs.  Procedural programming and OO programming are fundamentally different ways to think about a problem.  Learning OO design is a long process and there will be many mistakes made along the way.  It takes a lot of effort to make the switch.  People need to have a reason to put in that effort.

What's the one thing that is most likely to cause a person to change?  Pain.  (Not just physical pain, but pain in the abstract sense.)  The higher the cost of the change the more pain we're willing to endure before making the change.  When faced with multiple choices for reducing the pain we'll typically choose the least expensive option that reduces the pain to an acceptable level.

CLAs well versed in procedural programming have had years to develop ways to reduce the pain they encounter on projects to acceptable levels.  Their pain doesn't reach the point where they are motivated to spend years relearning what they already know how to do.  Furthermore, OO programming isn't pain-free itself so it's very difficult to determine how much the pain will be reduced, or even that it will be reduced.  In essence, the cost of attempting to reduce the pain (with no guarantee there will be a reduction) is more than the cost of enduring the pain.

So the real answer to why more people don't use LVOOP is simple:  The perceived cost outweighs the perceived benefit.

[fabric]

Being able to browse the contents of my .exe using WinZip...

[drjdpowell]

I would have thought that there was an easy route into basic LVOOP via treating it as a typedef cluster in a library with data encapsulation (and, BONUS, define your own pretty wires!).  Keeping bundle/unbundle private to a library is already a significant architectural advantage.  A much longer path to get to dynamic dispatch and OO "patterns", but LVOOP is already an advantage used simply.

[Neil.Pate]

Bingo!

This, for me, is the number one reason to use OOP. Data encapsulation. Number 2 perhaps is that coding things up as classes really lends itself very well to generating basic unit test VIs. 

[PaulG.]

---

@nrp wrote:

Bingo!

This, for me, is the number one reason to use OOP. Data encapsulation. Number 2 perhaps is that coding things up as classes really lends itself very well to generating basic unit test VIs. 

---

#2 would be the inheritance of OOP.  Right now I have dozens of DUT's and they are all "similar". Similar testing, identical test equipment, similar reports, etc. And new products coming down the pipe are just as "similar". Unit/software testing/debug for just one DUT would filter down into all the child classes/DUTs. Eventually this code would write itself. 

[Daklu]

"I would have thought that there was an easy route into basic LVOOP..."

Sure, that's a fairly easy way to get started for those already motivated to learn it for other reasons.  But for many developers it doesn't provide a reason to learn LVOOP in the first place.  What pain is being reduced for the CLA level developer by replacing clusters with classes?  In many cases the answer is nothing--they already have coding conventions or dev practices in place to prevent the pain.  For those people creating a class and providing accessors is pointless.

"Keeping bundle/unbundle private to a library is already a significant architectural advantage... but LVOOP is already an advantage used simply."

Personally I agree with you.  I place a very high priority on managing dependencies and LVOOP helps me keep things organized, so it is a significant architectural advantage to me.  However, the things that are important to me and that I value aren't necessarily the same things that are important to anyone else.  Whether or not an arbitrary feature/practice is an advantage depends on what an individual or organization values.