i think most people that have an opinion on visual programming have not actually ever used a visual programming language in earnest.
i have worked in labview very seriously over the past 4-5 years. at this point, i am essentially an expert in the language. i have done object-oriented programming (OOP), functional programming, and also programmed using an actor framework. all of that is in addition to obviously adopting the dataflow-first paradigm. my projects have not been simple applications. they have been large applications, with many different components and non-trivial user interfaces.
it's amazing how such a simple and small base language can be so powerful due to the dataflow nature. my programs are almost always essentially bug free when i am done. this is due to how labview works, which is rather advanced. as i program labview, i work on VIs. these are small blocks of code that perform a certain task. oftentimes, these are purely dataflow functions. in other words, they take in information and pass information out without modifying things via references. since every VI has dynamic type propogation and compilation as you work on it, you get immediate feedback on wehther or not your types match up and whether your VI runs. once your VI successfully compiles (by the way, you never kick off the compile process as it's automatic), you can run it. so i build up systems out of basic dataflow processors, almost all of which i am able to run freely with inputs to see how they interact. out of those that i can't, mainly due to needing a "mock object" to test, it still makes it easy to reason about to due simply having to understand how the data flows through your code. if something's not available, it's pretty easy to trace it back to where it should have come from. all of this also makes labview easy to debug. data is just flowing through your program. just navigate to where you want to view your data and place a probe on a wire to see what's happening at that point in your program.
all of this is quite advanced. this type of interactive writing of code, running, and debugging doesn't really exist in other languages. then you have the ability to easily create modern looking user interfaces (my interfaces are almost untraceable back to labview based upon their look) and program desktop, real-time OS, and FPGA applications all with the same language.
and i haven't even talked about how labview is concurrent by default. want two while loops running concurrently? just draw two while loops on the screen, and you're done. multithreading is so easy in labview that you don't even have to think about it. it's inherent to the language, and labview takes advantage of multiple cores by default.
many of these features are discussed ad nauseum in reference to other languages: type propagation, REPLs, dataflow, concurrent/multithreaded programming, etc. these are things people throw out in praise of a language, and yet labview has all of them.
finally, i will mention that labview does struggle with some things, but it is not due to the visual programming environment being inadequate in most cases. most of the time it is because the language is manufactured by a company, which has finite resources in what they can do to the language. there are plenty of problems with labview, but they are all solvable. they just need attention from national instruments and the research community at large.
it's just that visual programming is different and necessitates different approaches. people somehow forget that it took them years to understand how to program computers using text. it isn't that text is THE way to program computers, but people certainly seem to think that. i am convinced a hybrid approach is appropriate. i myself am slowly designing a language and environment along these lines.
> i think most people that have an opinion on visual programming have not actually ever used a visual programming language in earnest.
Yes. I have used a dataflow language for 3d modeling - Grasshopper - for 5-6 years. I can't agree enough with you about the joy of interactive writing, running, debugging, etc. Grasshopper also happens to have blocks/nodes where Python/C# code can be inserted, which is the best of both worlds.
As someone who has never used labview - do you have any links to examples of your work, or well-structured labview code?
I don't encounter people, either IRL or online, with significant experience in LabVIEW, or other visual dataflow languages. I wonder if you could give me feedback on my own visual dataflow language, described in http://web.onetel.com/~hibou/fmj/FMJ.html
Though I haven't updated the web pages, the language is still evolving, and not yet ready for release.
i have worked in labview very seriously over the past 4-5 years. at this point, i am essentially an expert in the language. i have done object-oriented programming (OOP), functional programming, and also programmed using an actor framework. all of that is in addition to obviously adopting the dataflow-first paradigm. my projects have not been simple applications. they have been large applications, with many different components and non-trivial user interfaces.
it's amazing how such a simple and small base language can be so powerful due to the dataflow nature. my programs are almost always essentially bug free when i am done. this is due to how labview works, which is rather advanced. as i program labview, i work on VIs. these are small blocks of code that perform a certain task. oftentimes, these are purely dataflow functions. in other words, they take in information and pass information out without modifying things via references. since every VI has dynamic type propogation and compilation as you work on it, you get immediate feedback on wehther or not your types match up and whether your VI runs. once your VI successfully compiles (by the way, you never kick off the compile process as it's automatic), you can run it. so i build up systems out of basic dataflow processors, almost all of which i am able to run freely with inputs to see how they interact. out of those that i can't, mainly due to needing a "mock object" to test, it still makes it easy to reason about to due simply having to understand how the data flows through your code. if something's not available, it's pretty easy to trace it back to where it should have come from. all of this also makes labview easy to debug. data is just flowing through your program. just navigate to where you want to view your data and place a probe on a wire to see what's happening at that point in your program.
all of this is quite advanced. this type of interactive writing of code, running, and debugging doesn't really exist in other languages. then you have the ability to easily create modern looking user interfaces (my interfaces are almost untraceable back to labview based upon their look) and program desktop, real-time OS, and FPGA applications all with the same language.
and i haven't even talked about how labview is concurrent by default. want two while loops running concurrently? just draw two while loops on the screen, and you're done. multithreading is so easy in labview that you don't even have to think about it. it's inherent to the language, and labview takes advantage of multiple cores by default.
many of these features are discussed ad nauseum in reference to other languages: type propagation, REPLs, dataflow, concurrent/multithreaded programming, etc. these are things people throw out in praise of a language, and yet labview has all of them.
finally, i will mention that labview does struggle with some things, but it is not due to the visual programming environment being inadequate in most cases. most of the time it is because the language is manufactured by a company, which has finite resources in what they can do to the language. there are plenty of problems with labview, but they are all solvable. they just need attention from national instruments and the research community at large.
it's just that visual programming is different and necessitates different approaches. people somehow forget that it took them years to understand how to program computers using text. it isn't that text is THE way to program computers, but people certainly seem to think that. i am convinced a hybrid approach is appropriate. i myself am slowly designing a language and environment along these lines.