|
|
|
|
|
by icefo
1625 days ago
|
|
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. |
|
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