View Single Post
  #1   Spotlight this post!  
Unread 18-04-2011, 16:45
Alan Anderson's Avatar
Alan Anderson Alan Anderson is offline
Software Architect
FRC #0045 (TechnoKats)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2004
Location: Kokomo, Indiana
Posts: 9,112
Alan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond repute
LabVIEW as a general-purpose programming tool

Quote:
Originally Posted by Kevin Sevcik View Post
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.

Quote:
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.

Quote:
...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.

Quote:
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).
Reply With Quote