Thankfully a piece that emphasizes that coroutines are functions that pause. Java frameworks like Quasar became focused on other goals besides that basic capability and lost their way (IMHO).
Java's not the easiest to pick up in high school unless you really make a big after-school effort. Something like Lua is probably better.
For FIRST robotics in particular, Java and LabView are the most commonly used languages because they are the two for which a robust library is maintained by Worcester Polytechnic Institute for use in the competition.
But I have long been of the opinion that both languages are kind of an ill fit for the application. Python is making some headway and I think it might be a better fit; It has some advantages on legibility, it has an optional static typing system, and it does support coroutines.
Thankfully, very few teams are still using LabView at this point and WPILib primarily targets C++ and Java, with first-party Python support coming next season.
> Java frameworks like Quasar became focused on other goals besides that basic capability and lost their way (IMHO).
A bit of an aside maybe, but the guy that made Quasar is behind project loom to add light weight threads to JVM which will become available in JVM 21 https://openjdk.org/jeps/444
In my day Borland had all the hostages, and every time you used something that wasn't orange text turbo pascal another one got fed to a gru.
The right intro language is an interesting study in itself and the intuitiveness of coroutines is an good data point. Go seems like a decent first one. It jas dark corners, but at least they are in the corner. I'd love to argue for rust as a first language, and maybe it isn't a bad one. But I'm not sure where I'd start the argument. C was my second language, and I'm not sure it would have made sense as qyuckly before commodore basic.
Especially when people try to impose Enterprise Quality Java on the students, and your project gets bloated with interfaces and dependency injection and config files…all for a single platform with fixed hardware :(
When we were still using Java, I had the students just make everything static. We don’t need more than one instance of our IntakeSubsystem. We only have one intake. But the OOP boilerplate persists.
I don't know Quasar, but a lot of projects seem to want to add functionality rather than be a library for that purpose, and create a new one for the completely unrelated feature that you want.
Java's not the easiest to pick up in high school unless you really make a big after-school effort. Something like Lua is probably better.