Interpreter vs compiler

Hallo,

ist der einzige Grund warum es Interpreter gibt der, um das Programm
auf einem anderen System laufen zu lassen ? Also es geht beim Interpreter
ausschließlich um die Eigenschaft der Portapilität? z.B. bei Java

Danke

Man kann einfach viel leichter einen Interpreter für eine Komplexe Pgrammiersprache erstellen, als einen Compailer

^^nicht nur, auch dinge wie automatisches anpassen an die umgebung und die fähigkeit von programmen, sich selbst zu analysieren und zu manipulieren, oder neuen code zu erzeugen, teile des interpreters mitzubenutzen, usw. sind manchmal ganz nützlich. guck hier: http://en.wikipedia.org/wiki/Adaptive_optimization
http://en.wikipedia.org/wiki/Reflection_(computer_science)
und dann werden interpretersprachen auch gern für webprogrammierung genutzt, weil z.b. compilieren entfällt. man testet lokal auf seinem apachen (mit z.b. PHP drauf) und wenn alles funzt, lädt man einfach die quelltexte auf den server hoch.
compilersprachen sind nur dann gut, wenn's auf hohe ausführungsgeschwindigkeit ankommt, wenn man seine source-codes nicht rausrücken will *fg* oder auf dynamisches OOP verzichten kann. aussderm gibts noch mischlösungen, wie z.b objective-C, Java, usw. (compilersprachen, die ein laufzeitsystem brauchen)

blurry33 schrieb:

Also es geht beim Interpreter
ausschließlich um die Eigenschaft der Portapilität? z.B. bei Java

Die guten Interpreter (zB für Java) sind ja gar keine Interpreter, sondern Compiler, die in einen Zischencode übersetzen ("Bytecode"), der dann besser interpretiert werden kann. Also kann man den Bytecode-Interpreter als die Beschreibung einer Maschine auffassen, die es nicht gibt.

Und schließlich kann man zwar beliebig viele Compiler zwischenschalten, am Ende steht aber immer ein Interpreter, der das Ding ausführt, auch wenn er "CPU" heißt.

Interpreter sind halt einfacher in der Handhabung. Einfach Programm schreiben und starten. Dafür brauchst Du den Interpreter auf dem Zielsystem. Bei einem Compiler musst Du erst compilieren, bevor Du Dein Programm ausführen kannst. Dafür brauchst Du auf dem Zielsystem weder den Compiler noch den Source-code und die Ausführungsgeschwindigkeit ist in der Regel deutlich höher.

Ein Zwischending ist da beispielsweise Java. Es vereint die Nachteile einer Interpretersprache mit den Nachteilen einer Compilersprache. Du musst ein Java Programm erst mal compilieren, brauchst auf dem Zielsystem aber trotzdem einen Interpreter. Ausserdem enthalten die Compilate (class-files) fast den kompletten Quellcode, so dass Du Dich umbiegen musst, um Deinen Source nicht offen zu legen.

µngbd schrieb:

Und schließlich kann man zwar beliebig viele Compiler zwischenschalten, am Ende steht aber immer ein Interpreter, der das Ding ausführt, auch wenn er "CPU" heißt.

und die gatter und flipflops im prozessor sind ein interpreter für schaltalgebra, die wiederum interpreter für elektrische spannungspegel, die sind dann interpreter für ladungsträger oder so und dann geht's richtung atomphysik. wo steckt denn nun die echte CPU? *fg*

unbekannter schrieb:

Bei einem Compiler musst Du erst compilieren, bevor Du Dein Programm ausführen kannst. Dafür brauchst Du auf dem Zielsystem weder den Compiler noch den Source-code und die Ausführungsgeschwindigkeit ist in der Regel deutlich höher.

ausserdem brauchste mindestens einen compilerlauf pro zielsystem und hast dann mehrere binaries, die du nicht vertauschen darfst. oft musst du auch eigenarten und unterschiede der betriebssysteme und compiler berücksichtigen (#ifdef WIN32, #ifdef GNUC, usw) oder irgendwelche seltsamen libraries (boost für c++ zb.) dazulinken, die das abstrahieren, aber im gegenzug zusätzliche komplexität und einschränkungen mit ins spiel bringen.

unbekannter schrieb:

Ein Zwischending ist da beispielsweise Java. Es vereint die Nachteile einer Interpretersprache mit den Nachteilen einer Compilersprache.

aber auch vorteile aus beiden welten. z.b. sind die class-files ziemlich klein.

fricky schrieb:

und die gatter und flipflops im prozessor sind ein interpreter für schaltalgebra, die wiederum interpreter für elektrische spannungspegel, die sind dann interpreter für ladungsträger oder so und dann geht's richtung atomphysik.

Da kann man sich viele lustige Gedanken machen. Ein Sinn ist in der ganzen Informationsverarbeitungssache halt immer erst dann, wenn ich einen hineinlege.

fricky schrieb:

wo steckt denn nun die echte CPU? *fg*

Wie der Rest der Welt: nur in meinem Kopf?

Helium

µngbd schrieb:

blurry33 schrieb:

Also es geht beim Interpreter
ausschließlich um die Eigenschaft der Portapilität? z.B. bei Java

Die guten Interpreter (zB für Java) sind ja gar keine Interpreter, sondern Compiler, die in einen Zischencode übersetzen ("Bytecode"), der dann besser interpretiert werden kann.

Java ist IMO kein besonders gutes Beispiel. Da hätte ich eher sowas, wie Python gewählt (wobei auch das nciht unbedingt für immer so sein wird, siehe Unladen Swallow). Java VMs habe heute alle JIT Compiler, die Maschienencode erzeugen und nurnoch teilweise Bytecode interpretieren.

Interpreten, die nicht zunächst in einen Bytecode übersetzen, der dann interpretiert wird, gibt es aus Geschwindigkeitsgründen relativ wenig. Ruby vor 1.9 wäre ein Beispiel.

rapso

der hauptunterschied ist eben dass compilate auf der cpu laufen und interpretierte sprachen auf software. deswegen sagt man meist dass es scriptsprachen sind die interpretiert werden, sie steuern dann die software mit einfachen anweisungen etwas recht komplexes zu machen.
Die software, wie z.b. browser, sind meistens nur mit diesem ziel gebaut und fuehren die scripte dann in einer eigenen welt aus, ohne dafuer wirklich einen eigenen prozess mit all den sicherheitsrisiken zu erstellen.