←back to thread

Hacking Coroutines into C

(wiomoc.de)
135 points jmillikin | 3 comments | 13 Jul 25 01:12 UTC | HN request time: 0.417s | source
Show context
Neywiny ◴[13 Jul 25 01:34 UTC] No.44546748[source]▶
The intent here is nice. I historically hate state machines for sequential executioners. To me they make sense in FPGA/ASIC/circuits. In software, they just get so complicated. I've even seen state managers managing an abstracted state machine implementing a custom device to do what's ultimately very sequential work.

It's my same argument that there should be no maximum number of lines to a function. Sometimes, you just need to do a lot of work. I comment the code blocks, maybe with steps/parts, but there's no point in making a function that's only called in one place.

But anything is better than one person I met who somehow was programming without knowing how to define their own functions. Gross

replies(3): >>44547042 #>>44547331 #>>44547585 #
1. duped ◴[13 Jul 25 04:43 UTC] No.44547585[source]▶
> I comment the code blocks, maybe with steps/parts, but there's no point in making a function that's only called in one place.

I encourage junior developers that get into this habit (getting worse now, with LLMs) to convert the comment into a function name and add the block as a function, thinking pretty carefully about its function signature. If you have a `typedef struct state` that gets passed around, great.

The reason for splitting up this code is so that the person writing it doesn't fuck up, the input/output is expressed as types and validated before they push it. It's easy for me to review, because I can understand small chunks of code better than big chunks, and logically divides up the high level architecture from the actual implementation so I can avoid reviewing the latter if I find trouble with the former. It's also good as a workflow, where you can pair to write out the high level flow and then split off to work on implementation internally. And most importantly, it makes it possible to test the code.

I have had this discussion with many grumbly developers that think of the above as a "skill issue." I don't really want to work with those people, because their code sucks.

replies(2): >>44549208 #>>44549237 #
2. Neywiny ◴[13 Jul 25 10:36 UTC] No.44549208[source]▶
I think for me, and it sounds like for this author, the context lost by that abstraction makes it harder to review. In my experience it's easier for me to understand a small block of code, but it's harder to understand how it impacts the system when it's out of context.

For example:

x++;

A very easy piece of code to understand. But who wants x, and what values could they expect? Why do we ++ and under what conditions?

Those effects, again just for me your mileage may vary, tend to get much harder to understand.

3. ◴[13 Jul 25 10:40 UTC] No.44549237[source]▶