I heard that python is very good for beginners but am just making sure. Lets say i needed to make a simple robot that can drive and have an arm to grab things would Python be better since it is easier to learn and is a simple robot.
2 Likes
You’re going to hear a lot of things asking that, some say use Java because it has the most support behind it, some say use Python, etc
Whatever programming language fits your team is the best.
My 2 cents is Java, but I have been developing in Java for years so your mileage may vary.
Just choose one and go.
7 Likes
They all have their pros and cons.
Java is a very popular language for FRC though, so it (currently) has more support and resources. However, it’s a slightly more complicated language to get the hang of, and it’s not as widely taught as python is to kids.
Python has an easier barrier to entry. Python is way more widely taught to younger kids, so rookies coming into your team might happen to have more experience with that. However, python is still a emerging programming language for FRC, so for now there are less resources and support.
I’d say just pick which one your students and mentors feel more comfortable with, and invest as much time as you can learning it before January.
5 Likes
i am a java fan but just kinda pick something and start learning is my advice
4 Likes
Can you elaborate on this simple robot? What are you running it off of?
1 Like
For FRC, the best answer is probably choose the language that the mentors are most familiar with to teach.
The second best answer is, choose the language that you as a mentor are most comfortable learning.
I have been teaching FRC programming to very beginner students for a long time now, and we decided to move from Java to Python this year because they announced for 2024 that it will have first class WPILib support.
I have found with my students, that Python seems to be a little easier for kids to follow along and learn.
I have found as a mentor, there’s a lot more time I have to spend to figure things out because we’re in the infancy of Python adoption across FRC.
To that end, I’ve been writing some basic tutorials and exercises that I teach to the students, some of which can do them as self-paced. Feel free and borrow/steal/augment/fork and PR etc: GitHub - Lambda-Corps/2023_python: Training repository for Robot in Python
5 Likes
You guys don’t have little goblins flipping switches and plugging wires in your robots?
2 Likes
XKCD 378. Yes, CD this is a full sentence.
3 Likes
Personally, I like programming in hardware but I have used mostly python to learn.
My programming experience is rather different to most people tho cuz I use it for things in a limited and usually unsupported way.
G Code and Minecraft commands are my favorite right now.
If you’re trying to use things in the way they’re intended I believe Python is usually recommended.
2 Likes
I think the consensus is pretty common here. But to throw my two cents in the ring…
I think it’s safe to say C++ is the least beginner friendly. As C++ relies heavily on proper memory management and how it doesn’t have garbage collection like Java and Python. Topics like pointers and such make the learning curve steeper than the other mentioned languages.
Python will be great in the coming years, and the syntax is by far the easiest to pick up and start coding. But I wouldn’t want to be on the bleeding edge of support in the events there are hiccups and bumps in it’s introduction and limited support resources compared to the other supported languages. Not to mention the overhead of it being an interpreted language. There’s technically a performance hit vs compiled languages. But if you’re a team just learning now, achieving as close to real time code performance probably isn’t your top priority.
Which leaves Java. Which I’m 100% biased to using, as it’s been what 319 has always used going back as far as I know ( to 2013 ). There’s tons of support both official with WPILib, as well as open source resources with many Einstein teams. Not to mention some of the more advanced features of Java are fairly straightforward to learn compared to the depth of some of the other languages. ( lamda/inline functions, templates / interfaces, etc )
And at this point I realize this might be a little more than two cents… so my apologies for rambling.
TLDR and my favorite metaphor :
C++ is like a manual transmission. If you know how to use it. You’ll get the extra milage / enjoyment.
Java is like an automatic transmission. Fairly turnkey. Been around a while, lots of people know how to use it, and can therefore teach it. Pretty much any user can pick it up and start driving with it.
Python is like up and coming EVs. They’re going to be pretty turnkey like automatics. But we don’t know the maintenance issues that may arise as they aren’t as adopted as the other options. In the coming years they may be the clear choice. But we’re not there yet.
2 Likes
In my also heavily biased experience with C++, I wouldn’t say that it’s necessary difficult. Least beginner friendly? Barely, while also being a little more… predictable than the other two.
To clear a misconception: The existence of std::unique_ptr since C++11 makes memory management far easier for the beginner and does GC for you. Unless you’re using direct mallocs, you’re not ever actually doing memory management. Which, in the grand scheme of things, should really never be done if you’re using C+±isms.
I think it should be quite simple to establish a simple convention for pointers, such as subsystems are pointers and everything else is a reference, and beginners will be fairly undaunted (just make all the subsystems in RobotContainer.h into std::unique_ptr.
Most of these advanced features will realistically go unused, outside of lambdas for command factories (and the syntax is barely different). Templates and interfaces are rare in robot code (in fact, C++ completely omits interfaces entirely, as it has multiple inheritance which is arguably far better than interface garbage).
Anyways, rant over. I encourage teams to NOT glance over C++. It is certainly a little harder, but realistically the hardest part about it is that Intellisense sucks for C++.
2 Likes
Not quite. Shared pointers do something similar to Java GC, but it’s still less safe and harder to learn. Unique pointers just behave like stack allocations, but allow polymorphism.
In either case, to code in C++ you have to rather fluently understand object lifespan or you will run into problems. Java is very much easier in this regard.
3 Likes
True. Unique pointers are definitely a help though.
For people who actually plan to do anything past FRC it’s definitely a good idea to learn how to effectively utilize pointers and understand lifespan, allocation, and freeing. As a whole, actually, if most of your team wants to go into the CS/CE industry, they’re best off using C++, as it’s (to my knowledge) more ubiquitous than Java in the actual industry. And it teaches programmers lower-level concepts, which will certainly help their understanding of other languages.
2 Likes
Python uses reference counting, not garbage collection. C++ also uses a combination of stack allocation and reference counting.
Just don’t use pointers. I never taught them to my C++ team, because they weren’t needed for FRC software written in modern C++.
My team just declared everything on the stack and used dependency injection (passing references to subsystems in constructors). We never had memory management issues. Don’t overcomplicate it.
No, they don’t. std::shared_ptr is reference counted. Garbage collection works through a different, less deterministic reclamation mechanism (the hope with a GC is that by deferring reclamation, one can avoid lots of overhead from adjusting object refcounts).
2 Likes
Seems like this has the potential to overflow the stack. But I suppose unless you’ve got a million subsystems, the very single-threaded robot code doesn’t have any need of the heap. Didn’t even think about that, that’s even better!
1 Like
That’s never been a problem in my experience in FRC. It’s only something you have to worry about on embedded MCUs like an STM32.
3 Likes
This is definitely true. Even with value semantics, there is minimal to no compiler checking of things like use-after-move. C++ does not have strong checking of object lifespan, and it abounds with UB (undefined behavior) which is often non-obvious and difficult for even very experienced C++ programmers to spot. C++ has UB in many areas where in Java/Python the operation is either impossible or you will get an exception (with a traceback!); some examples:
- Accessing outside of array bounds
- Accessing a null or uninitialized object or value
- Accessing an object after it’s been destroyed / lifetime has ended
- Static initialization order dependencies
- Multiple definitions of the same class/function (e.g. putting non-inline definitions into a .h file)
In general, programming errors in C++ usually result in a crash (sometimes at a distance if random memory was overwritten due to a use-after-free or out of bounds access), versus in Java/Python you will get an exception with a traceback, which is much more beginner-friendly. I like to think about using a managed language is like bowling with guardrails on.
3 Likes
C++ also has much more language features including templating, operator overloading, etc.
However, this makes it very easy to shoot yourself in the foot (as you have pointed out with memory access). There’s a reason there aren’t any valgrind equivalents in java (I think). It’s also annoying how linker errors and templating errors (especially with the C++ units library, which I love) compete for who can have the longest lines that mean absolutely nothing.
Happy thanksgiving!
1 Like
It’s true that a lot of the features C++ inherited from C are dangerous, and there’s often not docs or mentors telling students to use modern alternatives instead. The phrasing is misleading here though; the features listed cannot cause memory errors.
There sort of is, actually: https://visualvm.github.io/. You can get memory leaks in Java through:
- Circular references within groups of objects, so the GC thinks they’re still referenced by the main program.
- Leaks of native resource handles (e.g., sensors, motor controllers, DIO). The GC is never guaranteed to run for a given object, so its close() method may never be called. This can occur even when it’s obvious the object has left scope because the JVM’s escape analysis often fails. WPILib’s integration tests that repeatedly allocate hardware explicitly call close() to avoid this.
I’ve been working on improving the unit library compilation errors, though the tests aren’t compiling yet: GitHub - calcmogul/allwpilib at wpimath-clean-up-units-library. Concepts should make the source code as well as the error messages much more readable.
With regard to the original topic, I’d like to see Rust become official eventually. It has the performance of C++ with much better guardrails and much less legacy cruft. That would make it a good choice for beginners in the embedded robotics space.
3 Likes
First if your team has a mentor/coach/student with experience in a language use that. If not, I would recommend Java, as at the basic levels all languages are nearly the same with just different spelling and structure.
Personally,I don’t recommend python for new programers as it can form bad habits if the programmer needs to use a low level language later. Also in my experience, Python is great if you are wanting to do quick programing (especially for data analytics or prototyping) but the easy syntax and untyped undefined variables become dangers in large collaborative projects. Additionally, outside of robotics the black box of python code dependance is just messy, but these are just my (perhaps unpopular) opinion.
1 Like