3 ms·

I'm a bit confused by all of this. The idea of coroutines existed since the 60's. Then we came up with OOP that tries to combine function + data. And now we abo

I'm a bit confused by all of this. The idea of coroutines existed since the 60's. Then we came up with OOP that tries to combine function + data. And now we abolished this, are back at only functions and are now solving the 'state capture' problem for functions again with: Coroutines? How does the history of programming paradigms/patterns make any sense? :) Good article though.

sheenobu 6y ago
The glib answer is that these kinds of things are cyclical. But C++ coroutines don't seem too incompatible with the level of OOP you already get in C++, no?
Mikhail_Edoshin 6y ago
Objects and coroutines are very closely related.
jussij 6y ago
These are features built into the language designed to make multi-threaded code safer and easier to write.
OskarS 6y ago
Your analysis of history there is a bit lacking. Coroutines didn't go out of fashion because of OOP, it went out of fashion because of structured programming and higher level languages. Coroutines are doable if you're programming directly in assembly, but if you want to do it in C-like structured languages, it turns out that it's really tricky: the whole concept of those languages are about having a single stack and hierarchical lexical structure. You can do coroutines in languages like this, but unless you want to do nasty things with longjmp and manually manipulating the stack pointer, they simply aren't built for it. You can build structured languages with first-class support for constructs with coroutines, but it took a couple of decades of programming language development for that to happen. Even today, most of the languages that support coroutines (C++20 included), only has support for the stackless kind. Basically the only languages with full stackful coroutine support in wide use are Lua and (sort-of) Go.
- spc476 6y ago
  Or take advantage of the ABI of the runtime, and use assembly. [1] Yeah, not portable. But using setjmp()/longjmp() has issues as well (way too easy to mess it up because it doesn't do what you think it's doing). [1] https://github.com/spc476/C-Coroutines https://github.com/spc476/C-Coroutines
- gpderetta 6y ago
  There is no particular difficulty in having one-shot continuations in C (or C++) and in fact over the last few decades there have been plenty of libraries implementing them. They just never caught on with the general C and C++ programming population, although they were popular in some niches. C with Classes had them from the beginning, as Stroustrup liked them in Simula, but then (like many other things) had to take them out of the language after user feedback. Re stackless coroutines and language support, while it is relatively straightforward to have stackfull coroutines as a library, the stackless kind in practice needs to be implemented as a language feature.
- diskmuncher 6y ago
  > Basically the only languages with full stackful coroutine support in wide use are Lua and (sort-of) Go. Aren't Javascript Generators also coroutines?
  - gpderetta 6y ago
    they are, as far as I know, stackless. I.e. you can only yield from the generator top level frame.
jcelerier 6y ago
> . And now we abolished this, ... no. coroutines are not supposed to be used in, like, more than an extremely small fraction of your codebase if you want to keep your code understandable
- oivey 6y ago
  Eh, I think coroutines are a convenient way to achieve concurrency and parallelism. If you limit mutation and try to reduce the long reaching accessibility of variables then I think they’re generally very understandable, especially compared to other concurrency/parallelism paradigms.
  - jcelerier 6y ago
    > Eh, I think coroutines are a convenient way to achieve concurrency and parallelism. but how often do you need concurrency and parallelism outside of handling network requests and performing some complicated math algorithm (which may be in a lib that you don't touch anyways, e.g. FFT>) ? e.g. most UI code has to run on the main thread due to macOS / Windows limitations, and in most UI software it is extremely rare to have the kind of chains of callbacks whose readability gets improved by coroutines.
    - gpderetta 6y ago
      Coroutines are not really for parallelism. I doubt you'll see them much around math heavy code. Possibly if someone implements some Cilk style work stealing executor...
- pjmlp 6y ago
  Ideally, but they taint everything they touch, that is why in C# I always start them from some point with Task.Run(), or leave it for the event and request handlers.

sheenobu 6y ago

The glib answer is that these kinds of things are cyclical. But C++ coroutines don't seem too incompatible with the level of OOP you already get in C++, no?

Mikhail_Edoshin 6y ago

Objects and coroutines are very closely related.

jussij 6y ago

These are features built into the language designed to make multi-threaded code safer and easier to write.

OskarS 6y ago

Your analysis of history there is a bit lacking. Coroutines didn't go out of fashion because of OOP, it went out of fashion because of structured programming and higher level languages. Coroutines are doable if you're programming directly in assembly, but if you want to do it in C-like structured languages, it turns out that it's really tricky: the whole concept of those languages are about having a single stack and hierarchical lexical structure. You can do coroutines in languages like this, but unless you want to do nasty things with longjmp and manually manipulating the stack pointer, they simply aren't built for it. You can build structured languages with first-class support for constructs with coroutines, but it took a couple of decades of programming language development for that to happen. Even today, most of the languages that support coroutines (C++20 included), only has support for the stackless kind. Basically the only languages with full stackful coroutine support in wide use are Lua and (sort-of) Go.

spc476 6y ago
Or take advantage of the ABI of the runtime, and use assembly. [1] Yeah, not portable. But using setjmp()/longjmp() has issues as well (way too easy to mess it up because it doesn't do what you think it's doing). [1] https://github.com/spc476/C-Coroutines https://github.com/spc476/C-Coroutines
gpderetta 6y ago
There is no particular difficulty in having one-shot continuations in C (or C++) and in fact over the last few decades there have been plenty of libraries implementing them. They just never caught on with the general C and C++ programming population, although they were popular in some niches. C with Classes had them from the beginning, as Stroustrup liked them in Simula, but then (like many other things) had to take them out of the language after user feedback. Re stackless coroutines and language support, while it is relatively straightforward to have stackfull coroutines as a library, the stackless kind in practice needs to be implemented as a language feature.
diskmuncher 6y ago
> Basically the only languages with full stackful coroutine support in wide use are Lua and (sort-of) Go. Aren't Javascript Generators also coroutines?
- gpderetta 6y ago
  they are, as far as I know, stackless. I.e. you can only yield from the generator top level frame.

jcelerier 6y ago

> . And now we abolished this, ... no. coroutines are not supposed to be used in, like, more than an extremely small fraction of your codebase if you want to keep your code understandable

oivey 6y ago
Eh, I think coroutines are a convenient way to achieve concurrency and parallelism. If you limit mutation and try to reduce the long reaching accessibility of variables then I think they’re generally very understandable, especially compared to other concurrency/parallelism paradigms.
- jcelerier 6y ago
  > Eh, I think coroutines are a convenient way to achieve concurrency and parallelism. but how often do you need concurrency and parallelism outside of handling network requests and performing some complicated math algorithm (which may be in a lib that you don't touch anyways, e.g. FFT>) ? e.g. most UI code has to run on the main thread due to macOS / Windows limitations, and in most UI software it is extremely rare to have the kind of chains of callbacks whose readability gets improved by coroutines.
  - gpderetta 6y ago
    Coroutines are not really for parallelism. I doubt you'll see them much around math heavy code. Possibly if someone implements some Cilk style work stealing executor...
pjmlp 6y ago
Ideally, but they taint everything they touch, that is why in C# I always start them from some point with Task.Run(), or leave it for the event and request handlers.