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]

Originally Posted by 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.

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.

Originally Posted by Phalanx

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

[tsaksa]

Originally Posted by Phalanx

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]

Originally Posted by Alexa Stott

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.