Hacker News Reader

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

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.

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.

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

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.

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.

>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

For MATLAB, just forget redistribution in general. Nobody is going to buy a MATLAB licence to run your code.

That's a bit far fetched. People already having a Matlab license (and it's not like there aren't many of those) already made that cost, so buying your Matlab product is not really different. Alternatively you could compile your code into a C API and distribute that instead: the Matlab runtime itself is free of charge.

You don't need a Matlab license to run compiled Matlab code. Matlab provides free runtime libraries.

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.

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.

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.

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.

Nim runs even on microcontrollers and produces tiny executables (few kilobytes).

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

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.

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.

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.

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.

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.

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.

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

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.