I've been using LabVIEW and I agree with you. LabVIEW has great hardware support which makes it really easy to get up and running collecting data.
But like you said, I've looked over some previous LV projects that have multiple copy and pasted sections, terrible design, etc.
As a software engineer, LV holds you back in my opinion. I don't doubt for a second that some really amazing things can be created with LV but ultimately it is extremely tiring/annoying to reinvent the wheel to accomplish things that would be extremely simple in almost any other programming language. This seems to come into play when you move past the simple act of collecting data and doing primitive processing.
Edit: The other thing I forgot to touch on was the presentation of the "code". With wires running all over the place and ambiguous function blocks you quickly find yourself wishing you could cozy up with a text editor instead. The main reason I don't think data flow programming will "take over" all programming is because ultimately I think its a inferior presentation for professionals.
As someone who has fallen into the unfortunate position of being the local LabView expert, there's a little tricky you might want to know. Pretty much all of the awesome hardware support is contained in the daqmx library. The C api for this library can be connected to through nicaiu.dll (or the corresponding dynamic library format for your OS). By linking in here, you get all the wonderful hardware support while being able to write code in your favorite language with your favorite editor and commit it to your favorite source control.
I've been slowly translating all of our LabView code out of G and it's both made my life vastly simpler and has also allowed other coders to work on it without learning G.
So, are you saying when I diff I am looking at textual representations of the graphs?
Which is fine, that is what I'd expect. It's how I'd implement it. But isn't that a huge clue about the fundamental weakness of graphical representation - as soon as you try to do anything nontrivial it's back to text. And back to text for a very good reason, not because the right git plugin hasn't been written yet.
One could write a real 2D graph diffing system, it is not inconceivable, at least. However, you won't get this for free by diffing a textual representation of the graph.
One simple hack is to take each version, set transparency to 50%, and then overlay them.
But like you said, I've looked over some previous LV projects that have multiple copy and pasted sections, terrible design, etc.
As a software engineer, LV holds you back in my opinion. I don't doubt for a second that some really amazing things can be created with LV but ultimately it is extremely tiring/annoying to reinvent the wheel to accomplish things that would be extremely simple in almost any other programming language. This seems to come into play when you move past the simple act of collecting data and doing primitive processing.
Edit: The other thing I forgot to touch on was the presentation of the "code". With wires running all over the place and ambiguous function blocks you quickly find yourself wishing you could cozy up with a text editor instead. The main reason I don't think data flow programming will "take over" all programming is because ultimately I think its a inferior presentation for professionals.