So my team has been coding in Java but my head coder is graduating and there isn’t a clear replacement. I tend to double as the coding mentor as we have no one else, so I basically have taught myself.
Python gets a lot of buzz as easy to learn. And there is the www.codecademy.com course which makes it easy to have my students learn the basics of the language.
My question is, do you think it is worth switching?
So far my Pro/Cons list
Pros:
-Can point students to www.codecademy.com course.
-Simpler for new coders to learn
When teams ask me which programming language to use, my first answer is “the one your mentor knows how to program.”
Teams without a strong programming mentor, in nearly all cases, should stick with one of the three officially supported languages.
Why?
For the sort of programming most teams do, there’s no material difference in difficulty between those languages and Python.
There is a much larger support ecosystem online for the supported languages.
You can ask other teams for help with the supported languages.
Most events have CSAs who know the supported languages.
I wholeheartedly support the teams that have brought additional language support to the FRC world. Those teams also have the people infrastructure to be independent.
Python is a great scripting language, but using any interpreted language in a production system (e.g. on the field in FRC) requires LOTS of care. You don’t want to sit dead for half a match because of a typo.
You don’t want to sit dead for half a match because of a typo.
Although I would generally agree with this, python actually helped my team out of a situation like this.
At my team’s first competition, I had made some last-minute tweaks to the robot’s drive code right before we left for a practice match. Autonomous runs, then I grab the joystick for teleop only to find my drive controls accelerated and inverted. Not from a syntax error, but a missing “-” and an extra “0” in the perfectly-valid python code. However, because I was using python, it only took about 30 seconds (mid-match) for me to ssh into the robot, modify the offending file, and re-load the code in order for us to continue practicing.
Python definitely is very good for quick iteration – though, I think the roborio has made redeployment of all code a lot easier.
There’s definitely a lot of risk when using interpreted languages, but a lot of that risk can be mitigated by things like writing unit tests, using simulators, and the like – which really, we should be teaching our students how to do that stuff anyways. This is why I’ve made sure that RobotPy has first-class support for unit testing and simulation. I’ve been using Python on robots since 2011, and teams I’ve worked with have never had a robot die in a match because of a syntax error.
The good thing about python in FRC is that the underlying library you interact with to control the robot is almost exactly the same – and generally speaking, the things that I’ve found teams have problems with in python tend to be the same things that people have in any language – how to control a motor, state machine concepts, not using sleep() in your autonomous mode, don’t overuse network tables… etc. And the good news is, if you ask others around you in terms of those concepts, they should be able to answer your questions regardless of which language you’re using.
I can relate to you, re-compiling and deploying your robot code seconds before a match is really stressful, especially with LabVIEW running on a low-end computer
That was one of the primary reasons why I switched our team from LabVIEW to C++ (it compiles much faster than LabVIEW, and our programming team is more familiar with it) and (testing) Python.
