Diskussion:Interpreter

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Interpreter“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Zum Archiv

Wie wird ein Archiv angelegt?

Automatische Archivierung

Auf dieser Seite werden Abschnitte halbmonatlich automatisch archiviert, deren jüngster Beitrag mehr als 365 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 5 Abschnitte. Die Archivübersicht befindet sich unter Archiv.

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, wenn sie mit {{Erledigt|1=--~~~~}} markiert sind und ihr jüngster signierter Beitrag mehr als 7 Tage zurückliegt.

Der Interpreter in Gestalt der universellen Funktion

In der Theorie, mit ihren einfachen, aber dafür noch exakt analysierbaren Modellen, findet man den Interpreter in Gestalt der universellen Funktion $u_{\varphi }$ der Standardnummerierung $\varphi$ der berechenbaren Funktionen wieder, wobei $u_{\varphi }(x,i)=\varphi _{i}(x)$ gilt. Siehe auch utm-Theorem.
Warum ist diese 2-stellige Funktion ein Interpreter? Nun, $i\in \mathbb {N}$ ist das Programm (siehe natürliche Zahlen), d.h. $u_{\varphi }$ ist in der Lage für jedes gegebene Programm, zu jedem Eingabewert $x$ den Ausgabewert $\varphi _{i}(x)$ (der per Semantik zugeordneten berechenbaren Funktion) zu berechnen. $u_{\varphi }$ kann somit für alle denkbaren Programme, deren Ausgabe bestimmen. Genau das ist ein Interpreter.
Ein Übersetzer macht etwas anderes, der wandelt Programme der Sprache A in Programme der Sprache B, wobei B direkt ausführbar sein kann. (Hier ist dann z.B. die CPU ein in Hardware realisierter Interpreter für B Programme).
--Marc van Woerkom 02:14, 3. Sep 2004 (CEST)

Der erste Satz dieses Artikels ist unverständlich (erl.)

Der erste Satz dieses Artikels ergibt keinen Sinn und ist irgendwie verunglückt. --84.180.232.38 5. Jul 2005 15:54 (CEST)

Ist jetzt ueberarbeitet. --Hullbr3ach 18:18, 23. Jul 2005 (CEST)

Nachteile des Interpreter als erstes Statement

Ich finde es einfach ungünstig, etwas zu beschreiben und gleich auf seine Nachteil hinzuweisen. Das ist respektlos, egal worum es geht.
Der Interpreter hat seine Vorteile und die würde ich erstmal ganz oben hin setzen. Das läßt sich zusammen mit den Eigenschaften gut beschreiben.
Dann ist generell der Hinweis, Interpreter wären langsam, schon uralt. Den kenne ich schon seit 20 Jahren. Stimmt das denn angesichts von Quad-Core Prozessoren überhaupt noch? Wenn ich mit Smalltalk arbeite, kann ich keine Performance-Unterschiede zu C# mehr feststellen. Die Datenbank mit den Plattenzugriffen ist der Flaschenhals. Der Prozessor langweilt sich eher die ganze Zeit, egal ob ich Smalltalk, Basic oder C# programmiere. Diese Aussage müßte also unbedingt erneut geprüft werden!! Wir sitzen doch alle nicht mehr vor einem 8086.
(nicht signierter Beitrag von 129.187.107.99 (Diskussion) 15:45, 3. Feb. 2011 (CET))

Binär-Interpreter (Bytecode)

Bei einigen Interpretern handelt es sich nicht im Sinn einer Programmiersprache um einen Interpreter, sondern im Sinn von Bytecode (eigentlich immer System-unabhängig, also ein Zwischencode). Das fehlt mir derzeit im Artikel. Da Emulatoren eine Zwischenschicht einziehen, die nur auf einem inkompatiblen Zielssystem notwendig ist, der auszuführende Maschinencode jedoch nicht als Zwischencode bezeichnet werden kann, ist dies hier nicht gänzlich zutreffend. Ein Beispiel, wo es zu 100% zutrifft:

• Java-Programme → Java bytecode
• AGI-Spiele (Zwischencode, der von einer Game-Engine interpretiert wird)^[Quelle]
• 4DOS und 4OS/2 BTM-Dateien können ebenfalls in binärem Zwischencode vorliegen.
• … (ich habe sicher zahlreiche weitere Beispiele hier nicht gelistet…)

Das alles steht derzeit im dritten Absatz, so:

Interpreter liegen zumeist in Maschinensprache des Zielprozessors vor, können aber auch selbst wieder in einer Interpretersprache vorliegen (siehe Beispiel unten) oder von einem Emulator interpretiert werden. Dies ist beliebig schachtelbar und wirkt sich dementsprechend auf die Abarbeitungsgeschwindigkeit aus.

Aber es kommt meiner bescheidenen Meinung nach nicht entsprechend heraus, dass es Interpreter für Programmiersprachen gibt (Menschen-lesbar), als Zwischencode/Bytecode (nicht Menschenlesbar, meist unabhängig vom Zielssystem), und als Mischform. Emulatoren sind eine Zusatzebene, die ein eigentlich ein anderes Zielsystem vorgaukelt, den Maschinencode einer anderen Plattform/Architektur somit zu einer Interpretation umbaut – also ein Sonderfall, da die Intention eine andere ist. Die Mischformen sind heutzutage überall zu finden. Allein, wo man heute überall JIT-Compiler findet, ist immens. Auch haben gängige Programmiersprachen meist sowohl reine Compiler, reine Interpreter als auch beides in einem.

‣Andreas•⚖ 14:39, 14. Sep. 2019 (CEST)

Ach herrje, das Zeugs gibts jetzt seit 60 Jahren und länger.

Dabei haben Zigtausende von Entwicklern Tausende von Systemen in die Welt gesetzt, die die Aufgabe genau so lösten, wie sie es brauchten; mit den Hardware-Beschränkungen, denen sie unterlagen, mit der Kompaibilität zu diesem und jenem, dabei die letztendlich angestrebte Funktion erfüllend.

Was man nie gemacht hat, war sich dabei einen Dreck drum zu scheren, ob das was dabei rauskam in einer wissenschaftlichen Klassifikation als Interpreter, Compiler, Emulator, Zwischenschicht-Bytecode-Sonstwas einzustufen wäre.

Dementsprechend gibt es in der realen Welt auch etliche Mischformen und Zwischenstufen.

Das entscheidende Merkmal, um überhaupt durch diesen Dschungel durchzufinden, ist:

• Ein Compiler übersetzt eine Spracheinheit von einem (höheren) Sprachlevel in einen maschinennäheren Sprachlevel, generiert aber nur neuen Code, ohne etwas auszuführen.
• Ein Interpreter nimmt eine Anweisung oder einen syntaktischen Anweisungsblock, wertet diesen aus, und führt ihn dann umittelbar aus. Nach der Ausführung vergisst er einen vermutlich hilfsweise generierten internen Code sofort wieder. Danach nimmt er sich die nächste Anweisung vor.

Welcher Art die in den Interpreter hineingefütterte Sprache ist, ob menschenfreundlicher Quellcode oder Bytecode oder was auch immer, ist für die Einstufung als Interpreter ziemlich belanglos.

Deshalb ist der erste Satz dieses Abschnitts hier für mich herzlich unbrauchbar. Die Natur einer Programmiersprache hat absolut nichts damit zu tun, in was für eine Art von System ich sie hineinlade.

Nehmen wir mal das bald halbjahrhundertjährige BASIC als einfachen Fall:

• Ich kann BASIC-Code in einen Compiler hineintun, bekomme wohl ein .EXE oder sowas, und kann irgendwann nach Belieben und so oft ich will dieses .EXE ausführen.
• Oder ich kann BASIC in einen Interpreter reintippen; nach jedem Enter wird der Befehl ausgeführt, und auf dem Bildschirm meines Taschenrechners, DOS-PC oder was immer erscheint nach PRINT 3*4 eine 12. Darüber kann ich mich freuen und die nächste Zeile tippen.

Die entscheidenden Schlüsselwörter stehen umseitig ganz am Anfang: „einliest, analysiert und ausführt“ sowie „Gastsystems befehlsweise“.

Welcher Natur ein Quellcode ist, ist hingegen ziemlich egal und wird sinnvollerweise umseitig auch nicht konkretisiert.

Umseitig steht allerdings eine Unsauberkeit: „Compilersprachen“ – es gibt zwar Sprachen, die ob ihrer Komplexität und Vernetzung eigentlich nur nach Kompilation verwendbar sind (alle objektorientierten etwa), aber eine wirkliche Trennung gibt es nicht, wie ich am Beispiel BASIC zeigte. Genauso ist es mit dem unscharfen Begriff „Skriptsprache“ – ich könnte zu jeder Skriptsprache einen Compiler bauen, der diese Skriptsprache zunächst in Bytecode oder Assembler oder physischen Maschinencode übersetzt, jedoch noch nicht ausführt. Dann wäre auch jede Skript- und Interpretersprache eine „Compilersprache“, weil ich immer eine maschinennähere noch nicht ausgeführte Übersetzung herstellen könnte. Bloß macht man sowas üblicherweise nicht.

LG --PerfektesChaos 18:55, 14. Sep. 2019 (CEST)

Absolute Zustimmung :) --Trustable (Diskussion) 20:04, 14. Sep. 2019 (CEST)

Das verstehe ich insofern nicht, als dass ein Interpreter nicht zwangsweise eine Programmiersprache interpretieren muss – es kann auch Zwischencode sein. Ein Programmierer schreibt also ein Programm, das dann von einem Compiler in Zwischencode übersetzt wird. Dieser ist also kompiliert, läuft aber nicht einfach so, denn nun braucht es einen Interpreter, der diesen Zwischencode zur Ausführung bringt, ihn also "zeilenweise ausführt und wieder vergisst". Das kann man aber nicht eintippen.

Welcher Natur ein Quellcode ist, ist hingegen ziemlich egal… Wirklich? Für mich ist das ein augenscheinlicher Unterschied – nämlich der, ob ich hier eine modifizierbare Sprache vor mir habe, wo ich den einen oder anderen Befehl relativ einfach umschreiben kann, oder ob ich ein binäres "Programm" vor mir habe, das ich zuerst reverse-engineeren müsste um es zu verstehen, und dann eventuell in Assembler-Manier (den Zwischencode verstehend) ändern könnte, weil ich keinen Zugang zum eigentlichen Quellcode habe. Und beides sind dann dennoch "Interpretersprachen", müssen also über einen Interpreter als Laufzeitumgebung zur Ausführung gebracht werden.

Außerdem ist zeilenweise Ausführung in einem Interpreter nicht zwangsläufig so. Da gibt es genug Interpreter, die den Code zwar häppchenweise, jedoch keinesfalls Zeilenweise analysieren und dann ausführen.

‣Andreas•⚖ 23:24, 14. Sep. 2019 (CEST)

• Die Frage, wie hoch oder niedrig, menschenverständlich oder maschinennah, eine formale Sprache einzustufen ist, hat absolut nichts mit der Unterscheidung Interpreter / Compiler zu tun:
  • Ein Compiler übersetzt von einem menschenverständlicheren zu einer maschinennäheren Niveau des gleichen Algorithnmus, führt aber nichts aus, sondern erzeugt nur eine Datei.
  • Ein Interpreter liest einen abgrenzbaren Befehl (ggf. einen zusammenhängenden syntaktischen Befehlsblock) ein, übersetzt ihn intern in Maschinenanweisungen, führt ihn sofort aus und vergisst die Übersetzung. Danach wird der nächste Befehl entgegengenommen und ausgeführt. Auf welchem Sprachniveau der Befehl gegeben wird ist egal; es muss halt eine dem Interpreter bekannte Syntax sein.
• Bytecode ist eine formale Sprache wie andere auch.
  • Sie ist einfach nur vorverdaute höhere Programmiersprache, alle Kommentare raus, alle Strings sortiert in einer Stringtabelle und dadurch mehrfach auftretende Strings nur über einen Pointer auf denselben String zugreifbar, Namen von Variablen werden durch fortlaufende Nummerierung in einem Array der Variablen ersetzt, konstante Ausdrücke werden vorab ausmultipliziert, Makro-Expansion, gewisse Optimierungen schon vorgenommen, toter Code nicht übernommen. Außerdem werden menschenlesbare Syntaxelemente (Schlüsselwörter) durch spezielle Bytecodes ersetzt, was dem Kind seinen Namen gab.
  • In LISP und Lua, zwei Sprachen, mit denen ich mich ganz gut auskenne, erfüllt Bytecode die normale Syntax der höheren Sprache. Du kannst also Bytecode erneut durch den Compiler schicken, es wird derselbe Bytecode herauskommen, und du kannst in Bytecode wieder normale Codesequenzen einfügen, falls du die richtige Stelle findest, oder in bzw. vor einen Block normalen Quellcode einen Block Bytecode stellen und nochmals alles kompilieren.
  • Man mag BASIC vielleicht auch in einen Bytecode wandeln; ich glaube, als Bill Gates noch in seiner Garage werkelte, war da auch mal sowas. PRINT 3*4 wird dann vielleicht zu etwas wie @19 12 und @19 ist der Bytecode von PRINT und 12 ist das vorab ausmultiplizierte 3*4. Dementsprechend kannst du auch diese Bytecode-Sequenz in denselben BASIC-Interpreter reinschieben, notfalls von Hand tippen, und es wird der gleiche Effekt eintreten.
  • Es gibt Interpreter, die sind für die Ausführungsphase gebaut, und die kennen und verstehen keine menschliche Syntax mehr. Im Beispiel würde der also nicht mehr wissen, was PRINT bedeuten soll, und kennt nur noch @19.
• In dem Moment, in dem man die auf Vorrat kompilierte Datei dann wirklich auf einem Rechner ausführen möchte, braucht man einen Interpreter oder sonstwie genanntes Ausführungsdings. In das wird die kompilierte Datei reingeschoben, ggf. mit anderen Bibliotheken zusammengebunden, und zum Schluss gesagt: EXEC!
• Von „zeilenweise“ war übrigens nicht die Rede gewesen; vielmehr von „Anweisung oder einen syntaktischen Anweisungsblock“.
  • Eine Anweisung mag über mehrere Zeilen verteilt sein.
  • Es kann auch sein, dass ein Anweisungsblock beginnt mit IF 3 < 4 THEN. Dann gehe in den Block-Level Modus 1, warte auf die nächste Anweisung, führe diese aus. Wenn irgendwann ENDIF auftaucht, verlasse den Block-Level Modus 1 wieder.
  • Es könnte auch sein, dass es beginnt mit IF 7 < 5 THEN. Dann schalte die Ohren auf Durchzug und ignoriere alle nachfolgenden Anweisungen, bis ein ENDIF auftaucht.
  • Klassische Interpretersprachen beenden ihre Anweisungen gern mit einem ; und das möglicherweise pflichtmäßig. Damit wird signalisiert, dass die Anweisung fertig hat und jetzt ausgeführt werden kann. Die Enter wäre sowas, wohingegen nach PRINT 3*4 in einer neuen Zeile oder wegen Überschreitung der darstellbaren Zeilenlänge noch ein +5 folgen könnte; ich will aber 17 rausbekommen und muss markieren, wann eine Anweisung beendet ist und ausgeführt werden kann.

HGZH --PerfektesChaos 01:45, 15. Sep. 2019 (CEST)

Ja, sehe ich genauso.

Interpreter liegen zumeist in Maschinensprache des Zielprozessors vor, können aber auch selbst wieder in einer Interpretersprache vorliegen (siehe Beispiel unten) oder von einem Emulator interpretiert werden. Dies ist beliebig schachtelbar und wirkt sich dementsprechend auf die Abarbeitungsgeschwindigkeit aus.

Hier fehlen mir dennoch Erwähnungen von sowas wie vorcompiliertem BTM (Batch-To-Memory, schnelle 4DOS/4OS2-Batch-Dateien), von vorkompiliertem Java (per JVM ausgeführt), von vorkompiliertem Forth (auf Open-Firmware-basierten Computern plattformunabhängig ausführbar), von vorkompiliertem AGI oder anderem Bytecode, der von Interpretern ausgeführt werden muss.

Auf diese Kleinigkeit wollte ich hinaus. Denn im jetztigen Zustand des Artikel konzentriert sich dieser sehr auf unkompilierten Syntax, also Programmiersprachen, die man auch als Interpretersprachen bezeichen kann. Das tifft auf Bytecode nicht zu.

Sowie der Teilsatz zumeist in Maschinensprache des Zielprozessors nicht dem weit verbreiteten JVM, Forth und anderen Interpreter-Bytecode entspricht (ScummVM läuft auf unzähligen Plattformen und interpretiert dabei vorkompilierten Spiele-Bytecode, der offenbar nicht auf ein einzelnes Zielssystem angewiesen ist).

Ich wollte da nur mal Meinungen hören. Wenn hier jemand, der sich besser auskennt, erklärt hätte, dass ich hier vollkommen falsch liege, hätte ich es erst gar nicht versucht. So werde ich mich wohl mal an die Arbeit machen... irgendwann, wenn ich mal Zeit finde.

Insofern: Danke für die Diskussion!

‣Andreas•⚖ 13:26, 15. Sep. 2019 (CEST)

Der Passus „liegen zumeist in Maschinensprache des Zielprozessors vor, können aber auch selbst wieder in einer Interpretersprache vorliegen“ ist relativ überflüssig und bestenfalls Sahnehäubchen für besonders Wissbegierige. Es gibt Zigtausende an Implementierungen, wie auch immer.

Dass man Interpreter auch mit Bytecode (oder Zwischencode, was gelegentlich synonym gebraucht wird) füttern könne, ist völlig nebensächlich. Insbesondere sollte hier nicht auch noch explizit eine einzelne Bytecode-Syntax genannt werden.

Der kardinale Denkfehler ist, dass Interpreter auch heute noch so vorgestellt werden wie vielleicht 1970 mal. Mittlerweile gibt es aber tausenderlei Implementierungen nach hunderterlei Konzepten.

Es ist nicht so, und war im Prinzip auch noch nie so gewesen, das man Interpreter nur mit einer menschenverständlichen Sprache füttern könne. Es ist völlig egal was für eine Sprache das ist; es muss eine formale Syntax sein und der Interpreter muss sie verstehen. Ob das auch menschenlesbar wäre ist völlig wurscht.

Entscheidend ist: Der Interpreter liest einen ausführbaren Befehl, übersetzt ihn in Maschinenanweisungen und führt ihn aus. Dann kommt der nächste Befehl. Zwischendurch mag es Blocksteuerungs-Anweisungen geben, oder die Deklaration von Symbolen oder Makros, die später innerhalb von Befehlen verwendet werden können, und die dann vor der Befehlsausführung geeignet auszuwerten wären.

Der Abschnitt „Interpretersprachen“ hat nicht ohne Grund einen Ü-Baustein. Das ist halt das klassische Bild von Interpreter und Interpretersprache: Eine menschengerechte Sprache, in der die Befehle formuliert wären, und mit der dann der Interpreter zeilenweise gefüttert würde. Historisch sind sehr viele einschlägige Sprachen in diesem Modus entstanden; aber das kann mich nicht daran hindern, sie statt der sofortigen Ausführung erstmal in irgendeinen Bytecode zu kompilieren und dann später einen geeigneten Interpreter mit meinem Bytecode zu füttern.

LG --PerfektesChaos 15:06, 15. Sep. 2019 (CEST)

Ein Anfang ist gemacht. Es fehlt noch der Abschnitt #Interpretersprachen. Wer sich hier besser auskennt und einbringen will... fühlt sich hoffentlich angesprochen. Es würde mich jedenfalls freuen. Der Fokus ist hier sicher auf einer Programmiersprache, also in Quelltext und menschenlesbar. Denn die Sache mit dem Zwischencode ist oben mMn nun gut drinne...

‣Andreas•⚖ 11:46, 25. Sep. 2019 (CEST)

Übersetzung in Maschinensprache?

Den Satz im Einführungsabsatz finde ich sehr verwirrend. Ist es nicht gerade ein Merkmal eines Interpreters, dass er Befehle direkt ausführt statt eine Maschinensprache-Übersetzung anzufertigen? Der Compiler-Artikel führt das auch als Unterscheidungsmerkmal auf. Es spricht ja auch nichts dagegen, einen Interpreter selbst in einer Hochsprache oder gar in einer interpretierten Sprache zu schreiben, da ist die Ausführung von Maschinensprache beim Lauf des Interpreters schon eher ein technisch bedingtes Merkmal statt einer Intention des Interpreterautors. Oder um es noch etwas weiter zu treiben: Ein G-Code-Interpreter steuert eine Werkzeugmaschine an, aber was wäre da die erzeugte Maschinensprache? Das Werkstück, die Werkzeugbewegungen, die Wellenform an den Motorspulen, die Digitalsignale zur Ansteuerung der Motortreiber oder vielleicht die Befehlssequenz, die die unbekannte CPU in der Maschine ausführt? Der Satz sollte meiner Meinung durch Streichung des Teils ab "indem" gekürzt werden um Fachfremde nicht unnötig zu verwirren. Ich wüsste auch kein Fachbuch, was einen Interpreter so definiert - das im Satz davor und danach verlinkte Standardwerk von Aho et al. verwendet in der mir vorliegenden Ausgabe keine solche Beschreibung. --2.206.253.27 20:21, 3. Apr. 2022 (CEST)

Das Problem an deiner Fragestellung ist das Wörtchen „statt“, und das gibt es häufiger.

Insbesondere wenn man nun den naheliegenden Schluss zieht, es würde sowas wie eine „Interpretersprache“ geben.

Das taucht genauso auf mit den Ausdrücken „Skriptsprache“, „Makro“ usw.

Tatsächlich gibt es den fundamentalen Unterschied nicht; vielleicht müsste es aber mal wieder noch klarer herausgearbeitet werden:

• Ein Interpreter liest Anweisung für Anweisung und führt sie sofort aus.
• Ein Compiler liest alles, übersetzt es in einen effizienteren vorverdauten anderen Code, führt aber nichts aus.

Jede „Interpretersprache“, „Skriptsprache“, „Makrosprache“ kann auch kompiliert werden.

Ursprünglich war ein Interpreter mal dazu bereitgestellt worden, um die in eine Tastatur eingegebenen Einzelbefehle sofort auszuführen; sei es was mit einer Datei im Betriebssystem zu machen, eine Aktion einer Werkzeugmaschine zu steuern, im Grafikprogramm ein Element zu zeichnen.

Nun kann man aber die Einzelbefehle aufzeichnen, dann hat man ein „Makro“ oder „Skript“.

Das „Makro“ kann man nun statt manueller Tastatur in den Interpreter reingeben; dann führt er nacheinander die Einzelbefehle wieder aus.

Oder man kompiliert das Makro, macht es effizienter, und speichert es.

Das kompilierte Makro kann man nun wieder in eine Exekutionsmaschine stecken, die letztlich das gleiche können muss wie der Interpreter (oder dieser selbst ist). Dann werden jetzt die Befehle ausgeführt. Nur dass nicht nach jedem Befehl einzeln eine Übersetzung in maschinell ausführbare Aktionen erfolgen muss, weil das ja schon bei der Kompilierung geschah, sondern direkt die schon vorverdauten Befehle ausgeführt werden.

„Befehle direkt ausführt statt eine Maschinensprache-Übersetzung anzufertigen“ – Nein, das kann auch er nicht. Der Befehl liegt in menschenverständlicher Sprache vor und muss als Einzelbefehl in maschinell ausführbare Aktionen übersetzt werden. Nur halt Einzelbefehl für Einzelbefehl.

Nun klarer?

Die umseitige Darstellung wird im Lauf der Jahre immer mal wieder verbaselt, und dann wird’s halt unverständlich.

VG --PerfektesChaos 21:16, 3. Apr. 2022 (CEST)

Ich hätte mehr zitieren sollen, inzwischen hat jemand den Abschnitt schon umgeschrieben und die aktuelle Fassung finde ich (als jemand, der durchaus mit Interpreter- und Compilerbau vertraut ist) ok. Die vorherige Beschreibung "und führt sie anschließend Anweisung für Anweisung aus, indem er sie in Maschinencode übersetzt, die ein Computersystem direkt ausführen kann." zeigte inhaltlich IMHO ziemlich in die falsche Richtung. --2.206.253.27 22:07, 3. Apr. 2022 (CEST)

Das kann schon sein. Übermäßig leicht verständlich kommt mir der momentane Zustand auch nicht vor, und´die Abgrenzung und Gemeinsamkeit zu den anderen Begriffflichkeiten ist nicht sauber herausgearbeitet, sondern alles zugeschwafelt.

Im Lauf der Jahrzehnte passiert das nach und nach immer wieder mit dem Komplex Interpreter – Compiler – Assembler – Skriptsprache.

Ich habe aber nicht die Zeit, um das mal wieder generalzusanieren, auf die Hälfte zu kürzen, und ewig drumrumzudiskutieren. Ich kann hier nur Rohmaterial liefern.

Der Sachverhalt ist simpel:

• Es braucht in jedem Fall eine Übersetzungseinheit und eine Ausführungseinheit.
• Die Übersetzungseinheit macht aus der menschenverständlichen Anwendungssprache maschinell ausführbare Befehle.
• Die Ausführungseinheit bewegt den Roboter-Arm, malt Kringel auf den Bildschirm, konfiguriert das Betriebssystem oder schubst Dateien herum.
• Ein Interpreter nimmt nun eine einzelne Anweisung in Menschensprache, übersetzt sie, und führt sie sofort aus.
• Wenn man dabei einen Rekorder mitlaufen lässt, hat man eine Makro-Datei mit den protokollierten Befehlen.
• Diese Makro-Datei kann man auch in den Interpreter schieben und das Gleiche nochmal ausführen lassen.
• Man kann nun eine solche Abfolge von Befehlen auch von Null an hinschreiben. Dann hat man ein Skript. Da können dann noch Anweisungen hinzukommen, die als Einzelbefehle schwierig sind, etwa die Definition von Parameterwerten, von Unterfunktionen mit aktuellen Argumenten, Kontrollstrukturen als Verzweigung oder Schleife.
• Das Skript kann man nun auch wieder in den Interpreter reinschmeißen und beliebig oft ausführen lassen. Die ggf. hinzugekommenen Sprachelemente muss er natürlich verdauen.
• Das Ergebnis des auf jeden Fall notwendigen Übersetzungsvorgangs kann man sich in eine separate Datei ausgeben lassen, und auf die sofortige Ausführung verzichten. Dann hat man einen Compiler.
• Ein und dasselbe Softwareprogramm kann je nach seiner Ansteuerung sowohl Interpreter wie auch Compiler sein, und man kann je nach Aktivierung zeilenweise Einzelbefehle reintun und ausführen lassen oder aber eine Datei auf einem maschinennäheren Level ausgeben und abspeichern. Und eine solche maschinennähere Sprachform wieder in dieselbe Software reinstecken und jetzt ausführen lassen.
• Diese ganze Wichtigtuerei mit der Abgrenzung zwischen den Softwareprogrammen ist gaga. Ein Compiler kann ggf. nur übersetzen und nichts ausführen, aber aus jedem Interpreter ließe sich auch ein Compiler machen.

Ansosnten gibt es viel Wortgeklingel um gebräuchliche Begrifflichkeiten, aber wenig standardisierte Definitionen und nach über einem halben Jahrhundert unendlich viele effizientere Mischformen an Sprachen und Software-Konzepten, die sich nicht immer glasklar in genau eine einzige Schublade stecken lassen.

VG --PerfektesChaos 08:15, 4. Apr. 2022 (CEST)

Zum Maschinencode: direkt ausführen ist ein synonym dafür, denn kein Prozessor kann etwas ausführen, was nicht Maschinencode ist. Aber das bedeutet auch, dass der Interpreter den Code nicht direkt ausführt (ausführen kann), denn das ist ja am Anfang kein Maschinencode: das heißt, der Interpreter muss immer einen Maschinencode daraus machen. Um das zu verdeutlichen, war der Satz so gebildet worden...

‣Andreas•⚖ 13:32, 4. Apr. 2022 (CEST)