Will LabVIEW ever support text-based development?

[jwestra-carrastro]

While LabVIEW is primarily focused on supporting measurement and test of hardware, it has a lot of advantages going for it as a general-purpose programming language:

• Effortless parallelism
• Low barrier-to-entry for non-software engineers
• Simple front-end development
• Cross-platform between Windows and Linux desktop environments

As a software engineer, I chose LabVIEW for many of my desktop applications because of these advantages. However, there are several key drawbacks to LabVIEW as a general-purpose language which have made my development experience difficult:

1. Mandatory graphical programming:
   
   • LabVIEW's graphical programming makes it a great choice for collaborating with fellow engineers whose background is in hardware rather than software, and it makes parallelism very simple to set up and understand.
   • However, it does make developing and maintaining complex applications very difficult. Simple additions to a program take much longer than they would in a text-based programming language because it forces you to spend hours pointing and clicking tiny nodes.
   • Connecting two nodes that don't fit in the window at the same time is a nightmare in LabVIEW. I have spent hours dragging wires across my block diagram just to add simple passthroughs in large case structures or shift registers in large loops. In a text-based programming language, this signal would just have a name I could type in both places in seconds.
2. Compiled source code:
   • .vi files are saved compiled with no option to save them in the text-based DFIR or the LLVM-IR. This makes version control with GIT a nightmare. No two developers can edit the same .vi at the same time to add or update functionality.
   • In a text-based programming language, or even a graphical programming language which saved to a text-based intermediate representation, multiple changes would be on different lines of the file, and GIT would be able to merge changes with little issue. This is impossible in LabVIEW because it saves to bytecode.
   • By default, compiled code is not separated from sources. There is an option to change this, but it doesn't seem to always work. Modifying a VI that calls another VI results in both VIs being recompiled on disk. The result is that you can overwrite changes another developer has made to a VI in your repo simply by opening a higher-level VI that calls it.

I would love it if LabVIEW had an option to save VIs in the DFIR or LLVM-IR. This way it would be possible to write text-based code in concert with the default graphical code, to maintain source file independence, and to enable precise version control. I believe LabVIEW has the potential to be a simultaneously high-performance and approachable general-purpose programming language, but withholding the option of text-based sources is holding it back from reaching its full potential.

[GerdW]

Hi carrastro,

---

@jwestra-carrastro wrote:

However, there are several key drawbacks to LabVIEW as a general-purpose language …

1. Mandatory graphical programming:
   
   • LabVIEW's graphical programming makes it a great choice for collaborating with fellow engineers whose background is in hardware rather than software, and it makes parallelism very simple to set up and understand.
   • However, it does make developing and maintaining complex applications very difficult. Simple additions to a program take much longer than they would in a text-based programming language because it forces you to spend hours pointing and clicking tiny nodes.
   • Connecting two nodes that don't fit in the window at the same time is a nightmare in LabVIEW. I have spent hours dragging wires across my block diagram just to add simple passthroughs in large case structures or shift registers in large loops. In a text-based programming language, this signal would just have a name I could type in both places in seconds.

---

For me the graphical nature is not a drawback, but a main advantage!

• Simple additions take the same time, regardless of the size of the exisiting code! Why do you need to click nodes for hours?
• When your nodes are not within the visible part of your block diagram then your block diagram is way too large. Simple rule/guideline: block diagrams should fit on a screen!

---

@jwestra-carrastro wrote:

1. Compiled source code:
   • .vi files are saved compiled with no option to save them in the text-based DFIR or the LLVM-IR. This makes version control with GIT a nightmare. No two developers can edit the same .vi at the same time to add or update functionality.
   • In a text-based programming language, or even a graphical programming language which saved to a text-based intermediate representation, multiple changes would be on different lines of the file, and GIT would be able to merge changes with little issue. This is impossible in LabVIEW because it saves to bytecode.
   • By default, compiled code is not separated from sources. There is an option to change this, but it doesn't seem to always work. Modifying a VI that calls another VI results in both VIs being recompiled on disk. The result is that you can overwrite changes another developer has made to a VI in your repo simply by opening a higher-level VI that calls it.

---

• To ease any kind of SCC you should always turn on "separate compiled code".
• Why do you need to merge multiple changes to a file? A VI should follow the rule "one file per function"/"one function per file"…
• You cannot overwrite changes in one VI by opening another VI. Why do you think so?
• When working in teams developers should not work on the very same function, no matter if its text based or LabVIEW. They can always check out code from a repo and prohibit other developers from modifying the very same part of code (regardless of programming language). In a team there should be clear tasks and responsibilites for each developer/team member!

[santo_13]

I totally agree with GerdW.

A lot of complaints you've are because you're not structuring your project appropriately to follow the best practices. There are several LabVIEW developers who have mastered a lot of shortcuts using the quick drop plugins to make their life easier. Using a proper architecture, framework and tools, adding features will become easier.

Only one thing that can be improved is the LV compare and merge but if you avoid ending up in that scenario by carefully structuring the VIs then you're good.

[LLindenbauer · Accepted solution]

---

@jwestra-carrastro wrote:

I would love it if LabVIEW had an option to save VIs in the DFIR or LLVM-IR. This way it would be possible to write text-based code in concert with the default graphical code, to maintain source file independence, and to enable precise version control. I believe LabVIEW has the potential to be a simultaneously high-performance and approachable general-purpose programming language, but withholding the option of text-based sources is holding it back from reaching its full potential.

---

I share your view on these issues and would like to add one more perspective to it:

The IDE and compiler are products. Opening the source code file format would allow third parties to create their own tools for editing and compiling. It is thus primarily a question of business strategy.

The last time I checked VI scripting, the functions that would allow you the create your own editor were restricted to use within the IDE only. NXG had an open format and was cancelled.

[ThomasHenkel]

Because no one has mentioned it yet: there is still LabWindows/CVI, where you can program text-based in C.

[billko]

---

@ThomasHenkel wrote:

Because no one has mentioned it yet: there is still LabWindows/CVI, where you can program text-based in C.

---

I guess that's because it is not LabVIEW.

[paul_a_cardinale]

Even for very large apps, I find LabVIEW easier to use than text-based languages.

In fact, for me, the large the app, the greater the advantage of using LabVIEW.

[billko]

---

@paul_a_cardinale wrote:

Even for very large apps, I find LabVIEW easier to use than text-based languages.

In fact, for me, the large the app, the greater the advantage of using LabVIEW.

---

Although you can query the ID of an instrument in LabVIEW faster than you can type "printf".  Well, faster than I could type it, anyway.  😄

[ThomasHenkel]

@billko wrote:

---

@ThomasHenkel wrote:

Because no one has mentioned it yet: there is still LabWindows/CVI, where you can program text-based in C.

---

I guess that's because it is not LabVIEW.

---

It is some kind of a text-based version of LabVIEW, which is what the OP asked. You can access DAQmx, VISA and Co in the same way as in LabVIEW. If he wants to program in a text-based language, LabWindows/CVI is definitely worth a look.

[billko]

---

@ThomasHenkel wrote:

@billko wrote:

---

@ThomasHenkel wrote:

Because no one has mentioned it yet: there is still LabWindows/CVI, where you can program text-based in C.

---

I guess that's because it is not LabVIEW.

---

It is some kind of a text-based version of LabVIEW, which is what the OP asked. You can access DAQmx, VISA and Co in the same way as in LabVIEW. If he wants to program in a text-based language, LabWindows/CVI is definitely worth a look.

---

No, this is not even closely related to LabVIEW.  It might have a superficial resemblance to LabVIEW, but that's where the similarities end.  And the question was specifically if LabVIEW would ever support text-based development.

Also, it would seem that the OP was thinking along the lines of a LabVIEW hybrid.