Hacker News Reader

Comment by 7thaccount | Hacker News Reader

Yep, this and there is a Quora question somewhere I think iirc.

It's mostly LabView I think, which is an interesting choice given all the hate it gets.

For those that don't know, LabView is a graphical (drag and drop) language for the most part where you interconnect various hardware components together. The advantage is that a lot of labs need to plug a lot of devices and sensors to run an experiment and LabView has support for a large amount of hardware. So you connect it all and can graphically view what the outputs are doing in chart form. The downside is that I don't think it's always very easy to specify exactly what you want to do, and code can pretty easily become spaghetti. There are a lot of horror stories about engineers having to maintain someone else's code.

Edit: -Flight software is C++ -Launch is mostly LabView and yes, they have LabView running in mission control

View on HN

We use LabVIEW, probably one of the few non-aero startups that do. It's great for parallel computation and test stand stuff, but I doubt they're flying LabVIEW executables. Most of the utility of LabVIEW comes on the V&V side (running lots of tests and logging lots of data).

Also it's very easy to build maintainable code in LabVIEW (contrary to the popular narrative), but there's a serious lack of good learning resources, and most people don't even take Core 1 and 2 before trying to code. Kind of like how a person on the business end of things may discover VB.NET and create some horrifying macros, simply because they don't know any better.

I think the main advantage of LabVIEW is not the language but the hardware it runs on. While it is ungodly expensive it's very reliable in a wide range of temperature & vibration.

I used LabVIEW to code the control / data logging of a prototype racecar and the hardware only broke once when we probably zapped it with a nasty ESD or reverse polarity connection somewhere. We never figured it out and didn't ask when we sent the part to be repaired.

Programming in LabVIEW is something I wouldn't wish on my worst enemy though. It's extremely hard to debug and time consuming to refactor. I always felt that I was 10-50x slower than when I would code in a standard text-based programming language. Working collaboratively also put you in a world of pain because, at least when I used it and I think it's still the case, LabVIEW doesn't support git natively so you have to use an external tool. They have a tool to merge / diff their proprietary binary files but the UX is terrible and I think even if they really tried to do something good, diffing diagrams (which is what a LabVIEW program is IMO) is going to stay hard.

From my experience the people that code in LabVIEW are not software engineer and I had discussions where I was arguing that yes the channel feature is broken but that's not a reason to put all the variables used to communicate between components in a single global variable file for example.

But once you fought against the language long enough and have something that works you can be pretty sure it will keep working forever.

I'd disagree about debugging; you can create custom probes for any given wire that run arbitrary code whenever the data gets updated, that combined with the ability to "hold wire values" aka program state, after execution has finished (or even paused) is a godsend.

Re: merging; yes absolutely, this is totally broken. NI should either release the file format for VIs, or offer conversion to something saner like XML, which you could easily build a nice git-diff tool for.

I maintain that LabVIEW is a good language with a terrible teaching problem; you can do so much if you just master the queued message handler architecture, and you can do things in a way that are extendible and maintainable for years afterwards

may be for prototyping labview is useful or python perhaps. but for real time I still think they rely upon C++

Reply on news.ycombinator.com