Having said that, every time I've looked into graphical programming paradigms they almost always seem to fall apart or get in the way of translating ideas and thoughts into machine instructions.
In the end, at least for me, it's about having an environment and a language that gets out of the way and let's me program the way you'd play the piano: The music just flows and the technical bits that make it happen are invisible.
It's a graphical programming language with an emphasis on system design (for scientists and engineers) that uses a dataflow paradigm (amongst other things) and has a unique UI creation system.
(Disclaimer: I work for National Instruments and my comments here in no way reflect the views of National Instruments and yadda yadda.)
It also seemed to be harder to read and understand the flow of the code, which made debugging a pain sometimes. I remember struggling to figure out why my code wasn't working, only to find out I had used 1 instead 1.0 as a constant. The only indicator of the data type was a thin colored border around the box.
LabVIEW seems to do a great job as a kind of Visual Basic for scientists and engineers, but I'd probably find it frustrating to spend any substantial amount of time programming with it.
It's definitely a tool and one should always use the best tool for the job. Sometimes the best tool is not necessarily the one with the most suited features, but the one that you're most adept at using. Either way, thanks for the input, really. It helps a lot to understand what people walk away with when they use a product you've been a part of, and I love that HN users are honest and gracious in their feedback. Cheers.
In any case, thank you for the feedback, it's always great to hear back from fellow programmers that have had experiences with LabVIEW.
What kind of programs are we missing out on by limiting ourselves to text? What kind of programmers?