The Graphical Tax
I’ve been thinking a lot lately about tooling. I’ve been getting my CI system running smoothly (ish, more on that later) as well as exploring another new language and working on open source projects on GitHub.
I’ve realised that there are specific penalties that we have to face as LabVIEW developers that are largely down to the graphical nature of LabVIEW.
In my head, I think of this as the graphical tax and thought it would be interesting to put these out there, see if there are solutions I’m missing or at least let’s have a discussion.
Software Engineering Tools
This one is an easy place to start.
Most software engineering tools assume a text-based system. Git works incredibly well on text. Github can merge requests in the browser on text-based files. CI tools use a text-based interface (the command line) to automate tasks like building, testing and linting your code.
As LabVIEW developers, we miss out on a lot here:
- I’ve tried to plug the gap to CI tools with G CLI ( https://github.com/JamesMc86/G-CLI) but it is far from seamless as LabVIEW still has many cases where it pops dialogues.
- Git etc. do work but don’t understand the files so manual merge and diffs all round
- Any tooling for the language has to start from scratch. We can’t leverage what already exists.
This one is frustrating as software engineering marches on – we have to be careful not to get left behind. NXG promises to help a little with a human-readable VI format but I’m not yet convinced it will solve many problems (though some I’m sure).
Consistent Style
This is one that I think is really fundamental and just something we have to accept.
Compared to LabVIEW, text-based style seems simple! spaces vs tabs, newlines or not, camel-case or snake-case. There are certainly huge debates but it is essentially a 1D problem. It’s also easier to manage with linters and code analysis tools.
With LabVIEW, we take that problem and add new dimensions. Style is literally 2D. There is so much room for variation. So many mitigating circumstances for given diagrams that having a common set of skills is hard.
With text, you can add your own visual style on top with your editor while keeping the code “pure”. With LabVIEW, if you want different colours for your background it saves into the code.
A great example was a pull request I got on GitHub. After downloading the code to my machine many of the comments were too small. When I requested they were made larger to fit the text, they sent back a screenshot showing it fits on their screen.
This is an area that interests me in understanding more. I’m not sure if it is hopeless or we just need to be stricter. It certainly feels like a barrier to more collaboration and so something that should be considered.
Web Tools for Review
I think this is going to get harder and harder over time.
Increasingly the web is the centre of our working world. Text translates to that world well.
Recently I found a bug in an open-source javascript project that I wanted to fix. But I wanted to understand it more first, so I could go to Github and explore the code in the browser rather than littering my computer with hundreds of GitHub repos I want to study.
Review is also getting bigger. The place this really hurts for me is in pull requests on GitHub. When I receive a pull request for the C# part of G CLI it can be a 5-minute process. I can review the diffs in GitHub and understand what is going on.
With LabVIEW, you are forced to pull the project down to the desktop to open the IDE and view it. So when, like as I write this, I’m not on my main dev machine I may not be able to provide any comment on what is happening.
This could be improved by having sites with plugins for LabVIEW that can generate code images and diffs. I know some work has been done on this in Jenkins so it can be improved. But it will never be as straightforward as commenting on text code (line by line comments are handly).
Why Pay?
So why pay the graphical tax? Or:
If your just going to moan about it James then use text based languages
Well, there are still some hugely compelling reasons:
- I believe it is easier to understand program structure graphically which greatly speeds up development and debugging. At least I’m a very graphical thinker.
- There are no other tools that allow you to target desktop, real-time and FPGA systems with very little difference in syntax and concepts.
- Even on a single target – there are not many other languages that combine a fairly high level of abstraction and the level of performance that LabVIEW provides.
So I still think I’m a net gain for using LabVIEW. I have no plans to jump ship any time soon. But maybe, by sharing my concerns, I might trigger some thoughts on how we can tackle these issues.
Pingback: The Graphical Tax – Alliance of LabVIEW™ Architects.
Fab
August 3, 2019James,
Thanks for sharing. I have felt that frustration but I love the language so much that I forget about it or try to excuse it.
There is certain initiative the community is working on that hopefully works on that. I will tell you more about it at GDevCon.
In the meantime, have you checked out this LabVIEW dif tool that works with CLI? Simon, one of the systems engineers at NI posted it here:
https://github.com/ni/niveristand-custom-device-build-tools/tree/master/lv/operations/DiffVI
James McNally
August 5, 2019Yeah I do like the look of that – especially the option to post to GitHub for pull requests. Thats a hugely valuable feature
This is why I love creating posts like this – already lots of things come out that can help – now we just need to make them really easy for people to use!
Joe F
August 5, 2019“With LabVIEW, you are forced to pull the project down to the desktop to open the IDE and view it. So when, like as I write this, I’m not on my main dev machine I may not be able to provide any comment on what is happening.”
I also have a LabVIEW CLI on GitHub, and one of its tools lets you mirror G source as png snippets. It has git hooks so that when you push, it creates or updates the snippet mirror.
The setup for it is… half-way automated. I haven’t done much work on the out-of-the-box experience or distribution, so there’s still plenty of room for improvement 😀
If you’re interested, the repo is here: https://github.com/wireddown/VIKit and the snippet mirror starts here: https://github.com/wireddown/VIKit/tree/master/source/lv-snippet
James McNally
August 5, 2019Hi Joe,
This looks cool. Thanks for sharing and it’s an interesting way around it. It’s already nice that I can see how you have coded it directly – I might have to play with this a bit.
If it helps with packaging I’ve tried to make it really easy with G CLI now. You can create a VI package and install to a directory it searches in vi.lib. Chec kout https://github.com/JamesMc86/G-CLI/wiki/Creating-Tools-To-Work-With-G-CLI if it sounds interesting. (It does mean some changes to your tools to use that interface though)
Christian Butcher
August 30, 2019Hi Joe,
I took a quick look over your code at wireddown/VIKit and wanted to check I was understanding correctly. Am I right to think that you’re keeping a snippet of every block diagram in your repository, and using the pre-commit hook to update changed (committed) VIs each commit?
It looks very nice, but I’d be curious to know if you have any feeling for or experience with the increase in size of a repository when using this, especially if you have frequent and small commits.
Is there any way (I didn’t immediately see one, but perhaps with slight modification) to use this to populate, for example, a Pull Request (or similar tool for non-GitHub platforms). I.e. output the results of git diff to a folder of pngs across a number of commits? It seems like VISnipDiagram.sh might do this when passed a folder as the VI path, but I’m not sure if it will only get the changed files when it isn’t being called via VI paths as passed by the commit hook.
Perhaps something like the ‘git diff –name-status’ command you use can be used to generate a list and iterate over for this purpose… (I hadn’t seen this option before)
Joe F
September 6, 2019Hi Christian!
> “Am I right to think that you’re keeping a snippet of every block diagram in your repository, and using the pre-commit hook to update changed (committed) VIs each commit?”
Yes, you’re right.
> “I’d be curious to know if you have any feeling for or experience with the increase in size of a repository when using this, especially if you have frequent and small commits.”
I don’t have much experience here, but my understanding and expectation is that binary files in git are largely a “solved problem” with developers saying “disk space is cheap now” and by git improving its delta-packs for binaries since the early “beware the binary!” blog posts influenced the general attitude of git users. For G frameworks with 100+ VIs, you might consider storing the snippet mirror via Git-LFS.
> “Is there any way to use this to populate a Pull Request (or similar tool for non-GitHub platforms)?”
Perhaps, although this tool already does that — https://github.com/ni/niveristand-custom-device-build-tools/tree/master/lv/operations/DiffVI