LabVIEW as a general-purpose programming tool

[Alan Anderson]

Originally Posted by Kevin Sevcik

If we want to further discuss the merits and deficiencies of Labview as a general and FRC language, we should start up a new thread.

Done.

I'll agree that labview vastly simplifies things for domain experts with little programming experience, but you don't have to do anything particularly complex for the over simplification to bite you.

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. But from the application programming perspective, there's usually no need to deal with those details. And when you do find it necessary to worry about them, you aren't prevented from doing so.

...The mere fact that a beginner doesn't need to think about where all this data is going is a pitifall waiting to trip you up later in your labview programming adventures.

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.

As for hardware compatibility, yes, labview runs on lots of platforms, as long as you're primarily interested in working with NI hardware to interface with the rest of the world. Once you step outside the NI garden, doing things with labview can quickly become complicated.

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).

[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.

[SuperS_5]

I personally believe that graphical based programming is the future. I can totally agree with LabVIEW's deficiencies, and the future may or may not include LabVIEW.

As a professional LabVIEW developer, I think about things like memory allocation, and efficiency all day long. LabVIEW just helps you to see the programming structures from a high level. I actually like reading the white papers on the LabVIEW compiler, and optimizations. There are a lot of docs/posts that explain some of the detailed guts of LabVIEW. (And how to use them to your advantage.) For example, one project that I know of, processed several very large images, hundreds of times per second. It was using the images to detect product flaws on the millimeter scale. 8 cores, and several image acquisition cards where used, and none where NI stamped. (PS the hardware setup took longer then the software development)

I also learned C and C++ before LabVIEW, and can't stand it anymore, especially now that I have looked at Iphone development. (Yes, I know that it is Apple's flavor of ObjectiveC )
Despite all of this, I can agree that LabVIEW is not used nearly as much as other languages. Exposure to other languages is very important.

Here is a video that might answer all of the "early" issues that new developers may complain of.
http://www.youtube.com/watch?v=4BppvSzsrNk&fmt=18

[Alan Anderson]

Originally Posted by Kevin Sevcik

...String processing in Labview tends to give me headaches, for instance.

That seems odd to me. The string functions I use in LabVIEW are pretty much the same as the ones I use in C.

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.

Learning any one language paradigm doesn't really prepare you for learning another, agreed. However, it's been said that the most important programming language to learn is your second one.

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.

I felt pretty much as you do before I got comfortable with dataflow programming. Now, though, I think there's a lot to be said for learning to program using a system that makes it virtually impossible to have syntax errors. In an ideal world, of course, students studying to become professional programmers would learn many ways to do things, and they'd learn how to choose a language to fit the situation.

I note that the robotics students I've met having a desire to work with the software tend already to be using text-based procedural languages. Teaching them to program FRC robots using LabVIEW doesn't deprive them of that background.

[Racer26]

Originally Posted by Alan Anderson

That seems odd to me. The string functions I use in LabVIEW are pretty much the same as the ones I use in C.

I'm a Certified LabVIEW Developer, working on my CLA, and I still find string manipulation in LabVIEW to feel kludgey. Yes, the functions are much the same, however, trying to extract something from a string based on positions and markers and so on very quickly leads to a mess of wires, and alot of extra copies of your string floating around in memory.

[Joe Ross]

Originally Posted by Alan Anderson

That seems odd to me. The string functions I use in LabVIEW are pretty much the same as the ones I use in C.

Having the same string functions as C is a disadvantage compared to the string manipulation in more modern languages.

[Mark McLeod]

SNOBOL anyone

[Ether]

Originally Posted by Mark McLeod

SNOBOL anyone

... or Lex