Why to use LV/C++/C?

[Bomberofdoom]

Hey guys,

The text in the middle is quite insignificant for the topic and I decided to keep it 'cause maybe someone would like to comment about. But if not, so you can just skip it all and go down to the rest of the topic. If you really want to read it, just mark the text area.

I'll be the veteran of the programming team this year. I'll be helping out the younger sub-team members while they do all the hard working, and I'll help fix major errors in critical times.
I've been programming with C for the past two years and I've taken courses of C and C++ way before FIRST, so when it comes to the point of this year's decision of which programming language to use (Labview, C or C++) I'll with no doubt chose C/C++ over Labview, since writing raw code is more appealing and more challenging to me and it is quite clearer for me to understand the logic of the algorithim than in LV.

Right now, the only programming invorment that is available to us is MPLab and Labview. Since we're looking ahead towards 2009, we're looking only at Labview.

The younger members have taken it to themselves to learn programming Labview (and they've done it splendidly, they're (almost) literaly masters in it) and they taught the rest of us the basic use of LV. I still felt a bit intimidated by the use of Visual blocks to draw a flowchart.

Now, I have nothing to use right now, to show them that writing in C++ is probablly better than using LV (except of explaining the genreal uses of principals of C++ [Object Orianted Programming,....and other stuff.] that can be used for programming the robot). I don't have any way to show that to them, not untill a default code + instructions to use Windriver's Workbench are released.

So, what I'd like to do is start a discussion ('cause I'm quite sure this hasn't been done "formaly" before) about the pro's and con's of using Labview and C++ for programming the robot this year.

[Andrew Schreiber]

I think the goal is that they are functionally equivalent, that is, they both have the same capabilities and efficiency. I believe the reason for that goal is to allow the programmer(s) to choose which one they prefer to use. Some of us are more comfortable using text based languages rather than flowchart like programming languages.

I think the list of pros and cons will be too programmer specific. Similar to why some people like c++ and others like java. For some people one works and is more efficient for others it is the opposite. Personally I like LV because I don't know c++. But if our programmers decide they want to use c++ because they feel more comfortable in it that is fine for them.

[DonRotolo]

The discussion of which language to use for **** has been repeated many times, in many ways. However, it's useful to have the discussion here with LabView and C++ as the subjects.

Most discussions boil down to one point: Use the language with which you are most comfortable.

LabView can do anything that can be done in C++, and vice-versa. For a less experienced programmer, LabView's graphical interface may be easier to develop into complex structures, but that really depends on the person - some people are not wired for graphical interfaces and prefer text.

Both are very common in industry, so learning one or the other isn't particularly useless. Learning both is good, too. C++ is far more common, but not many engineers would have much need to be other than familiar in passing, whereas LabView is really used heavily in engineering, since it interfaces with so much instrumentation. Of course, if you're not planning to be an engineer, this is moot.

I know and use both, albeit for widely different kinds of tasks. For FRC, my personal choice is LabView, as Ii find it better suited to the task-oriented nature of robot programming. Again, this is my personal preference; yours may differ

[Robostang 548]

Our team is struggling with the question ourselves. While we want to use C++, we understand that LabView has some strengths that we would like to take advantage of. We be believe it will be easier to do our vision programming as well as interfacing our sensors with LabView. We hope to then using LabView's external code capabilities to interface the stuff LabView's doing with our C++ code.

[ATannahill]

Our team is going with LabView because it is what our mentor uses at work, and students learn it if they are in the engineering academy.

[Pat Fairbank]

One of the main reasons we will be using C/C++ is that it requires less overhead and setup. LabVIEW is a fairly large and resource-intensive program, and based on past experience (with the CMUCam) we think that it would be more of a hassle to install and get running on every computer we want to program on (whereas all you really need for C/C++ is a text editor).

Given that we have mentors and students who are already familiar with C/C++, and that all indication to date has been that the control system will have the same functionality either way, there just isn't enough incentive for us to switch.

[R.C.]

Quick question to everyone, does labview have the same amount of power as C/C++ and how long does it to make code on labview then on C/C++ IDE.

[Bomberofdoom]

Depends how fast you write (C/C++) and how fast you click, drag and type (Labview).

But really, it all depends on how easier it is to you in think about the code in each IDE's enviorment (text-written or graphical presentation).

Now that you mention the point of speed, it doesn't matter how fast you can create blocks or code, but what matters is how easy it is to find solutions to algorithim problems in each enviorment, because no matter how smart you are, most of the chances are that you will encouter bugs in your code (or the robot will respond unexpectidly) and you'll want to be able to figure out that problem using the best debuging tools out there.

[slavik262]

Our team will be using C++ for all of the reasons that have been mentioned already. While I will admit I haven't worked with LabVIEW, I personally prefer writing raw code as opposed to designing a program using a graphical interface. I have also already created some data structure classes in C++ that I hope to implement this year. Our code team is also fairly well-versed in C++ and I look forward to showing it to the new members of the code team.

[Greg McKaskle]

There are so many ways to do the comparison. Years ago I read a book on comparing languages, and I thought their system was a pretty good one.

My disclaimer -- I work for NI, on LV. That means I'm a C/C++ programmer, and I also program in LV. My opinion is that they both have their strengths, and that is as it should be. In Atlanta, the question came up, "What is the most important language for the kids to learn?" There are many answers this, but my favorite answer is that the most important computer language for you to learn is your second one.

Learning a language gives you a logic tool. You begin to look at problems from the perspective of that tool. It is the "If you are holding a hammer, everything looks like a nail" psychology. Learning a second language, especially one that is considerably different, results in having a second perspective, and learning the tradeoffs and interplay. Hopefully the second language also opens the eyes to the possibility of other language features, perhaps ones that haven't even been invented yet. To keep with my analogy, learning about other fasteners such as screws, bolts, clips, adhesives, etc. really gets started once you change your point of view and realize that the hammer and nail, while they are amazing, aren't the only tools in the modern toolbox.

The book on comparing programming languages was "Comparative Programming Languages" by Wilson and Clark. No, it doesn't cover LV, but it does break down the elements that they think are most useful to measure when looking at languages for a comparison. It is also useful to see the different ideas that languages implement, and to watch that change over time.

Inspired by their categorization, I normally condense this to, Expressive Power, Simplicity & Orthogonality, Implementation, Error Detection & Correction, Correctness and Standards.

If I were to go into each of these for both LV and C, it would be a mega-post, and besides, I think it is better for people to do it on their own and come to their own conclusions.

As an example, C++ scores better on expressive power than C does. Why? They both have the ability for the user to declare new functions, new variables, and even new types. But C++ goes further to allow for operators like + and - to be expanded for new types, and allows for the -> to be used to dispatch to class member functions. C++ also has additional keywords. This power comes at a price, however, as the sorts of errors you can receive from the compiler go way up, and the overall simplicity goes down.

Finally, while most new users initially focus on the text versus graphics difference, this is pretty superficial. There could be a graphics C. Arguably you've already seen that. There could be a textual LV, but defining parallel graphs in text is fundamentally hard and we have instead headed down the graphics road. A more fundamental difference is that C/C++ are procedural languages or imperative languages whereas LV is mostly a functional language. These terms may not mean much, but they are the more important ones to look up and think about.

I don't have a great analogy, but that won't stop me from trying one anyway. An imperative language to me is like driving a vehicle with a manual transmission. There are discrete gears, combined in various ratios to direct the engine rotation to the wheels. You control this with a clutch, a shifter, possibly more if in a semi or farm equipment where I can control other differentials. Fundamentally I'm exposed to the implementation and am expected to manipulate the system at that level. Not all settings make sense, and grinding of gears, getting stuck in neutral, and stalling the engine are all common occurrences, especially until you learn the system quite well. But once you understand the system, it is quite powerful and adaptable.

A functional language in this analogy is more like an automatic transmission system. Fundamentally the big difference is that the driver specifies what the outcome should be, but not the intermediate details. It may be as simple as F-N-R and a pedal. You still control the velocity of the vehicle, but you have traded control for simplicity. When you inspect the automatic transmission system you may find that it is really a manual with an automated shifter, or you may find a CVT or hydrostatic where it isn't even easy to compare them any longer. A CVT isn't limited to a small number of gear combinations, so is it better than a limited manual transmission? Or is it inferior because of the limits on the amount of power it can transfer?

Different approaches to the same problem. Isn't it better to focus on understanding both than to be dogmatic about it?

Greg McKaskle

[slavik262]

Originally Posted by Greg McKaskle

"What is the most important language for the kids to learn?" There are many answers this, but my favorite answer is that the most important computer language for you to learn is your second one.

I wholeheartedly agree with you on this. My first language was Visual Basic.NET, and then through FIRST robotics I learned C, then taught myself C++. The first language really taught me how to "think like a programmer," but the second language really broadens your horizons.

Originally Posted by Greg McKaskle

As an example, C++ scores better on expressive power than C does. Why? They both have the ability for the user to declare new functions, new variables, and even new types. But C++ goes further to allow for operators like + and - to be expanded for new types, and allows for the -> to be used to dispatch to class member functions. C++ also has additional keywords. This power comes at a price, however, as the sorts of errors you can receive from the compiler go way up, and the overall simplicity goes down.

Agreed, but once you learn how to wield that power I have found that C++ (in my opinion) can be used to make programming much easier to understand. Object-Oriented Programming in C++ such as allowing functions to be members of objects make code much less abstract and easier to follow since things are gouped together. Yes, learning OOP can be very challenging because it forces you to think completely differently, but once you become well-versed in it I have found that it makes life easier. Which brings me to...

Originally Posted by Greg McKaskle

A more fundamental difference is that C/C++ are procedural languages or imperative languages whereas LV is mostly a functional language. These terms may not mean much, but they are the more important ones to look up and think about.

I'm confused by what you're saying by this. While C is procedural or imperative, C++ is Object-Oriented. Of course you can write procedurally in C++ just like you would in C, but by taking advantage of the object-oriented approach offered in C++ you can make your programs much less procedural, like I mentioned above.

Originally Posted by Greg McKaskle

I don't have a great analogy, but that won't stop me from trying one anyway. An imperative language to me is like driving a vehicle with a manual transmission. There are discrete gears, combined in various ratios to direct the engine rotation to the wheels. You control this with a clutch, a shifter, possibly more if in a semi or farm equipment where I can control other differentials. Fundamentally I'm exposed to the implementation and am expected to manipulate the system at that level. Not all settings make sense, and grinding of gears, getting stuck in neutral, and stalling the engine are all common occurrences, especially until you learn the system quite well. But once you understand the system, it is quite powerful and adaptable.

A functional language in this analogy is more like an automatic transmission system. Fundamentally the big difference is that the driver specifies what the outcome should be, but not the intermediate details. It may be as simple as F-N-R and a pedal. You still control the velocity of the vehicle, but you have traded control for simplicity. When you inspect the automatic transmission system you may find that it is really a manual with an automated shifter, or you may find a CVT or hydrostatic where it isn't even easy to compare them any longer. A CVT isn't limited to a small number of gear combinations, so is it better than a limited manual transmission? Or is it inferior because of the limits on the amount of power it can transfer?

Different approaches to the same problem. Isn't it better to focus on understanding both than to be dogmatic about it?

That actually turned out to be a beautiful example. The reasons I love C++ are the ones you mentioned above. At first, things don't make sense, don't work, and seem to vex you at every turn. But once you get the hang of it, you realize that you have an incredibly powerful and flexible tool at your disposal. The downside is that programs can take longer to develop. I personally don't mind this, however, because I enjoy working "under the hood" and being more in control (perhaps it's just because I'm obsessive-compulsive ). I would also like to take the chance to look at LV though to see how it works and what advantages it has, even though our team will be coding in C++ this year.

[Alan Anderson]

(C/C++ is procedural, LV is functional)

Originally Posted by slavik262

I'm confused by what you're saying by this. While C is procedural or imperative, C++ is Object-Oriented.

You should probably look up what "functional programming" means (try Wikipedia). Being Object-Oriented doesn't appreciably change C++'s imperative nature. What you've written seems similar to "While an orange is a fruit, a navel orange is seedless."

[DonRotolo]

Originally Posted by Greg McKaskle

There could be a graphics C.

There is, we call it "Easy C".

[slavik262]

Originally Posted by Alan Anderson

(C/C++ is procedural, LV is functional)


You should probably look up what "functional programming" means (try Wikipedia). Being Object-Oriented doesn't appreciably change C++'s imperative nature. What you've written seems similar to "While an orange is a fruit, a navel orange is seedless."

Ah. Thank you for clearing that up.

[lasereyes]

Originally Posted by Don Rotolo

There is, we call it "Easy C".

Will there be an EasyC option next year?