[Artikel] Mono/.NET kein guter Ansatz?

[bakunin]

Hi!

Ich habe mal ein paar Gedanken aufgeschrieben, die mir gerade in den Sinn kamen. Ich finde das Resultat nicht interessant, relevant, tiefgründig und gut genug, um es als Artikel zu veröffentlichen. Da ich es aber schon geschrieben haben, poste ich es halt mal hier. Vielleicht wäre auch ein anderes Forum besser geeignet, etwa Diskussionen über Diskussionen oder so. Aber eigentlich ist es mir egal, ob damit eine Diskussion angestoßen wird, aber wer es kommentieren möchte, kann das natürlich gerne tun. Auch korrekturen für eventuelle inhaltliche Fehler sind willkommen.

(Dass .NET eigentlich etwas mehr umfasst, ist mir klar, aber mir geht es um den Aspekt, der als hauptsächlicher Vorteil meist genannt wird.)

-------------------

Dieser Artikel besteht aus vier Teilen. Zunächst werde ich erläutern, warum das Kombinieren von Quelltexten, die in unterschiedlichen Programmiersprachen geschrieben wurden, ein relevantes Problem ist. Danach werde ich Ihnen drei verschiedene Modelle präsentieren, die dieses Problem lösen sollen.

1. Das Problem

Heute sind unzählige Programmiersprachen im Einsatz. Für welche man sich entscheidet, hängt einerseits von persönlichen Vorlieben ab, andererseits aber auch davon, ob es für das Lösen einer Aufgabe hilfreiche Bibliotheken für eine bestimmte Sprache gibt, d.h. ob man vorhandenen Code wiederverwenden kann. Ein dritter Faktor ist, wie geeignet die betreffende Sprache für die betreffende Aufgabe ist.

Weil die persönlichen Vorlieben stark variieren und unterschiedliche Sprachen für unterschiedliche Zwecke unterschiedlich gut geeignet sind, gibt es für verschiedene Sprachen oft eigene Bibliotheken, die mehr oder weniger das gleiche machen. Hier wird Arbeit mehrfach erledigt, obwohl es prinzipiell möglich wäre, dies zu verhindern.

Einen anderen Grund kriegen alle Projekte zu spüren, die Schnittstellen zu verschiedenen Programmiersprachen bereitstellen möchten, was keineswegs nur das GNOME-Projekt ist. Beispielsweise dürfte auch das GNU Hurd-Projekt mittelfristig sich mit diesem Thema auseinandersetzen müssen. Selbst Linux würde es nicht schaden, wenn Module in verschiedenen Sprachen erstellt werden könnten, sofern BASIC
hiervon ausgeschlossen wird.

2. Lösung A: Bytecode

Die von Microsofts .NET angestrebte Lösung, die in Mono eine freie Implementierung gefunden hat und zukünftig möglicherweise in GNOME Einzug hält, ist die Verwendung eines Zwischencodes. Ein Compiler erzeugt dabei nicht direkt Maschienencode, sondern einen Bytecode, der später beispielsweise mit Hilfe eines JIT-Compilers in Maschienencode umgesetzt werden kann. Compiler für sämtliche Sprachen erzeugen dabei den gleichen Zwischencode, wodurch die einzelnen Teile problemslos zusammenarbeiten.

Bei näherer Betrachtung wird das Problem dadurch nur teilweise gelöst. Zwar können Bibliotheken von allen Programmiersprachen gemeinsam genutzt werden, doch dazu muss jede Programmiersprache die Möglichkeit bieten, entsprechenden Bytecode zu erzeugen. Es muss wohlgemerkt nicht nur jede bisher existierende Sprache angepasst werden, es müssen auch alle Zukünftigen über diese Möglichkeit verfügen. Es ist fraglich, ob sich eine solche Lösung jemals durchsetzt, da viel Arbeit erforderlich ist, damit das gewünschte Ergebnis erreicht wird und selbst dann ist noch lange nicht sichergestellt, dass dieses Konzept auch langfristig bestehen kann.

3. Lösung B: Dynamische Programmiersprache

Diese Lösung wird vom wenig bekannten Pliant-Projekt umgesetzt. Es ist im Wesentlichen ein Ein-Mann-Projekt, aber dennoch erstaunlich weit fortgeschritten. Es handelt sich um eine Programmiersprache, die dynamisch in sich selbst erweitert und geändert werden kann. Etwa kann sie so geändert werden, dass C-Code direkt verstanden wird. Außerdem wäre für neue Paradigmen keine neue Programmiersprache erforderlich, d.h. wärend C nur mit von der Sprache direkt angebotener Objektorientierung ausgestattet werden konnte, indem eine neue Programmiersprache geschaffen wurde (nämlich Objective-C; Gerüchten zufolge auch C++), könnte bei Pliant etwas Vergleichbares getan werden, indem man eine Bibliothek hinzufügt. "Nebenbei" wird hierbei auch erreicht, dass unterschiedliche Programmiersprachen kombiniert werden können.

Eine so dynamische Sprache hat gewiss einige Vorteile, doch als Lösung für das hier behandelte Problem ist sie ungeeignet, da sie über alle Nachteile der Lösung A verfügt, nur dass diese hier noch deutlich verstärkt auftreten.

4. Lösung C: Stub-Code

Diese Lösung lohnt sich am meisten, wenn es unterschiedliche Implementierungen für die gleiche Schnittstelle gibt (Polymorphie). Es wird in einer eigenen Definitionssprache eine Schnittstelle festgelegt. Für jede Programmiersprache wird dann automatisch eine dünne Schicht (sogenannter Stub-Code) erstellt, die besagte Schnittstelle von der Programmiersprache aus zugänglich macht, wobei das Konvertieren in jeweils angemessene Datentypen Aufgabe des Stub-Codes ist. Auch die Gegenseite muss unterstützt werden, d.h. das Implementieren dieser Schnittstelle mittels einer beliebigen Programmiersprache, was ebenfalls durch aus der Schnittstellendefinition generierten Stub-Code erreicht wird. Es muss hierzu nur ein einzelnes Programm gepflegt werden, jenes von den Implementierungen der Programmiersprachen unabhängig ist und natürlich zur Aufgabe hat, Stub-Code zu erzeugen.

Hierbei kann es unter Umständen zu gewissen Performance-Einbußen zur Laufzeit kommen, doch die Umsetzung dieser Lösung ist realistisch betrachtet um ein Vielfaches einfacher. Das Schöne ist, dass es bereits derartige Ansätze gibt, beispielsweise geht CORBA in diese Richtung. Auch in Hurd dürfte diese Variante verwendet werden, da hier Polymorphie praktisch im ganzen System anzutreffen ist.

-------------------

Cheers,
GNU/Wolfgang

[arni]

Du hast die vierte Methode vergessen: Dual-Endian.
Die VM hat bei dieser Variante eine weitaus bessere Performance weil sie keinen JIT benutzt sondern stattdessen dual-endian binaries unterstützt. Vertreter dieser Gattung ist "Internet C++".

[bakunin]

Hi Arni!

Kannst du das mal näher erläutern?

Cheers,
GNU/Wolfgang

[arni]

Hi Wolfgang,

So wie ich das verstanden habe:
Die VM unterstützt (Binär)Dateien die beide Formate (Big- und Little-Endian) beinhalten können. Ausgeführt wird die Datei von der VM dann im nativen Endian der Hostmaschine. Dadurch enstehen wohl keine Geschwindigkeitseinbussen in Zusammenhang mit "Endian" Konvertierung usw. Der andere Punkt ist, das wohl ein spezieller Registersatz- und Modell genutzt wird, mit dem direkt auf die Hardware-Register gemappet werden kann. Man braucht eigentlich nur einen gepatchten gcc und kann dann normal in C++/C schreiben. Es ist damit auch ziemlich einfach z.b. selbst OpenGL und/oder Spiele in dieser VM laufen zu lassen. (Quake soll z.b. mit fast nativer Geschwindigkeit laufen)


Dieses "Internet C++" steht jetzt unter der GPL. Ich hatte es mal vor etlicher Zeit getestet (ging sehr gut!) aber es war unter einer inakzeptablen Lizenz. Die Leute des Projektes selbst, sehen es als Alternative zu Java und C#.

http://ivm.sourceforge.net/

[arni]

Mmh - fällt mir noch so ein. Die Sache mit dem Stub Code hat noch einen Nachteil: Versuche mal bei Corba oder DCOM Implementierungsvererbung..
Genaugenommen geht nur Schnittstellenvererbung. Mit Java, C#, Internet C++ ist das alles kein Problem.
Ich finde zudem Aggregation weitaus schwieriger zu implementieren.