Compiler vs Interpreter
-
nunja schrieb:
Zu 1.
Man muß nicht vor dem ausführen compilieren, übersetzt bzw. interpretiert wird das Programm vom Interpreter aber trotzdem, nämlich zur Laufzeit.
Insofern ist das ein dummes Argument, denn man gewinnt nix.doch natürlich. Man gewinnt weniger Entwicklungszeit (testen geht deutlich schneller). Das könnte mit Zyklus gemeint sein.
-
DrGreenthumb schrieb:
nunja schrieb:
Zu 1.
Man muß nicht vor dem ausführen compilieren, übersetzt bzw. interpretiert wird das Programm vom Interpreter aber trotzdem, nämlich zur Laufzeit.
Insofern ist das ein dummes Argument, denn man gewinnt nix.doch natürlich. Man gewinnt weniger Entwicklungszeit (testen geht deutlich schneller). Das könnte mit Zyklus gemeint sein.
Die Zeit, die du durch das nicht compilieren sparst, die verlierst du wieder bei der Ausführung.
Man gewinnt also nix.
-
nein, so kannst du das nicht verrechnen.
wenn du einen falschen C++ Header änderst dauerts evtl. 10min zu kompilieren. Änderst du eine Zeile Python startet das Programm sofort und braucht nicht 10min länger.
-
ich denke das ist auch mit "Entwicklungszyklen" gemeint, also turn around time schlecht ueberzetzt
script sprachen sind oft so eingebunden, dass die scripts 'hot reloaded' werden, das bedeutet also, dass das program, dass sie ausfuehrt nicht neu gestartet wird und nicht neu gebaut wird und... du aenerst was uns siehst es.
z.b. wenn du php benutzt oder java script, aenderst du eine zeile, ein refresh und du siehst das resultat. wuerdest du deine homepage in c++ implementieren, muesst du jedesmal neustarten, was ziemlich ein aufwand ist bei vielen DB daten.
du kannst natuerlich ueber cgi gehen in dem fall, aber das war auch nur ein beispiel.
-
Was ist mit Compreter-Sprachen ala Java?
-
Interpreter
Ein Interpreter hat je nach Programmgröße gewisse Laufzeitnachteile, da zunächst der Interpreter gestartet werden muss bis das Programm ausgeführt werden kann. Je nach Konzeption können Fehler evtl. erst zur Laufzeit erkannt werden, was die Entwicklungszeit wiederum negativ beeinflussen kann. Dadurch werden Fehler evtl. unentdeckt. Erkannte Fehler können aber schnell geändert und sofort wieder getestet werden. Der Vorteil von Interpretern ist auch, dass ein Programm auf jedem Computer lauffähig ist, wo der Interpreter verfügbar ist. Es ist also nicht notwendig die Programme selber zu portieren, es muss "nur" der Interpreter portiert werden. Die Programmierung eines Interpreters ist übrigens um einiges "einfacher", als die Entwicklung eines Compilers.Compiler
Ein Compiler ist in der Lage Programme stark zu optimieren, da Ausdrücke berechnet und direkt in das ausführbare Programm kompiliert werden können. Auch der Start eines solchen Programms ist schneller, da das Programm nur noch ausgeführt werden muss und keine weitere Interpretierung mehr notwendig ist. Da das Ausgabeformat plattformspezifisch ist und abweicht, muss das Programm für unterschiedliche Betriebssysteme neu kompiliert werden.Kombination (JIT-Compiler)
Das Programm wird auf Optimierungen untersucht und eine Zwischensprache "kompiliert", die von einem Interpreter ausgeführt werden kann. Dadurch wird die Laufzeit erheblich verbessert. Ein gewisser Overhead bleibt jedoch bestehen, da noch immer eine Interpreter gestarten werden muss und auch die Zwischensprache ausgeführt werden muss.Natürlich gibt es weitere Aspekte, aber das sind erst mal die, die mir auf die Schnelle eingefallen sind.
-
hkjhjk schrieb:
Der Vorteil von Interpretern ist auch, dass ein Programm auf jedem Computer lauffähig ist, wo der Interpreter verfügbar ist. Es ist also nicht notwendig die Programme selber zu portieren, es muss "nur" der Interpreter portiert werden.
Das würde ich als gehörigen Nachteil von Interpretern zählen.
-
SeppJ schrieb:
hkjhjk schrieb:
Der Vorteil von Interpretern ist auch, dass ein Programm auf jedem Computer lauffähig ist, wo der Interpreter verfügbar ist. Es ist also nicht notwendig die Programme selber zu portieren, es muss "nur" der Interpreter portiert werden.
Das würde ich als gehörigen Nachteil von Interpretern zählen.
Wenn man den Interpreter entsprechend schreibt, dann ist dieser ja sogar von sich aus sehr plattformunabhängig. Das wird bei einem Compiler schon allein wegen verschiedener Prozessoren, etc. nicht gehen. Ich denke also schon, dass es ehere in Vor- als ein Nachteil ist.
-
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.
-
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
