Is switching from LabVIEW a bad idea?

[Itamar]

Hello!
In the past four years my team has been working with LabVIEW, and lately I've been thinking about switching to C++ (or perhaps Java or Python... though C++ is the one I have in mind).

Here's why: Many of the students that join the programming team have no previous (or very little) experience with programming. As their teacher, I want the students to be able to use the knowledge they gain to any other programming field they like: game development, web development and more. Obviously working with LabVIEW will give them some understanding of programming concepts, but it will be much harder to transform that knowledge to other fields. Plus (though this is just my view), C++ just seems more challenging and... fun.

The only thing that prevented me from using a different language than LabVIEW is the understanding that each year there is less and less support for using other languages in the FRC. I am worried we will face unexpected/unsolveable bugs because of this lack of support.

Are my worries justified?
Have faced weird unsolveable problems that you couldn't do anything about, just because you weren't using LabVIEW?

Itamar.

[Greg McKaskle]

I'm happy to hear that you are able to teach the kids to program in LabVIEW, and if you have the ability and time, I'd encourage you to add in another language. Another approach would be to rotate through the languages over the years so that the students can experience various tools and languages. I would hope that support is not a barrier to this. If you have suggestions as to how to improve it, please offer them.

In my opinion, students destined to become engineers or scientists should have some exposure to a programming tool. Students destined to become computer scientists or computer engineers will gain exposure to all sorts of languages, and C++ is still very common in industry, but not necessarily as a teaching language. It is indeed more challenging. Fun, ... I suppose it depends on the amount of success.

I certainly hope your fears aren't justified.

Greg McKaskle

[Bryan Herbst]

If you have the support from a mentor knowledgeable in C++ and believe that your team can use C++ (or Java) effectively in the short season, I would say go for it! I would definitely use it in the off-season first so that you can get a feel for it though.

I haven't really felt like the support for C++ or Java has been waning over the years, though I definitely acknowledge that LabView as it relates to FIRST has far more support than any other language. C++ and Java are used so much more extensively than LabView that I think this is warranted, and actually brings LabView on par with C++ and Java in terms of support if you include the vast resources and people with experience for the latter two.

[vhcook]

I'd avoid Python, not because there's anything wrong with it as a language (I use it at work and find it delightful), but because it is not an officially supported option.

My team uses Labview because if we're having a problem in the control system, it's all NI and they have splendid tech support. Most of my students have or will have other language experience through AP classes, college, or their own general programming interests, and Labview is an interesting choice for us because it requires a different mindset than text-based programming. We also use a lot of state machines, which are extraordinarily easy to code and debug in Labview.

C++ and Java are more generally used languages, and they have both been available long enough that there's plenty of official and community support in FRC, although my perception is that C++ has more users and resources available.

[Robert103]

For as long as I remember, my team used labVIEW every single year. This year however, we decided to switch to C++. Switching was... difficult. If you have enough support, however, it is definitely doable and worth it.

[Phyrxes]

Our teams experience is while the programming mentors tend to be fluent in C++ from their professional lives many students are not. As AP computer science has shifted away from C to Java student familiarity with C has dropped significantly. Presented with either teaching a student LabView or C++ the better answer may be do both but pick one to start with.

[JohnSchneider]

We've never used labview and always used C++ - however that was when it was students exclusively in the programming department. We had a new mentor this year who was familiar with JAVA, and were going to make the CAN trek, so we switched over to JAVA.

JAVA was a blessing in disguise. It's what the students are taught in AP computer science, and its a very elegant language (very easy to read...though I'm reminded of the old joke that "I'd rather read a C++ short story than a JAVA novel) We had 0 issues with it or with CAN this season.

I also happen to go to school where Bjarne Stroustrup teaches....so I've heard more JAVA bashing than I care to in my life...but I'd still support JAVA over C++ next season.

[Phalanx]

I'm the Mentor for my Team for both Software and Electronics.
I've been a low level ASSEMBLY language coder my entire career (30 yrs).

I personally don't like any OOP(Object Oriented Programming) whether it be JAVA, C++ or Labview. However, these are the choices we have to work with. So let me share my reasoning for recommending Labview.

My own personal food for thought..
1) National Instruments makes and supports the CRIO and it's Modules.
2) National Instruments makes and supports LabView.
So when something doesn't work as it should or as designed then you only have ONE place to point a finger at to get it corrected.

I have had this very issue in my professional career with software and hardware products that are "supposed" to work together. Here's how it usually goes.
Vendor A says it must be something with Vendor B's product.
Vendor B says it must be something with Vendor A's product.
Round and around it goes, until someone other(usually ME) than Vendor A or Vendor B clearly identify who's problem it really is.

So I'd rather have one vendor to point a finger at, that can't point it at anyone else except themselves.

I'm only sharing my thoughts, my views, my experiences, the decisions are ultimately up to your team.

[Hjelstrom]

If your team has an experienced C++ mentor, then I think C++ is great. If not, then I'd recommend Java instead. The problem is that in C++ you can accidentally create very difficult to find bugs which can really road-block a team if you don't have someone with experience to find them. For example, incorrect usage of pointers can cause random, extremely difficult to solve bugs that you essentially don't get in LabView or Java (those languages protect you pretty well).

[Bryce Paputa]

If you have mentor support in C++ or Java, it would be a great idea, but if you don't, it might be just a little too much.

If you do change, good luck!

[FrankJ]

The best reason for using Java the AP programing exam is based on Java. So if you can program the robot in Java the AP exam should be cake.

The NI guys we have talked to about our problems, have always been very supportive. (We have lots of problems) Although their main expertise is Labview they have never suggested that our problems would best be resolved by switching to Labview. No matter how true that statement would be. :)

[Alexa Stott]

For as long as I remember, my team used labVIEW every single year. This year however, we decided to switch to C++. Switching was... difficult. If you have enough support, however, it is definitely doable and worth it.

That switch made me happy. ;)

------------------
I am mostly going to talk about C++ because I have never used Java in a FIRST context.

I would definitely recommend a switch to Java or C++. It's much more useful, I think, down the line. I really benefited from learning C (which was used my first three years) and C++ when I went to college to study computer science.

There is a lot of great support for it and the C++ is nothing too involved. Bharat, Kristian, and I ran 2 programming workshops for our students and 103 in December (I have the slides from the second presentation that focused specifically on C++ in FIRST--the first session was barebones programming basics like what is an int) and they were able to get a pretty good handle on it from just those two days. It's really straightforward, I think, especially since some of our students had taken or were taking the intro to CS or AP CS classes at our school that teach Java. The differences between Java and C++ are minimal in terms of the depth of knowledge you really need to program a FIRST robot. Of course, if you use Java and experience a similar overlap, you're even better off.

As someone who learned C and C++ first, I once tried to do something in LabVIEW. And I was completely lost. And I have yet to encounter a situation where I've needed to know anything like LabVIEW. I do, however, do CS research where I use things like Java and C++ and such. In terms of moving from FIRST to the "real world," I'd say there's no competition.

RE: python. Python is a really great language to learn, but there is far less support for it. If you as the mentor feel comfortable with it and feel that you would be able to get the job done with it, then you can always give it a shot.

Since you are ultimately the one that will be teaching the students and will likely be their first go-to for any troubleshooting or problems, go with what you are comfortable with. I would recommend taking some time in the off-season to yourself to first acquaint yourself with the new language (if you have the time/resources, maybe try out two or something), but I highly recommend switching to Java or C++ just because of it better benefits students in their future endeavors.



I have had this very issue in my professional career with software and hardware products that are "supposed" to work together. Here's how it usually goes.
Vendor A says it must be something with Vendor B's product.
Vendor B says it must be something with Vendor A's product.
Round and around it goes, until someone other(usually ME) than Vendor A or Vendor B clearly identify who's problem it really is.

So I'd rather have one vendor to point a finger at, that can't point it at anyone else except themselves.

I'm only sharing my thoughts, my views, my experiences, the decisions are ultimately up to your team.

To be 100% honest, we have never had a problem that was "caused" by our using C++. Most of the issues we have had were solved through a quick ChiefDelphi search or a new post. Other times, we have contacted someone directly for support and our issues were resolved. This literally has never been an issue. Greg McKaskle (he previously posted in this thread) responds to threads asking for help where people are using any of the three supported languages. Mostly because it comes down to something that can happen in any language (watchdog issues, not having the right firmware installed, etc.). I honestly don't think NI is ill-equipped to deal with C++ issues.

[rbmj]

If you have enough time and resources, I would definitely recommend making the switch to C++.

My team is a bit of an abnormal example. At the beginning of this year, I was the only returning programmer (I'm a senior) and we had no programming mentors. Since I would have to teach the new kids how to program, I needed to be able to teach in a language I felt comfortable in, so C++ won.

I also knew from the previous few years that, while LabVIEW can be a great tool, badly written LabVIEW is IMPOSSIBLE to decipher. Programmers who are just starting out in LabVIEW often put everything in one giant mega VI and all of the wires and relationships between the different components look like the space behind the TV at my house. The auto-straightener-uper (I don't know what it's called) would do an OK job, but even that was difficult to read. Most of the time "indent" can do a decent job at straightening up C++ code...

I also think that for people who are not used to programming, it's easier to teach them with an iterative model. The functional aspects of LabVIEW are a little more abstract. Make sure you don't fight the language - I had a friend last year who attempted to do low-level C programming with lots of bit twiddling and it was very difficult to understand with all of the ands and ors going in a thousand different directions.

That said, LabVIEW has some awesome features. If you make heavy use of parallel processing, C++ is going to be a bit of a pain. If you are able to use C++11 (unsupported toolchain), this is improved somewhat, but it still does not feel "natural". C++'s parallel processing capabilities (and Java's, from what I can glean) seem to mostly be good for just spawning a task and letting it run on its own. Any amount of communication between tasks is much more difficult.

Additionally, the debugger for LabVIEW is SO much better. It did break once at competition last year (I still don't know why - the NI guy at that competition didn't know either), but I think that was a corner-case fluke. It was very, very helpful (much better than the debug printfs we used this year - the WindRiver debugger would sometimes crash randomly) and allowed us to prototype much more quickly. It also integrates quite nicely with the other NI utilities provided with the driver station, and if you make a custom dashboard it doesn't look so obviously out of place.

One last shout out for C++: WPILib C++ is VERY well written and is probably 90% documented. Even relative beginners can read the source code.

Again, though, choice of language is most often a business decision, not a technical one. If you want to try it, go ahead. If you need help, we're happy to provide. But what's most important factor in success is what the team has experience with. If you have a solid programming team and think they can use the added language experience by hopping languages every few years, go for it. But if your team doesn't have as strong of a base, but they have a fair amount of experience invested in a certain language, switching languages might not be a good idea.

That was much longer than I wanted it to be. TL;DR: I like to blabber about programming languages :D

[tsaksa]

My own personal food for thought..
1) National Instruments makes and supports the CRIO and it's Modules.
2) National Instruments makes and supports LabView.
So when something doesn't work as it should or as designed then you only have ONE place to point a finger at to get it corrected.


Good point, but I would add one more. In industry I often pick a vendor based on their degree of commitment I feel they have to the specific area where I may need support. National Instuments is a dedicated sponsor of FIRST, and as such seems willing to help provide good example code and utilities for many common FIRST capabilities. My team currently uses Java, and it is quite common for them to find incomplete example code or bugs where the Labview implimentation seemed more complete and stable. But, I have no complaints with this, because much of this code is developed and provided by volunteers.

As I said before, our team chose Java based on the skill set of the current mentors, and interests of the stubents. But, my personal opinion is that the Labview code often seems more robust and complete. Perhaps this in a distorted opinion based only on a small sample set. But National Instuments does seem to have some skin in the game as far as FIRST goes. And having a company that is willing to put technical resources behind making their products succsesful in a given area is a factor that should not be taken lightly.

[plnyyanks]

I would definitely recommend a switch to Java or C++. It's much more useful, I think, down the line. I really benefited from learning C (which was used my first three years) and C++ when I went to college to study computer science.

I'm not going to argue with this, because it's true. However, my LabVIEW skills I learned through FIRST did help me get a job last summer. It's not like LabVIEW isn't used in the real world, it just has a smaller niche.

As for what language to use, follow your mentors. They'll be most helpful, and in the end, it's not the language that's important, it's how you implement it.

[topgun]

We went with Java two years ago and have never looked back. The new command pattern libraries this year are awesome.

[techhelpbb]

We've used Java for several years. It works.

The JavaDocs are not always very helpful.

The language is legible...unless your students are tired then you have to figure out why you have a variable called broccoli :confused:.

The only thing that has bothered me for some time with Labview in this context is that sometimes what it produces is more bloated than you may suspect. I also am unclear on what it does when certain things go wrong in subtle ways.

We've used C in the past and I'm sure we can do C++.

It's been my understanding over the years that the languages tend to fall like this:

Labview, nice elegant and visually accessible.
Java, harder to crash but sometimes a bit of a black box.
C++, not hard to cause yourself headaches with at all but very powerful.

I've left out Python because as others have said it's sort of not official. We did use Python for some LEGO NXT tinkering and for some robot mounted laptop video tinkering (didn't make it to the field, used Java for that too).

[mdrouillard]

This thread certainly resonated with me.
As a mentor , we participated in the beta test for the 2012 software, playing with kinect and all things F.I.R.S.T. prior to the build season. In previous years the team used labview, and while this was my first year as a programming mentor for the students, we beta tested the environment in C++. We fully intended to build our 2012 robot using C++. We played with the circle vision code and extended our 2010 robot to track circles and controlled with kinect, all in C++. However, when the 2012 game was released we noticed that the square target sample code was released for labview but not for C++. Since the build season is so short, we elected to use labview since it allowed us to get our base code up quickly. BTW, as the mentor, I did not understand labview until the build season, but I am pleased we stayed with labview for this season. We are now in the off season working to convert our 2012 robot into C++ so that we can again next year make the informed decision of which path to take. The younger students are mixed on the matter, having learned labview and with our senior labview programmer graduating this year, we have an opportunity to start again. Mixed because as the original post suggested, they also would like to learn a language that may help them in later studies while recognizing that labview can prove to get a working robot going faster.

[taichichuan]

As an employer of embedded developers that work in environments such as Android, embedded Linux, VxWorks and several others, I can say the the experience of C/C++ will help ensure that your students are employable. Java is syntactically not that different. I find the use of the JVM does introduce some subtle timing issues, but they can be dealt with in the less than 3 minutes of a match.

In the TIOBE language survey (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html) NXT-G has finally been able to break the top 20 whereas C and Java have been at the top of the list for several years. The Labview environment is very rich and well supported by NI. However, as pointed out in an earlier post, it's a proprietary language targeted at NI products. With the exception of the Lego Mindstorms, you won't find Labview in any other environment except those using NI products.

The NI Labview support helps get kids who don't have any software experience up and running quickly. It's a completely different programming paradigm. As long as you're connecting existing VIs together, Labview is quick and efficient. The output code from Labview is a binary. So, from an execution perspective, it's also fast. As also pointed out earlier, the support from NI and here on CD are great.

The issues that I personally have with Labview are twofold. First, it's a very specialized piece of the embedded industry. The number of jobs available with just a Labview background are much smaller than those with Java or C/C++. The second is the process of creating new VIs. Because we in FIRST are always creating new interfaces for the challenge du jour, if a team has to create a new VI from scratch, they are often faced with a seemingly impossible task. If they keep pushing, maybe someone with more experience will come to their rescue. But, if you have to go off the reservation and create a VI that didn't previously exist, many kids get stuck because they have very little source material from which to draw. Try Googling "create a Labview VI" and you'll find that most of the references that come up are all linked back to the same Labview tutorials from NI. Don't get me wrong, Labview isn't *bad* -- just different. But, C/C++ and Java have a lot more sources to choose from.

In the end, it all comes down to the mentor's and student's past experiences and willingness to learn. C++ has a lot of potential gotchas with the use of pointers. However, pointers are what make C/C++ the language of choice for platform development. Even Android (a Java-centric environment) is adding extensive support for C/C++ in it's native development kit in order to get more speed and better hardware integration for games and other high-performance applications. So, if you want to learn C/C++, you'll be positioning your students with a skill that they can carry forward. Many of my C++ students are actually working as C/C++ programmers while they go to college. So, I know the model works. If you've got the time and inclination to try it, C/C++ can be a real positive addition to your robotics program.

All that being said, I'll be working to learn Labview in the off season so we can dork with the dashboard next season. Hopefully, this old dog can learn new tricks.

[Andrew Lawrence]

Would it be good to switch from Labview?

Does switching to Geico really save you 15% or more on car insurance?


The answer to both, is a Yes. Sort of. For both, it all depends on how you use it. If you know a lot more C++, and can use it efficiently, go ahead. If you know how to get the most out of your car insurance, go with Geico. But in the end, it doesn't matter. If you're better at Labview and it's more efficient for you to use, sticking with it won't kill you. Likewise, you won't be pushing up daisies if you don't change car insurance anytime soon.


tl;dr: Both are great, depending on how you use them.

[Alan Anderson]

As an employer of embedded developers that work in environments such as Android, embedded Linux, VxWorks and several others, I can say the the experience of C/C++ will help ensure that your students are employable.

Having experience with C/C++ will arguably help them be employable as embedded software developers. If that's what they want to do, great. It'll certainly give them more options.

LabVIEW is the sort of programming environment that gets used by "just plain engineers" who don't do software as a primary job function. Knowing how to use it is a major plus in a wide variety of careers. It's also tremendously powerful for "real programmers" who want to take advantage of the wide availability of toolkits for many applications.

C/C++ provides the programmer vast flexibility and power, but I've always said that it gives you enough rope to shoot yourself in the foot. If you're disciplined enough, it's great. If not, it's easy to make stupid mistakes that result in a perfectly valid program that doesn't do at all what was intended.

In my day job, I'm a software developer. I write programs for embedded systems, for web servers, for database front-ends, and for process automation. I use languages ranging from assembly to Pascal to C/C++ to VB to Tcl/Tk to G (LabVIEW). Plus two dialects of SQL, a bit of PostScript, and a couple of special-purpose "languages" of my own creation that are essentially function libraries. My general tool of choice is actually Tcl in most cases, though I think LabVIEW is very good for creating large programs that are easy to maintain.

[JCharlton]

Twice now I've taken good text/procedural programmers and dumped them into LabVIEW's graphical blocks. Not because it's a better language to program the robot, or there are more jobs, or because it's easier.

Both of these natural coders "got" text-based line-by-line coding, but LabVIEW introduces them to a new way of thinking about "code". After 30 years programming it certainly opened my eyes wide.

Had it been the other way around, a student who started in LabVIEW and was proficient at it, I'd probably introduce Java or C++ to add that to their toolkit. I'm mean that way :)

I think a good employer will be more interested in a student with a varied experience than someone who knows but one language. These are high-school kids after all, who knows what direction they'll take from here, give them as many experiences as possible.

[FrankJ]

With the way things move in the computer world.... I can just about guarantee the programming tool you learn in high school will not be the one you use through out your career. In terms of learning the logic of programming any of the programming languages work. The rest is just syntax & pointers.

In the industrial world. You will have to learn whatever programming tool the machines in your plant are using. When you change jobs as most of you will, you likely will be learning another tool.

[Alexa Stott]

Having experience with C/C++ will arguably help them be employable as embedded software developers. If that's what they want to do, great. It'll certainly give them more options.

LabVIEW is the sort of programming environment that gets used by "just plain engineers" who don't do software as a primary job function. Knowing how to use it is a major plus in a wide variety of careers. It's also tremendously powerful for "real programmers" who want to take advantage of the wide availability of toolkits for many applications.

<snip>

I have applied to a ton of CS jobs and internships in the past three years since coming to college. I'd have to say that the most popular desired/required programming languages for any of these positions includes C/C++ and/or Java (other popular languages would be python/perl/any of the popular scripting languages and some of the web-based ones). For students who wish to go on and pursue a degree and a career in computer science, I think using C++ or Java is most beneficial.

For students whose primary interest lies in engineering, I could see the benefits of knowing LabVIEW. However, I have many friends in the engineering school here at UMD (one of the top public universities for engineering and CS), and many of the different engineering disciplines require a computing/software class. There's an Aerospace Computing class for the aerospace engineering students that teaches C++ and MATLAB. MechEs also have a software class that focuses on MATLAB. The same is true for Civil.

Basically, in the countless job applications and interviews that I (a CS major) and my engineer friends have encountered, LabVIEW has never once come up.

[GBilletdeaux930]

With the way things move in the computer world.... I can just about guarantee the programming tool you learn in high school will not be the one you use through out your career. In terms of learning the logic of programming any of the programming languages work. The rest is just syntax & pointers.

In the industrial world. You will have to learn whatever programming tool the machines in your plant are using. When you change jobs as most of you will, you likely will be learning another tool.

This.

It is my belief that FIRST is about giving kids a head start in College and maybe in their desired field. In a good software curriculum, students will be taught software theories, not shoving tons of languages at them. They will be taught how to design software using UML and various design patterns. They will be taught to make readable and reusable code.

Using the lingo of Championships, learning a ton of languages will get you a job. Learning the theory of programming will get you a career.

[Alexa Stott]

With the way things move in the computer world.... I can just about guarantee the programming tool you learn in high school will not be the one you use through out your career. In terms of learning the logic of programming any of the programming languages work. The rest is just syntax & pointers.

In the industrial world. You will have to learn whatever programming tool the machines in your plant are using. When you change jobs as most of you will, you likely will be learning another tool.

C has been around since the 70s and C++ came out in the early 80s. Java was released in 1995. Perl and python came around the late 80s with Ruby following sometime in the mid-90s.

Many places still use these languages. Of course, there have been significant updates to them over the years, but they're all still around.

I guess this basically sums up my thoughts on this thread:

As a computer science student, never once have I wished that I could go back in time and learn LabVIEW. I have, however, been thankful many times for having a background in C/C++ and Java before entering college.

[Andrew Schreiber]

Basically, in the countless job applications and interviews that I (a CS major) and my engineer friends have encountered, LabVIEW has never once come up.

Allow me to offer a counterpoint, I have encountered numerous jobs where having LabVIEW on my resume was helpful to me. But I also list C/C++, Python, Ruby, Java, and a handful of other languages I've picked up over the years.


As for the topic, if your mentor force (or students) feel more comfortable working in or helping with another language switch to that one. If they don't have a preference any of the languages will teach programming concepts equally well. LV might also have a benefit in that most students will never take a course on it. Most of this comes down to preference though.

[techhelpbb]

Well I know as far as language longevity is concerned, someone pinch me when GCC is no longer important:

http://gcc.gnu.org/wiki/History
http://gcc.gnu.org/develop.html
http://gcc.gnu.org/