Dal punto di vista dell'esecuzione è un interprete uguale a JVM / o .net Framework

Diversi commenti hanno evidenziato diverse ambiguità nella domanda e sfumature alla risposta, ma la risposta semplice è no.

La JVM e .NET Framework sono I compilatori Just-In-Time . Sono ancora compilatori e fanno tutto il lavoro di un compilatore. Prendono un linguaggio intermedio (bytecode), lo ottimizzano e lo convertono in codice macchina. L'unica differenza tra jitter e compilatori tradizionali è quando fanno la compilazione.

Interpreti , almeno nella loro definizione tradizionale, mai codice di compilazione . Piuttosto, usano un codice che è già compilato per eseguire le istruzioni che sono state date. Questo li rende più veloci da avviare (dato che non hanno bisogno di compilare nulla) ma generalmente sono più lenti da eseguire, dato che c'è un sovraccarico associato a ciascuna istruzione.

Se hai scritto del codice che ha seguito una serie di istruzioni "switch" o "if":

• Leggi ogni riga di un file
• Per ogni riga che dice "A", scrivi "ciao" sullo schermo
• Per ogni riga che dice "B", scrivi "mondo" sullo schermo
• Per ogni altra riga, scrivi "errore" sullo schermo

Quindi questo sarebbe un interprete (molto rozzo). Sarebbe non essere un compilatore di qualsiasi tipo, perché tutte le parti che effettivamente eseguite sulla macchina sono nel tuo programma. Sta facendo analisi , ma salta i passaggi compilazione e link e passa direttamente a esecuzione in base a una ricerca tavolo.

Un altro modo di pensarci - e mi preme che questa sia puramente un'analogia per i principianti e non una descrizione tecnica perfettamente accurata - è che gli interpreti essenzialmente lavorano su base riga per riga, mentre i nervosismi compileranno grossi pezzi di il bytecode o forse anche l'intero bytecode allo stesso tempo.

Spesso è anche possibile precompilare il bytecode senza un jitter (come NGen di Microsoft), poiché il codice byte è in genere molto simile (ma non identico) al codice macchina. Il codice interpretato di solito rimane in un linguaggio di alto livello fino all'esecuzione.

C'è un punto di vista tecnico:

• un compilatore è un processo che trasforma una vista di un programma in un'altra vista, abbassando il livello di astrazione

• un interprete è un processo che esegue un programma, possibilmente prima trasformando la sorgente in un'altra vista, ma quella non avrà un livello di astrazione significativamente più basso.

C'è un punto di vista dell'utente:

• un compilatore trasfor semplicemente il programma, non verrà eseguito lì fino a un altro passo

• un interprete eseguirà il programma.

C'è una certa confusione nella differenza tra i due.

Un interprete come utente lo vede a volte usa tecniche di compilazione. In primo piano, compilando il programma sorgente in una rappresentazione intermedia che è di un livello di astrazione significativamente inferiore rispetto alla sorgente prima di interpretarla, magari andando anche a livello macchina ( carica e vai compilatore ). A volte rileva codice molto usato e compila solo quella parte o applica un'ottimizzazione speciale ( solo in tempo di compilazione ).

I compilatori non devono andare al linguaggio macchina. C è un obiettivo popolare per le lingue sperimentali. Un'altra scelta popolare è un codice intermedio più o meno simile a una macchina che deve essere interpretato da una macchina virtuale, a volte esponendo il codice byte in quanto tale, a volte unendo la macchina virtuale con il codice byte in un eseguibile (era il modo di l'implementazione Pascal più diffusa e diffusa ha funzionato).

La macchina virtuale è essa stessa un interprete, ma può applicare tecniche di compilazione come sopra scritto.

A volte i compilatori generano una descrizione più o meno simile a una macchina e delegano le vere generazioni di codice macchina al linker. Quella generazione può anche essere eseguita al momento dell'installazione (AS / 400 e successori il cui nome non riesco a ricordare nella serie? Zube è il più lungo durante il sistema che conosco che usa quel metodo).

Ora le tue domande:

• Un interprete fa lo stesso lavoro di qualcosa come la JVM, solo senza il codice byte?

A volte sì, a volte è il raggruppamento del compilatore java e della JVM.

• Per python l'interprete prende il codice di alto livello e lo traduce in codice macchina?

Esistono diversi interpreti e sistemi Python. Non penso che il più popolare passi al codice macchina.

• La macchina virtuale Java deve essere installata su una macchina affinché venga eseguita su di essa un programma java - è simile per python - se l'interprete è installato sulla macchina di destinazione, verrà eseguito il programma python?

L'implementazione Python più popolare è un interprete che deve essere installato.

• La JVM (& .net framework) è un efficace interprete di codice byte?

Sì, quelli che ho chiamato "interpreti di livello utente" possono applicare tecniche di compilazione vere per offrire prestazioni migliori.

La distinzione tra codice interpretato e codice compilato era più chiara quando stavo imparando per la prima volta.

Il primo linguaggio di programmazione che ho imparato era una versione precedente di Microsoft BASIC che era testo ed è stata interpretata da un interprete.

Poi, quando andai all'università, imparai a programmare in Pascal e C che sono entrambi linguaggi compilati che si compongono fino al codice macchina e non hanno bisogno di nulla come una macchina virtuale da eseguire.

Inoltre, al college, ho imparato lo scripting di shell Unix che è testo e viene interpretato.

La distinzione era più chiara.

Penso a Java e Python in quanto entrambi vengono compilati e interpretati. Vedo Python come lo strumento giusto per il lavoro quando vuoi essere in grado di cambiare qualcosa senza dover ricompilare.

Java è buono perché quando lo compili, molti dei bug si trovano in fase di compilazione.

Credo che sia Python sia Java siano entrambi compilati e interpretati. Vedo Java come "più compilato" perché vengono trovati più bug in fase di compilazione.