Esempi di quando useremo il linguaggio interpretato sul linguaggio compilato?

Non c'è (a mia conoscenza) nessuna cosa come una "lingua" interpretata o una "lingua" compilata.

Lingue specificare la sintassi e il significato di parole chiave del codice, costrutti di flusso e varie altre cose, ma io sono a conoscenza di alcun linguaggio che specifica se sia o non deve essere compilato o interpretato nella specifica lingua.

Ora, se la domanda è quando usi un compilatore linguistico o un interprete di lingua, si tratta in realtà dei 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 anziché con l'interprete rubino MRI. Probabilmente ci sono anche ragioni per usare l'interprete rubino di MRI su JRuby, però non ho familiarità con la lingua e non posso parlarne.

Vantaggi offerti dagli interpreti:

• Nessuna compilazione significa che il tempo di modifica del codice per testare l'app può essere ridotto
• Non c'è bisogno di generare binari per architetture multiple perché l'interprete gestirà l'architettura astrazione (anche se si possono è necessario preoccuparsi ancora circa della movimentazione formati interi correttamente, non solo la distribuzione binaria script)

Vantaggi offerti dai compilatori:

• Il codice nativo compilato non ha il sovraccarico di un interprete ed è quindi solitamente più efficiente in termini di tempo e spazio
• L'interoperabilità di solito è migliore, l'unico modo per l'interoperabilità in-proc con gli script è tramite un interprete piuttosto che una FFI standard
• Capacità di supportare le architetture per le quali l'interprete non è stato compilato (come i sistemi incorporati)

Tuttavia, nel 90% dei casi punterei su 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, a 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. Maggiori informazioni su wikipedia

Un punto importante qui è che molte implementazioni linguistiche fanno effettivamente 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. In questo modo vengono in genere implementati Java, C #, Python, Ruby e Lua. In effetti, questo è probabilmente il modo in cui la maggior parte delle lingue in uso oggi vengono implementate. Quindi, il fatto è che il linguaggio oggi interpreta e compila il loro codice. Alcuni di questi linguaggi hanno un compiler JIT aggiuntivo per convertire il bytecode in codice nativo per l'esecuzione.

Secondo me, 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 dei linguaggi interpretati e compilati, probabilmente intendi qualcos'altro. Potresti chiederti del merito della tipizzazione statica / dinamica, dei meriti della distribuzione di eseguibili nativi, dei relativi vantaggi della compilazione JIT e AOT. Questi sono tutti problemi che si confondono con l'interpretazione / la compilazione ma sono problemi diversi.

Prima di tutto, un linguaggio di programmazione può essere sia ininterrotto che compilato. Interpretazione e 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 esegue il codice mentre lo interpreta. Un compilatore, d'altro canto, legge il codice sorgente e genera un file binario eseguibile dal codice sorgente, in modo che il programma possa essere eseguito indipendentemente come processo separato.

Ora prima che qualcuno si chieda ... Sì, è possibile interpretare C / C ++ / C # / Java e sì, è possibile compilare 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 che significhi quando preferire l'interpretazione alla compilazione. Uno dei lati negativi della compilazione è che genera un sovraccarico dovuto al 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 di equivalente codice sorgente interpretato a causa del sovraccarico causato dall'interpretazione del codice. D'altro canto, gli interpreti possono invocare ed eseguire il codice sorgente con un sovraccarico di invocazione molto piccolo, ma a scapito delle prestazioni di runtime.

Alla fine è quasi impossibile menzionare qualsiasi caso di utilizzo definito quando preferire uno dopo l'altro, ma per esempio uno (al mio caso molto irrealistico) sarebbe quando il codice sorgente del programma cambia dinamicamente tra le invocazioni dei programmi e il sovraccarico della compilazione è troppo alto perché possa essere una scelta praticabile. In questo caso, l'interpretazione del codice sorgente invece della compilazione sarebbe probabilmente auspicabile.

Tuttavia, c'è qualcosa che può essere considerato un esempio reale: hidnig source code on deployment. con nativamente codice compilato lo sviluppatore distribuisce il codice macine eseguibile del programma e dei dati. Con il codice interpretato si deve implementare il codice sorgente stesso che può quindi essere ispezionato e decodificato con molto meno sforzo di quello che è per decodificare il codice macchina nativo. Un'eccezione a questo è linguaggi come C # e Java che compilano in linguaggio immediato / bytecode (MSIL per C # e Java bytecode per Java) che poi vengono distribuiti e compilati "just in time" in runtime, un po 'come fa un interprete. Tuttavia, esistono decompilatori cosiddetti per MSIL e Java Bytecode che possono ricostruire il codice sorgente originale con una precisione relativamente buona e in quanto tale reverse-engineering tali prodotti sono molto più banali dei prodotti di reverse engineering che vengono distribuiti nel codice macchina nativo.

Oltre alle ragioni che gli altri hanno menzionato, vi è un caso d'uso particolarmente importante per la scelta di un'interpretazione ad hoc su qualsiasi forma di compilazione o qualsiasi approccio ibrido.

Nel caso in cui un linguaggio di programmazione sia usato come un protocollo di comunicazione e quando la latenza della risposta è importante, ha più senso evitare di sprecare tempo nella compilazione e in ogni possibile pre-elaborazione.

Questo vale per le lingue degli agenti, per esempio, o per il modo in cui, per esempio, Tcl / Tk viene normalmente usato.

Un altro motivo possibile per rimanere fedeli all'interpretazione è quando un interprete di lingua viene utilizzato per l'avvio automatico di se stesso o un linguaggio più elaborato e di livello superiore e la sua semplicità è più importante delle prestazioni del processo di bootstrap.

Per quasi tutti gli altri casi d'uso possibili, la compilazione (o un approccio ibrido) è più adatta.

Posso pensare ai seguenti scenari quando utilizzi una lingua interpretata :

• Dove non esiste alcun compilatore, come Linux / Unix script di shell .
• Script rapidi e sporchi che risolvono un piccolo problema
• Lingue che semplificano la scrittura di pagine HTML dinamiche e sono interpretate in modo generale come JSP (Tomcat lo compila in un servo per previos da eseguire), PHP, ASP ecc.

Posso pensare ai seguenti scenari quando vuoi compilare il tuo codice:

• Devi distribuire i binari perché la tua app è closed-source e non vuoi dare il tuo codice sorgente.
• Velocità, come sistemi incorporati e simili.
• Hai bisogno di un livello di tipo di codice-sicurezza che solo un compilatore con una lingua tipizzata rigorosamente può darti. I compilatori espongono errori di battitura in ogni angolo del codice sorgente, mentre nei programmi interpretati gli errori di battitura possono non essere inclusi nel codice di produzione.
• Grandi , sistemi complessi: impossibile immaginare un sistema operativo o un seme d'ufficio come qualcosa di diverso da binari compilati.
• Desiderate ottenere ogni minimo dettaglio possibile e avere bisogno di una buona comunicazione con gli snippet assembler (difficile con qualsiasi tipo di runtime, specialmente con un interprete) (questo punto è stato causato da un commento di @delnam)

Alla fine, il grande compromesso è tra la produttività (quante righe di codice devi scrivere) e le prestazioni (quanto velocemente il tuo programma verrà eseguito).

Poiché le lingue interpretate quando vengono trasformate in informazioni sulla CPU hanno più informazioni, possono fare affidamento su riflessione e digitazione dinamica che aumentare notevolmente la produttività . Un altro vantaggio delle lingue interpretate è che sono indipendenti dalla piattaforma, a patto che ci sia un interprete per la piattaforma.

Poiché la CPU non deve trasformare il codice lingua nel codice macchina ed eseguire il codice contemporaneamente, come nel caso interpretato, lingue compilate produce programmi più veloci. Inoltre, un sistema compilato in un linguaggio compilato è più sicuro poiché può rilevare problemi in fase di compilazione, il che significa in pratica vedere un errore durante la digitazione (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:

1. Sviluppo produttivo: veloce sviluppo web (PHP, Javascript) o per prototipazione.
2. Cross-Platform; ad esempio JavaScript è supportato in tutti i browser (compresi i browser mobili).

E le lingue compilate sono adatte quando:

1. Le prestazioni sono fondamentali (sistemi operativi) o le risorse sono scarse (microcontrollori).
2. I sistemi da costruire sono complessi; quando si costruiscono grandi sistemi (sistemi aziendali) i linguaggi compilati sono essenziali per gestire molti possibili bug che possono apparire in linguaggi interpretati; anche i programmi complessi richiedono molte risorse e anche l'equilibrio tende a compilare le lingue.