Live data from Hacker News

Coroutines make robot code easy

bvisness.me

11–20 of 127 posts

Re: Coroutines make robot code easy

#13
I 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://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

#15
Ah coroutines, essentially glorified goto. My 10keV take is that dijsktra's paper while probably right about goto back then has cursed us and we are still cursed till this day. Some logical structures map well to just using goto in a series of steps, but because of this allergy to goto, we're stuck where basically jumping into a random place in a function is "novel."

Re: Coroutines make robot code easy

#16
Coroutined make programming for pico8 very chill as well.

The 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

#17

I 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://…

I mean, this is an interesting thing to think about but isn't at all what the article is about...coroutines have many uses may be and are often related to async work in general but OP is using coroutines just as a pauseable function (in good old asm, you know how computers actually just work, this is just jumping into a subroutine).

Re: Coroutines make robot code easy

#18

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(); }

I seem to recall reading (though quite some time ago so I may be mistaken), that `yield` was developed for use in robotics as part of the CCR (Concurrency and Coordination Runtime), and it's inclusion in C# 2.0 was to support this.

Re: Coroutines make robot code easy

#19
People 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.

Re: Coroutines make robot code easy

#20

People 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 imagine you would get a lot of blank stares with that POV, at least from folks with working bullshit detectors (like young kids that haven’t been conditioned to “modern” industry practices).

I found the article a great example of the kind of crap that passes for programming these days.

Post reply on HN