Compiler vs Interpreter
-
SeppJ schrieb:
Ich meine nicht, dass man den Interpreter nicht portieren könnte, sondern dass man den Interpreter auf JEDEM RECHNER haben muss. Gib mal einem Nicht-Programmierer ein Basic-Programm und die gucken erst einmal blöd aus der Wäsche. Java bis vor ein paar Jahren auch. Oder Python und Perl unter Nicht-Unixen.
Bei einem Compiler brauche ich hingegen das Programm nur ein einziges Mal für ein System übersetzen und alle Leute mit dem gleichen System können das Programm benutzen. Da man die Anzahl gängiger Systeme an zwei Händen abzählen kann, die Anzahl aller Rechner hingegen viel viel viel größer ist, ist das ein klarer Vorteil.
man kann auch python zu exe kompilieren. Ist doch nur eine Frage des Paketierens und auch nur ein windows-spezifischer Nachteil.
-
Dann ist es nicht mehr interpretiert. Und "Windowsspezifischer Nachteil" ist ein denkbar schlechtes Argument, wenn du von Portabilität sprichst. Irgendwie fehlt deinem Beitrag ein Smiley für Ironie, so unpassend ist er.
-
SeppJ schrieb:
Dann ist es nicht mehr interpretiert.
nicht? ich habe es noch nie ausprobiert aber ich bin davon ausgegangen, da wird einfach der interpreter mit in die exe gepackt? Wenn nicht - so könnte man es jedenfalls machen
Und "Windowsspezifischer Nachteil" ist ein denkbar schlechtes Argument, wenn du von Portabilität sprichst.
das eigentliche Programm ist doch auch windows-kompatibel! nur bei der Windows-Version ist die exe halt 40mb statt 40kb.
Man könnte unter Windows natürlich auch einen Installer machen, der die fehlenden interpreter nur bei Bedarf runterlädt...
Irgendwie fehlt deinem Beitrag ein Smiley für Ironie
welcher ist das? :xmas1:
-
Genau, man kann die Dateiendung auch mit dem Interpreter verknüpfen, dann wird dieser für diese Dateien automatisch gestartet. Lässt sich prima mit einem Installer bündeln. Alternativ kann man das natürlich auch so paketieren, wie DrGreenthumb vorgeschlagen hat. Nachteil bei der Variante ist aber, dass das Viren oft auch so machen, weshalb die mit diesen Packprogrammen erzeugten Dateien schnell mal ein false positive hervorbringen.
-
Großartig. Dann ist der Vorteil von Interpretern also, dass Programme > 40 MB groß sind, damit sie sich wie compilierte Programme anfühlen?
-
SeppJ schrieb:
Großartig. Dann ist der Vorteil von Interpretern also, dass Programme > 40 MB groß sind, damit sie sich wie compilierte Programme anfühlen?
du meinst Nachteil?
wenn man unbedingt die alles-ist-drin.exe haben muss, ja. Aber da wirds bei statisch gelinkten, kompilierten C++ oder Common Lisp Programmen auch nicht viel besser.
-
SeppJ schrieb:
Großartig. Dann ist der Vorteil von Interpretern also, dass Programme > 40 MB groß sind, damit sie sich wie compilierte Programme anfühlen?
Nein, es erfordert nur einen entsprechenden Installer, der das System einmalig so konfiguriert, dass sich die Programme ohne weitere Handlung des Benutzers ausführen lassen. Mag natürlich sein, dass der Installer eine gewisse Größe hat, um alle erforderlichen Komponenten mitzubringen. Würde man diese mit dem Programmcode bündeln, dann wäre folglich das gesamte Programmpaket größer. Aber das ist ja auch bei dem Kompilaten der Fall.
Natürlich macht ein Interpreter nicht überall Sinn. Auf einem Mikrocontroller wäre es ziemlich schwachsinnig eine interpretierte Sprache zu verwenden, da der Interpreter + Programmcode die Ressourcen schnell ausschöpfen würde.
Aber davon war hier ja auch nie die Rede.
-
SeppJ schrieb:
Großartig. Dann ist der Vorteil von Interpretern also, dass Programme > 40 MB groß sind, damit sie sich wie compilierte Programme anfühlen?
Bescheuerte Argumentation, entweder die Laufzeitumgebung die mein Programm benötigt ist auf dem PC vorhanden oder eben nicht. Falls nicht muss ich sie eben mitliefern. In welcher Sprache ich mein Programm schreibe ist dann auch egal. Wenn ich pech hab muss ich für mein C++ Programm eben auch ein installer schreiben der die VS Redistributable oder Qt oder wasauchimmer mitinstalliert.
-
Ein Interpreter simuliert zur Laufzeit eine Maschine, während ein Compiler Code für eine reale oder virtuelle Maschine generiert. Das ist eigentlich der einzige Unterschied. Alles andere relativiert sich durch spezielle Technologien.
-
ujuzui schrieb:
Natürlich macht ein Interpreter nicht überall Sinn. Auf einem Mikrocontroller wäre es ziemlich schwachsinnig eine interpretierte Sprache zu verwenden, da der Interpreter + Programmcode die Ressourcen schnell ausschöpfen würde.
Das stimmt so natürlich nicht. Ein Interpreter muss nicht immer gleich Perl/Python/Ruby mit allen mitgelieferten Bibliotheken bedeuten. Zum Beispiel Lua lässt sich bereits mit einem Ansi C Compiler übersetzen, ist eine voll funktionsfähige Sprache und bringt ein paar (optionale) Bibliotheken mit. Aber selbst die wäre für einen kleinen Mikrocontroller bereits überdimensioniert. Sehr kompakt bekommt man Interpreter für Lisp-Dialekte hin und für kleinere Skripte sind die bereits vollkommen ausreichend. Man denke zum Beispiel an so etwas wie eine read-eval-print-loop um mal eben etwas Code auf dem Mikrocontroller ausführen zu können um ein paar Informationen auszulesen, oder sogar einen Bug zu fixen/kaputte Daten wiederherzustellen. Dafür ist so ein kleiner Interpreter echt gold wert
-
Mikrocontroller + Interpreter: Forth
-
forth ist interpreter und compiler (threaded code-) zugleich.
-
Die Gretchenfrage: Wird Maschinencode interpretiert? Ja, von der Maschine ...
-
knivil schrieb:
Die Gretchenfrage: Wird Maschinencode interpretiert? Ja, von der Maschine ...
Ja, damit hast du natürlich recht. Bei einem Interpreter folgt aber noch die Indirektion, dass zunächst der Maschinencode des Interpreters und dieser somit den Programmcode ausführt. Das erfordert also mehr Instruktionen durch diesen "Umweg".
-
wenn man tief genug herabsteigt, wird letztlichendlich alles interpretiert - und sei es durch ein Schaltwerk, das nicht viel mehr macht, als Nanobefehle in Bitmuster auf einem Steuerbus umzusetzen (Decoder). Ein Maschinenbefehl ist auf dieser Ebene betrachtet bereits eine "Routine", die in compiliertem nanocode vorliegt.
-
add:
es gibt natürlich Alternativen, zum Beispiel asynchrone Systeme, ohne zentrales Schaltwerk gebaute Systeme usw.
-
!rr!rr_. schrieb:
wenn man tief genug herabsteigt, wird letztlichendlich alles interpretiert ...
Also erzeugt ein Compiler immer Code für einen speziellen Interpreter.
Und ein Compiler ist immer auch selbst ein Interpreter, da er Code interpretieren muß, um anderen Code zu erzeugen, der von irgendeiner Maschine (aus Soft- oder Hardware) interpretiert werden soll.Aber was ist nun ein Codegenerator, der z.B. aus einer (grafischen) Metasprache C-Code erzeugt? Ein Compiler, ein Interpreter, oder beides?
-
Compiler ist immer auch selbst ein Interpreter
Nein, ein Compiler transformiert Quelltext in einer Darstellung in eine andere. Ein Interpreter fuehrt das Programm aus. Ein Interpreter erzeugt im Normalfall keinen Code.
Aber was ist nun ein Codegenerator, der z.B. aus einer (grafischen) Metasprache C-Code erzeugt?
Von einer Darstellung in eine andere, also Compiler.
-
knivil schrieb:
Ein Interpreter erzeugt im Normalfall keinen Code.
Kann man denn die Wirkung eines Interpreters, d.h. des Programms das er interpretiert, nicht ganz allgemein auch als Code bezeichnen? Sozusagen ein "Code", der in der realen Welt irgendetwas bewirkt? In dem Fall wäre der Interpreter auch nur ein Code-Konverter, wie ein Compiler.
-
Prinzipiell kann man das. Aber ich finde, dass diese Verwaesserung nicht von Nutzen ist. Ein Compiler ueberfuehrt die Darstellung des Programms in eine andere. Hat also erstmal keine Auswirkung auf "aeussere Welt", ein Interpreter setzt das Programm um, d.h. hat eine Wirkung. Darstellung und Wirkung in einen Topf zu werfen lehne ich ab. Es besteht ein fundamentaler Unterschied zwischen das Schreiben von "erschiesse XY!" und der eigentlichen Tat.
