Is switching from LabVIEW a bad idea?

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

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/conte...pci/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.

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]

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

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]

Originally Posted by Alan Anderson

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]

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

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]

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

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]

Originally Posted by Alexa Stott

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/