VI API - The solution to all problems

[Quiztus2]

Maybe not all problems, but a few important ones. I wanted to share and discuss an idea I have that could significantly improve LabVIEW.

The problems
1. Binary VI representation hinders source code control and collaboration.
2. Class manipulation in the LabVIEW IDE is more tedious than in text-based programming. Creating and editing classes were not primary requirements when the IDE was initially designed.

The "solution":
By introducing an API for VI creation, we could achieve something similar to a SQL database dump—a readable functional representation of a VI. This would give us real source code that is much easier to compare, merge, and revise.

We could develop custom tools to create LabVIEW classes from text-based programming in any language. I recall a parser from JDP that did something similar, likely using scripting. If LabVIEW could live-update its codebase with external changes, as Sam Taggert suggested recently, it could create a seamless experience and bridge the gap between single VI users and more experienced ones.

[paul_a_cardinale]

You are  quite mistaken.  All problems are caused by gravity.  If we just eliminate gravity, there will be no more problems.

[cordm]

In the beginning the Universe was created. This has made many people very angry and has been widely regarded as a bad move.
- Douglas Adams, The Restaurant at the End of the Universe

[paul_a_cardinale]

Hey Quiztus2: Do you realize that what you are proposing is insane?

You want to put a wrapper around a graphical language in order to use it as a text based language.

There are already hundreds of text based computer languages.  Just use one of them instead of trying to add a kludge to LabVIEW.

[altenbach]

While I am not sure I fully understand your idea, your subject somehow reminds me of a Homer Simpson quote:

"To alcohol! The cause of, and solution to, all of life's problems."

😄

[rolfk]

In a somewhat more serious tone than the others, what you propose has been debated over and over in the course of LabVIEW. And NXG was supposed to solve it all with its XML based file format according to some prophets, except they were wrong. XML is not the panacea to all inter-application readable file formats but usually falls more in the following joke:

I had a problem about representing my structured binary data in a way that was readable for other software than my own and chose XML. Now I have at least two problems! (Most realistically they got likely a few more too and the XML format still doesn't solve the original problem without also having the entire XML schema available, and having the tools involved understand it fully).

The reality is that you can represent involved structured binary data in a generic way but still can't do anything with it without knowing the exact context and schema structure of that data. Anyone claiming otherwise just has not yet ever tried to parse such data! Just try to develop your own JSON parser, and no JSON in itself is not enough to represent arbitrary structured binary data without some custom extensions.