3 ms·

Totally fair. I think a lot of the things we used to do in the name of efficiency has been completely lost in the progress of time. Largely from the emergence

by taeric 1y ago

Totally fair. I think a lot of the things we used to do in the name of efficiency has been completely lost in the progress of time. Largely from the emergence and refinement of JIT compilers, I think? That is, a lot of why you would go with macros in the past was to avoid the expense of function calls. Right? We have so far left the world of caring about function call overhead for most projects, that it is hard to really comprehend. Coroutines still strike me as a hard one to really grok. I remember reading them in Knuth's work and originally thinking it was a fancy way of saying what we came to call functions and methods. I think without defining threads first, defining a coroutine is really hard to nail down. And too many of us take understanding of threads as a given. Despite many of us (myself not immune) having a bad understanding of threads.

bvrmn 1y ago
Coroutines as a technique to implement state machines is the first things which comes to my mind. It's a more abstract and requires a way less fundamentals to know comparing to concurrency.
- taeric 1y ago
  But coroutines really only work any better than "objects" if you understand the implication to the stack pointer? Which requires understanding exactly what a thread is. Right? That is, a basic class that has defined state and methods to modify the state is already enough to explain a state machine. What makes coroutines better for it?
  - bvrmn 1y ago
    The issue with state you should handle it. Compare for example some iterator implementation in Java and Python. Latter needs only one method with coroutine and no state to store on object level. > the state is already enough to explain a state machine. I did not talk about explaining state machines but implementing state machines as coroutines. Progression: give an idea of state machines, show how hard is to handle state, present coroutines as way to handle states.
    - taeric 1y ago
      Fair that they are a way to implement without having to give more details. Those details are pushed to somewhere else, though. Which tends to make then less good for pedagogical reasons, to me. Also a bit harder to reason about to me, for some reason.

by taeric 1y ago

bvrmn 1y ago

Coroutines as a technique to implement state machines is the first things which comes to my mind. It's a more abstract and requires a way less fundamentals to know comparing to concurrency.

taeric 1y ago
But coroutines really only work any better than "objects" if you understand the implication to the stack pointer? Which requires understanding exactly what a thread is. Right? That is, a basic class that has defined state and methods to modify the state is already enough to explain a state machine. What makes coroutines better for it?
- bvrmn 1y ago
  The issue with state you should handle it. Compare for example some iterator implementation in Java and Python. Latter needs only one method with coroutine and no state to store on object level. > the state is already enough to explain a state machine. I did not talk about explaining state machines but implementing state machines as coroutines. Progression: give an idea of state machines, show how hard is to handle state, present coroutines as way to handle states.
  - taeric 1y ago
    Fair that they are a way to implement without having to give more details. Those details are pushed to somewhere else, though. Which tends to make then less good for pedagogical reasons, to me. Also a bit harder to reason about to me, for some reason.