Yes, LabVIEW is great until you learn about functional abstraction. ("Gosh, you mean I can write this code once and then call it multiple times with different arguments?") At which point you will start pining for the awesome expressive power of Visual Basic.
Imagine if, every time you wanted to define a function, you had to open up a PowerPoint document and draw that function's interface using the mouse. Then you'd have to call your function by embedding its thumbnail into another PowerPoint document. (The linking is done by embedding a pathname, which you pick by using a File Open dialog box.) That's the feel of the LabVIEW programming experience. It takes vast reserves of patience.
You might wonder what happens if you copy your program onto another system, or -- god help you -- revise one of your functions in a way that breaks some other program which invisibly depends on it. The answer is: you're screwed. You can't even ask your version control system for help: Your code is in a proprietary graphical binary format. Better keep those backups current!
As you can probably tell, I'm a veteran of LabVIEW, like many laboratory scientists. LabVIEW is to experimental science what Excel is to accountancy. It's a powerful tool in its domain [1], perhaps even an indispensible one, which tempts amateurs to extend it farther, and farther, until they find themselves doing things that really ought to be done using a different tool. One that can be configured using a text editor.
---
[1] "Make the oscilloscope talk to the spectrum analyzer, then sample the voltage with this interface card and draw a strip chart of the results. You have twenty minutes."
I know nothing about LabVIEW, but I get your excel analogy. However, whenever I have seen adequate (bug ugly) excel "systems" replaced by something, the result is far from great, and rarely justifies the effort (but I am just one data point). Not sure if that could flow back to the analogy or not though.
Your example does flow back, which I why I drew the Excel analogy. LabVIEW is a fascinating piece of tech. I have had many occasions to loathe it -- what emacs user wouldn't hate a language that can't be edited as text? -- yet I love it all the same, and when you work in science you can't really resist using it. It is fast, and effective, and if you carefully avoid the temptation to use it for everything it is a joy to use.
Part of its secret is that it fits the problem. You're standing in a lab plugging things into other things using a snarl of BNC cables. You're not trying to design the correct abstraction. You're trying to solve your problem by lashing together the tools that you already have, sometimes in a hilarious fashion. ("We're out of voltmeters, but we do have a $50k sampling oscilloscope. We can use that!") LabVIEW code often looks like spaghetti, but that's partly because its use case also looks like spaghetti.
There is more than one kind of power tool. Computer scientists like general-purpose high-level tools, for good reason. They understand that "the pen is mightier than the sword", and they spend a lot of time collecting pens. But sometimes you need to cut something in a hurry, and at those times there's really no substitute for a well-designed sword. You can use a pen to design a sword -- perhaps even a better sword -- or to convince the folks with swords to move somewhere else. But it's a long and unreliable process. And it can be immensely satisfying to just pick up a sword and stab something!
Imagine if, every time you wanted to define a function, you had to open up a PowerPoint document and draw that function's interface using the mouse. Then you'd have to call your function by embedding its thumbnail into another PowerPoint document. (The linking is done by embedding a pathname, which you pick by using a File Open dialog box.) That's the feel of the LabVIEW programming experience. It takes vast reserves of patience.
You might wonder what happens if you copy your program onto another system, or -- god help you -- revise one of your functions in a way that breaks some other program which invisibly depends on it. The answer is: you're screwed. You can't even ask your version control system for help: Your code is in a proprietary graphical binary format. Better keep those backups current!
As you can probably tell, I'm a veteran of LabVIEW, like many laboratory scientists. LabVIEW is to experimental science what Excel is to accountancy. It's a powerful tool in its domain [1], perhaps even an indispensible one, which tempts amateurs to extend it farther, and farther, until they find themselves doing things that really ought to be done using a different tool. One that can be configured using a text editor.
---
[1] "Make the oscilloscope talk to the spectrum analyzer, then sample the voltage with this interface card and draw a strip chart of the results. You have twenty minutes."