I'm currently preparing for an exam. One of the question I found in an old exam is:
"Why do most object oriented languages not support coroutines? (Hint: It's not because they support threads)"
The problem is, that I can't find a good answer. Of course you don't need coroutines if you have object orientation, but it would still be very useful to have them in some cases.
I think it is because of ideological reasons. In OOP main entity that represents the state is object. Nothing else should have state. In the world of coroutines they become one more carrier of state and that slightly contradicts with OOP. In C# there is minor version of coroutine: yield statement, but it is purely feature of C#, not CLR and .net itself, while compiled all state variables become fields of hidden class. It is because nothing except object can have a state in .net.
The purpose of a question like this in an exam is not to see if you know the answer. (There doesn't need to be a right answer.) Rather, it is to determine whether the student has developed the ability to think and reason within the subject domain.
If I were to answer this question I would observe: a) An actor-model is very much a merging of object-orientation with coroutines, in the sense that actors (agents) could receive and process messages concurrently. b) The real reason coroutines are not often in OOP languages is the same as the reason coroutines are not often in any mainstream language, viz. coroutines are difficult to implement in the presence of a conventional stack.
My response is almost certainly to late to help the original poster. I thought I'd respond anyway as coroutines and other forms of concurrency are currently a popular topic.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With