Preferred Programming Language

[SoftwareBug2.0]

Originally Posted by teku14

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/commen...launch/c8boafz

[MrTimKlein]

Originally Posted by jkelleyrtp

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.

[Ether]

Originally Posted by MrTimKlein

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]

Originally Posted by Ether

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]

Originally Posted by MamaSpoldi

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.

[Ether]

Originally Posted by virtuald

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.

[Arhowk]

Originally Posted by Ether

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]

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

[GeeTwo]

Originally Posted by axiomofdarkness

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]

Originally Posted by GeeTwo

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.

[Spoam]

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]

Originally Posted by Spoam

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.

[Spoam]

Originally Posted by virtuald

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]

Originally Posted by Spoam

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!

[Jaci]

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?