Prinzipiell kann man solche Interfaces auch so bauen, dass die Sprache, in der die eigentliche Spiellogik geschrieben ist, egal ist. Letztlich landet man dann aber direkt auf der Ebene der aufgabenspezifischen VM, und der geneigte XYZ-Sprachfreund müsste das Binding seiner Sprache dann selbst schreiben. Damit ist wenig gewonnen.
Ein altes, prominentes Beispiel ist die Z-Machine. Dafür gibt es etliche (wenn auch exotische) Sprachbindings. Letztlich stürzen sich aber inzwischen doch alle auf Inform7, um damit Textadventures zu entwickeln, weil die Tools gut sind und man damit die breiteste Helferbasis hat.
Oder, um mal von den Spielen wegzukommen: CGI. Das ist eine wirklich simple, wohldefinierte Schnittstelle, die man nun mit wirklich *jeder* Sprache simpel nutzen kann. Trotzdem denken immer noch mehr als 50% der Leute, dass man dazu Perl benutzen müsste, eine Sprache, die angesichts der Write-Only-Qualitäten ihrer Apologeten keine Feinde mehr braucht. Folglich will keiner CGI benutzen, sondern das direkt im Serverkontext machen, und da dann unbedingt mit PHP, weil geht ja nicht anders *FALSCH*. Geht natürlich anders, macht aber kaum einer.
Oder, um mal von den Spielen wegzukommen: CGI. Das ist eine wirklich simple, wohldefinierte Schnittstelle, die man nun mit wirklich *jeder* Sprache simpel nutzen kann. Trotzdem denken immer noch mehr als 50% der Leute, dass man dazu Perl benutzen müsste, eine Sprache, die angesichts der Write-Only-Qualitäten ihrer Apologeten keine Feinde mehr braucht.
Perl ist nicht mehr und nicht weniger read-only als andere Sprachen auch. Perl stellt alle Mittel bereit, die nötig sind, um wartbaren Code zu schreiben; wenn jemand trotzdem unwartbaren Code schreibt, dann ist es also die Schuld des Programmierers.
Folglich will keiner CGI benutzen
Zum einen halte ich Deine zugrunde liegende Annahme für falsch (ich denke nicht, dass die meisten denken, man müsste Perl verwenden, um CGI-Anwendungen zu schreiben), zum anderen ist CGI vor allem deswegen unbeliebt, weil es einfach langsam ist. Es ist gnadenlos ineffizient, für jeden Request einen neuen Prozess starten zu müssen, vor allem, wenn dabei aufwändige Schritte wie z. B. das Parsen eines Perl-Scripts jedes mal wieder durchgeführt werden müssen.
Prinzipiell kann man solche Interfaces auch so bauen, dass die Sprache, in der die eigentliche Spiellogik geschrieben ist, egal ist. Letztlich landet man dann aber direkt auf der Ebene der aufgabenspezifischen VM, und der geneigte XYZ-Sprachfreund müsste das Binding seiner Sprache dann selbst schreiben. Damit ist wenig gewonnen.
Ein altes, prominentes Beispiel ist die Z-Machine. Dafür gibt es etliche (wenn auch exotische) Sprachbindings. Letztlich stürzen sich aber inzwischen doch alle auf Inform7, um damit Textadventures zu entwickeln, weil die Tools gut sind und man damit die breiteste Helferbasis hat.
Oder, um mal von den Spielen wegzukommen: CGI. Das ist eine wirklich simple, wohldefinierte Schnittstelle, die man nun mit wirklich *jeder* Sprache simpel nutzen kann. Trotzdem denken immer noch mehr als 50% der Leute, dass man dazu Perl benutzen müsste, eine Sprache, die angesichts der Write-Only-Qualitäten ihrer Apologeten keine Feinde mehr braucht. Folglich will keiner CGI benutzen, sondern das direkt im Serverkontext machen, und da dann unbedingt mit PHP, weil geht ja nicht anders *FALSCH*. Geht natürlich anders, macht aber kaum einer.
Dasselbe gilt natürlich auch für Fast CGI, WCGI etc.