[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