Polyglotte Programmierung: Ist die Erstellung von Anwendungen in mehreren Sprachen eine gute Praxis?

Question

Ich erwäge den Aufbau einer Anwendung, die eine Mischung aus einer dynamischen Sprache (Python oder Ruby) und einer kompilierten Sprache ist, und brauche etwas Hilfe, um mich davon zu überzeugen, dass dies eine gute Idee ist.

Mein Gedanke ist, dass ich eine dynamische Sprache verwenden kann, um schnell eine Menge Code zu schreiben, und dann auf eine kompilierte Sprache wie C/C++ zurückgreifen kann, um leistungsrelevanten Code zu implementieren.

Ich sehe viele Vorteile in diesem Ansatz:

1. Gesteigerte Produktivität durch primäres Programmieren in der dynamischen Sprache
2. Verfügbarkeit von Bibliotheken in beiden Sprachen

Aber es gibt auch einige Nachteile:

1. Aufrechterhaltung einer Brücke zwischen den beiden Sprachen
2. Abhängigkeit von zwei Sprachen und Sprach-/Bibliotheksfehlern anstelle von einem

Was sind die weiteren Vor- und Nachteile dieses Ansatzes? Kennt jemand Ressourcen und/oder bewährte Verfahren zu diesem Thema?

Answer 1

Ich bin dafür, das beste Werkzeug für die Arbeit zu verwenden. Im Fall der Softwareentwicklung bedeutet das, polyglott zu sein. Man würde nie von einem Zimmermann erwarten, dass er nur einen Hammer benutzt, egal was er baut. Warum sollte es bei uns anders sein?

Answer 2

@ Zorkerman

Ich habe Erfahrung sowohl mit Jython als auch mit JRuby... viel mehr mit JRuby.

Ich muss sagen, sie sind großartige Plattformen, und Sie erhalten den großen Vorteil von dynamischen Sprachen, PLUS die reichhaltige Unterstützung von 3rd- und 1st-Party-Bibliotheken von Java, PLUS eine hochgradig plattformunabhängige kompilierte Basissprache, PLUS Garbage Collection in beiden Sprachen (es ist wichtig, das Speichermanagement zu verstehen, aber ich bin der Meinung, dass Sie es besser vermeiden sollten, es sei denn, Sie brauchen es WIRKLICH, z. B. wenn Sie Treiber oder Sachen auf Kernel-Ebene machen, oder Sachen, die jedes Quäntchen Leistung brauchen, das Sie aufbringen können).

Ich möchte nur eine kurze Anekdote erzählen. Ich habe kürzlich ein Ruby-Skript zum Indizieren einer Solr-Instanz erstellt und musste auf eine DB2-Datenbank zugreifen (die Quelle unserer zu indizierenden Daten). Straight Ruby scheiterte kläglich... es hat eine schreckliche DB2-Unterstützung, die eine vollständige Installation der DB2 Express Edition erfordert... die immer noch nicht wie angekündigt funktionierte (ich konnte die Ruby-Treiber nicht kompilieren, nachdem ich die Installation beendet hatte). Die Lösung war, einfach zu JRuby zu wechseln und JDBC von der Ruby-Seite aus zu verwenden, mit ein paar einfach zu installierenden Jars (und viel, viel, viel kleineren Dateien als die DB2-Installation).

Ich würde auf jeden Fall empfehlen, JRuby oder Jython statt C als Backend zu verwenden... Ich habe festgestellt, dass die Leistung von Algorithmen und Ressourcen in der Regel einen viel größeren Einfluss auf die Anwendungsleistung hat als die gewählte Sprache, und die Java-Plattform hat so viel zu bieten (und sie hat sich seit den frühen Tagen, als die Leute sie als wesentlich langsamer als C/C++ bezeichneten, sehr weiterentwickelt). Wenn Sie nicht gerade sehr rechenintensive Dinge tun, die nicht algorithmisch refaktorisiert werden können, werden Sie höchstwahrscheinlich nicht auf eine kompilierte Sprache zurückgreifen müssen, unabhängig von Ihrer Wahl.

---

PS Die Integration mit Java in JRuby ist sehr nahtlos (jedenfalls von der JRuby- zur Java-Seite), so dass die Aufrechterhaltung einer Brücke kein Problem ist. Jython ich denke, ist das gleiche, aber wieder meine Erfahrung mit ihm ist viel weniger.

Answer 3

Es ist erwähnenswert, dass Gambit Scheme und Chicken (und ein paar andere Implementierungen) in einem interpretierten Modus laufen und dann nach C kompiliert werden können.

Answer 4

Ich halte das für eine gute Idee.

Da die meisten (fast alle?) Betriebssysteme in C oder C++ geschrieben sind, greift jede dynamische oder interpretierte Sprache auf einer gewissen Ebene auf eine kompilierte, optimierte Sprache für Low-Level-Sachen zurück.

Answer 5

Manche Leute behaupten, dass wir Programmierer zu viele Sprachen beherrschen müssen. Sie argumentieren, dass das Hinzufügen einer Sprache eine schlechte Sache ist.

Der gesamte Datenzugriff in SQL, die Darstellung in HTML/CSS scheint unumkehrbar zu sein.

Die Sache mit XML ist ein wenig ermüdend: Manche Leute versuchen, alles in XML zu machen, als ob XML magische Kräfte hätte, um Software besser zu machen.

Außerdem gibt es wegen der vielen Sprachen eine Menge Redundanz. All die sprachübergreifenden Bindungen bedeuten, dass Dinge zweimal geschrieben werden, einmal in jeder Sprache.