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.

5 Comments

  • Pingback: The Graphical Tax – Alliance of LabVIEW™ Architects.

  • Fab

    August 3, 2019

    James,

    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

    Reply
    • James McNally

      August 5, 2019

      Yeah 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!

      Reply
  • 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

    Reply
    • James McNally

      August 5, 2019

      Hi 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)

      Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.


By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close