C or LabVIEW: CompactRIO

[TDohse]

Originally Posted by dcbrown

For me, LabView promotes being a user of black box technology pieces rather than promoting understanding how to be a creator of useful technology. There is nothing wrong with being a technology user, but where's the fun in that?

As helpful as LabVIEW is, it isn't magic. Whether building a VI or writing C functions, the same programming concepts apply along with the same problem solving skills and methods. LabVIEW isn't alone in abstracting away some of the bits&bytes details to allow developers to focus their time on solving real-world problems instead of worrying about issues like memory management.

Understanding the low-level details is undeniably important for software engineers, but there is no reason to fear using high level languages like LabVIEW or Java. C++ has the standard template library to save time by reusing common data structures and algorithms. Code reuse, whether provided by a calling a LabVIEW VI or #including something into your C/C++ code, should help developers be creators of useful technology, not hinder them.

[neutrino15]

Originally Posted by TDohse

Understanding the low-level details is undeniably important for software engineers, but there is no reason to fear using high level languages like LabVIEW or Java.

Please correct me if I am wrong, but C++ can be just as "high level" as Java or LabVIEW. Assuming WPIlib has similar included functions and objects to LabVIEW's panels, and Java's libraries, isn't it relatively equal?

The way I have always seen it, you can make a language as high level as you want (as long as it supports things like functions and objects), but if you are working in an exclusively high level language (such as LabVIEW) it is hard to get down into the nitty gritty low level to debug and perform hacks.

To me, the difference between LabVIEW and C++ is like the difference between writing a paper and drawing a wordless comic strip. They both convey the same thing, but the paper can be written faster and allows for more subtle tweaking.

Again, if I am off track, correct me...

[TDohse]

Originally Posted by neutrino15

. . . but if you are working in an exclusively high level language (such as LabVIEW) it is hard to get down into the nitty gritty low level to debug and perform hacks.

To me, the difference between LabVIEW and C++ is like the difference between writing a paper and drawing a wordless comic strip. They both convey the same thing, but the paper can be written faster and allows for more subtle tweaking.

LabVIEW has a number of tools to help with debugging, you can set breakpoints, probe wires to watch values at runtime, highlight the execution paths, etc so debugging should not be a concern.

As to which is faster, this probably depends on the problem being solved and the user, but the general notion would be the opposite of what you have suggested. Higher level languages tend to increase programmer productivity.

One of the best things you can do is to learn both.

[Daniel_LaFleur]

A pretty good report (IMHO) about the state of C and it's relation to C++ and LabView can be found here.

[Greg McKaskle]

Originally Posted by neutrino15

Please correct me if I am wrong, but C++ can be just as "high level" as Java or LabVIEW. Assuming WPIlib has similar included functions and objects to LabVIEW's panels, and Java's libraries, isn't it relatively equal?

In these sorts of conversations, it is useful to break these programming environments into elements such as (langauage, libraries, and tools).

The panels and UI objects, along with vision, signal processing, and file I/O, are library elements, and can be added to most any language. The level of library integration you can achieve with a given language will differ, and the tools are often key to getting the libraries well integrated -- think intellisense or whatever it is called.

The tools are things like the debugger, tracer, text or graphics editor, and source code control. These features, again, aren't unique to a langauge, but their level of integration can make a huge difference. When C is bundled into a package with a slow compiler, weak debugger, and primitive text editor, it feels like a bad visit to the dentist. Choose a package with better tools, and it is like going to the candy store. Same language, different tools.

Language differences come down to issues like expressiveness, control over (scoping and encapsulation, time of binding), etc. I don't have my favorite language book handy, so I can't be that complete. Anyway, independent of tools and packaging with libraries, some languages add additional syntax to give power for things like binding time. Other languages focus in simpler syntax and more expressive power through polymorphism or sophisticated dispatching mechanisms.

In the end, all three elements affect programmer effectiveness and happiness. Breaking them apart into topics like this allows us to be more precise about the tradeoffs, because words like high-level can be very misleading and imprecise.

The way I have always seen it, you can make a language as high level as you want (as long as it supports things like functions and objects), but if you are working in an exclusively high level language (such as LabVIEW) it is hard to get down into the nitty gritty low level to debug and perform hacks.

High level languages tend to have no pointers or low level access built into the language. Just as low level languages can be made higher level with libraries, high level languages can gain low level features with libraries, and this is how LV does peeking and poking to memory.

Taking out pointer magic, of course seems like a major limitation at first, but the tradeoff is that you wind up with a more structured access, that gives you more certainty about what code is really doing versus the side effects that happened. If code is peeking and poking all over the place, where do you look when a piece of memory is getting corrupted? If the access is limited to a single function or object, the bug gets solved more quickly, and hopefully doesn't happen in the first place.

So, if you limit what you use in C++, it can become a high level language. Arguably, that is what Java and C# are, (((C++)--)--). They are variations of C++ with less of the low-level stuff available. But if the low-level isn't off-limits, I think the language is both high and low level -- not a bad thing in the hands of a trained user, but with the low-level stuff still there, it can still cause bad things as well as good.

To me, the difference between LabVIEW and C++ is like the difference between writing a paper and drawing a wordless comic strip. They both convey the same thing, but the paper can be written faster and allows for more subtle tweaking.

While humorous to think about, I don't think your description is very accurate. LV was designed by some physics guys, not cartoonists. They wanted to break away from some of the limits of current languages. They noticed that when you asked a scientist, engineer, or student how something worked, or how they wanted it to work, they would walk to the chalk board (this was the 80s, so possibly a white board), and they would usually draw their system as pictures, not C code. One common picture involved shapes that represented processing and lines that represented the information or product flowing between the processing stations.

They thought this lent itself to being represented in a data flow language, and wanted to include the graphics too. When Fortran and other early languages were invented, they chose a stream of ANSI chars because that was all that computers could process -- stacks of cards with holes punched into them. The ways of representing the holes improved, and fancy computers could even support graphics and sound, but programming languages still consisted of ANSI chars that the compiler consumed one at a time.

The end result of this exploration was to define a structured data driven data flow language that used graphics to represent the functions, and lines or wires to represent the flow. They added in libraries for common engineering tasks and UI displays, and because they couldn't integrate graphics into VI or emacs, they wrote their own tools for editing, etc.

LV is by no means the only graphical language out there, and not all graphical languages are the same, just as not all textual languages are the same. While an obvious difference, the more important difference when actually writing code, is the data flow functional approach of LV versus the procedural approach of C.

While this analysis and analogy can be interesting, in the end, the important thing is that the language, libraries, and tools support the user to quickly accomplish what it is they are trying to do. Hopefully they also allow for others to understand, contribute, and extend it to their purposes as well. Both the C and LV languages have been around for decades. They work in different ways, and this gives the user a choice. I truly hope that most students become familiar with both of these languages, and others as well.

When I'm asked the question, "What is the most important computer language to learn to prepare me for a programming career?"; my answer is, "Your second one." You will learn way more from the differences and similarities than you gained from the initial language. It will also be far easier, as will the third, etc. It also tends to get lessen the zealotry a bit.

Greg McKaskle

[mathking]

Originally Posted by Greg McKaskle

When I'm asked the question, "What is the most important computer language to learn to prepare me for a programming career?"; my answer is, "Your second one." You will learn way more from the differences and similarities than you gained from the initial language. It will also be far easier, as will the third, etc. It also tends to get lessen the zealotry a bit.

Greg McKaskle

This is a great answer to the question.