Comprendo le differenze tra le lingue interpretate e compilate, ma se qualcuno potesse fornire alcuni esempi di situazioni in cui è probabile che si utilizzino lingue interpretate su lingue compilate, nonché situazioni in cui è probabile che si utilizzino lingue compilate su lingue interpretate, sarebbe essere davvero utile.
Risposte:
Per quanto ne so, non esiste una "lingua" interpretata o una "lingua" compilata.
Le lingue specificano la sintassi e il significato delle parole chiave del codice, dei costrutti di flusso e di varie altre cose, ma non sono a conoscenza di alcuna lingua che specifichi se deve essere compilato o interpretato o meno nelle specifiche della lingua.
Ora, se la tua domanda è quando usi un compilatore di lingue rispetto a un interprete di lingue, si riduce davvero ai pro / contro del compilatore rispetto all'interprete e allo scopo del progetto.
Ad esempio, è possibile utilizzare il compilatore JRuby per una più facile integrazione con le librerie Java invece dell'interprete ruby MRI. Probabilmente ci sono anche ragioni per usare l'interprete ruby di risonanza magnetica su JRuby, ma non ho familiarità con la lingua e non posso parlarne.
Benefici stimati degli interpreti:
Benefici stimati dei compilatori:
Tuttavia, scommetterei nel 90% dei casi che va qualcosa di più simile a questo: voglio scrivere questo software in blub perché lo conosco bene e dovrebbe fare un buon lavoro. Userò l'interprete blub (o compilatore) perché è il metodo canonico generalmente accettato per scrivere software in blub.
Quindi TL; DR è fondamentalmente un confronto caso per caso degli interpreti rispetto ai compilatori per il tuo caso d'uso specifico.
Inoltre, FFI: Foreign Function Interface, in altre parole interfaccia per l'interoperabilità con altre lingue. Altre letture su Wikipedia
Un punto importante qui è che molte implementazioni linguistiche in realtà fanno una sorta di ibrido di entrambi. Molte lingue comunemente usate oggi funzionano compilando un programma in un formato intermedio come bytecode e quindi eseguendolo in un interprete. Ecco come vengono implementati Java, C #, Python, Ruby e Lua. In realtà, questo è probabilmente il modo in cui viene implementata la maggior parte del linguaggio in uso oggi. Quindi, il fatto è che il linguaggio oggi interpreta e compila il loro codice. Alcune di queste lingue hanno un compilatore JIT aggiuntivo per convertire il bytecode in codice nativo per l'esecuzione.
A mio avviso, dovremmo smettere di parlare di linguaggi interpretati e compilati perché non sono più categorie utili per distinguere le complessità delle attuali implementazioni linguistiche.
Quando chiedi dei meriti delle lingue interpretate e compilate, probabilmente intendi qualcos'altro. Potresti chiedere il merito della tipizzazione statica / dinamica, i vantaggi della distribuzione di eseguibili nativi, i vantaggi relativi della compilazione JIT e AOT. Questi sono tutti problemi che si confondono con l'interpretazione / compilazione ma sono diversi.
Prima di tutto, un linguaggio di programmazione può essere sia interpretato che compilato. L'interpretazione e la compilazione sono solo metodi per generare codice eseguibile dal codice sorgente. Con un interprete il codice sorgente viene letto e interpretato da un interprete che quindi esegue il codice mentre lo interpreta. D'altra parte un compilatore legge il codice sorgente e genera un file binario eseguibile dal codice sorgente, in modo che il programma possa essere eseguito in modo indipendente come processo separato.
Ora, prima che qualcuno si chieda ... Sì, è possibile interpretare C / C ++ / C # / Java e sì, è possibile compilare gli script JavaScript e Bash. Se ci sono interpreti o compilatori funzionanti per queste lingue è un'altra domanda però.
Ora per rispondere effettivamente alla domanda quando useremo "linguaggio interpretato" su "linguaggio compilato". La domanda in sé è alquanto confusa, ma presumo significhi quando preferire l'interpretazione alla compilazione. Uno degli aspetti negativi della compilazione è che genera un overhead a causa del processo di compilazione: il codice sorgente deve essere compilato in codice macchina eseguibile, quindi non è adatto per attività che richiedono un ritardo minimo quando si richiama il codice sorgente per eseguire un programma. D'altra parte il codice sorgente compilato è quasi sempre più veloce del codice sorgente interpretato equivalente a causa del sovraccarico causato dall'interpretazione del codice. Gli interpreti invece possono invocare ed eseguire il codice sorgente con pochissime spese di invocazione, ma a scapito delle prestazioni di runtime.
Alla fine è quasi impossibile menzionare casi d'uso definiti quando preferire uno dopo l'altro, ma per esempio un caso (a mio avviso molto poco realistico) sarebbe quando il codice sorgente del programma cambia dinamicamente tra le invocazioni del programma e anche l'overhead della compilazione è alto per essere una scelta praticabile. In tal caso sarebbe probabilmente preferibile interpretare il codice sorgente anziché compilare.
Tuttavia, c'è qualcosa che può essere considerato un esempio reale: nascondere il codice sorgente al momento della distribuzione. Con nativamentecodice compilato lo sviluppatore distribuisce il codice macine eseguibile del programma e dei dati. Con il codice interpretato deve essere distribuito il codice sorgente stesso che può quindi essere ispezionato e retroingegnerizzato con molto meno sforzo di quello che è il reverse engineering del codice macchina nativo. Un'eccezione a ciò è rappresentata da linguaggi come C # e Java che vengono compilati in linguaggio / bytecode immediati (MSIL per C # e bytecode Java per Java) che vengono quindi distribuiti e compilati "just in time" in fase di esecuzione, un po 'come fa un interprete. Tuttavia, esistono i cosiddetti decompilatori per MSIL e Java Bytecode che possono ricostruire il codice sorgente originale con una precisione relativamente buona e come tale retroingegnerizzazione di tali prodotti è molto più banale dei prodotti di retroingegnerizzazione che sono distribuiti in codice macchina nativo.
Posso pensare ai seguenti scenari quando useresti un linguaggio interpretato :
Posso pensare ai seguenti scenari quando vuoi compilare il tuo codice:
Alla fine, il grande compromesso è tra produttività (quante righe di codice devi scrivere) e prestazioni (quanto velocemente il tuo programma verrà eseguito).
Poiché i linguaggi interpretati quando trasformati in informazioni sulla CPU hanno più informazioni, possono fare affidamento sulla riflessione e sulla digitazione dinamica che aumentano notevolmente la produttività . Un altro vantaggio delle lingue interpretate è che sono indipendenti dalla piattaforma così a lungo che esiste un interprete per la piattaforma.
Poiché la CPU non deve trasformare il codice della lingua in codice macchina ed eseguire il codice contemporaneamente, come nel caso interpretato, i linguaggi compilati producono programmi più veloci. Inoltre, un sistema costruito in un linguaggio compilato è più sicuro poiché può rilevare i problemi in fase di compilazione, il che significa sostanzialmente che vedi un errore mentre lo digiti (con IDE moderni) invece di vederlo solo quando esegui effettivamente il programma (ovviamente , questo non risolve errori logici).
Sapendo questo, le lingue interpretate sono adatte per:
E i linguaggi compilati sono adatti quando:
Oltre ai motivi citati dagli altri, esiste un caso d'uso particolarmente importante per la scelta di un'interpretazione ad hoc rispetto a qualsiasi forma di compilazione o approccio ibrido.
Nel caso in cui un linguaggio di programmazione sia utilizzato come protocollo di comunicazione e quando la latenza di risposta è importante, ha più senso evitare di perdere tempo nella compilazione e ogni possibile preelaborazione.
Questo vale per le lingue degli agenti, ad esempio, o per il modo in cui, ad esempio, Tcl / Tk viene normalmente utilizzato.
Un altro possibile motivo per attenersi all'interpretazione è quando un interprete di linguaggio viene utilizzato per l'avvio automatico o un linguaggio di livello superiore più elaborato e la sua semplicità è più importante delle prestazioni del processo bootstrap.
Per quasi tutti gli altri possibili casi d'uso, la compilazione (o un approccio ibrido) si adatta meglio.