I don’t understand why doing this with normal Java is difficult. Just have a list of objectives. Each objective is a class. The autonomous loop picks the next objective from the list and each tick, asks if it has finished, if so get the next objective and so on.
All the details about the actual commands to complete the objective and checking the state and so on go into the classes.
If no more objectives in the list, mission accomplished.
You can also easily test each objective independently.
Maybe the trouble is trying to fight abstraction so hard in the first place.
Having taught FRC students to use Java: when you're talking about people with very little experience programming before, the multiple class abstraction is itself an obstacle to accomplishing the goal.
I can't tell you how many times students have gotten frustrated trying to understand why you have to pass arguments into the constructor or, for that matter, Why the constructor is different from other method calls. "But we already said 'drivetrain' in the constructor, and over here in this other class. Why do we have to say m_drivetrain in the class also and do m_drivetrain = drivetrain?" And there isn't actually a better answer than "in other languages that learned from Java's mistakes, you don't. But we happen to be using a language that dates back to when Animaniacs was teaching kids the names all the countries, so some parts are just bad."
> the multiple class abstraction is itself an obstacle to accomplishing the goal.
Not if your goal is to learn about object orientated programming!
> I can't tell you how many times students have gotten frustrated trying to understand why you have to pass arguments into the constructor or, for that matter, Why the constructor is different from other method calls. "But we already said 'drivetrain' in the constructor, and over here in this other class. Why do we have to say m_drivetrain in the class also and do m_drivetrain = drivetrain?" And there isn't actually a better answer than "in other languages that learned from Java's mistakes, you don't. But we happen to be using a language that dates back to when Animaniacs was teaching kids the names all the countries, so some parts are just bad."
Do they also have nervous breakdowns every time the spell or read the word "knight"? The etymology of a language can be interesting, and they're welcome to look it up on their own time, but the sooner they learn that all of these decisions are arbitrary, the better.
When I was first learning how to use FreeBSD I was equally confounded by trying to apply logic and reason to how the commands looked and worked. Once I just accepted the fact that it was no different to questioning why the buttons were on the left side of the toaster rather than right side, or why sought and sort are two different words pronounced the same my life got a whole lot easier.
When I'm teaching kids about code and they ask "why ... " it's an opportunity for them to learn that oh-so-important lesson that in almost all cases the design decisions in software are totally arbitrary or of such obscure etymological origin that, unless you actually want to be a computer science historian, the best answer is "because".
And while nobody had a nervous breakdown, yes, the need to pass references around extremely redundantly because this language lacks any way to establish a global context and top level non-class variables was a continuous impediment to their ability to accomplish the task.
I've seen some good suggestions in this topic though; I think next year I may recommend a top-level container class that has init called on it one time and can then be referenced in all other class files. It's the closest thing to global variables Java has to offer, and would save them a lot of hardship passing references around for no other reason than passing references around.
It's addressed in the article... you sort of end up with a meta-programming language when you do that, which ends up being less ergonomic than your initial code. Then you have questions like how do you do control flow within that list? Can you branch or loop over multiple objectives? If you add support for that you end up even closer to a meta programming language, with worse syntax than if things were directly in the base language.
> you sort of end up with a meta-programming language when you do that, which ends up being less ergonomic than your initial code
I would say that what you end up with is a program.
> Then you have questions like how do you do control flow within that list
You don't. Each objective has an "isDone" method. That method returns true if done, false if not. If unable to complete its objective for some reason, throw an exception. Seems like pretty canonical object orientation to me.
> Can you branch or loop over multiple objectives?
No, but you could easily have an objective that groups together multiple smaller discrete objectives.
> If you add support for that you end up even closer to a meta programming language, with worse syntax than if things were directly in the base language.
Again, I just think you end up with a program, using the syntax of the language in which you're writing.
Like if you write a story, you end up with a story, written using the language in which you wrote it.
All the details about the actual commands to complete the objective and checking the state and so on go into the classes.
If no more objectives in the list, mission accomplished.
You can also easily test each objective independently.
Maybe the trouble is trying to fight abstraction so hard in the first place.