News for hackers. Stuff that matters.
Re:Coroutines make robot code easy for high schoolers by taeric on Thursday June 22, 2023 @10:40AM (#36432860)
Coroutines are covered in Knuth's first volume. And, I confess, I think I went years thinking he was just describing method calls. Yes, they were method calls that had state attached, but that felt essentially like attaching the method to an object and calling it a day.

Seeing them make an odd resurgence in recent years has been awkward. I'm not entirely clear that they make things much more readable than alternatives. Reminds me of thinking continuations were amazing, when I saw some demos. Than I saw some attempts at using them in anger, and that rarely worked out that well.

Also to the point of the article, I love being "that guy" that points out that LISP having a very easy "code as data" path makes the concerns expressed over the "command" system basically go away. You can keep the code as, essentially:

    (DriveForward 0.5 48)
    (while (NotCarryingBall)
        (Grab)
        (pause 2)) 
    (DriveBackward -0.5 48)
    (Shoot)
With god know how much bike shedding around how you want to write the loop there.

Of course, you could go further for the "pretty" code that you want by using conditions/restarts such that you could have:

    (DriveForward 0.5 48)
    (Grab)
    (DriveBackward -0.5 48)
    (Shoot)
And then show what happens if "Grab" is unsuccessful and define a restart that is basically "sleep, then try again." Could start plugging in new restart ideas such as "turn a little, then try again." All without changing that core loop.
Re:Coroutines make robot code easy for high schoolers by zooch on Thursday June 22, 2023 @09:04PM (#36441438)
With these examples I think the author would still be stuck with stepping through the state machines with the students. Unless what you wrote would allow for the "autonomousPeriodic function to keep ticking" another way?
Re:Coroutines make robot code easy for high schoolers by taeric on Friday June 23, 2023 @09:45AM (#36446756)
Apologies for not making that more explicit. My point was that that isn't necessarily code, but also data. Literally, you can turn that into a list and instead of evaluating it with the standard runtime, you can send it to another place that turns it into the "command" style from the example java.

You can /kind/ of do this with java, of course. Just make sure to not use "new FooCommand" and instead change the "foo" function to return a the command object. No reason that couldn't be done; but, and this is the big difference, it requires building a ton of scaffolding in the java program to support both ideas at the same time. In lisp, it is fairly easy to wrap in a macro. Still somewhat magical, I suppose, but no more so than the rest of the compilation/build process.

That make sense? I'm somewhat interested in this, so more than happy to try and do a blog post on the idea, if that would help.