9 ms·

Don't be rude. LabVIEW is used in production in a lot of serious environments.

jki275 8y ago
I've been in those environments. I've had to try to repair horrific "code" written in it. I've participated in "code reviews" where the straightness of the lines was carefully assessed in the massive mess of spaghetti code they had created and thought was good code. LabVIEW is a toy for EEs to write prototypes in. That would have been okay if it had stayed there -- but the problem is that people are actually distributing "applications" using it, and trying to maintain them is nearly impossible.
- stinos 8y ago
  I still don't get why you call it a toy, or just for prototypes. Maybe think somewhat broader and not just about the bad experience(s) you had with it. For the things it's good at, it just works and it's pretty hard to find alternatives (well, Measurement Studio is ok, but for simple things it's usually still a bit more work than Labview). The hard part is figuring out what Labview is good at and not make the mistake of trying to use it for everything. Sound like that's where most of your bad experiences come from. Here's an example of a place where Labview just shines: I needed something to plot 'rolling' analog and digital signals, i.e. basically provide a visualization of the inputs of a combined analog/digital input card. With ability to pause the thing, each line in a different color, data cursors, ... The data is acquired by C++ code, but since Labview has this stuff built in getting the whole thing up and running is just a matter of setting up a communication protocol between the C++ part and Labview. I just went for TCP/IP and got the thing up and running in a couple of hours. Has been used like that for years now. Not exactly a prototype, nor a toy. It just does this one thing, it's all we needed, and it does it extremely good.
  - jki275 8y ago
    I call it a toy because that's what it is. It's used almost exclusively to bypass doing things the right way. As you highlight quite well with your example.
    - detaro 8y ago
      What's "the right way"? Spending an extra few days on making your own visualization code, throwing away flexibility in the process?
      - jki275 8y ago
        Time spent doing it right up front pays off when someone has to maintain it.
    - stinos 8y ago
      Well, enlighten us then. What is the right way according to you? In case of my example: what is a better way than getting things done in a few hours, with no bugs whatsoever, with all functionality needed, and just working? I'm actually truly curious as to what would be better and more right.
      - jki275 8y ago
        To begin with, the labview run time is riddled with bugs. Every application I've ever seen written under labview is expected by its creators and its users to crash randomly and continually for no explainable reason. Yes, drawing out some things in a visual IDE and having it work is nice. The problem is that eventually LabVIEW is going to update their runtime and it won't work anymore. Now what? Take the time and do it right up front, and then when it needs to be updated people aren't cursing "whoever decided to do this in LabVIEW years ago" as they often do in these situations.
        stinos 8y ago
        do it right up front, Ok, but again what do you suggest is 'right' then, any example? Because as laid out, for me, it is right, since we have zero problems. Every application I've ever seen written under labview is expected by its creators and its users to crash randomly and continually for no explainable reason. Hmm, strange. Sounds to me like those creators must be doing something wrong. I mean, we've been running a couple of Labview applications for +10 years and I honestly think none of them ever crashed (where 'crash' means suddenly stops working without apparent reason because of a bug in Labview itself, not come to a halt due to programmer error). Also wen to, I don't know, 3 or 4 updates, without much problems. Again I think it just comes down to hwat I said first: the hard part might be fuguring out how to do Labview right, I guess.

I've been in those environments. I've had to try to repair horrific "code" written in it. I've participated in "code reviews" where the straightness of the lines was carefully assessed in the massive mess of spaghetti code they had created and thought was good code. LabVIEW is a toy for EEs to write prototypes in. That would have been okay if it had stayed there -- but the problem is that people are actually distributing "applications" using it, and trying to maintain them is nearly impossible.

stinos 8y ago
I still don't get why you call it a toy, or just for prototypes. Maybe think somewhat broader and not just about the bad experience(s) you had with it. For the things it's good at, it just works and it's pretty hard to find alternatives (well, Measurement Studio is ok, but for simple things it's usually still a bit more work than Labview). The hard part is figuring out what Labview is good at and not make the mistake of trying to use it for everything. Sound like that's where most of your bad experiences come from. Here's an example of a place where Labview just shines: I needed something to plot 'rolling' analog and digital signals, i.e. basically provide a visualization of the inputs of a combined analog/digital input card. With ability to pause the thing, each line in a different color, data cursors, ... The data is acquired by C++ code, but since Labview has this stuff built in getting the whole thing up and running is just a matter of setting up a communication protocol between the C++ part and Labview. I just went for TCP/IP and got the thing up and running in a couple of hours. Has been used like that for years now. Not exactly a prototype, nor a toy. It just does this one thing, it's all we needed, and it does it extremely good.
- jki275 8y ago
  I call it a toy because that's what it is. It's used almost exclusively to bypass doing things the right way. As you highlight quite well with your example.
  - detaro 8y ago
    What's "the right way"? Spending an extra few days on making your own visualization code, throwing away flexibility in the process?
    - jki275 8y ago
      Time spent doing it right up front pays off when someone has to maintain it.
  - stinos 8y ago
    Well, enlighten us then. What is the right way according to you? In case of my example: what is a better way than getting things done in a few hours, with no bugs whatsoever, with all functionality needed, and just working? I'm actually truly curious as to what would be better and more right.
    - jki275 8y ago
      To begin with, the labview run time is riddled with bugs. Every application I've ever seen written under labview is expected by its creators and its users to crash randomly and continually for no explainable reason. Yes, drawing out some things in a visual IDE and having it work is nice. The problem is that eventually LabVIEW is going to update their runtime and it won't work anymore. Now what? Take the time and do it right up front, and then when it needs to be updated people aren't cursing "whoever decided to do this in LabVIEW years ago" as they often do in these situations.
      - stinos 8y ago
        do it right up front, Ok, but again what do you suggest is 'right' then, any example? Because as laid out, for me, it is right, since we have zero problems. Every application I've ever seen written under labview is expected by its creators and its users to crash randomly and continually for no explainable reason. Hmm, strange. Sounds to me like those creators must be doing something wrong. I mean, we've been running a couple of Labview applications for +10 years and I honestly think none of them ever crashed (where 'crash' means suddenly stops working without apparent reason because of a bug in Labview itself, not come to a halt due to programmer error). Also wen to, I don't know, 3 or 4 updates, without much problems. Again I think it just comes down to hwat I said first: the hard part might be fuguring out how to do Labview right, I guess.