I’m likely to start a holy war with this,
but it would be awful nice to teach kids a language without all of the strings attached to it like Java Licensing once they reach the business world.
Particularly .net core 2+.
I don’t know if they still are, but you might get in contact with 4488.
But for your criteria, how about C++?
Python for FRC exists, it just not officially supported by FIRST/Any CSA’s, so you’re SOL there if anything goes wrong at comps.
OpenJDK has no licensing requirements attached and is pretty widely used. OracleJDK is largely for companies that require software they used to have a support contract.
This seems like a silly reason to move away from Java.
Clearly you meant to put “Python” in your title. 
^^
^^ What Nick said two posts up.
In any case, what did you mean by your second sentence, in particular “once they reach the business world”? This is exactly when it is almost always more cost effective to pay for support for infrastructure than to pay your employees to support themselves.
I vote stick with Java. Industry is full of choosing languages and infrastructure because they’re officially/best supported.
In this case, Java and C++ are the only officially supported languages for FRC.
Pave the runway as best as possible. Don’t make it harder for them to take flight.
Only supported TEXT languages for FRC.
Given how many CSA’a are NI employees, support for non-LV environments in general is iffy.
We have the same problem in programming languages that teacher’s colleges has: too many PHD’s, not enough common sense. Do we really need Python2, Python3, Lua, <pick a new language>. What happened to PL/1, Pascal, Modula, Modula-2, APL, COBOL, FORTRAN, <pick your favorite old language>. Something simpler, as (or more) efficient, came along and wiped them out.
Or, in the case of C, DEC’s PDP-11 assembly language was pretty useful. With the OO baggage of C++ on top. turned out to be a cost effective way to get things done. Somehow the evil spawn, Java, flowed to form the marriage of C++ and Modula-2, to create a single inheritance monstrosity, driving the reaffirmed truth: "We can found no scientific discipline, nor a hearty profession on the technical mistakes of the Department of Defense and, mainly, one computer manufacturer. "
C-hash? Sounds like lunch.
Tim
Of all the possible problems one can find with Java (of which there are many), you’re really going to choose the lack of multiple inheritance? In nearly any situation where multiple inheritance can be applied, composition will produce clearer and less error-prone code. See: https://en.wikipedia.org/wiki/Composition_over_inheritance
Is this a challenge? Am CSA at Mount Olive, NJ.
As to the rest of the topic: 30+ programming languages later: I find the academics are fairly irrelevant as things just need to get done.
I favor any language I can read my own code clearly long after I put it out of my head, and that won’t drive anyone suitably motivated to give up trying to learn it.
As noted elsewhere early robots were sometimes controlled by end users in languages like COBOL, as strange as that may seem. After all: back then my first home computer was >$50k US. A Walmart $100 tablet from RCA is more powerful.
I still don’t see everyone using VR daily, flying skateboards normally in the town square, or Rosie the robot…and I won’t care what langauge these visions of the future use when I do but I’ll bet they will all be machine code in the end.
What I do find strange is a topic on C# programmed robots that does not mention:
https://www.microsoft.com/en-us/download/details.aspx?id=29081
Please note under critique that some people went from MRDS to IPC++, and MRDS is now 6 years old:
Back in the day when we were dreaming up the RoboRio I guess Microsoft was thinking of positioning this as a LabView/C# alternative. I know it was discussed and obviously it’s not huge in FRC. As to whether that was a Microsoft play just for FRC I would not know, but if it were so superior one would think it would own huge market share.
Eh, I don’t think so, especially considering how more teams use text based languages (with java being the most popular) than Labview. The way I’ve thought about it is, CSA support can be highly variable, depending if the CSA knows labview or java or C++. Don’t let official support hold a huge sway in programming language choice, unless you are a rookie team, lack programming capability, or are already struggling to produce workable code with an officially supported language. Python has excellent libraries in the form of RobotPy, complete with better docs than standard WPIlib. C# on the other hand, not so much. I chose to move my team to Kotlin because of its advantages as a programming language over Java, the fact it uses a stable library (WPIlibJ), and my assessment of my programming team’s capabilities. I didn’t take into account support at competitions because I think we have bigger issues than language choice if we require a CSA to look over our code for anything other than FMS connection issues and the like.
What’s most important is to have a baseline template you can deplay that you know will work with the FRC field. In whatever language you use.
If you have that you know at the core things worked: whatever else is wrong is now easier to isolate.
So whatever you decide to use: be sure somewhere you have a minimal base template that you know for a fact works on an FRC field. Otherwise as a CSA you are making my job really hard.
In my experience once you know one C-based language learning another one isn’t super crazy (C++, Java, C#, etc.). I would say better to use a language with FRC support. Through college and in industry, having a good grasp of programming concepts, logic, etc. is more important than mastery of any specific language.