5 ms·

> i have used python before, and it was slower to develop in and more error prone than labview for system development. Exact opposite in my experience. I've b

> i have used python before, and it was slower to develop in and more error prone than labview for system development. Exact opposite in my experience. I've been there, tried that. Re-wrote it in python for a more than 50x productivity gain. At my first job out of school, I inherited maintenance for a couple of projects. All were extremely expensive custom test equipment, written in Labview. One was the central project, the whole point of this group's existence. It had been in development for more than two years. It routinely destroyed thousands of dollars worth of hand-made sensors during its power-on self-test. It was a far cry from being finished. It couldn't even be considered a prototype. In a two-week period, I taught myself python, quickly cloned the existing calibration procedures, and finished the entire thing. My boss thought I was a genius rockstar, but no, I'm not. I just had the sense to evaluate every available tool and came to the conclusion that Python (mostly due to the ctypes module and a robust Windows ecosystem), was the best option. Personally I'll use C whenever possible for embedded work. (And later I did port the entire project to a DSP running C, because Labview & an AD DAcq board was too expensive.) But if latency doesn't matter, Python is fine. edit: Side note, I was already conversational in Labview. Admittedly only for school projects, but at that point I knew more Labview than Python.

zwieback 9y ago
Agreed, at my job I'm now actively campaigning against LabView (and Matlab) for application development. These projects turn out productive at first and invariably turn into unsupportable messes. What's the right platform for "embedded systems" is debatable. A true bare-metal app has different requirements from something running on RPi or Beagleboard.
- nikofeyn 9y ago
  see my other reply. but in general, without proper architecture, any project will become a mess in any language. this isn't special to labview. all of my systems and code in labview are extremely extensible and maintenance. why? i pay attention to design and architecture and use labview's OOP functionality. people regular comment how great it is that i can add full features in mere minutes, including UI behavior, and they are regularly surprised by the end result i have with labview. is that possible in other languages? yes. but labview's dataflow makes it very easy to reason about local changes.
- lvoudour 9y ago
  I strongly disagree. I've used both LV and matlab for many years and they are tremendously good for specific tasks. Labview is great for data acquisition and GUIs to visualize this data. Drop a ready made UART/TCP/VISA block, some array manipulation in a loop, connect a waveform block with zoom/cursors/etc. and you have a working real-time app in a couple of hours. Matlab is perfect for heavy matrix operations on large datasets, fantastic for plotting your data and it's very good for prototyping algorithms. I tried python as an alternative for both. Tons of boilerplate code, a pain for GUIs and don't get me started on matplotlib/scipy/numpy... The biggest drawback of both LV/matlab is their proprietary nature and the expensive licenses which make them unsuitable for hobbyists (at least there's octave as a matlab alternative). But they're great tools for the appropriate tasks
  - snovv_crash 9y ago
    The problem with both LV and MATLAB is that once you've done the basics, and now you want to turn it into something that you can maintain and sell. With LabVIEW you can compile and redistribute, but good luck writing an efficient binary search tree when your data gets bigger than what can be searched for with brute force. Also, at least last time I used it, the version control was horrendous. For MATLAB, just forget redistribution in general. Nobody is going to buy a MATLAB licence to run your code.
    - thethirdone 9y ago
      I know very little about the current state of Labview; I used it a bit 6 years ago so this may be a silly idea. Do you know of any Labview -> Python conversion tools? I would think that would be a pretty ideal solution for the right problem domains. You could get a quick first version up, and then when you need more maintainability or flexibility, convert to Python. Obviously, this would require some kind of Labview library in Python, but that seems like it should be relatively easy to make as a wrapper around the Labview included library.
    - lvoudour 9y ago
      >The problem with both LV and MATLAB is that once you've done the basics, and now you want to turn it into something that you can maintain and sell. That's true, but it's not their strong selling point. There's tons of problems to solve at the r&d stage when dealing with custom hardware, a dozen different instruments and algorithm exploration. That's where these tools shine and the reason they're ubiquitous in industrial/military/aerospace environments. For a full product with drivers, libraries and fast, customer friendly UI sure there are better solutions, but there's no law that dictates to use the same tools at the development stage
nikofeyn 9y ago
that sounds like the software design itself was at fault. labview is a programming language. if one writes poor code, then labview can't magically fix that. since labview is dataflow and has static typing, it shares a lot in common with functional languages. this means you can trace your data and execution in a very deterministic manner. i often write code that just works. there are almost always no bugs in the final software. that's almost impossible in python. labview also has OOP, which any respectable labview developer uses heavily on any project. for larger projects and systems with concurrent processing needs, it's multithreaded features and actor framework are necessary. labview makes it easy to code simple projects, and so people don't treat it with respect. labview code is often written by non-software engineers, who will write poor code in ANY language. people seem to forget that. if one treats labview as any other language and with respect from the perspective of a software engineer, then it has a lot of functionality that is very difficult to replicate in other languages. for example, async is all the rage these days, including in python. labview has had that functionality for many years now. and the dataflow paradigm pays off big time. labview is different and people don't respect it. that's okay, because i do which makes me pretty valuable and quite efficient. and i do think labview could be improved. it's just i wouldn't put any effort into python, especially for real embedded systems. many, many languages out perform it in many vectors.

zwieback 9y ago

Agreed, at my job I'm now actively campaigning against LabView (and Matlab) for application development. These projects turn out productive at first and invariably turn into unsupportable messes. What's the right platform for "embedded systems" is debatable. A true bare-metal app has different requirements from something running on RPi or Beagleboard.

nikofeyn 9y ago
see my other reply. but in general, without proper architecture, any project will become a mess in any language. this isn't special to labview. all of my systems and code in labview are extremely extensible and maintenance. why? i pay attention to design and architecture and use labview's OOP functionality. people regular comment how great it is that i can add full features in mere minutes, including UI behavior, and they are regularly surprised by the end result i have with labview. is that possible in other languages? yes. but labview's dataflow makes it very easy to reason about local changes.
lvoudour 9y ago
I strongly disagree. I've used both LV and matlab for many years and they are tremendously good for specific tasks. Labview is great for data acquisition and GUIs to visualize this data. Drop a ready made UART/TCP/VISA block, some array manipulation in a loop, connect a waveform block with zoom/cursors/etc. and you have a working real-time app in a couple of hours. Matlab is perfect for heavy matrix operations on large datasets, fantastic for plotting your data and it's very good for prototyping algorithms. I tried python as an alternative for both. Tons of boilerplate code, a pain for GUIs and don't get me started on matplotlib/scipy/numpy... The biggest drawback of both LV/matlab is their proprietary nature and the expensive licenses which make them unsuitable for hobbyists (at least there's octave as a matlab alternative). But they're great tools for the appropriate tasks
- snovv_crash 9y ago
  The problem with both LV and MATLAB is that once you've done the basics, and now you want to turn it into something that you can maintain and sell. With LabVIEW you can compile and redistribute, but good luck writing an efficient binary search tree when your data gets bigger than what can be searched for with brute force. Also, at least last time I used it, the version control was horrendous. For MATLAB, just forget redistribution in general. Nobody is going to buy a MATLAB licence to run your code.
  - thethirdone 9y ago
    I know very little about the current state of Labview; I used it a bit 6 years ago so this may be a silly idea. Do you know of any Labview -> Python conversion tools? I would think that would be a pretty ideal solution for the right problem domains. You could get a quick first version up, and then when you need more maintainability or flexibility, convert to Python. Obviously, this would require some kind of Labview library in Python, but that seems like it should be relatively easy to make as a wrapper around the Labview included library.
  - lvoudour 9y ago
    >The problem with both LV and MATLAB is that once you've done the basics, and now you want to turn it into something that you can maintain and sell. That's true, but it's not their strong selling point. There's tons of problems to solve at the r&d stage when dealing with custom hardware, a dozen different instruments and algorithm exploration. That's where these tools shine and the reason they're ubiquitous in industrial/military/aerospace environments. For a full product with drivers, libraries and fast, customer friendly UI sure there are better solutions, but there's no law that dictates to use the same tools at the development stage

nikofeyn 9y ago

that sounds like the software design itself was at fault. labview is a programming language. if one writes poor code, then labview can't magically fix that. since labview is dataflow and has static typing, it shares a lot in common with functional languages. this means you can trace your data and execution in a very deterministic manner. i often write code that just works. there are almost always no bugs in the final software. that's almost impossible in python. labview also has OOP, which any respectable labview developer uses heavily on any project. for larger projects and systems with concurrent processing needs, it's multithreaded features and actor framework are necessary. labview makes it easy to code simple projects, and so people don't treat it with respect. labview code is often written by non-software engineers, who will write poor code in ANY language. people seem to forget that. if one treats labview as any other language and with respect from the perspective of a software engineer, then it has a lot of functionality that is very difficult to replicate in other languages. for example, async is all the rage these days, including in python. labview has had that functionality for many years now. and the dataflow paradigm pays off big time. labview is different and people don't respect it. that's okay, because i do which makes me pretty valuable and quite efficient. and i do think labview could be improved. it's just i wouldn't put any effort into python, especially for real embedded systems. many, many languages out perform it in many vectors.