Hi, I’m looking to make some pretty significant changes to my team’s programming workflow for next year. One of the things that I constantly bring before my team’s programming mentor, is that I believe that we should switch to an alternative JVM language called Kotlin, as well as switching to using Gradle with GradleRIO for the build system. He expressed a concern that doing this would mean that we would be on our own if we ran into any technical troubles. So, if my team were to do this, would we still get help with programming?
No official help, and CSAs may not be able to help you at competition.
I certainly wouldn’t be able to help you. How often do you need help from other teams? Are you the only person on your team who knows how to use these tools? Your mentor probably is very familiar with Java, and doesn’t want to have to learn Kotlin.
If you consistently need outside help, you probably shouldn’t do this.
IF you received any support it would be through sheer luck. Even with the current languages, the CSAs at the events may be able to answer basic questions, but not advanced ones.
A good question to ask yourself is why you think changes like this will improve your team in the long term. Like over the next 7 of 8 years.
Good teams do great things with Labview C++ and Java.C++ and Java are a language industry has used for years. FRC ppl know Java, C++ and Labview. There is a lot of support for new learners from WPI and other sources. If you mentor has a grasp of one of these languages you should stay with it. They will be there for the next several years to train new ppl, a student may not.
Just my opinion…
GradleRIO is fairly stable, and has less to do with your code than it is about deploying to the RIO. IF, and only IF the toolchain is updated for 2018’s competition should you consider switching to it next year. Learning it on your 2017 bot is never a bad thing though. Gradle is an amazing tool that sets up development environments for anyone within minutes, rather than them spending an entire day downloading jars, setting up classpaths, etc. Its deployment feature needs maintenance from time to time, but once that’s setup deployments are extremely easy to perform and nearly impossible to mess up. GradleRIO has all of the details you need to get it going on your 2017 bot. If your mentor likes Java, he or she will likely come around to liking Gradle.
As for a custom JVM, I wouldn’t go there. In theory everything works, but there may be errors in your custom JVM (particularly with JIT, different versions of classes, etc) which would cause your robot to execute code incorrectly.
Why Kotlin? With Java 8 lambdas, most “boilerplate” is gone. With the Java 8 Optional paradigm most null pointers are dealt with up-front (hint: null data is your friend - it’s not an error condition so much as an admission about the data that says “in some cases, I don’t know”). On the surface, the rest of what Kotlin has to offer from a coding perspective is basically like sweeping your technical debt under the rug.
Kotlin isn’t a custom JVM. It’s a language that runs on the JVM. At the end of the day, both java and kotlin compile to java byte-code.
OP, If you want to use Kotlin, you can. It works alongside java natively, and if you have any troubles, IntelliJ IDEA has a “convert to java” button for Kotlin source files if you’re desperate.
The only troubles you should have are picking up a new language syntax. We used Kotlin in 2016 (and yes, GradleRIO has support for Kotlin). GitHub - FRC5333/2016-Champs: Our 2016 Code Rewrite for use at the World Championships in St Louis
I highly suggest you do not move away from either Java, C++, or Labview. As many folks here have said it is hard enough to get help from a CSA when using any of those 3. You want to set your team up for success and one of those ways is by using something you know at least 50 other people at a competition know. Now something that would be fun is recoding this years robot after the season is over in Kotlin just as a learning experience.
Just my two cents.
GradleRIO is a must if you’re an aspiring programmer who wants to get a little more control over their code. As JesseK said, it’s very stable, and Gradle makes dependency management a breeze.
My team moved straight into Kotlin from LabVIEW this year, and so far I think it’s been a really great transition. While some of the comments above are true, Kotlin is much easier to read than other JVM languages, so any CSA that knows java should be able to understand Kotlin. Lambdas in java are really just a wrapper for a functional interface. In Kotlin, you can easily specify a parameter as a function without a functional interface. Kotlin just makes your code more concise and honestly easier to read.
If you want to take a look at some more robot code in Kotlin, feel free to look at our team’s Github repo: GitHub - team401/2017-Robot-Code: Robot Code for the 2017 season
Depends on what your goals are.
I see a lot of people here telling you not to use Kotlin, which I think is somewhat silly.
If you are confident that you will be able to pull it off, and you think that it will help you achieve your goals, absolutely go for it.
How much support for it will you get? It depends. Probably less code support than you otherwise would, but consider how much you need the support.
We use a very very custom setup (still C++, but most of our kids don’t ever see a call to WPILib), because we think that the benefits of that setup are worth the downsides of not getting as much support.
The main question is what benefit are you getting from switching to a custom setup? Personally, I like the idea just because I like seeing people try new things (but also Kotlin is great). Think about the pros and cons, and weigh them. Imo, it seems worth it, but you need to make the decision based on the goals and abilities of your team.
As someone who has been using and supporting an unsupported and unofficial language stack in FRC for 6 years now, and has been a CSA for 3 years, I feel vaguely obligated to throw some gasoline onto this fire.
TL;DR: Do It
Longer answer: I have to start by echoing @remulasce’s comment:
If you consistently need outside help, you probably shouldn’t do this.
However, if you and your team have great programming resources and abilities, and if you’re in agreement that this is a super cool awesome idea that you should pursue, then you’ll probably be fine as long as you do a LOT of testing during the actual build season.
It’s correct that you won’t get any official support, and if you run into programming related issues at your event, then you may be SOL. You should be prepared to deal with that – but look, if you’re using a standard drivetrain that comes with WPILib support, you should be able to create a replacement program in Java that gets a majority of your robot’s functionality working (without bells and whistles) in less than an hour – and if you can’t do this, then you probably shouldn’t be using your own language.
The good news about official support is that as a CSA, a majority of the problems I’ve had to help teams with have been electrical issues, namely either one of the PDP fuses popped out or they didn’t secure their radio/RoboRIO wires correctly. These issues don’t care what language you’re using.
But the bottom line is that you and your team must be extremely confident and capable software engineers. It might be hard work (though, since it’s built on the JVM, I suspect much less work than creating your own language stack).
Something important to consider is how many people on the team will know and understand the new code?
If it is just you, that puts the team at great risk. If, for some reason you can’t attend an event, you get sick, you have an emergency, etc. There may be no one else who can step in.
On the flip side, if there are several who will be skilled and capable of making changes, understanding issues, correcting problems, etc. that is less risk to the team.
I remember taking a workshop-style class on software project management provided by my company. Part of that was deciding what tools to use. When it came to changing “infrastructure” type tools, such as programming languages, operating systems, graphics libraries of any such “behind the scenes” type development tools, the rule of thumb for the instructor was to assume that any programming estimates (i.e. how long will it take to do this?) should have an additional 20% added if you change one element, and an additional 50% if you change two of them. If you change three? Don’t.
In my many years of professional development, there’s nothing I hate more than hearing someone on the team insist that we could do things so much better if we just change from what we are using to the new thing.
My serious advice about using anything “non-standard”, is that it is ok if someone on the team (mentor or student) is a truly experienced programmer with that new tool. i.e. if you want to go to Kotlin, and someone on your team has done several significant projects with Kotlin, then it is safe. Go to Kotlin. (As an aside: I wonder what Kotlin is. Is this some other new thing I will have to learn to keep my job until retirement?) Even then, you should only do it if there’s something you can do with the new tool that will actually solve a problem.
If you want to go to Kotlin because you read that it’s cool and you will be able to do much cooler things if you just switch to Kotlin…don’t.
I guess I’ll chime in again.
I’ll make the bottom line clear: don’t rely on help for CSAs. This isn’t even me talking about a language like Kotlin, this is for any language, official or not. Unless it’s basic, boilerplate and simple code, the CSAs won’t be able to help you, mostly because they have to have time to orient themselves around your codebase.
You’re at a point in your programming career where you should be experiencing new technologies and ways of thinking other than “just copy the examples from screensteps”. Learn it during the offseason, and if you’re still set on it, implement it during the on-season. You won’t learn anything if you don’t experiment. It might not work out, and you may decide it’s not for you, and that’s perfectly fine, at least you’ll be wiser than before.
Programming is all about different paradigms and different ways to do things. What I, or you, or anyone does might not be the best way, or the cleanest, or check the most boxes. The only way to learn about the other ways is to dive in and try it. Not everything is like Java, and not everything has to be.
“But the other members on the team don’t know or appreciate the language”.
Make a case for yourself, show them why you should be using it, and teach them. You’ll gain some leadership and presentation skills to boot.
My honest advice is the same advice I give for anything like this. Just go for it. You’re here for a learning experience, not a tutorial.
To expand upon this, programming is one of those privileged areas of the FRC skill-tree (so to speak) that /has/ tutorials. You won’t find anything like them for mechanical design, and very little regarding electrical. Tutorials are amazing learning tools. But they’re just that. Tools. If you just copy every tutorial you see, you won’t learn jack.
I remember I was at a programming class a few years back, and we were basically given free reign over our final projects. As rewards for doing cool stuff, we were given raffle tickets. On the one of the last days, an instructor walked up to a kid next to me and said “I will give you twenty tickets if you can explain any piece of this code to me.” Because the kid had just been copying off Stack Overflow for the full two weeks, he couldn’t explain any of it, and nor could he debug it.
Moral of the story: Use tutorials to help you learn, but don’t blindly follow them.
Thanks everyone for chiming in on this. The thing is, that I’ve been using Kotlin for about a year outside of FRC, and I do feel that the features it provides would be of help when programming the robot. The big point that my team’s programming mentor pushed is that we would be SOL if we did run into a problem that we’d need to ask about on here. I’m gonna show him the opinions in this thread and see if I can convince him.
<offtopic>If we did have a problem, and I were to convert the problematic Kotlin code back into Java to post in a thread on here, we would get support, right?</offtopic>
Thanks again
Another thing to keep in mind that no one has mentioned here is the language you use could be something that teams are scouting for and could affect where they rank you or if you even make their list.
If a team has a piece of active cheese cake that will require changes to code you might miss the short list if they don’t think they can quickly help you adapt your code to support the cheese cake mechanism.
Another reason teams might scout the language and style of code you are using is if they have plans to have you adjust an autonomous routine to add a delay or make it take a different path to avoid a collision with other robots. Once again if they don’t think they can quickly help you make those changes you may miss out on being picked.
While this isn’t directly related to your question it is just something else to keep in mind.
My 2 cents.
Manage your risk profile. If your team generally builds a standard robot, makes its deadlines and has good support for experimenting with code on older robots, then this can be a good, though somewhat risky decision that the team needs to be aware of and supportive of.
If your team commonly overextends itself on design and manufacture and the programming team struggles with one of the supported languages, then this will not improve things and will likely make them far worse.
FRC is a great place to experiment and take managed risks. But be careful to think about the results of failure. Prepare for the transition, make backup plans, etc.
Greg McKaskle
It sounds like you meet the first criterion for why to switch to something non-standard. You have a programmer (yourself) who has some significant experience with Kotlin.
So now what about the second? What is it that Kotlin has that Java doesn’t? In this case, I’m asking for my own curiousity/professional development. I’ve never heard of it. What makes it better, either in general, or specifically for FIRST style programming?
As someone who is using both Kotlin and Java professionally, who has been mentoring an FRC team’s programmers for many years, and who works with a lot of the troubleshooting at competitions, here’s my take:
As far as support goes, I agree with what’s been said. The CSA’s likely won’t be able to help you debug your code if you are having issues at competitions. They can provide high level guidance (e.g. “I see you have high trip times and high CPU usage- maybe your code is doing too much in each tick”), but won’t be able to dive in to the code with you. That being said, if you are even considering Kotlin your team likely can do a lot of that debugging yourself.
The bigger issue to me is what the future of your team looks like. If your programming mentor doesn’t know any Kotlin, you as the student pushing for it are responsible for training the rest of the team on how to use it. Bear in mind this is likely many students’ first language.
Then what happens when you graduate? Do you have other similarly passionate programmers on your team who can continue teaching Kotlin? Or will that code become unmaintainable should your team want to make any modifications to that code to use the robot for demos in the future?
If you believe your team is set up well to do that, then by all means go ahead!
You would be more likely to get help from a CSA in identifying the specific lines of code that are misbehaving (and why). However, as others have mentioned, you may not have a CSA who knows Java anyway (though events try hard to get a good mix).
There’s no cut and dry rule surrounding how much support the CSAs provide. The CSAs will simply do whatever is within their power to help you fix your problem. If you use a tool they are not familiar with, their ability to do so diminishes.
Also keep in mind that having the tooling automatically convert the code for you means that you are now using code that you did not directly write. Probably not a huge issue, but you may not be as familiar with how the code is working.