I am a text-based traitor

I realised the other day that's it's been more than a year since I used LabVIEW! After a couple of job changes, I've ended up using other languages but I do still have a huge soft spot for LabVIEW and graphical code. That being said, I hadn't realised how different the text-based ecosystem felt in terms of tools and workflows.

Here's some of the things that have blown my mind:

1. Text diffs in MRs on GitLab where you can add comment threads to line ranges. I guess you can still add comments to LabVIEW MRs on a file-by-file basis but there's nothing like being able to point to an exact line! (Or subVI, I guess!). Even being able to see the code in GitLab instead of having to pull it down to check what it is is super nifty.
2. Being able to `Git blame` in the browser in GitLab, or within Git itself. This basically shows a log of who changed a line and what they changed it to. In LabVIEW there's not a simple way of seeing who messed with your code without pulling up the log for a file and diffing each change, which is a pain.
3. AI code reviews. The future is here, and that future is getting GitLab Duo to sense check your code. Yes, sometimes it is overly fussy or plain wrong, but it can catch things that a human reviewer might have missed so you might as well run it! It seems especially useful for teams of 1 person. 
4. Having your IDE in a browser with scripts to automate the setup and environment. I can press the 'Ona' button on GitLab and within 30 seconds I have a browser version of VScode with the code pulled into that I can run scripts in. Neat! Beats having to install a new version of LabVIEW so you have to save for a previous version (did they solve that one yet)?
5. Static analysis packages that do a lot of the painful stuff for you. I remember having to write some code that looked at which files changed, and only running VI Analyzer on those files in my pipeline. Turns out that's built into packages like SonarQube already - it compares with the default branch. 
6. Security being a massive concern. I once worked somewhere that had daily Nessus scanning for CVEs that affect development environments that I was writing LabVIEW on but I feel like this is not the norm. Now it's something I am hyper aware of, and am frequently scanning my containers, dependencies etc. and have set certain things to autopatch. 
7. Dependabot and rennovate, i.e. version bumping bots for public packages, which will uprev your code directly (or make a MR, depending on how you set it) when a new compatible version of a package becomes available. I can't imagine this happening using VIPM, for example, it seems a pain to script the changes. Beware though, you probably want to let the updates lag by a week to give people the chance to find vulnerabilities or malicious updates...
8. Containers being the norm. I didn't use them when I was working in Embedded C, but since then it's quite normal for one of the pipeline steps to be to make a container image with your package on, and test it in a container which has some extra tools on, for example. Heck, we even use a container to build these containers. Though I do hear there's a LabVIEW docker image now?
9. Package managers that make graphs of transient dependencies (i.e. dependencies of dependencies), a bit like the VI Hierarchy. I have become a massive Conan (a C++ package manager) nerd and I love seeing the interactive graph. I also love when it checks our Conan remote if the package dependency has already been built for the OS/Architecture that I am asking for, and just building it for me if not. I can't help thinking I might have got on better with PPLs if they had some better tooling built in. 
10. Uses of AI, and inhouse AI models where your data doesn't leave the company. I certainty am not one of the people who lets AI write all the code for me (I have the option to let it loose in my IDE, but not right now thanks!), but I do sometimes let it look at the code and improve my README based on the actual code. I feel like this is invaluable for legacy code. I don't see this level of usefulness arriving for LabVIEW any time soon.

Despite LabVIEW lagging behind the tools available to text based developers, I feel like there are still many advantages of graphical code, so don't take this as me criticising LabVIEW! I just wanted to record my perspective as someone who used to mostly work in LabVIEW and now works in other languages.

Disclaimer, because I am out of the loop on new developments in LabVIEW, it's possible that some of these things are in the works in the LabVIEW world... let me know in the comments!

 - Leah