Portabilità di un linguaggio
Perché i linguaggi interpretati sono più portabili rispetto ai linguaggi compilati?
Risposte
In realtà la portabilità di un linguaggio è un tema parecchio vasto, che dubito riesca a venire liquidato in poche righe[nota]E ti premetto che esula parecchio dalla mia competenza...[/nota].
Da quanto ho sempre sentito dire, è il codice scritto in un linguaggio interpretato ad essere più facilmente trasferibile in altre architetture ("write once, run (debug) everywhere" no?). Se è questo che intendi, credo che il motivo sia il minore lavoro che spetta al programmatore nell'ottimizzazione del codice rispetto a una determinata macchina, essendo questo svolto dall'implementazione stessa dell'interprete. Per definizione un linguaggio compilato è legato all'ISA per cui lavora il compilatore.
Se ciò che intendi è invece il linguaggio stesso (il compilatore, la sdk..), tutto ciò che al momento mi viene in mente è la storia di C (non C++ eh): un compilatore relativamente semplice, portato in (riscritto per) una pletora di sistemi differenti ("WOCE"); rimaneggiare il source nel passaggio da un'architettura ad un altra credo sia comunque inevitabile: la somma di due operandi sarà pure tradotta differentemente nell'eseguibile, però nota che ad esempio le operazioni di i/o comunemente gestite dalla libreria standard vanno anch'esse adattate, anche se non direttamente dall'utente del linguaggio. Un interprete deve per sua natura essere legato all'architettura nella quale deve "interpretare" il codice, quindi forse (forse invece sto dicendo una [strike]cazz[/strike]cosa stupida) è un applicativo più complesso e più legato alla stessa di un compilatore
Altra diramazione è quella tra linguaggio macchina (assembly, anche le sue derivazioni di più alto livello) e linguaggio compilato: mentre il primo è tutt'uno (più o meno) con l'ISA dove si targetta lo sviluppo, il secondo è per l'astrazione voluta dal compilatore più indipendente da essa, e la disponibilità del compilatore stesso su più macchine permette una maggiore portabilità del prodotto finale.
Comunque attendi risposte più cristiane: non ho a che fare da parecchio con queste cose, né mai le ho approfondite più di tanto
Da quanto ho sempre sentito dire, è il codice scritto in un linguaggio interpretato ad essere più facilmente trasferibile in altre architetture ("write once, run (debug) everywhere" no?). Se è questo che intendi, credo che il motivo sia il minore lavoro che spetta al programmatore nell'ottimizzazione del codice rispetto a una determinata macchina, essendo questo svolto dall'implementazione stessa dell'interprete. Per definizione un linguaggio compilato è legato all'ISA per cui lavora il compilatore.
Se ciò che intendi è invece il linguaggio stesso (il compilatore, la sdk..), tutto ciò che al momento mi viene in mente è la storia di C (non C++ eh): un compilatore relativamente semplice, portato in (riscritto per) una pletora di sistemi differenti ("WOCE"); rimaneggiare il source nel passaggio da un'architettura ad un altra credo sia comunque inevitabile: la somma di due operandi sarà pure tradotta differentemente nell'eseguibile, però nota che ad esempio le operazioni di i/o comunemente gestite dalla libreria standard vanno anch'esse adattate, anche se non direttamente dall'utente del linguaggio. Un interprete deve per sua natura essere legato all'architettura nella quale deve "interpretare" il codice, quindi forse (forse invece sto dicendo una [strike]cazz[/strike]cosa stupida) è un applicativo più complesso e più legato alla stessa di un compilatore
Altra diramazione è quella tra linguaggio macchina (assembly, anche le sue derivazioni di più alto livello) e linguaggio compilato: mentre il primo è tutt'uno (più o meno) con l'ISA dove si targetta lo sviluppo, il secondo è per l'astrazione voluta dal compilatore più indipendente da essa, e la disponibilità del compilatore stesso su più macchine permette una maggiore portabilità del prodotto finale.
Comunque attendi risposte più cristiane: non ho a che fare da parecchio con queste cose, né mai le ho approfondite più di tanto
Dove hai letto questa frase? Sinceramente ritengo non abbia senso siccome, come già detto giustamente da @marco2132k, il discorso è molto più complicato e sfugge ad una semplice approssimazione come quella che hai scritto.
Il primo problema è che non è semplice separare i linguaggi nelle due categorie di compilati e interpretati. Esistono infatti situazioni ibride, come linguaggi compilati in una rappresentazione intermedia o script che vengono compilati just in time. Esistono inoltre differenze di portabilità notevoli all'interno delle due famiglie. Ci sono sia linguaggi compilati che interpretati che sono disponibili per una sola architettura mentre altri linguaggi (sia compilati che interpretati) sono disponibili per decine di architetture.
Possiamo poi parlare di portabilità dell'eseguibile o del codice sorgente. La portabilità di un eseguibile, come nel caso dei linguaggi interpretati o di linguaggi come Java, è la portabilità del file che può poi essere eseguito dall'utente. In generale la portabilità di un file eseguibile dipende dalla portabilità dell'interprete o della macchina virtuale. In teoria (in pratica è più complicato) un linguaggio che dispone di questo tipo di portabilità può essere eseguito usando lo stesso file su più sistemi senza che sia necessario modificarlo/ricrearlo. La portabilità del codice sorgente significa che, a patto che siano disponibili i necessari strumenti di sviluppo sulla nuova architettura, il software può essere preparato per quella nuova architettura senza modifiche.
In pratica, a meno di star parlando di software che fanno solo uso di librerie standard, un codice può essere molto meno portabile dei suoi strumenti di sviluppo o interprete o macchina virtuale. Non è insomma per esempio difficile creare un software che funziona solo su Windows facendo uso di un qualsiasi linguaggio disponibile per molte più architetture.
Il primo problema è che non è semplice separare i linguaggi nelle due categorie di compilati e interpretati. Esistono infatti situazioni ibride, come linguaggi compilati in una rappresentazione intermedia o script che vengono compilati just in time. Esistono inoltre differenze di portabilità notevoli all'interno delle due famiglie. Ci sono sia linguaggi compilati che interpretati che sono disponibili per una sola architettura mentre altri linguaggi (sia compilati che interpretati) sono disponibili per decine di architetture.
Possiamo poi parlare di portabilità dell'eseguibile o del codice sorgente. La portabilità di un eseguibile, come nel caso dei linguaggi interpretati o di linguaggi come Java, è la portabilità del file che può poi essere eseguito dall'utente. In generale la portabilità di un file eseguibile dipende dalla portabilità dell'interprete o della macchina virtuale. In teoria (in pratica è più complicato) un linguaggio che dispone di questo tipo di portabilità può essere eseguito usando lo stesso file su più sistemi senza che sia necessario modificarlo/ricrearlo. La portabilità del codice sorgente significa che, a patto che siano disponibili i necessari strumenti di sviluppo sulla nuova architettura, il software può essere preparato per quella nuova architettura senza modifiche.
In pratica, a meno di star parlando di software che fanno solo uso di librerie standard, un codice può essere molto meno portabile dei suoi strumenti di sviluppo o interprete o macchina virtuale. Non è insomma per esempio difficile creare un software che funziona solo su Windows facendo uso di un qualsiasi linguaggio disponibile per molte più architetture.
Volevo dire il contrario, un linguaggio interpretato risulta più portabile rispetto ad uno compilato. Da quanto credo di sapere, un linguaggio come il C attraversa 4 fasi e durante quella di compilation e assembly il codice viene viene tradotto nel codice oggetto di una determinata architettura, quindi penso per questo sia meno portabile. Mentre per i linguaggi interpretati non so molto bene come funzioni.
Stai quindi parlando di portabilità dell'eseguibile. In questo caso è certamente vero che qualcosa che va interpretato può essere eseguito su architetture diverse mentre non è il caso per un eseguibile compilato per la macchina specifica. Tuttavia, parlando di linguaggi di programmazione ha più senso parlare di portabilità del codice sorgente. La differenza tra compilato e interpretato non è infatti insita nel linguaggio. Esistono ad esempio interpreti per il C e compilatori per Python. Da questo punto di vista un linguaggio come C è probabilmente il più portabile.
Un programma compilato su una determinata maccchina non ha bisogno di una nuova compilazione su una macchina diversa ma che ha stesso processore della prima?
Se il sistema operativo è lo stesso non ne ha bisogno.
Ma il codice oggetto non dipende dalla particolare architettura del processore, quindi dal ISA e non dal sistema operativo?
Un eseguibile contiene più informazioni rispetto alle istruzioni che vengono eseguite. Queste informazioni sono memorizzate in un formato che dipende dal sistema operativo.
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo