Why do most object oriented languages not support coroutines?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

This is just a guess:

A coroutine uses the state of the subroutine to alter its return value, whereas a method on an object can use the object state to alter its return value.

Answer 4

This sounds to me like a lousy question for an exam -- it's highly subjective, and there is no one right answer or even best answer. To make a long story short, I don't think anybody can do much more than guess at this.

My own guess is that it's mostly because the languages that have included coroutines (e.g., Concurrent Pascal, Concurrent C (which actually supported the C++ of the time), and Ada Tasks are sort of similar as well), have never become particularly popular. From a technical viewpoint, these designs are already extremely good, but they've never become particularly popular. To a degree, that's probably a matter of timing as much as anything else. By the time multiprocessor computers became available to make parallel computing a real goal for most programmers, these languages were already mostly forgotten.

From a technical viewpoint, I'm not sure anybody has a lot new to add -- mostly what's needed is a good "sales pitch" to make Concurrent C or Ada 95 (etc.) sound like something new and innovative enough to get people to at least try them out. Of course, implementations from decades ago were often single-threaded under the hood -- that would need updating. For one example, however, I'm sure Ada 95 implementations have been updated so they can use multiple cores quite nicely. That doesn't seem to have done a lot of its popularity though (e.g., here on SO, the ada tag has currently been used only 90 times).

Answer 5

The idea of an object is to isolate state. Everything you need should be present in that object. A coroutine will 'break' this idea because now an object is no longer an isolated state, but rather it depends on another object.

Answer 6

Well, actually both Simula 67 and Smalltalk 80 - the definitive and ultimate OO languages - did support coroutines perfectly. So I doubt the idea of coroutines is fundamentally incompatible with OOP per se. It's more likely to be a coincidence, that sort of question like "why is the cool thing X not supported in the mainsteam languages/operating systems/etc".