LabVOOP and mild flame wars

[Val Brown]

In another thread jdunham posted:

"Well at risk of both a thread hijack and a mild flame war, I suggest you take another look at LabVIEW's built-in OOP (usually called LabVOOP). It's pure dataflow. You could also call it clusters on steroids.

As I see it, it adds two features. One is to hide the implementation (i.e. the messy details) of each component of your code from the others. This makes it more likely to avoid bugs, because without this, it's very easy to change a subvi or a typedef and have it break some other code which you were not paying attention to at that time.

The other benefit is dynamic dispatch. If you've ever passed data in a variant (or a binary string, or a cluster with optional fields), and then accompanied that with an enum which tells receiving code how to unpack the variant, then you are better off using LabVOOP/Dynamic Dispatch because it does the same thing with less code and less chance for error."

So I thought to start another thread here FWIW.

Here's the problem with OOP and LV: which version does one use? Now one could say that, having to ask that question belies the wealth of options and that's a good thing but, on the other hand, it actually is a profound problem IMO, esp in terms of code reuse. Differing approaches (by ref vs by value, private vendor vs native LV, etc) all lead to code that can not be reused easily across differing implementations (unless I'm wrong on that) and yet isn't that supposed to be one of the many values of OOP?

This really is just a personal opinion of a long time LV user and is NOT meant to incite a flame war, mild or otherwise.

[jdunham]

QUOTE (Val Brown @ Dec 17 2008, 04:22 PM)

So I thought to start another thread here FWIW.

Great idea, thanks.

QUOTE (Val Brown @ Dec 17 2008, 11:24 AM)

It's just that my experience has been with traditional

LV

dataflow and that's what I feel most comfortable with at this point.

I think there are two interesting topics of discussion. One is your point about different flavors of LV-OOP, which is kind of interesting, and the other is about getting away from pure dataflow, which segues into debates about by-value or by-reference programming.

For OOP, I am trying to use the native ("LabVOOP") structure as much as possible, both to reduce dependencies, and to try to use by-value programming as much as possible in favor of by-reference (Endevo GOOP and OpenGOOP) approaches. I'm sure there is merit to using the other stuff, and I expect we'll hear from their fans shortly.

Once you start to question the use of by-reference objects, then you have to question the use of locals, globals, event structures, queues, and notifiiers. I think all of them are tremendously useful, but I have to say it's a lot easier to grow bugs in code that is not strict and simple dataflow. I think you could argue that all of those are deviations from the concept of pure dataflow programming, and yet now that we have these tools, LabVIEW programs can get more sophisticated and useful.

The first time I used a by-reference object, I was thrown for a loop. I had an IMAQ image, and I branched the wire, ran a filter on one side and compared it to the original. I couldn't figure out why there was no difference , but of course the data was never copied because my wired only contained references to the image. Many years later, my code is filled with queues and refnums and whatnot, and I know that branches of the wires all refer to the same data, but it feels like the purity is gone.

[LAVA 1.0 Content]

QUOTE (Val Brown @ Dec 18 2008, 01:22 AM)

....

Here's the problem with OOP and LV: which version does one use? Now one could say that, having to ask that question belies the wealth of options and that's a good thing but, on the other hand, it actually is a profound problem IMO, esp in terms of code reuse. Differing approaches (by ref vs by value, private vendor vs native LV, etc) all lead to code that can not be reused easily across differing implementations (unless I'm wrong on that) and yet isn't that supposed to be one of the many values of OOP?

If you use Endevo's toolkit with a by-ref class, you will be able to run these code without having Endevo GOOP installed (just like using an event structure in LabVIEW base), but you won't be able to adjust the Class behaviour.

This goes for most of the GOOP's implementations, using the implementation is OK, editing class behaviour might be restricted.

Ton

[Val Brown]

QUOTE (Ton @ Dec 17 2008, 09:21 PM)

If you use Endevo's toolkit with a by-ref class, you will be able to run these code without having Endevo GOOP installed (just like using an event structure in LabVIEW base), but you won't be able to adjust the Class behaviour.

This goes for most of the GOOP's implementations, using the implementation is OK, editing class behaviour might be restricted.

Ton

So, in a sense, it's like using componentized code from MS, eg COM object and ActiveX. You can use them but not edit them.

OK fair enough but what really then is the difference?

[Jeffrey Habets]

QUOTE (Val Brown @ Dec 18 2008, 06:58 AM)

So, in a sense, it's like using componentized code from MS, eg COM object and ActiveX. You can use them but not edit them.

OK far enough but what really then is the difference?

Not really.. You can actually edit all relevant class-code (the methods and attributes) without having the toolkit(s) installed (unless the programmer of the class locks the BD's).

You can even add new methods without the toolkit (although it's of course a lot easier and faster if you have the toolkit).

[Mark Smith]

I learned how to do OOP using .NET (C# and C++/CLI) where all of the objects are passed by reference - and most everything is an object! I was an experienced LabVIEW developer when I started using .NET, so I was used to dataflow. The first time I passed in an object reference, copied that object into a new object, performed some operation on the new object, returned the new object from the function (or I thought it was a new object!), and saw my orginal object had been modified, I was surprised to say the least. I quickly learned what "deep copy" means in a by-reference context! With that said, once I learned how to properly handle objects in a by-reference context, I found this to be a powerful programming paradigm. Now, when I try to use the by-value objects in LabVOOP (native labview OOP tools), I feel like I'm fighting with one hand tied behind my back. But this may only be because to use by-value objects properly would probably require me to re-learn some design patterns and techniques. But I think my important point is that if you are a LabVIEW only developer, then it might make sense to learn the proper LabVOOP by-value techniques and patterns. Otherwise, I would choose one of the by-reference toolkits because what you learn there is more directly applicable to almost any other OOP development environment.

But, I'm using LabVOOP right now on a project because I think it's important to learn how this toolkit works. In this project, I see a good use for inheritance so LabVOOP may prove its worth. I used the orginal Endevo toolkit (the one for LV6) on a previous project a few years ago and I did find it worked as advertised, but my opinion was that it's a lot of extra effort - and this version did not support any kind of inheritance. I'm counting on (hoping for?) NI to offer the option of by-reference objects in the next version of LV.

Mark

QUOTE (Val Brown @ Dec 17 2008, 10:58 PM)

So, in a sense, it's like using componentized code from MS, eg COM object and ActiveX. You can use them but not edit them.

OK far enough but what really then is the difference?

[LAVA 1.0 Content]

I only dipped my toe into the pre-LVOOP versions of OOP for LV. I avoided the previous versions since "I could not attack the core" meaning I had to leave the core the way it was and therefore had to copy the data out manipulate it and then put it back. Most of my apps require high performance and I cringed at the idea of not being able to "work in-place".

I have become rather fond of LVOOP since it lets me "work in-place" and the "by-reference issue" (not built-in) is a non-issue for me since I just implemented my own version in LVOOP.

Ben

[Val Brown]

Now again I may be missing it but all of these notes are confirming at least one aspect of what I'm saying: viz, all the different versions means there really isn't any good continuity to using OOP within LV. By-ref versions are recommended if you're not only programming in LV. The native LV version is recommended if you are only using LV except if...etc, etc.

It seems to me that all of this inconsistency really defeats one of the core rationales for OOP within LV.

[Omar Mussa]

QUOTE (Val Brown @ Dec 18 2008, 07:47 AM)

It seems to me that all of this inconsistency really defeats one of the core rationales for OOP within LV.

I think that it is more like there are multiple tools (design patterns, etc) and so you can choose which tools are appropriate for the problem that you are trying to solve. I don't think this defeats any rationale for LVOOP.

[Mark Smith]

Like Ben, I have created my own "by-reference" functionality in LabVOOP since I found places where I really needed it - and I agree with Val that all of these versions make it more difficult to make portable code with OOP in LabVIEW. That's why I'm hoping that the next release of LabVIEW will support by-ref objects in LabVOOP. Then we'll have a complete and portable version.

Mark

QUOTE (Val Brown @ Dec 18 2008, 08:47 AM)

...It seems to me that all of this inconsistency really defeats one of the core rationales for OOP within LV.

QUOTE (neB @ Dec 18 2008, 08:04 AM)

...the "by-reference issue" (not built-in) is a non-issue for me since I just implemented my own version in LVOOP.

Ben

[shoneill]

QUOTE (mesmith @ Dec 18 2008, 05:15 PM)

Like Ben, I have created my own "by-reference" functionality in LabVOOP since I found places where I really needed it - and I agree with Val that all of these versions make it more difficult to make portable code with OOP in LabVIEW. That's why I'm hoping that the next release of LabVIEW will support by-ref objects in LabVOOP. Then we'll have a complete and portable version.

I'm no OOP guru, but how will implementing by-ref LVOOP lead to portable code?

I personally like LVOOP being by-value. It maintains a constant behaviour throughout LabVIEW. Using the Vision toolkit leads to a lot of bugs for me because switching between by-val and by-ref (mentally) is not easy within the same code (not for me anyway). And yes, I know the limitations of a by-ref vision toolkit and that there are good reasons for a by-value approach. I just don't find it a very good fit with normal LV practises.

As we've already heard from a few posts in this thread, it's also possible to make a by-ref implementation if necessary. What's the problem with that?

Shane.

PS I just read the post leading to this thread..... I think the abilities of LVOOP are being treated in kind of the same way LV was treated in the beginning - "But it can't do this, but it can't do that". Well yes, LV is still geared towards a primary type of application (Even though the barriers are becoming less clear all the time) and I can fully understand the implementation behind LVOOP. I personally much prefer it this way than forcing a whole by-ref approach. Each approach requires a bit of time to get used to it, but can someone give a concrete example of something which CAN'T be done with LVOOP which could be done with by-ref LVOOP? And when I mean "can't", I don't mean "awkward" or "not automatic", I mean "can't".

[Neville D]

QUOTE (shoneill @ Dec 18 2008, 09:17 AM)

I personally much prefer it this way than forcing a whole by-ref approach. Each approach requires a bit of time to get used to it, but can someone give a concrete example of something which CAN'T be done with LVOOP which could be done with by-ref LVOOP? And when I mean "can't", I don't mean "awkward" or "not automatic", I mean "can't".

You CAN'T use LabVOOP (by value) in LV-RT. You CAN use 3rd Party "by-ref" OOP toolkits with RT.

PS. I don't use either in my projects, but I thought I'd throw it out there for you guys to gnaw on..

N.

[Mark Smith]

QUOTE (shoneill @ Dec 18 2008, 10:17 AM)

I'm no OOP guru, but how will implementing by-ref LVOOP lead to portable code?...

Here, I just meant that if the by-ref implementation were part of native LabVIEW, if you tried to use a class that used by-ref, you wouldn't have to worry about which third-party toolkit was being used and whether or not you had it installed. And you wouldn't have to try to figure out some hacker's (like mine ) home-grown implementation.

Mark

[Val Brown]

QUOTE (mesmith @ Dec 18 2008, 10:12 AM)

Here, I just meant that if the by-ref implementation were part of native LabVIEW, if you tried to use a class that used by-ref, you wouldn't have to worry about which third-party toolkit was being used and whether or not you had it installed. And you wouldn't have to try to figure out some hacker's (like mine ) home-grown implementation.

Mark

Yes, and again, to be clear, this is one of my biggest gripes in all of this. WHATEVER is not native LV, is no longer (as) portable across all LV implementations. It would be as if someone created their own Signal Processing Toolkit and started pushing for it to be used as "a standard" because it "seemed better" in some ways.

[jdunham]

QUOTE (Val Brown @ Dec 18 2008, 10:45 AM)

Yes, and again, to be clear, this is one of my biggest gripes in all of this. WHATEVER is not native LV, is no longer (as) portable across all LV implementations. It would be as if someone created their own Signal Processing Toolkit and started pushing for it to be used as "a standard" because it "seemed better" in some ways.

Well, what if there were a separate, open-source library of a lot of functions which really should have been put into vi.lib in the first place?

Of course OpenG does exist, and it is your free choice whether to use it or not. It's not worth getting mad or griping about it. Just decide whether adding it to your toolkit makes sense for the realities of your situation and move on. Of course discussing that choice in this forum is just fine, I just don't get the apparent frustration you are expressing.

[Val Brown]

QUOTE (jdunham @ Dec 18 2008, 11:08 AM)

Well, what if there were a separate, open-source library of a lot of functions which really should have been put into vi.lib in the first place?

Of course OpenG does exist, and it is your free choice whether to use it or not. It's not worth getting mad or griping about it. Just decide whether adding it to your toolkit makes sense for the realities of your situation and move on. Of course discussing that choice in this forum is just fine, I just don't get the apparent frustration you are expressing.

Part of my frustration is over the continuing "by-ref" vs "by-value" discussions and the implications that, unless one uses OOP etc, then one isn't a "real" programmer. BUt the essence of my frustration is with how NI has, IMO, gone off mission in dropping over the years true cross-platform development in favor of a Windows-centric approach that again, IMO, takes them off mission in additional ways.

Yes, it's my choice and I've made my choice -- which I've also discussed in some other threads. And, yes, my situation is different from others, perhaps even the majority of others, here; however, I think it's important to at least voice the other perspective.

Re: open-source, I'm not a big advocate of open source. Having come up through the "unix wars" of the early 80s, I'm not at all interested in having to balance so many different distros and versions within my overall code. I know that's also an unpopular perspective here -- and it isn't meant to imply ANY criticism of OpenG or the efforts of JKI and others who have truly done marvelous work -- but it is what's so for me. Perhaps OpenG could be transitioned INTO the overall NI distro -- with appropriate fees involved, etc -- and then I would be happy to use the code. At this point, as a single developer, my choice is to remain with the corporate profile of NI supplied/supported code, with the added support of all of the knowledgeable folks here at LAVA!

[LAVA 1.0 Content]

QUOTE (Val Brown @ Dec 18 2008, 09:25 PM)

..., unless one uses OOP etc, then one isn't a "real" programmer. BUt the essence of my frustration is with how NI has, IMO, gone off mission in dropping over the years true cross-platform development in favor of a Windows-centric approach that again, IMO, takes them off mission in additional ways.

...

Here, here!

Ton

(now about the rest of the post )

[Omar Mussa]

QUOTE (Val Brown @ Dec 18 2008, 12:25 PM)

Perhaps OpenG could be transitioned INTO the overall NI distro

There are many examples of VIs that have been 'transitioned' into LabVIEW as a result of OpenG (fees have not been involved to my knowledge ...). So if you want to wait for NI to 'transition' VIs from OpenG, that's your choice. I, for one, am glad that I don't have to wait for NI to create every function or framework that I need or use.

[Mark Smith]

QUOTE (Val Brown @ Dec 18 2008, 01:25 PM)

Part of my frustration is over the continuing "by-ref" vs "by-value" discussions and the implications that, unless one uses OOP etc, then one isn't a "real" programmer. BUt the essence of my frustration is with how NI has, IMO, gone off mission in dropping over the years true cross-platform development in favor of a Windows-centric approach that again, IMO, takes them off mission in additional ways.

Where I work one isn't a real programmer unless they do embedded development in C or VHDL! So every community has its bias. But I do fail to see where the OOP push in LabVIEW makes it less cross-platform compatible - is the LabVIEW OOP implementation (the native one) not supported on Mac and/or Linux?

Mark

[Val Brown]

QUOTE (Omar Mussa @ Dec 18 2008, 01:22 PM)

There are many examples of VIs that have been 'transitioned' into LabVIEW as a result of OpenG (fees have not been involved to my knowledge ...). So if you want to wait for NI to 'transition' VIs from OpenG, that's your choice. I, for one, am glad that I don't have to wait for NI to create every function or framework that I need or use.

I don't think I've ever said that OpenG shouldn't exist, just that I choose to not use it.

QUOTE (mesmith @ Dec 18 2008, 01:56 PM)

Where I work one isn't a real programmer unless they do embedded development in C or VHDL! So every community has its bias. But I do fail to see where the OOP push in LabVIEW makes it less cross-platform compatible - is the LabVIEW OOP implementation (the native one) not supported on Mac and/or Linux?

Mark

Yes, every community has its biases. I'm not sure about the native OOP going cross platform but isn't it interesting that we even have to ask when a fundamental mission statement of LV was to be transparently cross platform "as far as possible"?

[crelf]

QUOTE (Val Brown @ Dec 18 2008, 05:05 PM)

...a fundamental mission statement of LV was to be transparently cross platform "as far as possible"?

Where does it say that? Is that in a vision document on ni.com somewhere? I'm not trying to be beligerent - I actually want to know if that's an official mission statement from NI or not.

...and if it is, maybe it should be "as far as practical" instead

QUOTE (Val Brown @ Dec 17 2008, 07:22 PM)

Differing approaches (by ref vs by value, private vendor vs native

LV

, etc) all lead to code that can not be reused easily across differing implementations...

Yes, and no. When I want by-val I use LV-OOP (i have no other choice, not that I want one). When I do by-ref I use dqGOOP (code is native LabVEIW queues, so I can use it anywhere), unless I need something more beefy (inheritance, etc), then I'd use Endevo's GOOP (that does have transferability limitations).

QUOTE (Val Brown @ Dec 18 2008, 10:47 AM)

It seems to me that all of this inconsistency really defeats one of the core rationales for OOP within

LV

.

I think that you're confusing the reasons for using OO with the reasons to use a particular version of OO.

[Val Brown]

QUOTE (crelf @ Dec 18 2008, 02:43 PM)

Where does it say that? Is that in a vision document on ni.com somewhere? I'm not trying to be beligerent - I actually want to know if that's an official mission statement from NI or not.

...and if it is, maybe it should be "as far as practical" instead

Yes, and no. When I want by-val I use LV-OOP (i have no other choice, not that I want one). When I do by-ref I use dqGOOP (code is native LabVEIW queues, so I can use it anywhere), unless I need something more beefy (inheritance, etc), then I'd use Endevo's GOOP (that does have transferability limitations).

I'd have to look at my legacy materials from my initial purchase of LV back in 98 but, if I'm not mistaken, there were statements to that effect at the time. Until the SPT came out my application was entirely Mac/Windows transparent -- same LV code worked completely cross-platform (for instance) and that was one of the big motivations for using LV at that time. Dataflow, graphical interface, etc were other obvious reasons as well.

I understand that you have three choices you use depending on context and again I think it's great that options are present. For me that simply complexifies the issue, esp in terms of portability of code. Yes there are lots of good reasons to make those choices -- as you and others have done -- but they're not universal solutions and for some -- like me -- those course create some problems. Maybe it's partly an "...old dog, new tricks" kind of issue but, if so, I'm still barking FWIW.

[crelf]

QUOTE (Neville D @ Dec 18 2008, 01:11 PM)

You CAN'T use LabVOOP (by value) in LV-RT.

yet...

[shoneill]

QUOTE (Val Brown @ Dec 18 2008, 09:25 PM)

BUt the essence of my frustration is with how NI has, IMO, gone off mission in dropping over the years true cross-platform development in favor of a Windows-centric approach that again, IMO, takes them off mission in additional ways.

I might be missing the point of the post here, but LVOOP is cross-platform.

I've just recently used a LVOOP project created on a Windows machine under Mac, no code changes required whatsoever. Works great. Works better actually because of the Mac's .app directory magic.

Shane.

[crelf]

QUOTE (shoneill @ Dec 19 2008, 10:00 AM)

I might be missing the point of the post here, but LVOOP is cross-platform.

dqGOOP is just based on queues (hence the name), so it's cross platform too.