Top Three Things in LVOOP That Make You Less Productive ?

[Dmitry]

There recently was a brief exchange on using classes in one of 'restricted' community forums. I thought it might be helpful getting feedback on the subject  from a wider group of LVOOP adopters.

I am specifically asking for negative feedback based on a quote from Anna Karenina by Lev Tolstoy: "All happy families are alike; each unhappy family is unhappy in its own way" in hope of getting a more diverse, helpful and actionable feedback.

My personal version of the "Top Three Things in LVOOP That Make Me Less Productive" list:

1. Lack of Interfaces or similar language features in G
2. I can't figure out why Static Dispatch methods need to be loaded with a class in case they are not called in the code
3. Using a class on multiple Targets in the same project locks that class

For the lucky ones coming to LAVA BBQ today and passionate on the subject - lets discuss this in person over beer and BBQ ...

Cheers,

Dmitry

[James_McN]

Number 3 is a massive issue for me right now! Combined with using JKI's VI Tester across targets it is not uncommon that the best way of unlocking things is to close and re-open the project.

I'm also realising how key Interfaces are. Many times an empty parent class does work for me but a specific interface may help with certain tasks. For example, if you must change the API, that is currently a bit tedious with no central point to identify breaks or updates required.

I think things I would add would tend to be small, repetitive tasks, I think some of which GDS may help with, changing localised names when creating a new class, deleting and moving terminals on a new override method. I love that methods are templated, but if using DVRs you have to go back to recreating it all from scratch (I would estimate I use DVR's in around 25-35% of my classes).

Unfortunately no NI Week for me this year but enjoy the BBQ!

James

[tyk007]

My personal list:

1. Lack of traits / interfaces / pluggable typed abstractions. With this LVOOP is significantly more useful to me. Guess that's the same as you.
2. Lack of generics / generic types without falling back to hacks like poly VIs or XNodes. Extremely useful for APIs; I guess scripting helps take some of the overhead off but lacks the elegance of this feature
3. LabVIEW compile-on-change. For nested hierarchies this brings the IDE to a grinding halt

[MikaelH]

Natively Interface support would be nice, so it becomes easier to reuse common design patterns.

GDS supports 2 interface implementation, Interface through Aggregation and with VI Server.

I’ve yet not had time to do a demo-video of these features, but here is an Interface by VI server demo.

https://decibel.ni.com/content/message/108145#108145

[fabric]

1. IDE sluggishness. I lose literally hours per week working with classes.

2. The fact that classes can never be unloaded at run-time.

3. No interfaces

[rolfk]

I haven't used LVOOP that much until now but from the experience so far, my 3 top points pretty much match the points Dimitry has mentioned.

1) Interfaces: The main reason for me to use LVOOP so far was for drivers for instruments and system APIs which had different implementations but supposedly the same top level interface. Having a clear interface definition would definitely help in making the different classes adhere to the same API so that they stay truely pluggable. Currently I solved that by making the Factory class basically also the parent class of the different drivers and in that way more or less the interface definition for them. It works but has some undesirable byeffects where the factory class ends up mostly with useless empty override methods for the interface definition. Also it is really mixing two pretty unrelated things into one.

2) Locking of classes if they are used in more than one context. WTF! How can I get rid of that???

3) Make a change to one method conpane and suddenly the entire class hierarchy is broken and the resulting error indication is usually pretty terse and not very helpful to properly locate the offending locations. If I change a method interface it's quite likely that I would want to change the according method interface of any derived and/or parent class too, and not just getting broken classes all over with some generic error message that the classes don't match anymore.

4) The fact that if you reference a class in any way, it will load anything and everything this class references in any possible way, into memory no matter if this is even needed in the current setup. I like Java much more where classes are loaded as they are needed. Yes that is probably not ideal on a real-time system but I'm sure it could be made such that the loading of classes could be forced anyways with some setting, once load on demand is implemented properly.

LBNL: It would be sometimes handy tandy to have classes also unload once they are not needed anymore. I'm sure it would actually solve point 2) for most situations.

[Intaris]

1) Definitely IDE reaction time when editing classes.  In my current application, just forcing a VI to recompile which is part of a class will make the IDE unresponsive for about a minute before I can do anything else.  I don't want to work out how much money these pauses are actually costing.  My LabVIEW license cost probably seems like a real bargain in comparison.

2) Unwieldly composition support.  Having to manually create wrapper VIs for countless numbers of contained objects methods is extremely tedious and has serious drawbacks regarding IDE responsiveness.  I suppose this goes down the same route as Traits or Mixins.

3) Using classes over multiple targets.  It's just unworkable.  Endless frustration.

4) Dynamic dispatch overhead / inability to prohibit run-time loading of classes / inability to transform dynamic dispatch calls to static calls at compile time / inability to inline Dynamic dispatch VIs.  This one is a niche application.  I like using classes on RT, but their DD overhead is significantly higher than standard VIs (This situation has apparently been improved since LV 2012) especially when factoring in that they can't be inlined.  The ability to take a certain object hierarachy and declare it "final" so that the compiler knows there will be no extra members loaded at run.time would allow for so many optimisations that such an architecture could be significantly more performant, especially on platformy like RT. It's already done on LabVIEW FPGA to a slightly lesser extent as long as the concrete VIs can be evaluated at compile time.

[jlokanis]

All the things mentioned are good points and I experience many of them as well.  Especially the IDE issues, the class dependency linking and the pain it takes to break that (lots more abstract classes), the locking issues, the mystifying errors you get when you break something as well as a desire for interfaces.  But I will add a few more of my own and offer a cool trick as well.

I would like the IDE to make renaming or changing the type of private data much easier.  If I decided to rename an element of my class private data, I must then rename the accessor VIs, rename the controls and indicators on those accessors and then rename the virtual folder containing the accessors since I usually allow them to be used via property nodes.  I have not found a way to script these edits so this takes a lot of time to do by hand.  And I find myself needing to do this often.  Maybe I need to do more paper design before coding but it is still a PITA.

There is no native 'clone class' function.  I am using the GDS toolkit to do this but due to the static linked dependency issues mentioned above this takes a long time and usually crashes LabVIEW.

And now the trick.  If you have a large number of classes in your project and you try to open the properties dialog for one of those classes, it can take around 45 seconds for the dialog to load and be usable.  This does not happen where there are only a few classes in your project.

Well, I just learned today that if you first select the class and then change the project from 'items' view to 'files' view before you right-click and open the properties, then the dialog will appear in a few seconds!

Credit to Jon McBee of Bloomy for this tip.  It alone made my entire NIWeek worthwhile.  (Not that I didn't learn other cool stuff as well)

[fabric]

jlokanis wrote:

Well, I just learned today that if you first select the class and then change the project from 'items' view to 'files' view before you right-click and open the properties, then the dialog will appear in a few seconds!

Interesting! Just tested this and it does indeed work... BUT: The problem is that it can take more than 45s to switch to Files view in a big project! Still a nice tip if you need to edit properties of multiple classes since you only pay the switching penalty once.

[TurboPhil]

1. Edit time
2. Build time
3. (Refer to 1 &2)

Seriously. Our pace of development has slowed to a crawl since we moved to LVOOP. I still think the code is more elegant, and I don't want to give up the flexibility, extensibility, and readability it affords us. But some of our larger applications can take 20 minutes just to open for editing, and take over 1.5 hours to build into exe. And considering our suite of applicaitons needing regular rebuilds now consists of 26 individual builds, the total build time when done serially is up to 16 hours. (Yes, we are working on parallelization via CI tools)

There are certainly aspects to our design that are my fault that are contributing to this--I did not approach it with the intent to keep class libraries decoupled, so coupling levels are quite high--but I still think the IDE is doing some completely unreasonable things when loading class libraries. Given the apparent logarithmic load speed, it would seem that the compiler must be reloading & recompiling each VI it encounters as it analyzes the linker information, without checking to see if that was already done.

We just really started the push for LVOOP refactoring throughout our systems about a year ago. And as the pace has ground down to a crawl, I think every day about how long we can keep going like this before requiring another significant overhaul to remove all the classes and go back to "stringly-typed" data messages and variant&enum style coding. I really don't want to have to admit defeat like that. Please make sure that this is one of the main things focused on when making LabVIEW "Better".