Hacker News new | past | comments | ask | show | jobs | submit login

Knowing that the ground control software is written in LabView is one of the more disappointing things I've read recently. I did a bunch of test engineering during co-ops during college, including multiple "codebases" of LabView, plus the normal class coursework and research lab instrumentation. I hate LabView, to the degree that I made a commitment never to apply to a job that has it's use as one of the requirements or as part of the desired qualifications.

I remember working on a getting a brushless motor test stand up and running using a LabView VI, which was written by one of the senior test engineers a couple years before. After spending days working on it, I eventually went to him for help. He sat down with me and it for another two hours, and even then, he needed to take the code (that he wrote!) and go sit down with it alone the next day for several hours to understand what was going on. If you're not working it essentially full-time, on the same codebase, it's insanely difficult to maintain any non-trivial code.

What makes the situation even a bigger shame is that National Instruments makes Labwindows/CVI, an ANSI C equivalent to LabView. The few times I've used it (in a graduate-level experimental physics class), it was so much easier to use and maintain.




How well do you actually know LabVIEW? Have you ever used its object-oriented system, actor framework, network streams, or get/set control value by indices (a feature actually implemented for SpaceX) functionalities? These are all things a professional LabVIEW engineer will be familiar with and use. The fact that a system didn't use these means it's either seriously outdated or the person writing it wasn't aware.

It sounds like you hate LabVIEW because you worked on a few poorly architected systems, as I don't see anything in your hate for it that actually applies to LabVIEW the language/environment.

> If you're not working it essentially full-time, on the same codebase, it's insanely difficult to maintain any non-trivial code.

It's hard to maintain any codebase if you're not giving it attention. I would argue that LabVIEW, when properly architected, can be maintained just fine and maybe even easier than other languages. I've done it.

LabVIEW is highly performant and excels at throwing data around and processing it and interacting with hardware. Its dataflow nature actually makes it easy to modify and maintain, when done properly. There aren't many languages that make it that easy to make user interfaces and distributed systems. Another language/ecosystem that I would consider for such a system is Elixir/Erlang, but you'll be searching for a user interface solution and lots of hardware drivers. However, with Elixir/Erlang you gain a system even more built for distribution but you lose out a lot on synchronous/sequential performance. C#/F#/.NET are other options to use since NI makes quite a lot of .NET drivers.


This is definitely fair--I don't consider myself a LabView expert. I'm proficient with object-oriented systems (Python, C++, Rust (if you consider Rust object-oriented)), with get/set for indices and network streams, but not familiar with actor frameworks outside of a passing read-some-docs a few times. I'd estimate I've cumulatively spent around a month working on LabView full-time, including writing/editing several working instrumentation sets in different settings.

I don't like LabView because of the when-properly-architected asterisk. Sure, well-written code doesn't happen all the time in any language, but my personal experience is that the both the frequency and severity of that being the case is much higher in LabView than any other language I've used, making the barrier to entry for writing good code essentially being close to a full-time LabView engineer.

You'll get no argument that it can do a good job when it's written well--the good LabView VIs I've used are definitely fast, and as you pointed out, NI makes sure that it plays well with hardware. But, to me, the risk of getting hired somewhere with a poorly-constructed system written in LabView is far too high, considering the grief I've had trying to fix those system.

I appreciate your suggestions for other alternatives--I haven't personally used C#/.NET a lot, but I know several test engineers who love it enough to do all their GUI work in it. I'll keep it in mind next time I'm setting up a DAQ system!


Just a few clarifications. By get/set control values by indices I meant a specific feature in LabVIEW that allows high-performant updates of front-panel controls. You use these when you have a lot of data being streamed to the front panel. By network streams, I again meant a specific LabVIEW feature (https://www.ni.com/documentation/en/labview-comms/latest/dat...) for sending data back and forth over Ethernet. It's a nice high-level library that is performant. It just makes it extremely easy to pass data around. In any big system, these features are a must-have. Also, I wasn't judging, so apologies if it came across that way. :) There's just a difference between little small systems that don't use LabVIEW's features and those that do. Most people who have used LabVIEW to its full extent have completely different complaints than those whose experience revolves around university or internship LabVIEW software, and so I like to point out that LabVIEW isn't fundamentally flawed as a visual language.

I think that the when properly architected asterisk applies to any language. LabVIEW is in a difficult situation because there are two huge factors at play. It makes it easy to start off and get things going, but systems inevitably grow beyond their original scope, and so LabVIEW systems are often developed by non-software people but still expected to grow. That's a conflict. The second thing is that more traditionally trained programmers have a mental block when it comes to LabVIEW, so people who do know how to properly modularize code don't pay attention to LabVIEW. So in LabVIEW, you have some experts who do treat it seriously, as if it was any other software system, but then a lot of code that was thrown together by others new to software and to LabVIEW. I would say Python is actually in a very similar situation by being "friendly" to beginners, so there is a ton of bad Python code out there.

I once interviewed at a place that had completely sworn off LabVIEW. I couldn't get them to explain why. They just hated it. But then I asked to see their Python code, which is what they had moved to, and I was greeted with a single file that was 10,000+ lines long. And in there I saw some function signatures that were 15-20 lines long (yes, the function's arguments spanned that many lines). So I see that as a disconnect. They hated LabVIEW but didn't know why and loved Python and didn't know why. In either case, they didn't know what they were doing.

The .NET APIs NI makes are nice enough, and I have used them before but not to a deep degree.


I have written and maintained a piece of testing/control software. It was originally horrible “old” spaghetti Labview. I maintained it for a while then wrote a replacement with Labview’s actor framework. I agree that the AF seems to be the only reasonable way to write certain kinds of larger application. However, the actor framework was, for me, just barely good enough to be usable.

- The debugging story is very bad: There were community efforts to write some tools to help, but they amounted to downloading software from a forum post.

- Development is incredibly tedious: Creating a new actor, or message, or (god forbid) implementation of an abstract message. They all take SO many clicks across lots of files in a slow IDE. Tedious and error prone.

- Distributing actors across nodes is not supported by the framework.

- There is no concept of supervision trees, so if you want “let it crash” robustness, you’ll be writing that yourself

I wish it were different, because at its heart I kind of love the idea of a strongly-typed dataflow language.

Edit: I want to point out that despite how personally ugly I found the experience, I’m not sure there was a better choice. I would love to have used Elixir, but what (non-software) engineering company can hire for that?


I agree with your complaints. Indeed, implementing an abstract message is awkward, although there was a specific version that did improve the project interface to make that easier at some point. I remember a relief of "finally". Haha. The right-click menu for the actor framework is implemented using project providers and LabVIEW scripting, both of which need massive improvement. It's an awkward process to even get the license to implement project providers as a user. I've just ignored them because I'd rather just write custom tools off to the side that use LabVIEW's application control system manually. And there's also a lot of ideas I have that require scripting, but it's not an easy system to use.

I also agree with the actor framework being too bare bones, and there are plenty of things I disagree with in the design. That's why I extended it myself to add in additional support. For example, I added built in messages to notify when an actor is ready, a publish/subscribe mechanism to break out of the recommended hierarchical setup when needed, a streaming actor that you can subscribe to the data it streams out via messages, a finite state machine actor that allows state transitions triggered by messages or internal requests and message mechanisms to notify when this happens to subscribers of the state updates, and some more.

> There is no concept of supervision trees, so if you want “let it crash” robustness, you’ll be writing that yourself

Yea. I recently learned Elixir/Erlang to some degree. I'd like to have an OTP-like system in LabVIEW. The above extensions are actually already close in some ways. For example, the FSM actor I made is similar to gen_fsm or gen_statem in OTP.

> I want to point out that despite how personally ugly I found the experience, I’m not sure there was a better choice.

Therein lies the rub. I've searched for one. Despite my complaints about LabVIEW, I end up finding other systems even harder to work with for these applications. Elixir/Erlang are great, but developing a user interface with them will require web-technologies. C#/F#/.NET is the other system I've identified, but it's a fairly complicated ecosystem. And what language allows me to do desktop apps, web apps, web servers, real-time deterministic programming, and FPGA programming all in the same language and environment? It's a tough feature set to replicate and replace.


I think another thing that is often overlooked is that a project like this requires a ton of very diverse hardware in the form of hundreds or maybe thousands of sensors, valves, PLCs etc. A rocket launch site reminds me a lot of an industrial process facility. National instruments sells all of that hardware with LabView as a complete solution. Their PXI systems, which are used extensively in the process industry, are quite expensive up-front but the seamless integration of the hardware with Labview drivers, Teststand etc makes it so much more cost-efficient down the line.


That AMA is from 2013, when LabView would have seemed like a more reasonable choice. Dunno if they've changed since then, but it's possible they've come to their senses.


Having worked at National Instruments, I will say there are some engineers out there that really love LabVIEW. It has been a successful tool.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: