5 ms·

whhhhhhyyyyyyy? i just can't understand why someone would want python for embedded applications. i primarily use labview for systems development, and there is

whhhhhhyyyyyyy? i just can't understand why someone would want python for embedded applications. i primarily use labview for systems development, and there is not a single thing that would be gained by moving to python while many things would be lost. and no one can convince me that using python over labview would generate more robust code. i have used python before, and it was slower to develop in and more error prone than labview for system development. personally, i want to see more lisps/schemes and ML-based languages on embedded systems. i know there are some, but they aren't quite there. that's the direction i think we should move. python isn't the best at any one thing other than having lots of libraries. there are far more productive dynamic languages (lisps/schemes) and far better languages for developing safe code (ML-based). i am currently learning idris, which seems like it could be amazing for embedded code development. having provable state machines would be a huge plus.

keenerd 9y ago
> 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.
elago 9y ago
Admittedly I'm not extremely advanced in embedded design, and work more on prototype r&d than production applications with really high stakes (life safety, expensive equipment failure) I've always been really repulsed by labview for a few reasons: expensive, proprietary, vendor lock in to national instruments. Also prefer text only rather than graphical click and drag programming. For these reasons I'd choose python over labview in a hypothetical project where the hardware could be chosen to support either
deleted 9y ago
[deleted]
adrianN 9y ago
One important point is that Labview is proprietary and expensive and Python is free both as in beer as well as in freedom. Many people already know Python, so supporting Python on embedded systems opens up a whole new field for tinkerers. I feel that more options for embedded development are always better than fewer options. Personally I'd prefer Rust or Ada over Python, but other people like dynamic languages better.
- nikofeyn 9y ago
  part of my comment was also advocating other languages. i am actively researching options for replacing labview, but the choices are just not great. python is the last language i would consider moving towards. in general, i am looking for a lisp, scheme, or ML-derived language. there are places where these can be ran on embedded controllers, but they aren't complete systems. it's great that people are putting together these alternatives, but it just feels python is being force fed in places it doesn't belong. i don't see how this article can say python is better for safe code.
  - throwaway7645 9y ago
    Python has a lot of good runtime checks and doesn't allow implicit castes in most cases. It is #4 on TIOBE, and used all over industry, so probably not all that bad. If you're looking for something to run embedded: Rust, Nim (maybe if you tune the GC or turn it off), Forth, and Ada come to mind besides the obvious C/C++/Assembly. I'd keep an eye out on Red although it still has a ways to 1.0 it will be much nicer than Python in this space and much easier to use than most of the above. Red should run fairly fast when compiled and will yield a tiny native executable.
    - nimmer 9y ago
      Nim runs even on microcontrollers and produces tiny executables (few kilobytes).
christophilus 9y ago
What would it take for a scheme/lisp to meet your criteria for embeddability?
- nikofeyn 9y ago
  that's a great question. given that i use the labview ecosystem, having another language that allows me to program desktop, real-time, and fpga applications all with the same lanhuage would be the eventual goal. so being bale to target any high-level cpu like x86 or arm but also targets like xilinx zynq would be great. in addition, libraries for signal and image processing in additional to libraries for serial and other instrument communication would be best. i realize i am describing more of a systems development rather than just embedded systems, but those are my needs. basically i want something that can replace labview to give me access to more advanced abstractions.
verall 9y ago
Because old C/C++ programmers can use python just like C/C++, and it's easy. I work on an embedded soc, and it's seriously easy for an experienced systems guy to make a python interface to the huge C++ high level driver, without knowing very much python (let alone some kind of "productive" language). On the other hand, my experience using labview was like amputating my fingers with a spoon. So I probably didn't spend enough time with it to 'get' it. But it did crash a lot. A friend of mine uses it in the research lab he works in, and he hates it with a passion, and complains about buggy closed source modules and hidden accrual of state.
throwaway7645 9y ago
You're the first person I've met that would take labview over python. I suppose if you're heavily using all the block diagrams for signal processing or control systems it probably makes sense, but as a general purpose & beginner friendly language, python is king.
stinos 9y ago
Like other comments: I have quite a different experience. I don't think you are wrong, nor that I am wrong, but rather that it depends heavily on the type of application. Need to quickly have a basic graph for some signals in 'real' time? I'll pick LV over anything else: it will be faster to develop, more robust, and just work (until you want to customize the graph). In Python I'd first have to go look for the appropriate libraries to use, start fiddling with gui layouts, etc. And after a couple of hours it probably still wouldn't even look remotely as good as LV and still lack basic zoom/cursor functionality. But for even basic if-then-else and loop programming (not even talking 'true' algorithms) I'm, after about 10 years of Labview experience, pretty sick of using Labview for it. You see in Python I can just do [func(x) for x in someRange if x > 0 and x in someOtherRange]. In the time I typed that, in Labview I would have maybe managed to draw the outer loop and drag the func block into it. Then I'd still have to the conditional logic, all the wriring, etc. So even though you say for some cases Python might be slower, there is no way you can do this real life example faster in LV. And that actually goes for a major part of the program logic. edit Also a note on Python vs C for embedded and the likes: we're currently running an application where the whole backend is C++ and does things like signal processing, but the frontend is written in MicroPython and with usability in mind. As such, I can just give it to very inexperienced programmers and they can actually build something useful with it. Yet they don't even have to touch a fiddly build system or learn how to shoot yourself in the foot a million times and the backend still happily runs speedy code. So again: heavily depends on the application.
sametmax 9y ago
It's just easier. It's an open source power yet simple to learn language. There are many materials about it and many libs. Python has great productivity, and hzs priven great for protyting which is an asset in getting lower costs. It's not a silver bullet but it's nice to have it as a solution.
Too 9y ago
Labview is only simple if your problem domain is simple, eg: only scalar values, only cyclically updated values, no text handling, no lists, no event systems, very few conditionals, whole program fits on a single page, no distributed development.
- nikofeyn 9y ago
  that's really not true. i build systems using full on OOP, actor framework, custom OOP UI controls, many user interfaces, distributed, etc. all in labview labview has some great libraries for developing complex systems. thiugh i a, the first to say it isn't close to end game.

keenerd 9y ago

> 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.

elago 9y ago

Admittedly I'm not extremely advanced in embedded design, and work more on prototype r&d than production applications with really high stakes (life safety, expensive equipment failure) I've always been really repulsed by labview for a few reasons: expensive, proprietary, vendor lock in to national instruments. Also prefer text only rather than graphical click and drag programming. For these reasons I'd choose python over labview in a hypothetical project where the hardware could be chosen to support either

deleted 9y ago

[deleted]

adrianN 9y ago

One important point is that Labview is proprietary and expensive and Python is free both as in beer as well as in freedom. Many people already know Python, so supporting Python on embedded systems opens up a whole new field for tinkerers. I feel that more options for embedded development are always better than fewer options. Personally I'd prefer Rust or Ada over Python, but other people like dynamic languages better.

nikofeyn 9y ago
part of my comment was also advocating other languages. i am actively researching options for replacing labview, but the choices are just not great. python is the last language i would consider moving towards. in general, i am looking for a lisp, scheme, or ML-derived language. there are places where these can be ran on embedded controllers, but they aren't complete systems. it's great that people are putting together these alternatives, but it just feels python is being force fed in places it doesn't belong. i don't see how this article can say python is better for safe code.
- throwaway7645 9y ago
  Python has a lot of good runtime checks and doesn't allow implicit castes in most cases. It is #4 on TIOBE, and used all over industry, so probably not all that bad. If you're looking for something to run embedded: Rust, Nim (maybe if you tune the GC or turn it off), Forth, and Ada come to mind besides the obvious C/C++/Assembly. I'd keep an eye out on Red although it still has a ways to 1.0 it will be much nicer than Python in this space and much easier to use than most of the above. Red should run fairly fast when compiled and will yield a tiny native executable.
  - nimmer 9y ago
    Nim runs even on microcontrollers and produces tiny executables (few kilobytes).

christophilus 9y ago

What would it take for a scheme/lisp to meet your criteria for embeddability?

nikofeyn 9y ago
that's a great question. given that i use the labview ecosystem, having another language that allows me to program desktop, real-time, and fpga applications all with the same lanhuage would be the eventual goal. so being bale to target any high-level cpu like x86 or arm but also targets like xilinx zynq would be great. in addition, libraries for signal and image processing in additional to libraries for serial and other instrument communication would be best. i realize i am describing more of a systems development rather than just embedded systems, but those are my needs. basically i want something that can replace labview to give me access to more advanced abstractions.

verall 9y ago

Because old C/C++ programmers can use python just like C/C++, and it's easy. I work on an embedded soc, and it's seriously easy for an experienced systems guy to make a python interface to the huge C++ high level driver, without knowing very much python (let alone some kind of "productive" language). On the other hand, my experience using labview was like amputating my fingers with a spoon. So I probably didn't spend enough time with it to 'get' it. But it did crash a lot. A friend of mine uses it in the research lab he works in, and he hates it with a passion, and complains about buggy closed source modules and hidden accrual of state.

throwaway7645 9y ago

You're the first person I've met that would take labview over python. I suppose if you're heavily using all the block diagrams for signal processing or control systems it probably makes sense, but as a general purpose & beginner friendly language, python is king.

stinos 9y ago

Like other comments: I have quite a different experience. I don't think you are wrong, nor that I am wrong, but rather that it depends heavily on the type of application. Need to quickly have a basic graph for some signals in 'real' time? I'll pick LV over anything else: it will be faster to develop, more robust, and just work (until you want to customize the graph). In Python I'd first have to go look for the appropriate libraries to use, start fiddling with gui layouts, etc. And after a couple of hours it probably still wouldn't even look remotely as good as LV and still lack basic zoom/cursor functionality. But for even basic if-then-else and loop programming (not even talking 'true' algorithms) I'm, after about 10 years of Labview experience, pretty sick of using Labview for it. You see in Python I can just do [func(x) for x in someRange if x > 0 and x in someOtherRange]. In the time I typed that, in Labview I would have maybe managed to draw the outer loop and drag the func block into it. Then I'd still have to the conditional logic, all the wriring, etc. So even though you say for some cases Python might be slower, there is no way you can do this real life example faster in LV. And that actually goes for a major part of the program logic. edit Also a note on Python vs C for embedded and the likes: we're currently running an application where the whole backend is C++ and does things like signal processing, but the frontend is written in MicroPython and with usability in mind. As such, I can just give it to very inexperienced programmers and they can actually build something useful with it. Yet they don't even have to touch a fiddly build system or learn how to shoot yourself in the foot a million times and the backend still happily runs speedy code. So again: heavily depends on the application.

sametmax 9y ago

It's just easier. It's an open source power yet simple to learn language. There are many materials about it and many libs. Python has great productivity, and hzs priven great for protyting which is an asset in getting lower costs. It's not a silver bullet but it's nice to have it as a solution.

Too 9y ago

Labview is only simple if your problem domain is simple, eg: only scalar values, only cyclically updated values, no text handling, no lists, no event systems, very few conditionals, whole program fits on a single page, no distributed development.

nikofeyn 9y ago
that's really not true. i build systems using full on OOP, actor framework, custom OOP UI controls, many user interfaces, distributed, etc. all in labview labview has some great libraries for developing complex systems. thiugh i a, the first to say it isn't close to end game.