Visual programming works very well for data flow problems.
Visual programming works very well for data flow problems.
LabVIEW has a diff capability, and while working for National Instruments, my team actually had a quite capable custom code-review system built out of this diff. This is an area that is brought up often, but text-based diff tools weren't magically found in the universe. They were built, and some of them are good and some of them not. It's not a paradigm's fault that tools like git were built around the idea that code must be text.
I do agree that better tools need to exist though, but there isn't a reason for why they can't. They just need to be built. There are hard and interesting problems in that space, both technically and design-wise.
> Some visual languages can turn an area into a 'subroutine', I have not seen any solution to build libraries of reusable 'subroutines'.
LabVIEW has a third-party developed package manager in the JKI VIPM. And LabVIEW has features where you can put your VIs and classes into various LabVIEW specific containers, most usually source libraries, that can then be referenced and re-used in projects. Just treat the libraries as modules like you would in any other language. They should contain classes and functions that have a shared or particular purpose.
FWIW you can have custom diff and merge drivers in git. One could probably hook up LabVIEW's diff tool as a git diff driver, I don't know about merge.
Merge is harder in LabVIEW and isn't where it should be. However, that doesn't mean it can't exist.