Verschiedene Sprachen in einem Projekt verwenden

Question

Ich habe kürzlich von der Verwendung verschiedener Sprachen in einem (großen) Projekt gehört, ich habe auch über berühmte Dienste wie Twitter gelesen, die Rails als Frontend verwenden, gemischt mit anderen Sprachen und Scala, denke ich Es war als Backend.

• Ist das gängige Praxis? Wer macht das?

• Ich bin sicher, dass es Nachteile gibt. Ich denke, dass Sie Probleme mit den verschiedenen Dolmetschern/Compilern haben und die verschiedenen Sprachen nahtlos verbinden werden. Ist das wahr?

• Warum wird das eigentlich gemacht? Für die Leistung?

Answer 1

Ich glaube, dass im Falle von Twitter war es leistungsbezogen; Scala ist ein wenig schneller als Ruby, und sie benutzen es, um ihre Warteschlangensysteme zu versorgen.

Abgesehen von Wartungsproblemen kann die Verwendung mehrerer Sprachen helfen, die Nachteile in jeder Sprache auszugleichen. Mit Twitter eignet sich Ruby (on Rails) hervorragend zum Ausführen des Frontends ihrer Website, aber es ist sinnvoller, eine schnellere Sprache zu verwenden, um die Hintergrundaufgaben im Hintergrund zu verarbeiten. Die Integration zwischen den Sprachen ist nicht schwierig, wenn es sich um Warteschlangensysteme handelt, da sie vollständig von der Anwendung getrennt sein können und ihre Aufgaben dennoch korrekt ausführen.

Answer 2

Die Frage geht im Wesentlichen auf Domain Specific Languages ​​(DSLs). Manchmal ist eine Sprache besser für einen Teil des Programms und eine andere Sprache für ein anderes Programm geeignet. Die Vorteile (Ausführungsgeschwindigkeit oder Einfachheit der Entwicklung) überwiegen oft die Nachteile des Mischens mehrerer Sprachen.

• Ist das gängige Praxis? Wer macht das?

Sehr häufig; Ich würde sagen, dass fast jede große Anwendung in mehr als einer Sprache geschrieben ist.

Betrachten Sie das Beispiel eines Spiels. Die Kern-Engine wird normalerweise in C oder C++ für Geschwindigkeits- und Low-Level-Hardware-Zugriff geschrieben, aber das Verhalten von Objekten und Zeichen wird in einer höheren Sprache wie Lua geschrieben.

• Ich bin sicher, dass es Nachteile gibt. Ich denke, dass Sie Probleme mit den verschiedenen Dolmetschern/Compilern haben und die verschiedenen Sprachen nahtlos verbinden werden. Ist das wahr?

Ja, es gibt eine gewisse Menge an Overhead-Skripts zu ermöglichen, die Objekte im Spiel und so zuzugreifen.

• Warum wird das eigentlich gemacht? Für die Leistung?

Ja und nein. Wenn die Leistung kein Problem darstellte, könnte das gesamte Spiel in einer Skriptsprache geschrieben werden.Einige andere Gründe sind:

• Geschwindigkeit der Entwicklung; Stellen Sie sich den Overhead vor, wenn all die kleinen Objekte und Charaktere in einem Spiel wie World of Warcraft in C++ geschrieben wurden. Das Programm müsste für jede kleine Änderung kompiliert und neu gestartet werden.

• Modularität; Neue Objekte können einfach heruntergeladen und zur Laufzeit hinzugefügt/entfernt werden, und erfahrene Benutzer können sie sogar modifizieren.

• Portabilität; Die gleichen Skripts werden auf verschiedenen Plattformen unverändert ausgeführt.

Answer 3

Ich habe mehrere Projekte mit gemischten Sprachen

In einem Fall habe ich einige F # mit C# gemischt, weil f # mir erlaubt ein Problem leichter zu kodieren (und war eine Herausforderung)

anderen Fällen würde Mischen von Silverlight und .net im selben Projekt - sie verwenden unterschiedliche CLR

In anderen Fällen habe ich vb.net und C# wenn Unternehmen Programmierer hatten, die mehrere Sprachen verwenden - die meisten Menschen, mit denen ich arbeite, kann nicht lesen .. Irgendein Code, der dabei gemacht wird, wäre wahrscheinlich nicht ich im besten Interesse des Arbeitgebers.

Der Hauptnachteil ist, dass jeder, der an dem Code arbeitet, alle Sprachen kennen muss.

Es ist nicht so etwas, was ich oft mache, aber es geht wirklich um die Werkzeuge für den Job imo.

Ich würde nicht sagen, es ist für die Leistung in der Regel getan ... obwohl ich mit C++ DLLs verbunden habe, wenn ich etwas sehr vey schnell (Grafik-Algorithmen, bevor ich keine Cuda tun kann) getan werden kann, tun ... die Entscheidungen Umgebungsleistung sind größer als Rechenzeit. Die üblichen Gemeinkosten wie Skalierbarkeit, Lesefreundlichkeit kommen immer noch ins Spiel. Dh ich glaube, Sie seine über die Leistung sagen kann, so lange wie Sie die Leistung nicht begrenzen die Geschwindigkeit o FDie Programme Ausführung

Answer 4

In einer typischen eingebetteten Anwendung meine ich für die 8051 zu schreiben, habe ich mehrere Sprachen beteiligt: ​​

• C - Der Großteil der Anwendung ist in C, da es viel schneller zu schreiben ist, aber es ist einfach, engen Code zu erzeugen, der in 64k (oder weniger) Coderaum passt.
• Assemblersprache - manchmal kommt man mit Compiler generiertem Code nicht zurecht. Wenn jedes Byte zählt, Regeln für die Assemblersprache.
• Perl - Mehrere meiner Build-Tools sind in Perl geschrieben. Eine leistungsstarke, flexible und dynamische Sprache wie Perl macht es einfach, mit ROM-Images zu arbeiten und viele Aspekte des Build-Prozesses zu bearbeiten.
• GNU machen - Huh? Ja, machen ist eine Sprache. Es ist eine deklarative Sprache (eine andere Kategorie von Sprache, die gleichwertig ist mit "objektorientiert", "funktional" und "imperativ"). Make ist die Grundlage meines Build-Systems.

Ich mache das, weil ich gerne das richtige Werkzeug für jeden Job verwenden. Ich muss C und Assembler für das winzige 8-Bit-Mikro verwenden. Ich benutze C so viel wie möglich, weil ich mehr Arbeit bekomme. Ich benutze Perl, um komplexe build-bezogene Aufgaben zu erledigen, weil es produktiver ist als C und leistungsfähiger und portabler als bash.Ich verwende GNU make als Grundlage meines Builds, weil es sehr gut auf die Verarbeitung von Abhängigkeitsbeziehungen zugeschnitten ist und es einfach macht, diese Metadaten zu erstellen und zu pflegen und sie auf meinen Projekt-Build-Prozess anzuwenden - mit anderen Worten: Produktivität.

Der große Nachteil dieses Ansatzes ist der offensichtliche: Verständnis meiner App erfordert einen Ingenieur, C, Assembler, Perl und make zu verstehen.

Answer 5

Viele Projekte sind gemischte Sprache. Eine der am häufigsten gemischten Sprachen ist SQL, und sie zeigt ein Schlüsselmerkmal gemischtsprachiger Projekte: Jede Sprache konzentriert sich auf die Teile des Problems, in denen es gut ist, und kompensiert die Schwächen des anderen (s). Im Fall von SQL behandelt es den relationalen Datenbankzugriff und lässt andere Dinge (sei es die GUI oder der Webservice oder ...) anderen Sprachen, die besser sind. Ich würde so weit gehen, zu sagen, dass das Verwenden einer einzigen Sprache fast so ist, als würde man nur einen Hammer verwenden, um ein Haus zu bauen; Ja, du brauchst einen Hammer, aber du brauchst auch ein paar andere Werkzeuge.

Ich kenne Projekte, die eine Mischung aus jQuery, Tcl, C, Fortran und SQL in einem Projekt verwenden. (Es ist eine Web-Anwendung, angetrieben von einem Webserver in Tcl geschrieben, mit Rechenkomponenten in C und Fortran und eine Datenbank über SQL zugegriffen.)

Answer 6

Betrachten sie das durchschnittliche Web-Projekt, und wie viele Sprachen beinhaltet:

HTML, CSS, JavaScript/JQuery, Java, SQL/HSQL.

Wenn jede Sprache weit besser geeignet, um die Domain als die Sprachen, die Sie bereits verwenden, in einer anderen Sprache werfen.

Ich hatte auch datenintensive Programme mit einer Web-Front in Java geschrieben Ende , aber ein Backend (um Zahlen tatsächlich zu knacken) geschrieben in C, gehostet auf verschiedenen Servern, und so weiter.

Und ich muss sagen, modellieren Sie nicht von Twitter. Es ist unwahrscheinlich, dass Sie eine Idee haben, dass so viele Menschen so viel wollen, dass sie keine Rentabilität haben, für die Anleger Sie mit Geld überschütten. Sie sind auch absolut furchtbar in der Passform und enden an einigen Stellen; Wenn Sie jemals Ihr Google Mail-Passwort eingegeben haben, ist es wahrscheinlich, dass es im Klartext übertragen wurde, und für mindestens zwei Jahre konnten Sie Freunde ohne ihre Erlaubnis durch die Textnachrichtenschnittstelle. (Gah.)

Answer 7

Ist das gängige Praxis? Warum wird das eigentlich gemacht? Für die Leistung?

Ja. Leute, die es tun, versuchen im Allgemeinen, vorhandene Software wiederzuverwenden (die Ihnen aufgefallen ist, dass sie in mehreren Sprachen geschrieben ist) oder versuchen, mehrere verschiedene Sprachen zu verwenden, wobei jede für sich gut ist.

Leistung kann manchmal verwandt sein; zum Beispiel kann ich will Lua für seine Rapid-Prototyping-Fähigkeiten nutzen, sondern sie zu einem hochperformante E-Mail-Parser in C.

Ich denke, geschrieben verbinden, dass Sie Probleme mit den verschiedenen Dolmetscher/Compiler haben wird und sich nahtlos verbindet die verschiedenen Sprachen. Ist das wahr?

Manchmal. Der Stand der Praxis in mehreren Sprachen ist ungefähr so, dass, wenn eine Sprache mit etwas anderem als sich selbst sprechen wird, sie mit C sprechen wird. So ist es oft möglich, Dinge durch eine Art C-ähnliche Schnittstelle zusammenzuarbeiten.

Andernfalls tauchen die ersten Probleme normalerweise entweder in der Speicherverwaltung oder in einer VM-Schicht auf, die wir als Beispiele für "verwalteten Code" betrachten könnten. Es ist sehr schwierig, ein Haskell-Programm zum Austausch von Heap-allokierten Objekten mit einer JVM zu erhalten. Eine typische Problemumgehung besteht darin, diese Art von Aufrufen wie Remoteprozeduraufrufe zu behandeln, so als ob die Programme in verschiedenen Prozessen oder sogar auf verschiedenen Computern ausgeführt würden. Solche Anrufe können einen beträchtlichen Overhead mit sich bringen, wodurch es zum Beispiel für zwei verschiedene Sprachen oft zu einem unverhältnismäßig hohen Aufwand wird, sich umwandelbare Objekte zu teilen. Wenn Sie die Dinge nicht mutieren müssen, sind die Gemeinkosten nicht so schlecht.

Zusammenfassung: gibt es gute Gründe, unterschiedliche Sprachen zu verwenden, um verschiedene Probleme zu lösen, und es wäre überraschend, wenn ein großes Software-System tut nicht Verwendung mehrere Sprachen (außer vielleicht in einsprachigen Silos wie Squeak Smalltalk, die einfach nicht mit dem Rest der Welt sprechen). Es gibt sicherlich Schwierigkeiten mit der Interoperabilität, aber das Problem ist ein altes Problem und Workarounds sind bekannt.