View Full Version : Preferred Programming Language
Our team is trying to decide what language to program our robot with. We are a new team and started last year with LabView, but we have all new team members and thought we should figure out what will be most beneficial in the future for the students - like when they get out in the real world and want to use the programming skills they learn in FIRST. Would love to hear other's opinions of what we should teach the team that will help the team now, and keep helping them after their FIRST experience.
EDesbiens
04-11-2015, 22:21
Our team is trying to decide what language to program our robot with. We are a new team and started last year with LabView, but we have all new team members and thought we should figure out what will be most beneficial in the future for the students - like when they get out in the real world and want to use the programming skills they learn in FIRST. Would love to hear other's opinions of what we should teach the team that will help the team now, and keep helping them after their FIRST experience.
In my opinion, Java is the most useful for the real world... But, I think that Labview is a very good choice since you can learn it very fast and that almost anyone, even without experience, can understand and debug your code (true story :) )...
Jacob Bendicksen
04-11-2015, 22:25
I think the usual answer is 'whatever language you know best/can learn most easily,' and this holds true here. We've had a lot of success with Java, but it's really more about how well the programmers know the language rather than the language itself.
virtuald
04-11-2015, 23:43
Yes, there are many threads on this topic in CD. And the answer is always the same: python. :p
Thad House
05-11-2015, 00:02
Yes, there are many threads on this topic in CD. And the answer is always the same: python. :p
Nah. Visual Basic is the obvious choice :D
In all seriousness, what do your mentors know? If you have a mentor that has a good amount of experience in one of the languages, I would highly recommend picking that one. If you don't have any programming mentors, I would personally recommend keeping LabVIEW, and it is usually the easiest to teach and debug in the time you have.
Instead of the whole "do what you know", I'm going to try and answer this objectively. After all, some people are just looking to expand their knowledge -- nothing wrong with that :P
C++: Fast, efficient, but a bit of a steep learning curve for those who are new. Doesn't offer as much freedom as other platforms like the JVM, but is a good language for those who don't mind the extra work
Java: Semi-fast, not very efficient, but provides a good tradeoff with the amount of freedom the JVM gives you. Although the JVM eats up RAM like there's no tomorrow, there's no denying it's easy to prototype for and is quite nice for any skill level. You also get a lot of freedom with the language you choose, as Scala, Groovy and Clojure all fit under this umbrella.
Python: Although unofficial, the Python support for FRC is first-class. Testability, wonderful documentation and easy prototyping make it the language of choice for many. The syntax is easy to pick up for new programmers, but remains a powerful tool, although less speedy than the JVM and C++ alternatives.
LabView: Probably the most controversial language in FRC. Some love it, some hate it, and some don't even consider it a language. Although it's visual based, it runs quite well on the RoboRIO thanks to National Instruments. Doesn't give you the same degree of freedom as other languages, but a nice alternative for those who aren't quite ready to learn a full language, and who learn better visually.
Hopefully that list explains (almost) everything. If you want my personal, subjective opinion, I've taken a liking to using multiple languages. Java for control structure, Scala for dealing with data.
EDesbiens
05-11-2015, 07:14
LabView: Probably the most controversial language in FRC. Some love it, some hate it, and some don't even consider it a language. Although it's visual based, it runs quite well on the RoboRIO thanks to National Instruments. Doesn't give you the same degree of freedom as other languages, but a nice alternative for those who aren't quite ready to learn a full language, and who learn better visually.
Add that creating a nice visual driver station is really easy!
jgrindle
05-11-2015, 07:21
My two top languages would be Java or C++. Java has a lot more resource to find on it, so it makes it a much easier learning curve. C++ on the other hand doesn't have as much resources on it, but it can be very similar to java. I think the bigger thing is, is how much time do you have to learn. If you have little time, I would suggest going with Java. If you have a lot of time, I would try C++ by following the examples. Overall I'd say Java is the better language for beginning teams.
John
If you are looking for a language that is commonly taught in schools and would be easier to find a mentor who knows, you should probably stick with Java.
If you do not anticipate finding a programming mentor, I would stick with LabVIEW. It is (in my opinion) by far the easiest language to be bad at and still end up with a working robot. And once you get good at it (which doesn't take very long), you can do all of the same level stuff as you can with Java. I entered FRC with very little programming knowledge. My first year as head programmer, using LabVIEW, we barely had a driving robot. by my second year, still with LabVIEW, we were able to do PID control, path planning, etc. (Note: this was on out test bot, not on our competition bot)
tl;dr I would highly recommend LabVIEW for any rookie head programmer without a programming mentor or knowledge of another language
Greg McKaskle
05-11-2015, 09:42
Some love it, some hate it, and some don't even consider it a language.
This could also be written as ..
Some love it, some hate it, and some don't quite get the definition of a computer language.
But the advice from all who have posted is on point.
My 2 cents. Discuss it with a mentor. Develop a plan. Enjoy the opportunity to learn something new.
Greg McKaskle
My 2 cents, plenty of teams on here will be able to help you with java/c++. I personally would love to mentor a team If you decide to use java.
EDesbiens
05-11-2015, 10:54
My 2 cents, plenty of teams on here will be able to help you with java/c++. I personally would love to mentor a team If you decide to use java.
Same about labview... And I can do it in french!
jkelleyrtp
05-11-2015, 11:08
We have a bad history for long deploy and build times with Labview... What is a better language for quickly changing and using code?
EDesbiens
05-11-2015, 11:12
We have a bad history for long deploy and build times with Labview... What is a better language for quickly changing and using code?
Labview is simply the slowest... Pick any other code supported by FIRST and you'll see a very big improvement of the time used to deploy and build...
Hsifeulbhsifder
05-11-2015, 12:50
Our team has used both Java and C++, what we found is that Java is great if you don't care about optimizations and stuff that goes on lower level. Java is good if you want to create code quickly but have the code run slowly. When we switched to c++, we had a LOT more work to do but the code is much better when it comes to speed, memory management, and overall control. Java's JVM benefits are irrelevant in this scenario because you are programming for one target. Java allowed us to write bad code really fast and create a buggy, slow, but working robot. C++ allowed us to write really optimized code slowly which runs very quickly and has more functionality. There are somethings we could do with C++ that we couldn't do with Java, such as dynamically loading the code so that we can make changes to the code on the fly without restarting the robot. C++ also allows us to interface directly to the OS as well, so memory management is great. The performance benefit C++ gave us also allowed us to run a separate thread at 200Hz that uses machine learning. However, java is easier to learn for sure.
C++:
Pros:
-Fast
-Control
-More functionality
-Native
-Multi-paradigm
-Good memory management if you are careful
-Not as limiting as java
-Easy interfacing to OS
Cons:
-Hard to learn
-Easy to mess up badly
-Terrible memory management if you are not careful
Java:
Pros:
-Easy for beginners to learn
-Hard to mess up terribly
-Safe
-Garbage Collection
Cons:
-Forced Object Oriented Programming
-Exceptions
-Slow
-No control over memory allocation and deallocation
-Limiting to the programmer
-Forced Garbage Collection
-Sometimes too safe
TLDR: If you are not that experienced, use Java. If you care about lower level control and optimization, use C++
If you want to pick a language that is going to help you in the real world. It doesn't matter. By the time you get there they will have all changed. :ahh: They all have uses & chances are you will have to learn multiple languages in your programming career. Work on developing logic behind the program. Developing good work habits such as organization and documentation. Learn how to communicate with people. Programming is really a means to an end. Work to understand the end. Programming languages is more about syntax than anything else.
BTW I hear NASA is looking for a few good FORTRAN programmers (http://www.theregister.co.uk/2015/10/31/brush_up_on_your_fortran/) for a project that is literally at the edge of the solar system.
Ben Martin
05-11-2015, 15:12
From a purely competitive/functional point of view, I'd go with Java for two reasons:
- It seems that more top teams publicly release code in Java than in other languages (purely based on observation of CD, I have no data for this)
- The build and deploy times are quick enough that you can change and deploy code if you're crunched for time on the field
Rangel(kf7fdb)
05-11-2015, 15:37
I would go with Java or C++. Although the popular languages industries use will change over time, these two are likely to be around for many years to come. Knowing these languages could also help short term in securing internships whether in college or high school.
MamaSpoldi
05-11-2015, 15:53
There is lots of good information being offered on this thread. I will add that our team uses C++ both because our programming mentor (me) has expertise in C++. But I also chose C++ because it is very similar syntactically to Java but gives the programming a few more tricks and improved run-time performance. The other key element to the decision was that many high schools teach Java (often since the AP Programming test is in Java). C++ is not a huge leap from Java so it is a great opportunity to help these students take that next step and learn another language.
I would also offer this link (http://iel.ucdavis.edu/publication/WhyC.html) to a paper from a few years back that provides some insight into what languages are used in industry.
Alan Anderson
05-11-2015, 16:21
For students who are already "into" programming, Java is probably the most reasonable option for FRC. For students who are just getting into it, LabVIEW is by far
the easiest to start with
the best for having multiple people looking at the code simultaneously
the fastest for implementing parallel tasks
(all in my opinion, of course).
The important thing to keep in mind is that whatever they learn now very likely won't be what they use in the "real world". With that as a guiding principle, I would suggest choosing something unlike what they already might know, on the theory that it's always good to have multiple viewpoints when approaching a task.
EDesbiens
05-11-2015, 16:28
The important thing to keep in mind is that whatever they learn now very likely won't be what they use in the "real world". With that as a guiding principle, I would suggest choosing something unlike what they already might know, on the theory that it's always good to have multiple viewpoints when approaching a task.
I like that point :) It makes me want to switch to C++... But do I have the time? :)
Hsifeulbhsifder
05-11-2015, 18:47
Also our deploy times for Java were roughly 30 seconds vs C++ which was under 2 seconds without disabling the robot.
I'm just going to bump in for a little bit (again)
A lot of the responses on this thread are claiming that Java and C++ are very similar languages. I can't say I necessarily agree.
Although, yes, Java and C++ share some syntactical similarities, the way the languages work can be completely different. If you learn Java, you shouldn't try to program in C++ 'The Java Way', because that leads to issues and inefficiencies. Take pointers for example. In C++, your life revolves around them. In Java, your life also revolves around them. But the key difference is that in C++ you have to handle it on your own, while in Java just about every little bit of data you deal with is a pointer. This leads to issues if you go in with the mindset "these two languages are pretty much the same", because they're not.
If you want to find a language to use on your Robot, look at the pros and cons behind each, and decide what YOU want to learn and use, there's no wrong answer. But please, don't leave it up to "Learn C++ if you have the time, otherwise fall back to Java", because they're not the same language, they just happen to share a fairly common Syntax. Each language has its own advantages and disadvantages, and it's not as easy as "C++ is more hardcore", because I can promise you that although Java presents a friendly face, there's a lot of more you can do with it if you're willing to put in the time.
</rant>
This thread kinda makes me want to learn c++ now. Last year i was playing around with opencv and ended up getting a pretty cool vision system running and operable but opencv isnt created for java. so i used python in the hopes it would work better(on a co-processor). I never ended up getting the co-processor working but hopefully this year brings better changes.
All depends on your teams previous experience, my team has used tabview for the past few years, the pros is that it is easier to get pid loops up and running and that vision processing is easier (maybe?) but the cons is that find it harder to read and there is a bit of a learning curve, and the fact that virtually nobody learns it before first and will virtually never be used in the outside world ,
pros to java is that everybody already knows it, so no learning curve, global classes (aka "subsystems") are easier to use, most of the better teams use it, and it is easier to read, cons are that vision processing is fairly hard
Here's my opinion:
I love LabVIEW. I learned it by mentoring FRC and have used it at NASA for data acquisition. It also made some college lab and project stuff a bit easier to accomplish. It's a great language to learn for robotics and if you get the right job, you will definitely be using it. Big companies use it besides NASA.
C++ is my second favorite. C and C++ are very powerful languages that are used from small, low powered, embedded applications (robotics), to very high-powered supercomputers. It's probably the most difficult language to learn, but also the most versatile language to choose from.
Java hasn't been useful in my experience in electrical and computer engineering. I learned Java for my database class, but haven't had a need to use it since then. If you're into web development or Android development, then it'll be useful. Embedded... yea... it'll run on microprocessors, but not as common to see as C++.
Python is the most significant upcoming language. Since I got to college in 2008, it seems its use has exploded. I dabble in Python more than any other language right now. It was shoved down my throat in the past few years of college and I use it everyday now. It's not officially supported by FIRST, but I bet it will very soon. It's also pretty easy to learn for the first time (harder to learn when you're taught C++ because you keep trying to do things the hard way).
MATLAB and Simulink are also very useful collegiate and lab based software solutions... but NI and Mathworks aren't the best of friends (competing products). I used a ton of Simulink in graduate school and I know NASA used it quite a bit for modeling and data processing.
MamaSpoldi
06-11-2015, 10:34
I'm just going to bump in for a little bit (again)
A lot of the responses on this thread are claiming that Java and C++ are very similar languages. I can't say I necessarily agree.
Although, yes, Java and C++ share some syntactical similarities, the way the languages work can be completely different. If you learn Java, you shouldn't try to program in C++ 'The Java Way', because that leads to issues and inefficiencies. Take pointers for example. In C++, your life revolves around them. In Java, your life also revolves around them. But the key difference is that in C++ you have to handle it on your own, while in Java just about every little bit of data you deal with is a pointer. This leads to issues if you go in with the mindset "these two languages are pretty much the same", because they're not.
If you want to find a language to use on your Robot, look at the pros and cons behind each, and decide what YOU want to learn and use, there's no wrong answer. But please, don't leave it up to "Learn C++ if you have the time, otherwise fall back to Java", because they're not the same language, they just happen to share a fairly common Syntax. Each language has its own advantages and disadvantages, and it's not as easy as "C++ is more hardcore", because I can promise you that although Java presents a friendly face, there's a lot of more you can do with it if you're willing to put in the time.
</rant>
Sorry but I differ with you on some points here. Syntactically C++ is a superset of Java... you could almost say that if you put C and Java it gives you an approximation of C++.
However, I would agree that Java has different conventions that are followed for coding standards and there are differences in the "default behaviors" of the code between C++ and Java as well. For example, C++ uses a "call by value" interface and Java uses "call by reference", meaning that one (C++) requires the use of pointers to allow a function to modify a value passed in and the other (Java) always implicitly passes a pointer (which can also be termed a "reference") and therefore any changes made to a parameter value inside a function modify persist after the function returns.
My point is that if you understand the underlying assumptions (which are always important regardless of the language you are using) in C++ and Java, you are likely to see them as much more similar than they are different. And the advantage of learning them both is that it provides you with perspective on the trade-offs of their variations in programming style.
cons is that find it harder to read and there is a bit of a learning curve, and the fact that virtually nobody learns it before first and will virtually never be used in the outside world
In the past three months, I've seen LabVIEW and NI hardware used on a series of fiber optic connector inspection systems, a gasket inspection system, a medical device testing system, and a robotics lab at MIT. LabVIEW's vision toolkit is incredibly powerful, and is simply the best when it comes to extremely high accuracy 3D imaging needed in inspection systems. It's used in the robotics lab over matlab/simulink simply because the hardware support/debugging tools are superior.
If you major in computer science, you'll be very familiar with text based object oriented languages, but the large majority of CS majors (at least the ones at my school) will never have done any significant work in LabVIEW. I know people who have been offered paid internships that led to jobs just because they were familiar with LabVIEW and most other applicants weren't.
MrRoboSteve
06-11-2015, 17:40
All of the officially supported languages, and Python, have real world applications.
Nearly every robot could be programmed in all four languages.
The three officially supported languages have the best support network -- for example, there are often CSAs at events that know the languages. With Python, you'll need to be more self-sufficient. Not a stopper for teams with depth in this area.
The best language is the one that your mentors know.
All depends on your teams previous experience, my team has used tabview for the past few years, the pros is that it is easier to get pid loops up and running and that vision processing is easier (maybe?) but the cons is that find it harder to read and there is a bit of a learning curve, and the fact that virtually nobody learns it before first and will virtually never be used in the outside world ,
pros to java is that everybody already knows it, so no learning curve, global classes (aka "subsystems") are easier to use, most of the better teams use it, and it is easier to read, cons are that vision processing is fairly hard
I saw some job openings at SpaceX where they listed LabVIEW as a required skill. One of their representatives at their company booth at worlds also told me that They use it extensively for for testing and their custom control system.
SoftwareBug2.0
06-11-2015, 21:48
I saw some job openings at SpaceX where they listed LabVIEW as a required skill. One of their representatives at their company booth at worlds also told me that They use it extensively for for testing and their custom control system.
Here's a recommendation from SpaceX about what languages to learn: https://www.reddit.com/r/IAmA/comments/1853ap/we_are_spacex_software_engineers_we_launch/c8boafz
MrTimKlein
12-03-2016, 08:49
We have a bad history for long deploy and build times with Labview... What is a better language for quickly changing and using code?
To respond to this direct question - Python.
Last year our lead programmer was more or less on his own so he used robotpy. In one practice session, we were tuning the control/drive system. He ssh'd into the robot and pushed edited files onto the robot as the robot was driving! Python dynamically accepts the new code on the fly.
Driver: Programmer, the ramp time for acceleration is too slow.
Programmer: hmmm... ok
D: Can you fix it?
P: I just did.
D: Oh yeah, that's great.
Notes:
1. This year, we have a lot of rookie programmers, so we're using Java because that fits the AP Programming classes some are taking.
2. RobotPy is improving. Last year it was awesome as a prototyping language, but it was hard to maintain the discipline to keep the code well organized for a team effort.
Driver: Programmer, the ramp time for acceleration is too slow.
Programmer: hmmm... ok
D: Can you fix it?
P: I just did.
D: Oh yeah, that's great.
Is that really a good example?
Can't you do pretty much the same thing in any language, including LabVIEW? Just keep all your constants in a configuration file that your code reads at start-up, or whenever the driver presses a designated button.
virtuald
12-03-2016, 21:01
Is that really a good example?
Can't you do pretty much the same thing in any language, including LabVIEW? Just keep all your constants in a configuration file that your code reads at start-up, or whenever the driver presses a designated button.
That takes a bit more effort to setup, and isn't quite as flexible.
I think for small programs/changes, deploy times in Java are comparable to python deploy times on the RoboRIO, so it's not a huge advantage like it used to be on a cRio.
However, the one place that RobotPy excels in that C++/Java don't currently match is off-robot testing + low fidelity simulation support. I can verify with the simulator that many types of code changes are going to work *without a robot* much faster than Java/C++ teams can (though, there are some non-FRC projects that are getting closer to that now).
I've heard LabVIEW has some off-robot testing support, but I don't know anything about it.
axiomofdarkness
12-03-2016, 21:13
Sorry but I differ with you on some points here. Syntactically C++ is a superset of Java... you could almost say that if you put C and Java it gives you an approximation of C++.
However, I would agree that Java has different conventions that are followed for coding standards and there are differences in the "default behaviors" of the code between C++ and Java as well. For example, C++ uses a "call by value" interface and Java uses "call by reference", meaning that one (C++) requires the use of pointers to allow a function to modify a value passed in and the other (Java) always implicitly passes a pointer (which can also be termed a "reference") and therefore any changes made to a parameter value inside a function modify persist after the function returns.
My point is that if you understand the underlying assumptions (which are always important regardless of the language you are using) in C++ and Java, you are likely to see them as much more similar than they are different. And the advantage of learning them both is that it provides you with perspective on the trade-offs of their variations in programming style.
Just a note: Java actually only supports passing by value, while C++ actually supports both passing by value and passing by reference.
That takes a bit more effort to setup, and isn't quite as flexible.
True, but somewhat off-topic.
The narrow point being made was that the implicit implication of the given example (to wit, that similar functionality is not available in any form when using LabVIEW) is not persuasive.
True, but somewhat off-topic.
The narrow point being made was that the implicit implication of the given example (to wit, that similar functionality is not available in any form when using LabVIEW) is not persuasive.
To a certain degree. I do concur with your sediments that it is not only manageable but efficient to store a deal of information in a config file but the question becomes this- how much data is in the config file? Let's say that instead of asking for the ramp rate to be changed, you are asked to change what the controls are, a sequence in auton, exponential factor on the controls, etc. and if you end up making your entire robot via config file you end up just becoming an interpreted language, a la Python.
My actual opinion on the topic is to go with whatever a mentor or the student knows, but I just do not believe that maintaining the same speed that you have in Python with Labview is unrealistic.
Greg McKaskle
13-03-2016, 13:07
If you are going to tune a PID, you likely don't know the values when you write the code. But many will write the code with constants/guesses, build, deploy, test, and repeat many times. A better approach is to run the code in the debugger, using the run button, to get the code into memory, run, test, abort, edit, repeat. Better still is to recognize that these aren't constants, not yet anyway, but unknown values that you need to discover. So use network table variables or front panel values instead of constants. This lets you tweak values with no file compilation, file download, or interruption. Once finished, you can change the code to use constants, or make the values be default.
This also works with vision, by the way. The vision example runs on the laptop with file images. Tweaking color cutoffs and limits doesn't require code changes at all. Inserting code to try something new is just a few seconds and you are up and going again. Code running on the roboRIO works the same -- you can tweak panel values very easily. Changing code is quick once you are in the debugger. Ditto for making changes so you can see what is happening when code runs. Prints or displays or charts of values help you understand how the code works and allow you to test it more thoroughly. LV panels are particularly good at this, but network tables is quite nice as well.
And yes, interpreted languages can be even faster once you learn how to take advantage of them, but be careful about state data in already allocated objects.
The key is to learn how to use the tools. And use whatever works for you. And if you only know how to use a hammer, ...
I see teams using all of the languages well, and I see cases with each of them where the user is still making mistakes -- and learning. FRC is a good place to do this and to learn how to do this in a productive manner.
And yes, you can easily do config files and dynamic plug-ins in LV or C++ or Java if you know that you need this.
Greg McKaskle
Just a note: Java actually only supports passing by value, while C++ actually supports both passing by value and passing by reference.
Correct about C++. Java objects are always passed by reference. AFAIK, java primitives are always passed by value.
jkoritzinsky
13-03-2016, 21:15
Correct about C++. Java objects are always passed by reference. AFAIK, java primitives are always passed by value.
Java passes references by value for objects. Java primitives are passed by value. Subtle difference, but it can matter sometimes.
IMO, Java is the language for FRC if what matters most to you is competitiveness. The main problem with C++ is that the freedom it affords you comes with many language specific nuances (e.g. undefined behavior) that you simply don't want to be debugging. Additionally, this added freedom isn't very useful in robot code (especially because the FRC libraries are identical between languages). From a simple cost/benefit analyses C++ introduces more potential for bugs and introduces little or no competitive advantage in FRC (the performance difference tends to be negligible). A relevant adage I once heard goes something like "bad Java code should refactored and fixed in a good IDE, bad C++ code should be burned".
virtuald
13-03-2016, 22:19
IMO, Java is the language for FRC if what matters most to you is competitiveness.
BS. A skilled practitioner can be competitive with ANY language in FRC, without regards to the mechanics of the robot. Whether it's easy to do or not, is a separate question.
BS. A skilled practitioner can be competitive with ANY language in FRC, without regards to the mechanics of the robot. Whether it's easy to do or not, is a separate question.
I agree. I actually vastly prefer C++ over Java in most circumstances. The tidbit with FRC is that you're rarely dealing with just skilled practitioners. The flexibility to use robot code written by a novice without worrying that a syntax error will cause a heap corruption that you'll spend 2 hours debugging is pretty significant in my experience.
wt200999
13-03-2016, 23:17
The flexibility to use robot code written by a novice without worrying that a syntax error will cause a heap corruption that you'll spend 2 hours debugging is pretty significant in my experience.
Sounds like a great reason to use LabVIEW!
Guys, all we're doing now is discussing edge cases that can affect a programmers experience. To any outside observers viewing this thread, we're just confusing them more.
The answer isn't as simple as "in 0.1% of cases, this will happen in X language, so therefore, you MUST use Y language". The answer to the question "which language should I use" isn't black and white. Each language has its own pros and cons, and where it fits in in the grand scheme of thing. If they didn't, we wouldn't have thousands of different languages in existence today.
Referring back to OP, they want to know what language will prepare you for the real world, not which language is easiest to learn. You don't do FRC because it's easy to learn, it's hard to learn, hence "Hard Fun". If you want to be good at something, it will take hard work. If you want to be prepared for the industry, it takes hard work.
Let's try not to deviate from the question and answer what the OP wants to know, and hopefully, the reason most of you are here - what will prepare you for the future industry?
jkoritzinsky
13-03-2016, 23:53
Guys, all we're doing now is discussing edge cases that can affect a programmers experience. To any outside observers viewing this thread, we're just confusing them more.
The answer isn't as simple as "in 0.1% of cases, this will happen in X language, so therefore, you MUST use Y language". The answer to the question "which language should I use" isn't black and white. Each language has its own pros and cons, and where it fits in in the grand scheme of thing. If they didn't, we wouldn't have thousands of different languages in existence today.
Referring back to OP, they want to know what language will prepare you for the real world, not which language is easiest to learn. You don't do FRC because it's easy to learn, it's hard to learn, hence "Hard Fun". If you want to be good at something, it will take hard work. If you want to be prepared for the industry, it takes hard work.
Let's try not to deviate from the question and answer what the OP wants to know, and hopefully, the reason most of you are here - what will prepare you for the future industry?
From my limited experience, here's what I've realized about each language. I am probably wrong somewhere in here, so please correct me if I am.
LabVIEW: Industrial hardware. Primarily used in (non-SW or borderline non-SW) engineering roles. As a SW person, it has the least utility (in terms of usage in SW roles).
C++: High performance, high throughput computing. Used in low level (firmware), low latency (market trading, game dev), large calculation (ex. CAD, High throughput computing, supercomputers), and other projects that require the strength of C++. Also used in many other scenarios such as general business applications (usually "legacy" projects at this point), and mobile apps (cross platform ironically enough).
Java: General business applications, "enterprisiey" systems, web-backend code (sometimes), Android.
C#/.NET: Similar to Java, but more web-backend and lacks Android (w/o Xamarin tools). Some game dev with Unity engine.
Python: General business apps, utility scripts, some large calculation (with numpy), web-backend code.
There are many other categories I haven't covered, but this is a general idea. Basically, everything but LabVIEW will be great experience for a wide variety of programming careers. Of the current languages, C++ is the only one that will get you into the embedded firmware, high throughput computing scene, but Python is making some gains in some of the C++ space (not much in the real time systems or top tier game dev though).
ProfessorAlekM
14-03-2016, 08:12
I would recommend trying python first, since it is the easiest language to learn and use (Plus it's waay easier to do networking in if you want to use a co-processor for openCV).
My next recommendation would be C++. The reason why most people tend to go for java over C is because java tends to be more simplified than C. However because of the WPIlibs libraries it is just as easy to use java as it is to use C. C is easier to use for networking that java (Surprisingly).
Hitchhiker 42
14-03-2016, 08:38
LabVIEW. Why? If your team is small, like ours, and has only 2 or 3 programmers, then it is easier to train each new programmer with it. That's the sole reason.
Honestly, the visual does get kind of messy. I, personally would love to see us use Java in the future for the "easier to keep neat" part. And I'd love to start moving programmers straight to a very necessary language.
Sounds like a great reason to use LabVIEW!
Eclipse can pick up on almost every single syntax error quite easily. I've dealt with issues such as users putting a space in front of their variable names in Labview causing them to fail for seemingly no reason. Labview has no advantage in this field.
Labview has no advantage in this field.
This is completely untrue and shows your lack of understanding. I use LabVIEW often in my Automation Engineering job and it has many advantages to traditional languages you just have to understand what those are (as many people have listed in posts above). I have experience with all three of the supported languages and python (never on a robot just in home use) and can certainly say that all of them have advantages and disadvantages, learn what those are and make an informed decision.
The flexibility to use robot code written by a novice without worrying that a syntax error will cause a heap corruption
Sounds like a great reason to use LabVIEW!
Eclipse can pick up on almost every single syntax error quite easily. I've dealt with issues such as users putting a space in front of their variable names in Labview causing them to fail for seemingly no reason. Labview has no advantage in this field.
This is completely untrue and shows your lack of understanding. I use LabVIEW often in my Automation Engineering job and it has many advantages to traditional languages you just have to understand what those are
Without making any judgement either way regarding the claim in Arhowk's post, the phrase "in this field" in context seemed to be narrowly referring to syntax checking only.
Alan Anderson
14-03-2016, 16:17
LabVIEW...
Honestly, the visual does get kind of messy. I, personally would love to see us use Java in the future for the "easier to keep neat" part.
How would you keep a text-based language neat? Unless you're talking about the formatting of indivicual lines, you can probably do the same sort of thing in a graphical language.
If your LabVIEW code is getting too messy for your tastes, you're likely trying to do more in one place than you ought to. Keep unrelated things separate, and use subVIs to encapsulate specific functionality. If you're good about using the graphical nature of the language, you can usually manage not to have a VI spill past the edges of the screen.
techhelpbb
14-03-2016, 16:26
How would you keep a text-based language neat? Unless you're talking about the formatting of indivicual lines, you can probably do the same sort of thing in a graphical language.
If your LabVIEW code is getting too messy for your tastes, you're likely trying to do more in one place than you ought to. Keep unrelated things separate, and use subVIs to encapsulate specific functionality. If you're good about using the graphical nature of the language, you can usually manage not to have a VI spill past the edges of the screen.
LabView UI in TUI (https://en.wikipedia.org/wiki/Text-based_user_interface)?
Then it would work over SSH :)
Alan Anderson
14-03-2016, 16:35
Eclipse can pick up on almost every single syntax error quite easily. I've dealt with issues such as users putting a space in front of their variable names in Labview causing them to fail for seemingly no reason. Labview has no advantage in this field.
First: if you're talking about LabVIEW variable names, I'm going to assume you don't know what you're talking about.
Second: LabVIEW is extremely proficient at not just detecting syntax errors, but at preventing them in the first place.
If you're talking about labels used in the RefNum Registry, then you have a point, but claiming "seemingly no reason" is overblown. A misspelled string passed to a RefNum Get function will give a distinct error.
In the typical TechnoKats robot code, each resource name exists only once in the entire program (it wouldn't have to exist at all if it weren't required in order for Test Mode to work properly). The problem of spelling a name two different ways simply does not occur. I know of at least three ways to do this, each with its own tradeoffs among such things as quickness of setup, speed of use, and simplicity of making major changes.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.