C or LabVIEW: CompactRIO

[dcbrown]

Originally Posted by Dave Flowerday

This is correct from my perspective, and also the very reason why I think it's most valuable that we're teaching C and low-level stuff to the kids interested in software on our team. When you make the bulk of the code easier to write (as graphical tools are starting to do), it becomes a commodity. For these jobs, you no longer need a software engineer to implement them - anyone with a logical mind has a decent chance at being able to do it. Of course, that means that the 10% of programmers out there who know how to get down and dirty with C and/or assembly coding and debugging become more valuable, and the value of the rest decreases. I think it's important that the kids on our team who show real interest in software be steered towards this 10%.

Agreed (not that it matters). In my view this is the difference between an applications programmer/coder and a systems programmer/engineer.

Although I believe there will be parity between LabView and C programming environments for the FIRST added value in the new platform - specifically in terms of the standard sensor suite included in the KOP. I cannot see how real parity will exist in the 2-3 year short term between the two environments. My reasoning is based upon what the customer base for cRIO has been using - only LabView. So the body of art in terms of VI blocks, knowledge, etc. exist only in LabView within the current customer community. That plus the fact that LabView can be used to model a system and provide the simulation of most of the sensor inputs for testing/simulation makes that environment have benefits that the C environment cannot match from a whole program standpoint in the near term.

I don't even like LabView but my opinion is it would be irresponsible for me to not push LabView as the main programming environment for the robot going forward given the functionality and current art associated with the new platform. I could easily envision that 10-20% of the code would still be in done in C just because it fits better, but that the majority of the software team would be using LabView. So this would reflect the typical 80-90% applications programmers and 10-20% of systems programming mentioned by Dave above.

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?

[mathking]

As a computer science teacher, I am actually strongly leaning toward "encouraging" our programmers to use Lab View, because it is better at forcing them to design good code. It is fairly easy to take a bright kid with any inclination to write workable code. It is quite another thing to design good code. Lab View's module oriented design, with testing of the modules, promotes good design and good practice. And Lab View is not a fluffy tool. It has been around for a long time and can be used for very intricate, high level programming.

I liken this to a debate that occasionally rages among HS and college computer science teachers: Should students start learning to program by learning assembly? My opinion is absolutely not! It teaches most students bad habits. The counter argument is "Would teach someone to drive a race car without teaching them how the engine actually works?" There are two counters to this argument. The first is simple. Sure you want your race car driver to understand how the engine works. But that is not the first thing you teach them. The second is that assembly is not really "how the engine (your computer) works." It is a less abstract interface than C, but still an abstraction.

I will say that I don't know if my opinion would change if my students did not already know some programming languages. On the whole, I don't think that it matters what language you learn first, as long as you learn good practices and skills. In a general sense (not computer science specific) this is actually an area of pedagogical research that is pretty well studied.

[EricVanWyk]

I see learning lower level languages (such as assembly) as the CompE equivalent of taking a Design for Manufacture course.

DFM teaches MechEs how to design things so it is easier for the manufacturing engineers. Learning assembly teaches CompEs how to write things so it is more efficient once it is compiled.

DFM is a necessity for any ME who intends to mass produce her work. Learning a low level programming language is a necessity for any CE who intends to mas produce his work.

For research and one offs, it is completely superfluous to cost optimize. Cost optimization is a very important skill for a large fraction of engineers, but it is not necessary for 100 percent of engineers, and it is not necessary to start with it.

[Greg McKaskle]

Originally Posted by EricVanWyk

I see learning lower level languages (such as assembly) as the CompE equivalent of taking a Design for Manufacture course.

I almost totally agree. But I think that a computer architecture course and an algorithms course are soooo much better than learning assembly.

Algorithms, to choose the simplest code with the simplest access patterns.

Architecture, because even at the assembly level, execution performance is hard to predict without considering cache lines, cache sizes, interrupt latencies, etc. Ideally, the architecture course uses an assembly language to illustrate some of the concepts.

And of course both of these will get you only so far, so familiarity with profiling techniques, profiling tools, and lots of experimentation are necessary too. The architectures just keep getting more comlex.

Greg McKaskle

[EricVanWyk]

Originally Posted by Greg McKaskle

I almost totally agree. But I think that a computer architecture course and an algorithms course are soooo much better than learning assembly.

Agreed. I used ASM as an example for this audience. CompArch&Algs is much more relevant.

Note: I am not a programmer by trade, I am a SparkE. However, I really like hardware, so I've spent a little time there.

I learned a little x86 assembly, and a little PIC assembly. Relatively low return on investment, though it helped me understand C much better.

In CompArch/VLSI, we designed our own processor. Started with architecture, decided on components and interconnects, went to gates, laid out on silicon, and we even wrote our own assembly languages. I think one team even made an assembler in python. I probably won't design too many more processors, but it sure did help me better understand what is going on under the hood.

I got a lot out my Foundations of CS class. We learned a new programming language every other week, spanning most schools of thought. Scheme (LISP) taught me a surprising amount about algorithms, and prolog just proved that specific languages solve specific tasks orders and orders of magnitude better than any others can.

So... I hit a few lower levels, scraped my knees a bit and moved to the higher level languages. Now I write any code I need in English (in the form of a spec document) or python (which is essentially a dialect of English).

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