Do you hate or like labview or want to use c

[zackcool123]

I personally hate it

[team2491]

On LV:
The non-linear execution forces me to re-learn everything about coding; there's so much abstraction that sometimes I sometimes find myself trying to work around it; error catching is a pain; the "code" gets disorganized quickly, unless you're extremely careful.

On the plus side:
Would be easy to learn, abstraction makes handling I/O easy (though a good function library in any other language would do the same).

[Tom Line]

Zackcool123. This is the second time we've gone through this. The first time the post was deleted.

First of all, do you think that perhaps taking polls with langauge stating that people "HATE" one of the main sponsors of FIRST, on a forum they frequent, where they spend company money to support and teach us, is the best idea?

Perhaps you could have stated the poll in such a way as to ask a positive question. Such as "Who prefers labview, and who prefers C++, and why?"

I would suggest that using that type of question would serve several purposes:
1. It would not make it appear that a portion of the FIRST community are ungrateful ingrates who will complain about being allowed to use a professional grade development system that is used around the world.
2. It would point out areas that C++ is preferred, and the people who develop labview might take those points to heart and modify their environment.

There is a large difference between constructive criticism wherein something can be learned, and damaging criticism where the only point is to degrade. Would you perhaps elaborate on why your prefer C or C++ and what could be improved in Labview?

[chmp09]

I personally like labview. It is easy to do the basics. It also has the ability to use powerful techniques such as the use of pids. Though it takes a while to get used to what time is right to use variables, i did not find it dificult to switch from c to labview.

I have not tried to program in C++, but I have programmed in both C and Java. I don't think that I am making as many logic errors with labview as in previous years.

[camper365]

Labview is good software, the problem is that you have to learn it, and it is extremely hard to learn. By now it is too late to learn because ship date is in three days. I started learning at the beginning of the season, so I am good at it now.
The problem is that labview is not based on any language that you would know. It is completely graphic, and you use the mouse a lot.
It is also a dataflow language, which menas that code is executed when it can, instead of in order (which means you could have three loops executing at once).

[dmoody92]

I do like it a lot. When I started the build season I barely knew what Labview was, let alone know how to use it. Through the build season I tried learning it and it was tough, but it just clicked after a while and I made the entire program by myself (I had a lot of help learning it by my two programming mentors). I know a little bit of C++ but its was definitely cool learning something that is difficult and actually used in industry.

[Greg McKaskle]

To Tom's point, asking questions is almost always a good idea. Learning how to ask so that you get good answers is the thing to think about. Provocation isn't always the best approach.

Let me restate the poll as:

Hate bananas.
Like bananas.
Rather eat apples.
Foo.

My point is that there isn't anything wrong with your opinion or discussing it. They are both just fruits, but there isn't necessarily a need to hate stuff. Just get back to making your fruit salad, ... errr, robot programs.

On the other hand, I really like hearing the feedback of people using the tools. LV is what it is. It is my job on a daily basis, along with many others, to make it bigger, better, stronger, and sometimes easier. Feedback is important for that to happen. The people working on LV use several languages and a handful of development tools. Honestly, none of us ever expected it be used for high school robotics, so this is all a new adventure. So far I'm pretty pleased with how its going.

By the way, it looks like I may be giving some advanced LV training in Atlanta. So if you are interested in maybe learning how to work with a new fruit -- like how to make a banana split, banana pudding, etc. Can you imaging an apple split, apple pudding? Maybe I should start a poll about favorite fruit desserts.

Greg McKaskle

[Daniel_LaFleur]

Originally Posted by zackcool123

I personally hate it

LabView is a paradigm shift from C++. The logic is the same but the flow (Data vs process) is very different, as is the environment ... so, in following Gregs lead, and trying to turn this into a positive thread ...


Let me ask further questions:
1> Why do you Hate/like Labview?
2> What would make it better/easier?
3> Is there any option you'd like to see added?
4> What is the maximum wind velocity of an unlaiden swollow?

[PurpleHaze]

I am very blessed to be on a team that has an expert mentor in LabVIEW, and so I feel I have been taught adequately. LabVIEW being massively parallel is very useful for trying to run multiple systems on the robot at the same time. That being said, if I had my choice, I would choose C for several reasons.

1. LabVIEW is nearly impossible to do version tracking. We wrote the code for the camera in a separate function, and trying to implement it into the main program was a nightmare of resolving conflicts.

2. The obvious problem: following the flow of the code feels unnatural, and makes debugging difficult.

3. LabVIEW is so high level that it makes changes you can't immediately see. Headaches often ensue.

Maybe I'm just old-fashioned, for I have been writing in standard text based programming languages for a long time, but I'm not cut out for these new-fangled graphics based languages.

Also: Darn kids get off my lawn!

[adamdb]

I too am a C programmer from waaaay back (19+ years) and Labview has been quite a stretch for me. I am coming to terms with it, but it has been difficult.

Our main issue has been with figuring out where within the Basic or Advanced framework you should do what. Specifically, where is the best place to (for instance) open a motor, and create a reference for it that we can use elsewhere.

We have also seen some flaky stuff happening. In our testing today, we worked through some reference issues for DIO's to get our autonomous working (all cases tested correct). Then we worked through some other issues to get Teleop working, only to discover that DIO reference issues we had had in autonomous had returned. Sometimes shutting down Labview and rebooting the robot, then restarting everything helped, sometimes it didn't. The DIO's in question are used only in autonomous, so I know we didn't honk anything up when working with the teleop code.

Frustrating. You like to think that once you have fixed a problem it will stay fixed.

[Uberbots]

once you fully understand the dataflow paradigm of labview, it becomes an extremely effective language for programming naturally parallel machines like robots in. Seriously, there is no reason to hate labview (other than believing the the lower level language you program in the cooler you are... which is totally not true at all unless you are optimizing the really tight loops).

you should really take some time to learn how the code is structured. i worked over the summer learning labview and how to interface with robot-like devices with the rio, so i was all set in aiding various teams in getting started with this thing. i also learned how to do code optimizations in labview, how the compiler works and tricking it into faster machine code, and what is simply not efficient (e.g. large global variables).

you should also realize that the FPGA, the not-quite processor that is doing all the background sensor processsing, was also programmed in labview, and is able to read hundreds of sensors in PARALLEL.

parallelism = labview
sequentialism = c++
though either can do the other, its easier in the specified language.

[leftylink]

Thanks, everyone. This is a topic I am interested in, though of course I would like to stay positive on the issue as well. I would like to hear some input on some questions I had.

Team 1318, after much deliberation, decided to use LabVIEW with this year. Had the choice been completely up to me, I would not have done this, but I learned to cope with the language, tolerate it, and use it to program a robot.

My main concern, as programming lead and a graduating senior, was being able to "pass down" the programming skills, instilling my passion for programing in others and giving people skills they will need to be able to competently program in the future, especially if they plan to pursue something programming-related as a career.

Certainly I am aware that programming concepts transcend languages. For example, things like if/else or switch/case in C-based languages can be represented with a case structure in LabVIEW. While loops? For loops? They are also in LabVIEW.

What I tell my new programmers is that this is like learning many different spoken languages. In English class, they learn about subjects, predicates, direct objects, indirect objects, and no matter whether they also learn Spanish, French, Japanese, etc., they will be able to take those concepts and apply them to the other languages. It is my hope that this trait of programming languages has allowed the new programmers to be able to think programmatically, even if LabVIEW is a vast departure from good ol' text-based programming. Thoughts on this?

My next thought is how directly applicable these programming skills will be in "the real world", so to speak. A search on google for "labview programming jobs" returns 136,000 results. What about C? 20,500,000. C++? 7,660,000. Java? 11,200,000. PHP? 12,100,000. Python? 12,600,000. Defenders of LabVIEW are quick to state things like this:

Originally Posted by Tom Line

It would not make it appear that a portion of the FIRST community are ungrateful ingrates who will complain about being allowed to use a professional grade development system that is used around the world.

My question is, to what extent is it "used around the world"? Who uses LabVIEW in any real-world application? What advantages do they see in paying for this proprietary programming language as opposed to using a language with open standards such as C++ and the like? Perhaps we can learn something from their motivations. If we saw that, for example, NASA chose LabVIEW because of its ease of debugging and graph-making (because you can out put to a graph indicator), then we would understand that LabVIEW is useful in instances where we would want to make graphs like this.

Even if LabVIEW is not as widely used as text-based programming languages, perhaps this question is less relevant because of the point I stated above (programming concepts are still the same)?

I took a look at the Tiobe TPCI and LabVIEW is 29. Not that bad, I suppose.

Other than that, I suppose it's a matter of taste. Programming is programming, after all, and you can do most things in both languages thanks to the hard work of WPI. We were frustrated with the long build times required by LabVIEW, but the debugging ability was nice with the ability to easily make graphs or "probe a wire", or things like that. We didn't like the lack of "find in files" or the cluttered-ness of the code, but perhaps it is easier for a new programmer to comprehend LabVIEW (after an informal poll of my programmers).

I would be interested to see what others have to say about these points.

[lproxster]

The programmers on 2265 tried both C and Labview and found Labview more to their liking. Personally I like Labview, but Xing (head programmer) and I really dislike WatchDog (it gave us a lot of problems while we were testing our programming).

[ComradeNikolai]

We went with C++ for this year because it is what I was more familiar with, and I was the head programmer -- no one else on the team had familiarity with LabVIEW at all, and a few others had slight familiarity with C-based languages.

I tried LabVIEW at one point in the season with the idea that it would help our programming, so others could help out without knowledge of syntax -- it just didn't make sense to me, I couldn't figure it out... I'll learn it eventually, probably, but in the crunch of the season, we stuck with what we knew.

LabVIEW is incredibly powerful, and would have been awesome! ... but I prefer C++.

[Boydean]

We used labview, for reasons not worth explaining here. Do I like labview? Not really. Learning labview is interesting, and although I think I would have preferred to use C++ I don't doubt using labview was a bad choice. Once you get used to the wire colors, and getting over the fact that its just going to get a little messy, it really isn't that bad. Sometimes after long nights on it debugging I get a little frustrated. I could not spend my career on it. But I can see were people are coming from by using it, I can see where people are coming from with not using it. I think it was very nice to get out of the "norm" of text programming, its good practice to get out of your comfort zone. I believe it was very nice for NI to give us this powerful software to use, and there is no doubt that I LOVE the new cRIO. I can see it being nice for FRC teams that have alot of FLL students coming up to them. And knowing Labview has helped alot with being a programming mentor for FLL.

Like said before. Programming is programming. Your purpose is to solve problems, both small ones like case orders, and big ones like traction control. Whether you program in Labview or C++ you are going to be a programmer, there to solve problems that the res of the team rather not fool with.

I like labview but I prefer text based programming.

EDIT: Oh yeah. And it was kinda weird to see an error in NXT lego software say "Could not find Sensors.vi"