LabVIEW
Do you still have fun using LabVIEW ?
I'm finding "fun" is becoming inversely proportional to the size of the LabVEW program.
NI makes some things very 'unfun'. Example: It's hard to convince yourself that calling a class object by (data value) reference using in-place structures is fun. Holy clunky syntax Batman! I mean, look at how you have to do error handling, if nothing else.
Then to get you good and mad, you realize, that NI doesn't do it this way. They call their class objects by reference in a much more sane way!
But, oh no.. race conditions... LOL
LV really can punish you if you can't do something using their normal "work-flows"... .. and it crashes a lot.. way too much, really... 30+ minute compile times get really unfun, when you realize that LV is only using one processor core... or realize that you have to do some crazy and exotic thing to prevent some memory object you created getting nuked by the memory manager..
In all seriousness, this latest program I'm currently working on may be the Plant's last big hurah in LabVIEW (been using it almost 25 years now). The reality was, the only reason LabVIEW was chosen this last time was because all the EE's here all have pretty extensive LabVIEW training. But we are all openly question if it is still the correct tool to be using in Capital Test and Measurement applications.
Like aeastet said earlier, it feels like you are watching something die. Worse still, something die that was once on the verge of greatness and then wasn't. It had potential.
But for small, quick and dirty, disposable applications, it's a blast and remains fun.
@joshua.l.guthrie2.civ wrote:
I'm finding "fun" is becoming inversely proportional to the size of the LabVEW program.
NI makes some things very 'unfun'. Example: It's hard to convince yourself that calling a class object by (data value) reference using in-place structures is fun. Holy clunky syntax Batman! I mean, look at how you have to do error handling, if nothing else.
Then to get you good and mad, you realize, that NI doesn't do it this way. They call their class objects by reference in a much more sane way!
But, oh no.. race conditions... LOL
LV really can punish you if you can't do something using their normal "work-flows"... .. and it crashes a lot.. way too much, really... 30+ minute compile times get really unfun, when you realize that LV is only using one processor core... or realize that you have to do some crazy and exotic thing to prevent some memory object you created getting nuked by the memory manager..
In all seriousness, this latest program I'm currently working on may be the Plant's last big hurah in LabVIEW (been using it almost 25 years now). The reality was, the only reason LabVIEW was chosen this last time was because all the EE's here all have pretty extensive LabVIEW training. But we are all openly question if it is still the correct tool to be using in Capital Test and Measurement applications.
Like aeastet said earlier, it feels like you are watching something die. Worse still, something die that was once on the verge of greatness and then wasn't. It had potential.
But for small, quick and dirty, disposable applications, it's a blast and remains fun.
Here's a VIM that can reduce the boilerplate needed for doing something inside a DVR.
@joshua.l.guthrie2.civ wrote:
I'm finding "fun" is becoming inversely proportional to the size of the LabVEW program.
NI makes some things very 'unfun'. Example: It's hard to convince yourself that calling a class object by (data value) reference using in-place structures is fun. Holy clunky syntax Batman! I mean, look at how you have to do error handling, if nothing else.
According to https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Can-we-have-an-error-in-terminal-on-the-in-place-elem... you are making it more clunky than it has to be.
[...]
Also, just FYI, the errors of the two bordernodes are the same result; the only errors generated are by the read, but we duplicate the error for you on teh read and the write so you don't have to wire through the structure; there's no need to merge both of them as you did.
[...]
@joshua.l.guthrie2.civ wrote:
I'm finding "fun" is becoming inversely proportional to the size of the LabVEW program.
I find that’s true for any programming language I worked with. The difference might be mainly that most other languages start with a much higher baseline of “unfunnyness” and the slope of increase is lower as the application grows larger. So the experienced pain over time often feels smaller in traditional languages but in absolute value you need to get in some fairly big applications to hit that crosspoint.
@joshua.l.guthrie2.civ wrote:
I'm finding "fun" is becoming inversely proportional to the size of the LabVEW program.
NI makes some things very 'unfun'. Example: It's hard to convince yourself that calling a class object by (data value) reference using in-place structures is fun. Holy clunky syntax Batman! I mean, look at how you have to do error handling, if nothing else.
That looks like you're trying to make it into a reference based class, basically. Maybe you should check out G#. 🙂
@UliB wrote:
According to https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Can-we-have-an-error-in-terminal-on-the-in-place-elem... you are making it more clunky than it has to be.
[...] Also, just FYI, the errors of the two bordernodes are the same result; the only errors generated are by the read, but we duplicate the error for you on teh read and the write so you don't have to wire through the structure; there's no need to merge both of them as you did. [...]
Granted.
But you still have to merge two errors. But wouldn't it be nice if the in-place had an error input (like the suggestion link suggested)? It's a lot of block diagram real estate to do something simple. To me, it screams, NI don't want you to do this, but you can if you want.
Regardless, it's frustrating it don't look like this (I get why, but something closer):
In other languages, it's super easy.
I fear I took the thread off topic with my rant. Sorry! 🙂
