Advantages of each programming language

[cierra_shawe]

Hi everyone!

Although it is only 3 days until our first regional, we have yet to solidify what programing language will be used. I was wondering what the advantages of each would be, and availability of teams who would be able to help at the regional. Also any other tips to help our rookie team out would also be great!

:]

[Alan Anderson]

Use whatever language you're most comfortable with. What did you program with while you were developing and testing your robot?

[basicxman]

Although it is only 3 days until our first regional, we have yet to solidify what programing language will be used.

I sincerely hope you've already programmed your robot :eek:



I was wondering what the advantages of each would be, and availability of teams who would be able to help at the regional. Also any other tips to help our rookie team out would also be great!

There are tons of threads out there on this, but I'll offer some quick points


There's a fair amount of support at regionals in all three official languages, but LabVIEW seems to take a majority
I'm not American, but I believe many American high school comp sci courses (specifically AP level) teach Java
Java and C++ have a fair amount of similar syntax
SmartDashboard can be extended with Java, default Dashboard can be extended with LabVIEW


EDIT: If you need specific real-time help, PM me

[andreboos]

Java and C++ compile and deploy much faster than LabVIEW, or at least that was the case last year. We use C++, and it takes 5-10 seconds to compile and 3 to deploy our code, which really cuts down on programming development time. LabVIEW takes several minutes. That said, LabVIEW is far easier for beginners at programming.

[basicxman]

Java and C++ compile and deploy much faster than LabVIEW, or at least that was the case last year. We use C++, and it takes 5-10 seconds to compile and 3 to deploy our code, which really cuts down on programming development time. LabVIEW takes several minutes. That said, LabVIEW is far easier for beginners at programming.

LabVIEW also has some very nice debugging tools.

Disclaimer: That being said, I use C++ for the robot and this year quite a bit of Java for the dashboard and won't be switching anytime soon.

[Ziv]

if(youKnowAnyLanguage) {
use(theLanguageYouKnow);
} else {
read(WPILibCookbook (http://firstforge.wpi.edu/sf/go/doc1297));
if(youUnderstoodAnyOfThat) {
use(java); // C++ is an option, but it's a bit fiddly.
} else {
use(labview);
}
}


An experienced FRC programmer using Java (and presumably any other language) can get a passable program running in a matter of hours, not days. Nevertheless, start learning and/or coding ASAP!

[basicxman]

// C++ is an option, but it's a bit fiddly.

Care to elaborate?

[Ziv]

Care to elaborate?
If I were teaching someone to program and I had a choice as to whether or not I had to explain memory management, I would choose not having to. But it's not that big of a deal. Besides, every language has its own special problems :).

[basicxman]

If I were teaching someone to program and I had a choice as to whether or not I had to explain memory management, I would choose not having to. But it's not that big of a deal. Besides, every language has its own special problems :).

Memory management is an important topic in Java, the severe memory leak in SmartDashboard this year is a perfect example.

[carrillo694]

Memory management is an important topic in Java, the severe memory leak in SmartDashboard this year is a perfect example.

For the purposes of programming a robot in only three days and not testing it until practice day, memory management probably is not their primary concern :p

cierra_shawe, what programming languages are you or those on your team familiar with? If the answer is "none," I am leaning towards recommending LabVIEW. Not because it is necessarily easier, but because its control structures seem more intuitive than the syntax that comes with Java or C++. If the answer is "some," then I would go with Java, because its WPIlib implementation seems simpler than the C++ implementation, which makes it easier to learn. But I could be wrong about that, since my team uses Java. At least you will not need to be concerned about memory management if you are unfamiliar with it, unless you are doing computer vision, which I do not recommend if you are testing your robot for the first time in a few days!

[basicxman]

If the answer is "none," I am leaning towards recommending LabVIEW. Not because it is necessarily easier, but because its control structures seem more intuitive than the syntax that comes with Java or C++.

I really think this depends on your background. LabVIEW control structures can be intimidating and non-obvious at first. The way a LabVIEW program executes is quite a bit different than a C++/Java program. If a student has a background or enjoys math or algorithms they might find C++/Java more intuitive to them. If a student has a background in electrical they might find LabVIEW more intuitive to them.

If the answer is "some," then I would go with Java, because its WPIlib implementation seems simpler than the C++ implementation, which makes it easier to learn.

I don't think this is entirely correct, the components inside the WPILib for Java and C++ are abstracted at essentially the exact same level - it's really about which ever language you're more comfortable with.

[Jared Russell]

I would argue that starting from scratch, it is easier for a student programmer to use Java (for FRC) than C++ (for FRC).

I cannot count the number of times I have been asked to help a team with C++ and seen problems like the following...


Victor myVictor(1);

myVictor->set(0.0); // Error!


Victor *myVictor = new Victor(1);

myVictor.set(0.0); // Error!


Victor *myVictor;

myVictor->set(0.0); // Error! You declared, but did not substantiate, your Victor!


void SomeFunction(Victor victor)
{
victor.set(0.0);
}

Victor *myVictor = new Victor(1);

SomeFunction(myVictor); // Error!


void SomeFunction(Victor victor)
{
victor.set(0.0);
}

Victor myVictor(1);

SomeFunction(myVictor); // Still an Error! You are making a copy of your Victor!


In Java you don't have to worry about objects on the stack vs. the heap (they are all on the heap), pass by reference vs. pass by value (always pass by value, even if your "value" is itself a reference to an object), memory leaks, C++ name mangling in compiler errors, initializing static class members outside of the class declaration, etc.

[basicxman]

I would argue that starting from scratch, it is easier for a student programmer to use Java (for FRC) than C++ (for FRC).

I cannot count the number of times I have been asked to help a team with C++ and seen problems like the following...

<snipped>

Definitely, but this all depends on the commitment and/or the amount of time the student has to learn the language they choose.

[remulasce]

<Obligatory Python pitch>

[ianonavy]

These advantages and disadvantages will differ according to your experience.

Java
Advantages

Can be programmed on Windows, Mac and Linux.
Forces good programming patterns such as object-orientation.
Simpler than C++.
No explicit memory management. You don't have to worry about handling specific memory addresses.
It's the AP Computer Science language, so if any of your students are taking that course, you don't have to learn a new language.

Disadvantages

Incomplete vision tracking APIs.
No explicit memory management. (Yes, this is both an advantage and a disadvantage.)


C++
Advantages

Executes and compiles much faster than LabVIEW.
Has complete vision tracking libraries.
Explicit memory management, so you don't ever have memory leaks if you know what you're doing.

Most popular, so more teams are likely to be able to help you at the competition.

Disadvantages

Syntax can be confusing for new programmers.
Requires a Windows PC to upload code.


LabVIEW
Advantages

Data flow is more intuitive than object-orientation in other languages.
Arguably easiest to teach among the three major supported languages.
Has access to the most NI vision libraries.
Very quick debugging tools. You can probe wires in the code while you're running it to see what the problem is very quickly.
Garbage collection means no explicit memory management.

Disadvantages

It's likely you know text-based languages already, so it could be harder to learn the data flow paradigm.
Only runs on Windows PCs.


Python
Advantages

You do NOT need to restart the cRIO to upload code, which is great for rapid development.
Uses the C++ cRIO image, so you can switch between the two if need be.
Simplest syntax of all of them. It's quite beautiful, and it's very easy to teach.
You can develop on any platform in any IDE.
Access to all of Python's fantastic modules.

Disadvantages

Depending on your IDE, a syntax error can go unnoticed, so you have to run tests that execute every line of code.
This language is not supported, so you won't get much help at the competition.


Honestly, write your programs in the language with which you are most comfortable. If you're caught between two or more, figure out which is the best for what you're trying to do. LabVIEW is much better for vision tracking than say Java, but if you need Java's higher level features, go for that.

[wireties]

There are many environments (in the real world) where C and C++ is only choice, favorite or not. For example the Linux kernel and drivers are written in C. The native API for the OS on the robot (VxWorks) is in C, all the other APIs are only a wrapper. Drivers and board support packages for VxWorks are written in C only.

I would advise a student looking to be a computer scientist that Java is a viable choice. If the student is going to be an engineer (especially in embedded systems and robotics), C/C++ is a better choice. C/C++ is not going away any time soon and C++ is not so different from Java that training in Java (which many high schools provide) is not applicable.

What are Oracle and Microsoft plans for Java? Will Java diverge? Will HTML5 and/or C# kill Java? Who knows? LabView and Python are awesome environments but not (works everywhere for everything) primary tools, they are specialized 4GL tools.

Also, (in FRC) using a language your mentor knows is a primary consideration.

HTH

[basicxman]

I would advise a student looking to be a computer scientist that Java is a viable choice.

Care to elaborate? What do you define as a computer scientist?


LabView and Python are awesome environments but not (works everywhere for everything) primary tools, they are specialized 4GL tools.

Is this a problem? FRC is a very specialized application.


Also, (in FRC) using a language your mentor knows is a primary consideration.

Seconding this.

[wireties]

Care to elaborate? What do you define as a computer scientist?


A student planning on getting a computer science degree rather than engineering or physics.


Is this a problem? FRC is a very specialized application.


I was thinking the skills from FIRST can help in college and in a career.

Both my kids learned Java from an awesome teacher at the high school and C++ on the robotics team. Neither encountered a class in college (both are EEs) where they did not already know the programming language and tools. They both won the junior design contests in college and attribute their success to FIRST experience.

HTH

[DominickC]

<Obligatory Python pitch>

Truths.

[rbmj]

These advantages and disadvantages will differ according to your experience.

Java
Advantages

Can be programmed on Windows, Mac and Linux.
Forces good programming patterns such as object-orientation.
Simpler than C++.
No explicit memory management. You don't have to worry about handling specific memory addresses.
It's the AP Computer Science language, so if any of your students are taking that course, you don't have to learn a new language.

Disadvantages

Incomplete vision tracking APIs.
No explicit memory management. (Yes, this is both an advantage and a disadvantage.)


C++
Advantages

Executes and compiles much faster than LabVIEW.
Has complete vision tracking libraries.
Explicit memory management, so you don't ever have memory leaks if you know what you're doing.

Most popular, so more teams are likely to be able to help you at the competition.

Disadvantages

Syntax can be confusing for new programmers.
Requires a Windows PC to upload code.



I can't address Java, but I do have experience with C++.

Thanks to ucpp, you no longer need a Windows PC for any part of the toolchain. If you can get a new gcc and libstdc++ (I've had issues with the cross compile for the latter :/) you don't even need to worry about memory management thanks to std::shared_ptr<T> and std::unique_ptr<T> if you don't want to.

C++ is also the anarchist's programming language. It gives you plenty of power, but also the ability to do not-so-good things with that power, and it doesn't try to stop you like Java (think pointer casts, crazy macros, abusive operator overloading, etc). In the hands of a good programmer, you can do amazing things in C++ incredibly succinctly and efficiently. In the hands of a bad programmer, C++ yields bug-ridden spaghetti code.

Lastly, you can also fall back to the raw VxWorks APIs in C++ if you want very, very easily.


LabVIEW
Advantages

Data flow is more intuitive than object-orientation in other languages.
Arguably easiest to teach among the three major supported languages.
Has access to the most NI vision libraries.
Very quick debugging tools. You can probe wires in the code while you're running it to see what the problem is very quickly.
Garbage collection means no explicit memory management.

Disadvantages

It's likely you know text-based languages already, so it could be harder to learn the data flow paradigm.
Only runs on Windows PCs.



I would say that for new programmers, LabView encourages some bad design practices. It makes it harder to define new functions (you have to make a new file, add terminals to that file, make a meaningful pixel art icon, etc. just to get a new function), the object orientation for the embedded target is incomplete (which forced us to use structs in C style OO), and those nice wires can quickly become mean when you have lots of connections and you can't tell what goes where. Yes, I'm biased :D I will say it DOES have the BEST parallel processing of any of the languages though.

Also, since it's not text based, it's not as friendly with version control.


Python
Advantages

You do NOT need to restart the cRIO to upload code, which is great for rapid development.
Uses the C++ cRIO image, so you can switch between the two if need be.
Simplest syntax of all of them. It's quite beautiful, and it's very easy to teach.
You can develop on any platform in any IDE.
Access to all of Python's fantastic modules.

Disadvantages

Depending on your IDE, a syntax error can go unnoticed, so you have to run tests that execute every line of code.
This language is not supported, so you won't get much help at the competition.


Python is an AWESOME programming language. That said, those disadvantages are two HUGE disadvantages, so tread carefully.

Honestly, write your programs in the language with which you are most comfortable. If you're caught between two or more, figure out which is the best for what you're trying to do. LabVIEW is much better for vision tracking than say Java, but if you need Java's higher level features, go for that.

+1: The biggest factor in determining which programming language to use is honestly the human factor. If the mentors and students on your team have the most experience with a given language, chances are that that's the best language to use regardless of the language's inherent strengths and weaknesses.

[abrightwell]

I agree with wireties, but I would have to argue that python deserves more credit than being a "specialized 4GL tool". Python is available on just about every platform and is increasingly becoming a must know language. Entire applications and frameworks have been built using python (Django and anything built with it is an excellent example), but it is also equally effective as a "automation" language to replace the typical unix based scripting. It is an incredibly dynamic and powerful language.

Speaking from the stand point of a software engineer/computer scientist, I agree with the statement of C/C++ or Java is better suited for those who are seeking such a degree. I also agree that they are similar enough to each other to negate any steep learning curve between the two. Java, in my opinion, is a bit easier to conceptually understand, however, as was stated it does have it's memory issues as well. It is very easy to accidentally hold on to a reference to an object thus keeping it from being garbage collected. Therefore, don't let the memory management aspect of C++ scare you away. Though, pointers tend to put the fear of God in some people.

A good computer scientist/software developer isn't going to constrain themselves to one language or even two. A healthy knowledge and proficiency in multiple languages is absolutely necessary. For instance, I use on a regular basis in my job the following languages: Java, C/C++, Python, Ruby, PHP, JavaScript, Scala, ActionScript and Objective-C. Sometimes, all in one day. :eek: They all have their pros and cons but each was selected for a very specific reason. Much like C/C++ is selected for most system level applications and Java is selected for most Web Applications. I like to look at it as layers of abstraction. At any rate, the point I want to make is that you should continue learning and exploring new languages and don't ever limit yourself.

[andreboos]

Abrightwell says it well, I think. Python is an essential language in terms of its exceptional readability and simplicity. The performance and weak typing are valid criticisms in certain situations, but it is incredibly valuable for rapid prototyping of algorithms and even large pieces of software. Django is an excellent example; I was able to create a dynamic upcoming match display for our team in a few hours, that integrates with our scouting system.

[theprgramerdude]

I would argue that starting from scratch, it is easier for a student programmer to use Java (for FRC) than C++ (for FRC).

I cannot count the number of times I have been asked to help a team with C++ and seen problems like the following...


Victor myVictor(1);

myVictor->set(0.0); // Error!


Victor *myVictor = new Victor(1);

myVictor.set(0.0); // Error!


Victor *myVictor;

myVictor->set(0.0); // Error! You declared, but did not substantiate, your Victor!


void SomeFunction(Victor victor)
{
victor.set(0.0);
}

Victor *myVictor = new Victor(1);

SomeFunction(myVictor); // Error!


void SomeFunction(Victor victor)
{
victor.set(0.0);
}

Victor myVictor(1);

SomeFunction(myVictor); // Still an Error! You are making a copy of your Victor!


In Java you don't have to worry about objects on the stack vs. the heap (they are all on the heap), pass by reference vs. pass by value (always pass by reference unless you are a built-in type), memory leaks, C++ name mangling in compiler errors, initializing static class members outside of the class declaration, etc.

Nothing is ever passed by reference in Java.

[Jared Russell]

Nothing is ever passed by reference in Java.

You are of course correct, editing the original post to avoid confusion...

[basicxman]

Also, since it's not text based, it's not as friendly with version control.

Little biased here as my team is sponsored by GitHub (http://github.com) but this is a huge con for me, version control is such a nice thing to have - especially working on a team with code that is changing constantly.

[cierra_shawe]

Thank you for all of the help!

Our programmer ended up using Labview, and so far it's working well enough :]
There are still a few minor bugs, but hopefully tomorrow we'll be able to get some assistance at the Portland regional.

Good luck everyone!

[jase728]

Honestly if you have never coded before start in Labview and use your off season to play around with c++/java

[DjScribbles]

Frankly, one overlooked piece of this argument is the students.

If you have students who are interested in Computer Science/Engineering I would recommend C++ or Java, as the experience they gain will be quite valuable for them in the future.

C++ is a more complex language (but has some advantages), if you have a student who is willing to do the research to learn the in's and out's of memory management, references, pointers, etc. then it is a great opportunity to learn coding at a deeper level.

Java, on the other hand, can take away alot of the painful hurdles that a new programmer would encounter, making it easier to get the robot up and running, and makes a better gateway language than C++.

If you have students who are interested in pursuing non-computer related engineering and science, but are still getting stuck with the programming :yikes:, then you should consider labview, as it is used much more frequently by non-programming oriented disciplines due to it's graphical nature, and ease of use.

Also take into account your mentors (if you have any that know programming), if you've got a mentor that knows any of the above, then it will take alot of the edge of learning that particular language.

[TimSchley]

Honestly if you have never coded before start in Labview and use your off season to play around with c++/java

I cannot stress enough how important I think it is to try to move from Labview to a text based language in your off season. Whether you move to java, c++, or python, it is going to be SO much more beneficial in the long run. Even if you don't go into CS, knowing how to use a text based language is so important in this world. They are so much more applicable in the real world. There is very little actual application to labview outside of robotics that a text based language would not be equivalent or better.

And honestly, learning Java is really not too difficult. There are tons and tons of tutorials out there, and using it in the scope of FIRST is a pretty easy transition. As a college freshman, I was fairly well able to teach 3 students Java from scratch, and bring one more up to date with FIRST java, within a few weeks. They now are doing all of the programming for our robot, and I couldnt be prouder of what they have accomplished in a few short weeks. Check em out at the Portland regional! Visit our pit! Team 997, Spartan Robotics.

[njg]

One additional advantage of Java for FRC (compared to C++ or LabVIEW) is installation and activation. With only the getting started guide and an internet connection all of the Java tools can be installed and then used indefinitely.

In terms of students gaining programming experience, there is also some room for a team to use multiple languages. For example, this year we programmed our robot in Java and modified the dashboard application in LabVIEW. (Java can easily send data back to a dashboard written in LabVIEW despite the lack of examples)

As a professional engineer, when I interview job candidates I evaluate their ability to work through the logic of programming and weigh that far above their claimed experiences. Granted, we sometimes look for experience with a particular language but that's often secondary since syntax is far easier to teach than good programming/reasoning skills.

[JamesBrown]

<Obligatory Python pitch>

Python may be a valid choice for some but it deserves no consideration by a team asking for advice on what language to choose two weeks after ship and only days before they compete.

Java
Advantages

Forces good programming patterns such as object-orientation.



Object-orientation is only a good design practice in object oriented languages. Lab-View can also teach good design practices.


I would advise a student looking to be a computer scientist that Java is a viable choice. If the student is going to be an engineer (especially in embedded systems and robotics), C/C++ is a better choice. C/C++ is not going away any time soon and C++ is not so different from Java that training in Java (which many high schools provide) is not applicable.


I would strongly reccomend C++ over JAVA for potential CS students. Many schools still teach all low level computer science courses in C/C++. I have both a CS degree and an Engineering degree and I only used JAVA in two classes, one was an intro to programming languages (~4 weeks on each of 4 languages) and one project based course where we could use and OO language and my group chose JAVA. There was way more focus on C/C++ than on JAVA.




I would say that for new programmers, LabView encourages some bad design practices. It makes it harder to define new functions (you have to make a new file, add terminals to that file, make a meaningful pixel art icon, etc. just to get a new function), the object orientation for the embedded target is incomplete (which forced us to use structs in C style OO), and those nice wires can quickly become mean when you have lots of connections and you can't tell what goes where. Yes, I'm biased :D I will say it DOES have the BEST parallel processing of any of the languages though..


LabView does not encourage bad design practices, you are making a huge mistake trying to attack LabView from and OO approach, it isn't an OO language so OO design patterns won't work well. Every thing you described is an example of some one who has never learned to program in LabView, you are/were just hacking through it. I have used LabView extensively I have worked on enormous projects that are monitoring pretty much everything that goes on in a Nuclear Power Plant and anyone with basic LabView experience can look at the VI and see where everything is going. It is true that Labview can get ugly if you get sloppy but that is true of any language, I would still rather dig through ugly LV code than Ugly C++/Java code.


I cannot stress enough how important I think it is to try to move from Labview to a text based language in your off season. Whether you move to java, c++, or python, it is going to be SO much more beneficial in the long run. Even if you don't go into CS, knowing how to use a text based language is so important in this world. They are so much more applicable in the real world. There is very little actual application to labview outside of robotics that a text based language would not be equivalent or better.


Seperating Labview and text based languages is a huge mistake, you should really be separating Data Flow and Object Oriented languages (more accurately Declaritive and Imperitive Languages) Data flow languages like Labview are incredibly applicable in the real world. LabView, Simulink, VHDL and Verilog are all great demand and are all Data Flow. I would highly reccomend that any one going into EE of ME learn these languages. I was hired out of school into a non-entry level position because they couldn't find any one with experience who could program in Verilog and VHDL. I have never used JAVA in a real application (I used it for one project in college), and have never used Python outside the classroom.

[wireties]

Python may be a valid choice for some but it deserves no consideration by a team asking for advice on what language to choose two weeks after ship and only days before they compete.


Jeez, I think you took the Python nod a little too seriously.


Object-orientation is only a good design practice in object oriented languages. Lab-View can also teach good design practices.


Thinking in terms of objects is good practice for any solution that lends itself to objectification. One should not try to force OO on every solution but cohesion, encapsulation, modular re-use and abstraction (fundamental goals of OO practices) are good in any programming environment.


I would strongly reccomend C++ over JAVA for potential CS students. Many schools still teach all low level computer science courses in C/C++. I have both a CS degree and an Engineering degree and I only used JAVA in two classes, one was an intro to programming languages (~4 weeks on each of 4 languages) and one project based course where we could use and OO language and my group chose JAVA. There was way more focus on C/C++ than on JAVA.


It sounds like you went to a good school but your experiences are atypical for the average CS student. Many programs have the opposite ratio of C/C++ to Java etal. I wish it were more C++ oriented myself. This is why most high schools (including all in Texas) teach Java and why the AP CS exam uses Java. Perhaps students should look into the course descriptions for universities they plan to attend.



LabView does not encourage bad design practices, you are making a huge mistake trying to attack LabView from and OO approach, it isn't an OO language so OO design patterns won't work well. Every thing you described is an example of some one who has never learned to program in LabView, you are/were just hacking through it. I have used LabView extensively I have worked on enormous projects that are monitoring pretty much everything that goes on in a Nuclear Power Plant and anyone with basic LabView experience can look at the VI and see where everything is going. It is true that Labview can get ugly if you get sloppy but that is true of any language, I would still rather dig through ugly LV code than Ugly C++/Java code.


Nobody is attacking LabView. It is a great tool for the application you describe. But I've been doing this for 30 years and have yet to encounter LabView in a resource-limited or real-time embedded system (other than the FIRST robot). It is commonly used for test environments and in industrial applications for command and control. For these purposes, in my humble opinion, LabView is a awesome environment.

Bottom line - use a language that your mentor knows! None of this academic discussion is more important than access to a hands-on teacher.

[EricVanWyk]

I should probably stay out of this, given that my paycheck comes from the LabVIEW R&D department... but I wanted to re-iterate what my co-worker Greg said the last time this thread came through: The most important language to learn is your second one.

From that perspective, I disagree with arguments based on "They will use X in the future, we should teach them X now." I'd go so far as to say we should intentionally dodge X and force them to learn their second language as soon as possible. Learning the differences between languages is an incredibly effective way to teach them the similarities between them. One of the best things I did for my understanding of computers was to take a class that taught a new language every other week.

Also, one of the most common college freshman pitfalls is the mistaken belief that they already know "the one true tool", and suddenly everything is a nail. We need to be sure they understand the importance of screws and bolts and glue before they run off with their sledgehammer.

[Chris Hibner]

I cannot stress enough how important I think it is to try to move from Labview to a text based language in your off season. Whether you move to java, c++, or python, it is going to be SO much more beneficial in the long run. Even if you don't go into CS, knowing how to use a text based language is so important in this world. They are so much more applicable in the real world. There is very little actual application to labview outside of robotics that a text based language would not be equivalent or better.

If you desire to be an embedded software engineer, text based languages will probably continue to be the standard for a little while. (For those that don't know: embedded software engineers deal with the very low-level software that interacts with the microchip's hardware. They set up the clocks, toggle the pins, read the inputs, etc.).

If you desire to design and implement control algorithms, text based languages are rapidly becoming extinct. In the last three years, I haven't done a single line of text-based code for a control algorithm (I've done text code on the embedded side, though). Where I work, all of our embedded algorithm work is done in Simulink, which is data flow based much like LabVIEW. For our test systems, everything is LabVIEW.

My point is, don't go running away from data flow programming since you think they aren't used in the real world. Far from it - they're becoming the standard in many areas. It's just that there's always the right tool for the given job.

[artdutra04]

What are Oracle and Microsoft plans for Java? Will Java diverge? Will HTML5 and/or C# kill Java? Who knows? LabView and Python are awesome environments but not (works everywhere for everything) primary tools, they are specialized 4GL tools.I seriously doubt that HTML5 alone would "kill" Java. HTML5 is the equivalent of the Java Swing toolkit.

[wireties]

I seriously doubt that HTML5 alone would "kill" Java. HTML5 is the equivalent of the Java Swing toolkit.

... didn't say that it would, I said "Who knows?". A simple google about the future of Java yields opinions all over the map. At a minimum it looks like the JCP is dying and the open source folks are not happy with Oracle.

[Waltonruler5]

Our programmer from last year had to move, and our programmer from two years ago couldn't be here to mentor often, so we were in a hard place. I was team leader but I was put in charge of this as well. I was kinda quickly intimidated by labview so I decided to give Java a go.

I was scared out of my mind at first but once I found BradAMiller's videos, I set up a command based program really quick and it worked pretty flawlessly. Now I didn't set up anything too complicated and I really only spent like 10 minutes on our autonomous control, which I could've cut down to 2 if I knew how to time a command at first. I even got an efficient SmartDashboard set up. My only problem was some limit switches that I couldn't get to work, but I think it was an electrical issue anyways :P.

Now that the competition is over, I really want to take time to learn LabView before I graduate so I have some kind of into to data flow languages, but this thread has really gotten me interested in Python. I might just reprogram our robot for each language in the next few months. I graduate this year, so I want to make sure the next programmers are comfortable in whatever languages they may want to use.

[Sconrad]

If you have students who are interested in Computer Science/Engineering I would recommend C++ or Java, as the experience they gain will be quite valuable for them in the future.

I definitely see the value in the experience C++ or Java programming affords, but I just want to throw out a counter argument in favor of LabVIEW. While it is not as commonly used in the field as many text-based languages, knowing LabVIEW can help a lot in a job search. FRC is one of the few places where people have an opportunity to learn the language without learning on the job, so there is a lower supply of LabVIEW programmers, but there is a growing demand. Personally, I know they use LabVIEW in the US Navy for almost all sensor management, on surface boats and submarines. Companies in the private sector also use LabVIEW (Measurement Specialties comes to mind). While it is non-traditional, LabVIEW can be helpful in the Computer Science/Engineering fields. Just figured I'd throw that point out there. :D

[seg9585]

No love for LabView on this forum.

Being involved with FRC since 2001, I've had the opportunity to program in PBASIC, C, Java, and LabView.

As a mentor, I think it's fun to learn something new myself when it comes to programming languages, and before this year I hadn't worked with LabView too much, but my industry (Aerospace) does make good use of this and similar data flow languages. Working with a rookie team where the students had zero programming experience, I thought it would be educational on my part to learn a new "language" along with them.
I actually really enjoyed programming in LabView this year, it felt very different from typical scripting and I found the debugging features very convenient (despite the long compile times). It made me think differently about how to apply my desired logic

I would recommend trying a language you are not as comfortable with, to gain experience. I challenge team programmers to spend their 4 years in high school using a different language each year.

[shawnz]

We decided to use labview since it felt most like the "native" language of the platform (even though we had some java programmers on our team already). It turns out that labview has a few huge advantages:

- Concurrency/Parallelism -- Just make a branch in a wire, and labview will magically figure out how everything needs to be threaded and synchronized to make it happen.

- Debugging -- Because you necessarily have wires that can be probed in between every "function call", it's always relatively easy to pinpoint the places where the problems are.

However, there are lots of disadvantages too.

- Unfamiliarity -- People are not likely to come onboard knowing labview, and they're not likely to use labview again after FRC (if they intend to go into compsci, anyway)

- Bad for teamwork -- labview doesn't really lend itself to creating strict definitions or interfaces for things, so when new modules are being integrated, it usually ends up being the responsibility of the module author to make sense of the parent code it's going into. Also, what with source files that are binary, it doesn't lend itself to version control either (although we've done it anyway, and it isn't too painful)

[blackflame2996]

if(youKnowAnyLanguage) {
use(theLanguageYouKnow);
} else {
read(WPILibCookbook (http://firstforge.wpi.edu/sf/go/doc1297));
if(youUnderstoodAnyOfThat) {
use(java); // C++ is an option, but it's a bit fiddly.
} else {
use(labview);
}
}


An experienced FRC programmer using Java (and presumably any other language) can get a passable program running in a matter of hours, not days. Nevertheless, start learning and/or coding ASAP!

nice.

[rbmj]

LabView does not encourage bad design practices, you are making a huge mistake trying to attack LabView from and OO approach, it isn't an OO language so OO design patterns won't work well. Every thing you described is an example of some one who has never learned to program in LabView, you are/were just hacking through it. I have used LabView extensively I have worked on enormous projects that are monitoring pretty much everything that goes on in a Nuclear Power Plant and anyone with basic LabView experience can look at the VI and see where everything is going. It is true that Labview can get ugly if you get sloppy but that is true of any language, I would still rather dig through ugly LV code than Ugly C++/Java code.


It does. It is possible to write good LabVIEW code, and you should. But it takes more effort, and I've seen lazy programmers write horid LabVIEW code in the past. No, it is not LabVIEW's fault that lazy programmers wrote bad code - it is the programmer's fault. But that doesn't mean that the design of the language (requiring a new file for each function, requiring the user to make a unique pixel art image make a function recognizable in source code, etc) should make it *harder* to write good code. A good language should get out of the programmer's way (I admit I am coming from a C++ background and have a bit of "cultural bias") and allow them to write the best code they can with as little extra effort as possible. Object Orientation is a good design pattern for many complex problems. Is it overused? Yes. People will always have their golden hammers.

Also, many of the people who will be programming in FRC will not know LabVIEW/will be "hacking through it". It took me a little over a year to write *tolerable* LabVIEW code. Yes, it was worth the effort as it changed the way I look some programming problems. LabVIEW (and declarative languages in general) are much, much better at expressing parallel computation, and this is their strength. LabVIEW also has an excellent debugger (when it works - for some reason ours stopped working at competition last year). But the fact that LabVIEW is graphical in my view disqualifies it from use, as there are no open-source and widely-used version control systems that can handle it. Yes, I know that there are some proprietary version control systems for LabVIEW, but AFAIK they are not available to FRC teams without payment and are not widely used enough to . Git can handle binary files, but I pity the person who has to handle a merge conflict on a set of VIs.

I agree people who come for an imperative background should learn a declarative language. Haskell blew my mind when I groked it.

And though academic discussion about languages is fun, which language you use is (or at least should) come down to the experience of a team's mentors and older students. No use in teaching newbies something when the teachers don't even know what they're teaching. That just encourages everyone to write bad code, in whatever language you choose.

[JamesBrown]

But that doesn't mean that the design of the language (requiring a new file for each function, requiring the user to make a unique pixel art image make a function recognizable in source code, etc)

It really isn't that hard, select the section of block diagram you want to create a VI for, click edit then create VI and there it is.

Do you actually create a pixel art image? Every company I have done Labview programming for used the function name text as the icon standard. That doesnt take any longer to create than typing a function name in any text based language does. Infact I would say it is faster to create a sub VI than it is to create a function since you dont have to worry about what your passing to and from the function, LV handles that for you.

I understand that the majority of new programmers in FIRST are not going to know Labview, however they aren't going to know JAVA or C++ either and I am positive that they could learn good LabView practices faster than they can learn good Object Oriented coding practices. If they don't have a mentor to teach them then I would strongly push them towards LabView and their video series.

[Greg McKaskle]

All of the languages being discussed are worth learning. All will work, will work well, and there are many ways to make your choice. I don't think the point of this thread is to argue which language everyone should use, but to discuss experiences of teams using a particular language, ways to adopt a language successfully, ways to take advantage of the programming opportunities FIRST offers, etc.

Just to add a few additional things.

While FIRST is a great opportunity to learn a language, to me, it is also an opportunity to learn how to program a complex system -- a robot. The language chosen is not nearly as important as learning how to identify what is causing a certain robot symptom and determine how a code change will modify it. Patterns for managing CPU and other resource usage, debugging a running system, logging data in order to analyze and debug the system later, and many more topics that are equally important to programming.

Regarding SCC, this is indeed a more complicated topic for binary files than ASCII, but it is used with LV every day. LV code is used for general research, FDA, and military apps. For more info on setting up SCC, you can search for it, or perhaps read through the comments on this (http://labviewwiki.org/Subversion) site. The site contains plenty of other good articles written by LV professionals. The Tools menu contains a rather powerful Compare and Merge tool that can be used individually or from other tool UIs. To embed the SCC tool into the LV workflow, there are fewer choices, typically those used by industry.

One post also implied that C++ was the most popular language used within the FIRST competition and would therefore have the best support. The data gathered by NI doesn't back that up. The three official languages are all in common use, and almost every regional we've seen has had a diversity of languages and teams that are able to assist when needed.

Greg McKaskle

[charlie.drummer]

Our team has never used LabView, so I cannot say anything for or against it, but I think it has been much easier to learn and teach Java. It is very similar to C++, but lacks a few things such as memory management and pointers. But when learning to program it is easier to get the basic concepts down in Java, then come to C++ and take away some of the levels of abstraction that Java gives.

Personally, when I first began to learn how to program, I tried learning C++, felt overwhelmed, learned Java, came back to C++ and understood the basic concepts, but easily picked up on things like pointers, that are not included in Java. I think it is much easier to teach Java from the start, especially when it comes to OOP. In Java everything is in a class, so when you start making your own classes, it isn't so foreign.