If you have been working with LV for a while, you should know about Type Definitions and possibly LVOOP/LV Class architecture. In short, you can EASILY do what you are talking about, as long as you have some idea how to use good practices in labview (and no, it doesn't take significantly more time, any more than avoiding GOTO statements).

In short, there are very simple "BKM"s in LV as there are in any language that will allow you to deal with exactly that (and other) situations.

And this is different from a poorly written text program how? I write my LV code in such a way that you can understand it by looking at it, amendable and commented.

Labview's biggest weakness is that it IS so easy to get a working program up that people who have never seen it before and get things done- sometimes rather horribly. But compare that to someone trying to write a deterministic piece of code in VB who has never seen a line of code before. They just can't (in a short period of time). But like any language, there are good and bad practices.

Well, that's just wrong. LV excels at bringing together other systems. I'll admit right away that the old DLL interface nodes are a pain in the neck, but ActiveX/.NET nodes could not be easier.

I have worked on OOP labview systems with thousands of VIs (I suppose you could take that to mean 25,000 lines of code?). And we never hesitated to "interface" to another system or program. Most problems we had were due to lazy documentation by the people writing other libraries.

What kind of number crunching? I have never seen anything that couldn't be implemented in LV; albeit there are some cases where a DLL might have a faster interface.

I guess I am saying that while MATLAB certainly has advantages over labview, if you get to that point, you should be able to find either a labview library or DLL/.net assembly that can perform your calculations.

Why not recode the MATLAB routine in C, then create a DLL and avoid the MATLAB license fee?

Yes and no. LV started out like that- as a tool for engineers to implement their DAQ ideas without having to teach a programmer about physics.
But around 5 years ago NI came 'round and started to listen to the developer community- and continuously improved the "IDE" to bring it in line with other languages.
Since around 1998, I do not hesitate to tell people that if it can be done in java/VB, I can do it in LV. There are probably exceptions to that rule, but I haven't come across them.
By the way,

is the equivalent of saying that C is a lousy language because eventually you have a 30,000 line program in on text file and you spend all your time hitting CTRL-F to jump around.

Whoa. While some of that may be true (the facilities for tagging and searching are rather lax) the resulting code that is written is only as good as the programmer. It's absolutely true that NEW labview programmers write spaghetti code more often than not. But just like GOTO statements, the mantra of the trained community is "No Globals!". I will say this- when I step into a bad labview project, I can figure out what is going on fairly quickly. The debugging mode and visual nature excel in that respect. Opening a bad C# or even VB.net project can take days to figure out. Bad code is bad code in any language. I will agree that it takes a little more time to code very simple things, but it usually takes less time to code more complex things.

I think your ideas of LV are out of date. I make my living writing labview code, and about 1/2 of what I write are off-line data analysis programs. This includes FFT, image analysis, complex math, matrix math, etc.

I don't love MS either. But when was the last time you got a BSOD on XP? I have crashes on XP about as often as I do on my debian server. The only BSODs I have had on XP have been when I ran VERY BAD software. Interestingly, the last one was two weeks ago when I was using a driver to read an ext2 volume mounted over USB. Yes, I have crashes on my debian box- the latest was somthing that rsync did that locked me out of both local and ssh connections. (Seriously. I have no idea what was happening and had to kill the machine) And no, I am not a linux guru. But if I have problems like these with my intermediate level of knowledge, then you'd better belive that joe blow will too.