[Kevin Sevcik]

Originally Posted by Alan Anderson

I take exception to the characterization of it as over simplification. From the point of view of someone who wants to have explicit control over every little thing -- perhaps someone writing a compiler or a device driver -- it might seem to be trading away too much control for the simplicity gained.

Personally annoying simplification, perhaps. Greg McKaskle's note that every language hides thing hit home here. My primary issue here is is from the pedagogical standpoint. Labview makes certain things extremely easy. Which is good for getting people introduced to programming things and starting to think like a programmer. My issue is that seeming simplicity makes it really easy for beginning programmers to completely miss things like memory allocation. To the obvious detriment of their applications, as in my anecdote. To be fair, this problem crops up in just about every "easy" programming language that gets picked up by non-programmers. I've run across similar issues in C# programs at my current employer. So this problem admittedly isn't isolated to Labview. I just think it's a little more prominent in Labview because it makes so very many things easy.

That's a valid point, but I don't think it's specific to LabVIEW or other "easy" languages. I suspect that the same beginner is going to have an even worse time of it using a language like C++. Failing to account for where data is going will typically crash a compiled C++ program due to buffer overruns, if you're lucky. If you're unlucky, it'll just subtly corrupt data in ways that aren't amenable to debugging.

I think my issue here is that C++ and more structured programming languages at least make you think about these issues. Blithely ignoring them sets you up for other subtle problems in the future. Or worse, just ingrains bad coding habits from the get go.

Doing "things"? I thought the topic was LabVIEW as a general-purpose programming tool, not just as a way of controlling I/O hardware. It's true that NI modules are in the majority of most of the I/O-heavy systems I work with. However, those systems are not what most of my LabVIEW programming is done for. I support a few applications that are mostly data retrieval and analysis tools, with no I/O other than that supported by a typical desktop OS. My biggest project does all its outside work through a box that it communicates with using a simple serial protocol, handled by LabVIEW's simple (!) support for DirectX plugins.

Even in the FRC world, there's no NI hardware involved in the Dashboard program (or the Driver Station, but teams don't get to mess with that).

Yes, Labview qualifies as a general purpose programming language. And yes even I prefer it for projects where I'm primarily doing data capture and processing. It's much simpler to do those things in Labview, so I use it where it's strongest. But I think there's a good number of things that it's not good at that I really prefer a structured text language for. String processing in Labview tends to give me headaches, for instance. And having needed to delve into the Labview VIs, it sometimes seems to me that NI tacitly admits that Labview isn't the greatest at everything. A lot of their signal processing VIs break down to C calls to DLLs.

Fundamentally, though, my frustration is that learning Labview doesn't really prepare you for learning any other programming languages. Which is fine if all you'll ever use is labview. But I know one of my strengths is the ability to quickly assimilate new structured text programming languages. We integrate 3 different robot platforms, a motion control computer, and PLCs with custom C# interfaces. I'm pretty certain that if my programming experience was limited to Labview, I'd have been completely lost until I got my head around structured text programming.

So, if you wanted to summarize my main concern with Labview, it's that the vast majority of other programming languages out there just aren't block diagram, dataflow languages. If I have the option, I'd really rather prepare my programming students for the kind of languages they're likely to encounter later in their careers. This isn't always an option, but it's my preferred one.