[documentation] Remove ReplaceMeCommand examples

[spacey-sooty]

Starting the process of modernising and cleaning up commands examples

vscode support is removed in wpilibsuite/vscode-wpilib#687

[sciencewhiz]

While these definitely need clean-up, since not all the classes exist any more, I'm not sure it's wise to completely remove all of them. One of the most common pieces of feedback that is received is that people find the fluent API confusing, and it requires language concepts that people aren't familiar with. I think that until everyone, especially low resource teams without a lot of programming is comfortable with the fluent API, we shouldn't be removing things that make using the "traditional' design pattern easier.

[spacey-sooty]

fluent API confusing, and it requires language concepts that people aren't familiar with.

I don't think its language features people aren't familiar with, it's just functions. IMO the reason teams find it more confusing is because frc-docs primarily focuses on how to write command classes as opposed to how to write command factories. I opened wpilibsuite/frc-docs#2748 which I'd be happy to work on in a few weeks

[rzblue]

I don't think its language features people aren't familiar with, it's just functions.

Lambdas are a language feature some people aren't familiar with. Yes, documentation helps, but getting rid of an assistive feature like the command class templates won't make them magically switch, nor will it help them find the docs. They'll just be frustrated, and likely continue to use command classes anyway.

frc-docs primarily focuses on how to write command classes

Can you show where this is done? Most of the docs show the fluent api, except for the part (at the bottom of the "Commands" page) that shows how to write command classes (where it also says "As this is significantly more verbose, it’s recommended to use the more concise factories mentioned above.")

Overall I'm not in favor of removing these. It seems like a really low risk thing to leave in, and removing them feels like removing functionality for the sake of removing it.

The older style is still a supported use of the command library, and is not an inherently dangerous/harmful way of using the api.

[Gold856]

If we're going to keep the class templates, we should at least remove the control command/subsystem templates, since those have been established to be bad ways of using the API.

[spacey-sooty]

Overall I'm not in favor of removing these. It seems like a really low risk thing to leave in, and removing them feels like removing functionality for the sake of removing it

IMO they should be removed as it's a way of encouraging people to use the more concise factory API. Maybe we could add snippets for the factory API to make getting into using them easier?

[rzblue]

IMO they should be removed as it's a way of encouraging people to use the more concise factory API.

They are still a supported use case, and removing them does not help teams learn the new style, it just breaks their workflow. I'm all for modernization, but breaking users workflows just to break them isn't cool. Perhaps we could include a note inside the templates suggesting they check out the new style?

Maybe we could add snippets for the factory API to make getting into using them easier?

Sure, that sounds like a cool feature for the plugin!

If we're going to keep the class templates, we should at least remove the control command/subsystem templates

I'm less opposed to that, though I think we should just deprecate and remove those classes as a whole in the normal manner.

[spacey-sooty]

IMO they should be removed as it's a way of encouraging people to use the more concise factory API.

They are still a supported use case, and removing them does not help teams learn the new style, it just breaks their workflow. I'm all for modernization, but breaking users workflows just to break them isn't cool. Perhaps we could include a note inside the templates suggesting they check out the new style?

I like including a note I'll do that.

I'm less opposed to that, though I think we should just deprecate and remove those classes as a whole in the normal manner.

Iirc that's in the works. I'll change this to delete those templates and include a note in the others then.