Warum unterstützen die meisten objektorientierten Sprachen keine Coroutinen?

Ich denke, es ist aus ideologischen Gründen. In der OOP-Haupteinheit, die den Status darstellt, handelt es sich um ein Objekt. Nichts anderes sollte state haben. In der Welt der Coroutines werden sie zu einem weiteren Träger des Staates und dies widerspricht leicht der OOP. In C # gibt es eine Nebenversion der Anweisung coroutine: yield, aber es ist ein reines Merkmal von C #, nicht CLR und .net selbst, während alle Statusvariablen zu Feldern versteckter Klassen kompiliert werden. Dies liegt daran, dass nichts außer dem Objekt einen Status in .net haben kann.

Der Zweck einer solchen Frage in einer Prüfung ist nicht zu sehen, ob Sie die Antwort wissen. (Es muss keine richtige Antwort geben.) Es ist eher zu bestimmen, ob der Schüler die Fähigkeit entwickelt hat, innerhalb der Fachdomäne zu denken und zu argumentieren.

Wenn ich diese Frage beantworten würde, würde ich folgendes beobachten: a) Ein Akteurmodell ist eine Verschmelzung von Objektorientierung und Koroutinen, in dem Sinne, dass Akteure (Agenten) Nachrichten gleichzeitig empfangen und verarbeiten können. b) Der wahre Grund, warum Koroutinen nicht oft in OOP-Sprachen vorkommen, ist der gleiche wie der Grund, warum Koroutinen in keiner Mainstream-Sprache häufig vorkommen, nämlich. Koroutinen sind in Gegenwart eines konventionellen Stacks schwer zu implementieren.

Meine Antwort ist fast sicher zu spät, um dem ursprünglichen Poster zu helfen. Ich dachte, ich würde trotzdem reagieren, da Koroutinen und andere Formen der Nebenläufigkeit derzeit ein beliebtes Thema sind.

Das klingt für mich wie eine lausige Frage nach einer Prüfung - es ist sehr subjektiv, und es gibt keine richtige Antwort oder sogar die beste Antwort. Um es kurz zu machen, ich glaube nicht, dass irgendjemand viel mehr tun kann, als das zu erraten.

Meine eigene Vermutung ist, dass es vor allem daran liegt, dass die Sprachen, die Coroutinen enthalten (zB Concurrent Pascal, Concurrent C (die eigentlich das C ++ der Zeit unterstützt haben) und Ada Tasks ähnlich sind), nie geworden sind besonders beliebt. Aus technischer Sicht sind diese Designs schon sehr gut, aber sie sind nie besonders populär geworden. Bis zu einem gewissen Grad ist das wahrscheinlich eine Frage des Timings. Zu der Zeit, als Multiprozessor-Computer verfügbar wurden, um das parallele Rechnen für die meisten Programmierer zu einem echten Ziel zu machen, waren diese Sprachen bereits größtenteils vergessen.

Aus technischer Sicht bin ich mir nicht sicher, ob irgendjemand viel Neues hinzuzufügen hat - vor allem, was benötigt wird, ist ein gutes Verkaufsgespräch, um Concurrent C oder Ada 95 (usw.) wie etwas Neues und Innovatives klingen zu lassen um Leute dazu zu bringen, sie zumindest auszuprobieren. Natürlich waren Implementierungen von vor Jahrzehnten oft single-threaded unter der Haube - das müsste aktualisiert werden. Zum Beispiel bin ich sicher, dass Ada 95-Implementierungen aktualisiert wurden, so dass sie mehrere Kerne recht gut verwenden können. Das scheint jedoch nicht viel an Popularität zu haben (z. B. wurde das ada -Tag in SO bisher nur 90 Mal verwendet).

Die Idee eines Objekts besteht darin, den Zustand zu isolieren. Alles, was Sie brauchen, sollte in diesem Objekt vorhanden sein. Eine Coroutine "bricht" diese Idee, denn ein Objekt ist jetzt kein isolierter Zustand mehr, sondern hängt von einem anderen Objekt ab.

Nun, tatsächlich haben sowohl Simula 67 als auch Smalltalk 80 - die definitive und ultimative OO-Sprache - die Korutinen perfekt unterstützt. Daher bezweifle ich, dass die Idee der Korotinen grundsätzlich mit OOP per se unvereinbar ist. Es ist wahrscheinlicher, dass es ein Zufall ist, eine Art Frage wie "Warum wird das Coole nicht in den Hauptsprachen / Betriebssystemen / etc unterstützt?".