LabVIEW
VI API - The solution to all problems
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.
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."
😄
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.
@Quiztus2 wrote: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.
There is an API for VI creation...
@Quiztus2 wrote: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.
There's only one tiny problem... This is a lot of very hard work.
There is no guarantee the many, many difficulties can be solved.
@Quiztus2 wrote:
If LabVIEW could live-update its codebase with external changes, as Sam Taggert suggested recently,
I suppose you could make a project provider that checks updates on disk and revert VIs when the file updates.
Again, a lot of very hard work.
@Quiztus2 wrote:
it could create a seamless experience and bridge the gap between single VI users and more experienced ones.
It could. It might not. The execution details will make a huge difference.
Both the (expected, not guaranteed) gain combined and the expected success rate prevent this from being attempted.
YMMV. Let us know.
Search LabVIEW like a graph!
@paul_a_cardinale wrote:In the 1990s, IBM developed the System Object Model (SOM), which allowed sharing of class libraries between different programming languages. But it has largely faded away.
COM (Common Object Model) was supposed to do the same, together with a seamless over the wire streamed format that was called DCOM, for Distributed COM. It was the building block of ActiveX and is still largely used in the Windows Shell component (basically everything File Explorer related). But the promises were never fully realized. And the security considerations eventually made it even for Microsoft pretty much unmanageable. It did however create a walled garden for Microsoft for a long time, as the entire technology was simply to complex for the competition to be fully tackled. (D)COM, despite its promises of being a highly platform independent technology, locked any user pretty much into using Windows, since the according implementations on other platforms were mediocre, if anything even existed.
Still, DCOM only tackles the relatively limited task of describing a class interface in a streamable format, and to allow invoking according class methods remotely based on just that description alone (similar to gRPC nowadays). Describing a LabVIEW VI requires a bit more than that, since it is more than just an object. The actual programming is a directed graph for instance, and that is just one aspect of it.
@paul_a_cardinale wrote:
@rolfk wrote:
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.
In the 1990s, IBM developed the System Object Model (SOM), which allowed sharing of class libraries between different programming languages. But it has largely faded away.
.NET allows sharing libraries between languages (and targets).
In general. it's quite successful at that too.
LabVIEW's limited .NET support makes it not nearly as useful as it could be, to us... But that's not .NET's fault.
