NI maintains a constant presence on all LV-related forums and communities. It also
provides fast support on its official forums and in-depth articles on ni.com. The
people there are not only marketing guys - in large part they're engineers who work
on the actual code of NIs products. All this is, generally, good. It is easy to talk
directly to people who really know how the code behind LV works. That is a strength
which often pushes clients towards these products.
But it also generates the possibility of silencing criticism and limiting visibility of unfavorable content. And these are taking place as well. So let me provide a few answers here.
Absolutely not. Not even close. Arguments about program optimization are irrelevant, you can optimize C code as well, and get way better results for code size and performance.
In other languages, you compile the whole code together, which allows the compiler to do
wild optimizations. It re-uses strings, re-uses parts of functions, in-lines functions
and expands loops. And while LV compiler is currently based on LLVM and therefore
is capable of doing all these things, it is not allowed to. That's because LV only
compiles small chunks of code, and keeps them in separate VI files. This impairs the
optimizer, giving it limited possibilities to influence the code.
Not to mention, the code from each VI is executed under control of the LV Runtime Environment - meaning that a large library is loaded at program start, and that library is controlling execution flow. The LVRT decides when to execute user code. And while it gives you effortless multithreading by doing that, it also creates unremovable overhead. You never really call other VIs, you are asking the LVRT to queue their execution.
Conclusion: LV is by design slower than C.
It's a lot easier than in other native languages, though a bit harder than in virtualized languages. You can decompile Java or C# almost effortlessly, while for C/C++ it's possible, but the process is manual in large part, and requires considerable work. For LV, it also requires work, but a lot less, and mostly because noone published a complete decompiler yet.
An executable built with LV does not directly contain user code. Instead, there's a package inside, which stores compiled VI files - and those contain chunks of the code. The package has LLB format; in LV7 and earlier, that LLB directly stores VI files. In later versions they were put into a ZIP file, and LLB stores that ZIP. The ZIP was introduced because LLB file has a flat structure, which caused issues with multiple files having the same names but being stored in different directories. Though users started complaining about the ZIP being easy to open and extract, and in LV12 the ZIP file was additionally encrypted, using simple XOR algorithm.
So from LV executable, you can extract all the separate VI files required to build it. They will lack Block Diagram, and some will lack Front Panel. But you're getting separate files, each storing something which is an equivalent of one function in other languages. You have names and directories where the files are stored. You can use these to re-build the application without even decompiling them, or look at the code chunks inside and re-create the files based on that. You don't have to go through megabytes of code, you're getting small chunks, with each of them named.
You are getting small chunks of code, like functions, and have their names - it sounds like kind-of OBJ files, right? Yes, that's what you have in LV EXE. The linking process is not part of creating LV executable, it is a part of executing an application. And the linking doesn't relay involve directly merging the code chunks together, but instead adds them to list of LVRT resources, and allows putting them into execution queue.
But if you're really worried about your code being reverse-engineered, it is more than likely that the issue is not in LV, but in you. If you're afraid of IP stealing - no, your LV project definitely doesn't have any crucial IP which others would want to steal by reversing. If you're worried about piracy - introducing any measures against that hurts legitimate users, it is way better to assume people are generally honest. And if you want to hide stolen IP, especially GPL, within your code - I will find it and expose it anyway, no matter how many levels of encryption you use.
Conclusion: LV is by design easy to reverse engineer.
Everything around LV is closed source and closed format. Even "source code" files - VIs,
don't have any public specification. The parser in pylabview project I made is actually
the best existing public documentation of the format.
That security by obscurity is the only way LV is protected. Independent security researchers are rarely looking into LV - because of lack of access (LV does cost), lack of interest (there really are more popular and more interesting apps to analyze) and lack of proper encouragement on NI side (they have a history of not caring even about severe security issues).
VIs have a lot of interesting flags and properties, plus they store a native code, which can easily be replaced by malicious one. Now, is there any security around executing that code? Can it be executed during loading of VI file, or do you have to press "run"? Hard to tell, I'm not motivated enough to dig into that. But just to be sure, I'd be very careful about even opening any VI files from the Internet on your machine.
I have to also mention NI Internet Toolkit which got interesting treatment after some
security concerns - it got discontinued. Since its last version was for LV12, and files
from versions above LV8.6 can be loaded in all newer LV releases, anyone requiring internet
protocols in their LV application, downloads and uses that old version with known flaws.
Conclusion: It is unlikely that the environment is secure.
Whether you will use LV or a normal text-based language is your decision only. If you're planning to make programming your main job, and you think about getting, over time, vast knowledge in the field, then LV will soon start limiting you and there's no point in getting into it. Saying goodbye is hard if everything you've learned so far only applies to a closed, isolated language developed by one company, which tries hard to isolate the developer from its internal workings.
If this is not your profession, ie. you're a testing technician, hardware engineer or some general scientist for whom programming is not the main focus, then you could consider LV. It allows to build a simple application fast and with no prior knowledge. Just remember that you're getting into proprietary and paid ecosystem, and make sure you won't get completely dependant on it. If you write your code in LV, it will not be possible to switch to other platform without complete re-implementation. Even to view the 'source code', you will need LV license.
There is a reason why LV isn't conquering any territories ruled by other languages. It is definitely not the best general solution. But there are specific use cases in which LV is as good as other environments.
Not really. You can read positive things about LV in many places; the LV engineers are generally open and provide a lot of true information. It's a bit worse with unpaid zealots, as these are writing insane things about how good LV is. Somehow their comments are rarely removed, while any negative opinions are heavily moderated on the official forums.
The whole ecosystem isn't perfect, but it's productive, lawful and mostly ethical. I focused on the bad here, as that is what's missing in other places.
Use LV at your own risk. And remember that the official forums are not only to exchange knowledge, but are a part of NIs marketing - moderators there are making sure to paint LV in good light only. Unofficial forums are a bit better, but still have close ties to NI.