Similar code could be written in C#, with code like IEnumerable MyRobotBrain() { while(drivetrain.getDistanceInches() > -48) { yield drivetrain.arcadeDrive(0.5, 0); } yield shooter.shoot(); }
Coroutines make robot code easy
11–20 of 127 posts
Re: Coroutines make robot code easy
#12Similar code could be written in C#, with code like IEnumerable MyRobotBrain() { while(drivetrain.getDistanceInches() > -48) { yield drivetrain.arcadeDrive(0.5, 0); } yield shooter.shoot(); }
Re: Coroutines make robot code easy
#13I don't like hardcoding functions in coroutine pipelines. Depending on the ordering of your pipeline, you might have to create things and then refer to them, because of the forward reference problem.
Here's my stackoverflow question for what I'm getting at:
https://stackoverflow.com/questions/74420108/whats-the-canon...
Coordinating work between independent threads of execution is adhoc and not really well developed. I would like to build a rich "process api" that can fork, merge, pause, yield, yield until, drop while, synchronize, wait (latch), react according to events. I feel every distributed systems builds this again and again.
Go's and Occam's CSP is pretty powerful.
I've noticed that people build turing completeness ontop of existing languages, probably due to the lack of expressivity of the original programming langauge to take turingness as an input.
Re: Coroutines make robot code easy
#14Re: Coroutines make robot code easy
#15Re: Coroutines make robot code easy
#16The biggest challenge is sometimes you do want external flow control, and there coroutines can get hard to untangle if your design is a bit messy.
Something like “A signals to B to do something else” starts to be a bit tricky (along with interruptible actions). I think there are good patterns in theory but I’ve found myself with pretty tangled knots at times.
This is ultimately a general problem when programming everything as functions. Sometimes you need to mess with state that’s “hidden away” in your closure. Building out control flow data structures ends up becoming mandatory in many cases.
Re: Coroutines make robot code easy
#17I think that developers have minimal scheduling primitives available to them, to schedule complicated work, in the order and timings you want it to have. I don't like hardcoding functions in coroutine pipelines. Depending on the ordering of your pipeline, you might have to create things and then refer to them, because of the forward reference problem. Here's my stackoverflow question for what I'm getting at: https://…
Re: Coroutines make robot code easy
#18Similar code could be written in C#, with code like IEnumerable MyRobotBrain() { while(drivetrain.getDistanceInches() > -48) { yield drivetrain.arcadeDrive(0.5, 0); } yield shooter.shoot(); }
Re: Coroutines make robot code easy
#19They're equivalent except that asynchronous callbacks is what actually happens and you have clear control and visibility on how control flow moves.
Re: Coroutines make robot code easy
#20People always say that coroutines make code easier to understand, but I've always found normal asynchronous code with callbacks much easier to understand. They're equivalent except that asynchronous callbacks is what actually happens and you have clear control and visibility on how control flow moves.
I found the article a great example of the kind of crap that passes for programming these days.