Beispiele dafür, wann wir interpretierte Sprache gegenüber kompilierter Sprache verwenden?

Ich verstehe die Unterschiede zwischen interpretierten und kompilierten Sprachen, aber wenn jemand einige Beispiele für Situationen liefern könnte, in denen man wahrscheinlich interpretierte Sprachen über kompilierte Sprachen verwendet, sowie Situationen, in denen man wahrscheinlich kompilierte Sprachen über interpretierte Sprachen verwendet, würde dies der Fall sein sei wirklich hilfreich.

Es gibt (meines Wissens) keine interpretierte "Sprache" oder kompilierte "Sprache".

Sprachen geben die Syntax und Bedeutung der Schlüsselwörter, Flusskonstrukte und verschiedener anderer Dinge des Codes an, aber mir ist keine Sprache bekannt, die angibt, ob sie in der Sprachspezifikation kompiliert oder interpretiert werden muss oder nicht.

Wenn Sie nun die Frage haben, wann Sie einen Sprachcompiler gegen einen Sprachinterpreter verwenden, kommt es wirklich auf die Vor- und Nachteile des Compilers gegenüber dem Interpreter und den Zweck des Projekts an.

Beispielsweise können Sie den JRuby-Compiler zur einfacheren Integration in Java-Bibliotheken anstelle des MRI-Ruby-Interpreters verwenden. Es gibt wahrscheinlich auch Gründe, den MRT-Ruby-Interpreter über JRuby zu verwenden. Ich bin jedoch mit der Sprache nicht vertraut und kann nicht mit ihr sprechen.

Vorteile von Dolmetschern:

• Keine Kompilierung bedeutet, dass die Zeit vom Bearbeiten des Codes bis zum Testen der App verkürzt werden kann
• Es ist nicht erforderlich, Binärdateien für mehrere Architekturen zu generieren, da der Interpreter die Architekturabstraktion verwaltet (obwohl Sie sich möglicherweise immer noch um die Skripte kümmern müssen, die Ganzzahlgrößen korrekt behandeln, nur nicht um die Binärverteilung).

Vorteile von Compilern:

• Kompilierter nativer Code hat nicht den Overhead eines Interpreters und ist daher in der Regel zeitlich und räumlich effizienter
• Die Interoperabilität ist normalerweise besser. Die einzige Möglichkeit für die In-Proc-Interoperation mit Skripten besteht in einem Interpreter und nicht in einem Standard-FFI
• Fähigkeit zur Unterstützung von Architekturen, für die der Interpreter nicht kompiliert wurde (z. B. eingebettete Systeme)

Ich würde jedoch wetten, dass es in 90% der Fälle eher so aussieht : Ich möchte diese Software in blub schreiben, weil ich sie gut kenne und sie einen guten Job machen sollte. Ich werde den Blub-Interpreter (oder Compiler) verwenden, da dies die allgemein akzeptierte kanonische Methode zum Schreiben von Software in Blub ist.

So TL; DR ist im Grunde auf einem von Fall zu Fall Vergleich der Dolmetscher vs den Compiler für Ihren speziellen Anwendungsfall.

Auch FFI: Foreign Function Interface, also Schnittstelle für die Interaktion mit anderen Sprachen. Weitere Informationen finden Sie auf Wikipedia

Ein wichtiger Punkt hierbei ist, dass viele Sprachimplementierungen tatsächlich eine Art Hybrid aus beiden ausführen. Viele heute häufig verwendete Sprachen arbeiten, indem sie ein Programm in ein Zwischenformat wie Bytecode kompilieren und dieses dann in einem Interpreter ausführen. So werden normalerweise Java, C #, Python, Ruby und Lua implementiert. In der Tat ist dies wohl die Art und Weise, wie die meisten heute verwendeten Sprachen implementiert werden. Tatsache ist also, dass die heutige Sprache ihren Code sowohl interpretiert als auch kompiliert. Einige dieser Sprachen verfügen über einen zusätzlichen JIT-Compiler, mit dem der Bytecode zur Ausführung in nativen Code konvertiert werden kann.

Meiner Meinung nach sollten wir aufhören, über interpretierte und kompilierte Sprachen zu sprechen, da diese keine nützlichen Kategorien mehr sind, um die Komplexität der heutigen Sprachimplementierungen zu unterscheiden.

Wenn Sie nach den Vorzügen interpretierter und kompilierter Sprachen fragen, meinen Sie wahrscheinlich etwas anderes. Möglicherweise fragen Sie nach den Vorteilen der statischen / dynamischen Typisierung, den Vorteilen der Verteilung nativer ausführbarer Dateien und den relativen Vorteilen der JIT- und AOT-Kompilierung. Dies sind alles Themen, die mit der Interpretation / Zusammenstellung in Konflikt geraten, aber unterschiedliche Themen sind.

Zunächst kann eine Programmiersprache sowohl interpretiert als auch kompiliert werden. Interpretation und Kompilierung sind nur Methoden zum Generieren von ausführbarem Code aus dem Quellcode. Mit einem Interpreter ist der Quellcode gelesen und wird interpretiert durch einen Interpreter , der dann den Code ausführt , wie es interpretiert. Ein Compiler hingegen liest den Quellcode und generiert aus dem Quellcode eine ausführbare Binärdatei - damit das Programm als separater Prozess unabhängig ausgeführt werden kann.

Bevor sich jemand wundert ... Ja, C / C ++ / C # / Java kann interpretiert werden, und ja, JavaScript- und Bash-Skripte können kompiliert werden. Ob es für diese Sprachen Dolmetscher oder Compiler gibt, ist eine andere Frage.

Um nun die Frage zu beantworten, wann wir "interpretierte Sprache" anstelle von "kompilierter Sprache" verwenden. Die Frage selbst ist etwas verwirrend, aber ich gehe davon aus, dass es bedeutet, wann die Interpretation der Zusammenstellung vorzuziehen ist. Einer der Nachteile der Kompilierung besteht darin, dass aufgrund des Kompilierungsprozesses ein gewisser Overhead entsteht. Der Quellcode muss zu ausführbarem Maschinencode kompiliert werden, sodass er nicht für Aufgaben geeignet ist, die beim Aufrufen des Quellcodes zum Ausführen eines Programms nur eine minimale Verzögerung erfordern . Andererseits ist kompilierter Quellcode aufgrund des durch die Interpretation des Codes verursachten Overheads fast immer schneller als gleichwertig interpretierter Quellcode. Dolmetscher hingegen können den Quellcode aufrufen und ausführen mit sehr geringem Aufrufaufwand, jedoch auf Kosten der Laufzeitleistung.

Am Ende ist es nahezu unmöglich, bestimmte Anwendungsfälle zu erwähnen, wenn einer nach dem anderen bevorzugt werden soll, aber zum Beispiel wäre ein (meiner Meinung nach sehr unrealistischer) Fall, wenn sich der Programmquellcode zwischen Programmaufrufen dynamisch ändert und der Aufwand für das Kompilieren ebenfalls ist hoch, damit es eine tragfähige Wahl ist. In diesem Fall wäre es wahrscheinlich wünschenswert, den Quellcode zu interpretieren, anstatt ihn zu kompilieren.

Es gibt jedoch etwas, das als reales Beispiel angesehen werden kann: Verstecken des Quellcodes bei der Bereitstellung. Mit nativkompilierter Code Der Entwickler stellt den ausführbaren Macine-Code des Programms und der Daten bereit. Bei interpretiertem Code muss der Quellcode selbst bereitgestellt werden, der dann mit viel weniger Aufwand überprüft und rückentwickelt werden kann als bei der Rückentwicklung von nativem Maschinencode. Eine Ausnahme bilden Sprachen wie C # und Java, die zu sofortiger Sprache / Bytecode kompiliert werden (MSIL für C # und Java-Bytecode für Java), die dann zur Laufzeit "just in time" bereitgestellt und kompiliert werden, ähnlich wie es ein Interpreter tut. Es gibt jedoch sogenannte Dekompilierer für MSIL und Java Bytecode, die den ursprünglichen Quellcode mit relativ guter Genauigkeit rekonstruieren können. Daher ist das Reverse Engineering solcher Produkte weitaus trivialer als das Reverse Engineering von Produkten, die im nativen Maschinencode eingesetzt werden.

Ich kann mir die folgenden Szenarien vorstellen, wenn Sie eine interpretierte Sprache verwenden würden:

• Wo kein Compiler vorhanden ist, wie Linux / Unix- Shell-Skripte .
• Schnelle und schmutzige Skripte, die ein kleines Problem lösen
• Sprachen, die das Schreiben dynamischer HTML-Seiten vereinfachen und allgemein interpretiert werden, sind JSP (Tomcat kompiliert es zu einem Servler, das zuvor ausgeführt werden soll), PHP, ASP usw.

Ich kann mir die folgenden Szenarien vorstellen, wenn Sie Ihren Code kompilieren möchten :

• Sie müssen Binärdateien verteilen, da Ihre App Closed-Source ist und Sie Ihren Quellcode nicht weitergeben möchten.
• Geschwindigkeit, wie eingebettete Systeme und dergleichen.
• Sie benötigen ein Maß an Sicherheit für Codetypen , das nur ein Compiler mit einer streng typisierten Sprache bieten kann. Compiler legen Tippfehler in jeder Ecke Ihres Quellcodes offen, während Tippfehler in interpretierten Programmen im Produktionscode unentdeckt bleiben können.
• Große , komplexe Systeme: Sie können sich ein Betriebssystem oder einen Büroanzug nur als kompilierte Binärdateien vorstellen.
• Sie möchten jeden kleinen Aufwand aus dem Weg räumen und benötigen eine gute Kommunikation mit Assembler-Snippets (schwierig mit jeder Art von Laufzeit, insbesondere mit einem Interpreter) (dieser Punkt wird durch einen @ delnam-Kommentar verursacht).

Am Ende besteht der große Kompromiss zwischen Produktivität (wie viele Codezeilen müssen Sie schreiben) und Leistung (wie schnell wird Ihr Programm ausgeführt).

Da interpretierte Sprachen bei der Umwandlung in CPU-Informationen mehr Informationen enthalten, können sie sich auf Reflexion und dynamische Typisierung verlassen, was die Produktivität erheblich steigert . Ein weiterer Vorteil interpretierter Sprachen besteht darin, dass sie plattformunabhängig sind, solange ein Interpreter für die Plattform vorhanden ist.

Da die CPU den Sprachcode nicht in Maschinencode umwandeln und den Code gleichzeitig ausführen darf, wie im interpretierten Fall, ergeben kompilierte Sprachen schnellere Programme. Außerdem ist ein in einer kompilierten Sprache erstelltes System sicherer, da es beim Kompilieren Probleme erkennen kann. Dies bedeutet im Grunde, dass Sie beim Eingeben einen Fehler sehen (mit modernen IDEs), anstatt ihn nur zu sehen, wenn Sie das Programm tatsächlich ausführen (natürlich) , dies behebt keine logischen Fehler).

In diesem Wissen eignen sich interpretierte Sprachen für:

1. Produktive Entwicklung: schnelle Webentwicklung (PHP, Javascript) oder für das Prototyping.
2. Plattformübergreifend; Beispielsweise wird JavaScript in jedem Browser (einschließlich mobiler Browser) unterstützt.

Und kompilierte Sprachen eignen sich, wenn:

1. Die Leistung ist kritisch (Betriebssysteme) oder die Ressourcen sind knapp (Mikrocontroller).
2. Zu bauende Systeme sind komplex; Beim Erstellen großer Systeme (Unternehmenssysteme) sind kompilierte Sprachen unerlässlich, um viele mögliche Fehler zu behandeln, die in interpretierten Sprachen auftreten können. Auch komplexe Programme erfordern viele Ressourcen und das Gleichgewicht tendiert dazu, auch Sprachen zu kompilieren.

Neben den von den anderen genannten Gründen gibt es einen besonders wichtigen Anwendungsfall für die Auswahl einer Ad-hoc-Interpretation gegenüber jeder Form der Zusammenstellung oder einem hybriden Ansatz.

Wenn eine Programmiersprache als Kommunikationsprotokoll verwendet wird und die Antwortlatenz wichtig ist, ist es sinnvoller, keine Zeit für die Kompilierung und eine mögliche Vorverarbeitung zu verschwenden.

Dies gilt beispielsweise für Agentensprachen oder für die Art und Weise, wie beispielsweise Tcl / Tk normalerweise verwendet wird.

Ein weiterer möglicher Grund für das Festhalten an der Interpretation besteht darin, dass ein Sprachinterpreter zum Bootstrapping selbst oder für eine ausgefeiltere Sprache höherer Ebene verwendet wird und seine Einfachheit wichtiger ist als die Leistung des Bootstrap-Prozesses.

Für fast jeden anderen möglichen Anwendungsfall ist die Kompilierung (oder ein hybrider Ansatz) besser geeignet.