Werden dynamische Sprachen immer interpretiert?


18

Betrachtet man die meisten (wenn nicht alle) dynamischen Sprachen (z. B. Python, PHP, Perl und Ruby), werden sie alle interpretiert. Korrigiere mich, wenn ich falsch liege. Gibt es ein Beispiel für eine dynamische Sprache, die die Kompilierungsphase durchläuft? Ist die dynamische Sprache identisch mit der interpretierten Sprache?


4
Dynamische Sprache definieren, wird sie dynamisch eingegeben?
BenjaminB

3
Objective-C weist viele "dynamische" Eigenschaften auf.
Edward Strange

4
@Job, das könnte man mit Lisp seit Jahrzehnten machen. Und es ist sowohl kompiliert als auch dynamisch typisiert. Es gab also nie eine genaue Grenze zwischen Zusammenstellung und Interpretation.
SK-logic

2
@ Darien Sie können dies auch zur Laufzeit kompilieren und anschließend Code ausführen. Genau genommen ist es keine Interpretation.
xmm0

3
@Darien Nichts hindert einen Compiler daran, Symboltabelleninformationen in der kompilierten Binärdatei zu speichern und Code zu generieren, um zur Laufzeit darauf zuzugreifen. Es ist wahr, dass einige Sprachen mehr als nur zum Kompilieren geeignet sind, aber der springende Punkt ist, dass es möglich ist , einen Compiler für diese Sprache zu haben. Ein weiterer wichtiger Punkt ist, dass manche Leute davon ausgehen, dass ein Compiler eine Art Maschinencode generieren muss. In der Praxis gibt es Compiler, die einfach eine Transformation auf Quellenebene in zwei Sprachen durchführen (oder sogar in derselben Sprache, wie einige Javascript-Minifier).
xmm0

Antworten:


33

Betrachtet man die meisten (wenn nicht alle) dynamischen Sprachen (z. B. Python, PHP, Perl und Ruby), werden sie alle interpretiert.

Nicht wahr. Sie können die Python-Quelle kompilieren. Das ist ein existenzieller Beweis.

Es gibt Interpreter für statisch typisierte Sprachen und Compiler für dynamisch typisierte Sprachen. Die beiden Konzepte sind orthogonal.

Randnotiz: Im Allgemeinen ist eine Sprache genau das: eine Sprache mit einer Reihe syntaktischer Konstrukte, um Semantik auszudrücken. Wenn Sie Python auf ein Whiteboard schreiben, heißt es immer noch Python! Es ist die Implementierung , die ein Interpreter oder ein Compiler sein kann. Die statische oder dynamische Typisierung (eine Art Hybrid aus beiden) ist eine Eigenschaft der Sprache, während die Ausführung eines Programms durch Interpretieren oder Kompilieren eine Eigenschaft der Implementierung ist.


19
Mit welcher Genauigkeit müssen Einrückungen auf einem Whiteboard übereinstimmen, damit Python syntaktisch gültig ist? ;)
edA-qa mort-ora-y

1
Sie können Python nicht kompilieren. PYC beschleunigen nur die Last eines Moduls. Und py2exe bettet einfach den Interpreter mit der Quelldatei in die exe ein.
BenjaminB

8
@ Ubiquité: .pycDateien sind Bytecode. Python-Quellcode wurde analysiert, optimiert und kompiliert , um sie zu erstellen. Die Bytecode-Anweisungen sind relativ umfangreich und die beliebteste Implementierung ist ein einfacher Interpreter (im Gegensatz dazu sehen Sie sich PyPy an, das zur Laufzeit Bytecode zu sehr cleverem Maschinencode kompiliert), aber Python ist nicht weniger kompiliert als Java oder C #. Python wird nur dann "nicht kompiliert", wenn "Kompilierung" auf die native Vor- Zeit-Kompilierung beschränkt war , aber niemand hat etwas darüber gesagt, und im Allgemeinen kann es sich auf eine Transformation von Sprache in Sprache beziehen.

4
@ Ubiquité: Ja, das ist richtig, aber das steht in keinem Zusammenhang mit Ihrer Behauptung, dass "Sie Python nicht kompilieren können" oder ob es möglich ist, Python zu kompilieren. In erster Linie mischen Sie Pythonund CPythonwährend die letztere eine Implementierung der ersteren ist, ist dies auch der Fall PyPy.
Phant0m

2
@ClemC ALLE Eigenschaften einer Sprache sind in einen Compiler oder Interpreter integriert, ansonsten ist der Interpreter oder Compiler etwas für eine andere Sprache.
Pieter B

15

Common Lisp ist dynamisch (und stark) typisiert und wird normalerweise kompiliert .

Da diese Dynamik zur Laufzeit erreicht wird, können Sie mit einigen Anweisungen im Quellcode sicherstellen, dass ein Symbol nur einen bestimmten Wert enthält, damit der Compiler den generierten Code optimieren und die Leistung steigern kann.


12

C # 4.0 unterstützt dynamische Typen (späte Bindung) und wird kompiliert.


4

node.js basiert auf Googles V8-Javascript-Engine. V8 kompiliert die Laufzeit. V8 ist angesichts dieser Tatsache unglaublich schnell. Schauen Sie sich einfach http://shootout.alioth.debian.org an und vergleichen Sie V8 mit einer der oben interpretierten Sprachen.


3

Nein - es ist durchaus möglich, dynamische Sprachen zu kompilieren.

Es gibt sogar einige dynamische Sprachen, die immer vom Design kompiliert werden (z. B. Clojure).

Die Frage berührt jedoch einen wichtigen verwandten Punkt: Obwohl dynamische Sprachen kompiliert werden können, ist es häufig so, dass dynamische Sprachen nicht zu Code kompiliert werden können, der so effizient ist wie eine statisch typisierte Sprache . Dies liegt daran, dass in dynamischen Sprachen einige inhärente Funktionen Laufzeitprüfungen erfordern, die in einer statisch kompilierten Sprache nicht erforderlich wären.

Ein Beispiel hierfür: Sprachen, die das Patchen von Objekten zur Laufzeit ermöglichen (z. B. Ruby), erfordern häufig, dass das Objekt beim Aufrufen einer Methode für das Objekt überprüft wird (mit einem Hashtable-Lookup oder ähnlichem). Selbst wenn dies kompiliert wird, muss der Compiler Code generieren, um die Methodensuche zur Laufzeit durchzuführen. In gewissem Maße unterscheidet sich diese Methodensuche nicht von dem, was ein Interpreter tun müsste.

Dies bedeutet einen erheblichen Mehraufwand im Vergleich zu einem Methodenaufruf in einer Sprache wie Java, in der die richtige Methode vom Compiler statisch aus der Klassendefinition ermittelt und auf einen einfachen Funktionsaufruf im systemeigenen Code reduziert werden kann.

Ich glaube, es ist mehr als alles andere dieser Effekt, der dazu führt, dass dynamische Sprachen im Durchschnitt langsamer arbeiten als ihre statisch kompilierten Gegenstücke. Wie Sie an den fehlerhaften Benchmarks sehen können , sind es die statisch typisierten Sprachen (C, Java, Fortran usw.), die am schnellsten mit den dynamischen Sprachen (Perl, Python, Ruby, PHP usw.) am Ende des Rankings abschneiden.


2

Es war einmal eine Interpretation von BASIC. Und einige Varianten von BASIC hatten dynamisches Tippen. Und Sie könnten auch Compiler für sie bekommen.

(Dies war in den Tagen von 100.000 Diskettenlaufwerken, als Dinosaurier noch auf der Erde umherstreiften und ahnungslose Softwareentwickler zum Frühstück aßen.)


... aber nur, wenn sie GOTOs benutzt haben. (Was natürlich ziemlich häufig war, wenn sie in BASIC entwickelt wurden. AHA! Das erklärt es!)
Mason Wheeler

BASIC war zu seiner Entwurfszeit eine kompilierte Sprache.
AProgrammer

2

Verschiedene Smalltalk-Implementierungen behandeln dies unterschiedlich, aber einige von ihnen werden zu Bytecodes kompiliert, die auf einer Hochleistungs-VM ausgeführt werden.


2

Tatsächlich durchlaufen die meisten der so genannten "interpretierten" Sprachen eine Just-in-Time-Kompilierung, um die Ausführung zu beschleunigen. Einige von ihnen müssen erst zu Bytecode kompiliert werden, bevor Sie sie ausführen können.

In der Tat sind dynamisch und interpretiert zwei völlig unterschiedliche Ideen, obwohl es eine Korrelation gibt. Der Grund dafür ist, dass es ihnen nichts ausmacht, den Code ein bisschen langsamer, aber portabel auszuführen, wenn sie jemals das Gefühl haben, dass die dynamische Eingabe ihre Arbeit einfacher und schneller macht.


1

Chrome, IE9 und Firefox 3.1+ kompilieren JavaScript in native Binärdateien, und JavaScript wird dynamisch eingegeben.

Ich denke, der Grund, warum dynamische Sprachen in der Vergangenheit eher interpretiert werden, liegt darin, dass dynamisches Tippen und Interpretieren (oder genauer gesagt das Fehlen von Kompilierungen) in der Regel nützliche Funktionen für Skriptsprachen und Skriptaufgaben im Allgemeinen sind.

Die Leistung ist (war) auch nicht so wichtig für die Art von Programmen, die in diesen Sprachen geschrieben wurden. Auch hier war der Aufwand für dynamisches Tippen und Dolmetschen kein so großes Problem wie in Sprachen dieser Wert Leistung.


1

Python wird normalerweise kompiliert. Zugegebenermaßen zu Bytecode kompiliert, der dann interpretiert wird.

Perl arbeitet ähnlich.

Common Lisp wird normalerweise in systemeigenen Code oder Bytecode kompiliert. Dies unterscheidet sich zwischen Implementierungen (und bis zu einem gewissen Grad innerhalb einer Implementierung, abhängig von verschiedenen Optimierungseinstellungen).


-5

Ja. Alle dynamischen Sprachen sind interpretierte Sprachen (eine interpretierte Sprache kann jedoch nicht dynamisch sein).

Der Grund ist einfach: Wenn es dynamisch ist, benötigt es einen Interpreter, um die Dynamik auf der Ebene der binären Kompilierung auszuführen.

Ex. : Wenn wir Daten in eine PHP-Variable und später in eine andere eines anderen Typs einfügen, kann unser Programm keinen Binärcode kompilieren, da jeder Typ sein eigenes Binärdarstellungsformat hat. Der Interpreter verwaltet die Verschiebungen auf binärer Ebene auf dynamische Weise


2
Falsch. Dynamische Sprachen können kompiliert werden (und manchmal sehr effizient, z. B. mithilfe von JIT und
adaptiven

"Grob gesagt kombiniert die JIT-Kompilierung die Geschwindigkeit des kompilierten Codes mit der Flexibilität der Interpretation mit dem Overhead eines Interpreters ..." en.wikipedia.org/wiki/Just-in-time_compilation Ihr Programm kompiliert nicht: Es wird von kompiliert der Dolmetscher für dich
ClearMind

Lesen Sie
Artikel

Sicher. In Ihrem Link heißt es: "Ein Merkmal von Self ist, dass es auf der gleichen Art von virtuellem Maschinensystem basiert wie frühere Smalltalk-Systeme. Das heißt, Programme sind keine eigenständigen Entitäten, da sie in Sprachen wie C vorliegen, sondern deren gesamte Speicherumgebung, um zu laufen. " nicht eigenständig = nicht binär kompiliert Die virtuelle Maschine wird benötigt, um die binäre Kompilierung
durchzuführen

1
Ihre Definition von Compiler ist zu restriktiv. Nicht jeder Compiler erzeugt eine ausführbare Binärdatei. Ein aktuelles Gegenbeispiel ist die Implementierung von SBCL . Lesen Sie das neueste Drachenbuch und Lisp in kleinen Stücken
Basile Starynkevitch
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.