Is LabVIEW OOP mature enough for large applications?

[ijustlovemath]

I'm starting the process of transitioning 3 large applications into one using LVOOP. After getting used to NI's terminology for it (why does everything need to be different from the standard vocabulary with NI?), I've got most of the groundwork laid for the real implementation to begin. Before I venture down this road for real, I'd like to hear the opinions of the seasoned LV devs on the capabilities and caveats to using LVOOP. A couple of the big posters on this forum admit to not even really using it, so I'm starting to question if it's a mature enough technology to handle what I'm about to throw at it.

[crossrulz]

I use it in almost all of my applications anymore.  Rarely do I regret it.  The only thing you have to remember is that LabVIEW's objects are value based, not reference based.  That seems to cause people coming from a C++ background to slip up.  Otherwise, I find it fairly straight forward.  A lot of bugs have been worked out since OOP came out in LabVIEW 8.2.  I would say it is definately mature enough to work with.

[ijustlovemath]

Yeah I've seen that from the whitepaper. Nothing I plan on doing is really all that fast or limited in resources, so that doesn't bother me all that much. Thanks for the input. I'm going to keep this thread open for more input before accepting any "solution".

[Jacobson-ni]

I don't do much development myself but the theme of this years CLA Summit was building better LabVIEW applications and it was basically all OOP. The community group linked below might also have some other input.

https://decibel.ni.com/content/groups/large-labview-application-development

Was there something in particular that you were concerned about LabVIEW OOP not doing well or were you just looking for general input from others?

[ijustlovemath]

My biggest fear is deploying the new version of the application, and six months down the line getting a call with cryptic "ClassNotFoundException" type errors from a client. The codebase as it stands is pretty foolproof to use, but expansion is getting difficult without proper OOP.

[Yamaeda]

In short, yes, but it's value based OOP as already mentioned.

If you want to use reference based OOP, take a look at out G#, it's basically LVOOP with DVRs (and garbage collection and some other C# features).

/Y

[mikeporter]

The thing to remember is that C++ and LabVIEW are two different languages that express things in different ways. Also LabVIEW is a language that has been essentially object-oriented from its earliest days -- unlike C++ which was (and is) essentially "C with classes".

Remember also that OOP is good at what it is good at. OOP is very good at providing things like hardware abstraction layers and the like. It is very poor as an overall structure for an application. I have seen many applications that were built 100% on OOP. I have not however seen any good ones -- where good is defined as readable, maintained and extensible. Even C++ is widely criticized as a "write-only" language.

In terms of terminology, all you have to remember is that:
Class = Type of wire
Object = One particular wire

Finally, LabVIEW is a dataflow language. Don't try to change that in your OO code. If you can get your head disconnected from the idea the C++ is a good implementation of OO principles (which it's not really) and study the underlying concepts you will discover that dataflow does a pretty good job of representing the ideas and concepts behind OOP.

Mike...

PS: On my blog (link in my signature) I have links to a couple papers that I delivered at NI Weeks, and several blog posts dealing with the topic.

[Bob_Schor]

---

@ijustlovemath wrote:
Yeah I've seen that from the whitepaper. Nothing I plan on doing is really all that fast or limited in resources, so that doesn't bother me all that much. Thanks for the input. I'm going to keep this thread open for more input before accepting any "solution".

---

Well, I don't know how you would pick a "solution".  Just about everyone who has been doing serious, high-level, big-project LabVIEW development over the past, say, 5 years has gradually drifted towards LVOOP.  Does that make it "mature enough for large applications"?  Well, that's a matter of opinion.  If the Developer(s) are "mature" and "experienced" enough to understand how to use LVOOP and are comfortable with it, it certainly seems to be "the way to go".  So the key question, it seems to me, is "Does Our Development Team (which may be a Team of One) Understand LVOOP to Commit to Using It?".

Bob Schor

P.S. -- I'm an example of the "Team of One" who wants to go to LVOOP but is not yet quite ready to "make the leap" ...

[PaulG.]

---

@mikeporter wrote:
... OOP is very good at providing things like hardware abstraction layers and the like. It is very poor as an overall structure for an application. I have seen many applications that were built 100% on OOP. I have not however seen any good ones -- where good is defined as readable, maintained and extensible... 

---

Play angelic chorus.

[Ben]

---

@mikeporter wrote:
...

. I have seen many applications that were built 100% on OOP. I have not however seen any good ones -- where good is defined as readable, maintained and extensible. Even C++ is widely criticized as a "write-only" language....

---

...

Spoiler

Gee thanks Mike!

Just becuase it ws my first totally LVOOP project and it was written in LV 8.2 and DVR's and worker pools had not been invented yet and it had to allow editing the Front Panel while the application was running and had to support adding new Front Panel controls to an executable...

What did you expect?

Ben