Re: Preferred Programming Language
 

Here's a recommendation from SpaceX about what languages to learn: https://www.reddit.com/r/IAmA/commen...launch/c8boafz

Re: Preferred Programming Language
 

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.

Re: Preferred Programming Language
 

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.

Re: Preferred Programming Language
 

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.

Re: Preferred Programming Language
 

Just a note: Java actually only supports passing by value, while C++ actually supports both passing by value and passing by reference.

Re: Preferred Programming Language
 

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.

Re: Preferred Programming Language
 

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.

Re: Preferred Programming Language
 

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

Re: Preferred Programming Language
 

Correct about C++. Java objects are always passed by reference. AFAIK, java primitives are always passed by value.

Re: Preferred Programming Language
 

Java passes references by value for objects. Java primitives are passed by value. Subtle difference, but it can matter sometimes.

Re: Preferred Programming Language
 

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

Re: Preferred Programming Language
 

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.

Re: Preferred Programming Language
 

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.

Re: Preferred Programming Language
 

Sounds like a great reason to use LabVIEW!

Re: Preferred Programming Language
 

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?