Interpretato vs vs Compilato late-binding

Question

Python viene compilato in un bytecode intermedio (PYC) e quindi eseguito. Quindi, v'è una raccolta seguita da un'interpretazione. Tuttavia, da lungo tempo gli utenti Python dicono che Python è un linguaggio "late-binding" e che should`nt essere indicato come un linguaggio interpretato.

1. Come sarebbe Python essere diverso da un altro linguaggio interpretato?

2. Potrebbe dirmi che cosa "late-binding" si intende, nel contesto Python?

Java è un altro linguaggio che per primo ha il codice sorgente compilato in bytecode e quindi interpretato in bytecode.

1. è Java un / linguaggio interpretato compilato?

2. Come è diverso da Python in termini di compilazione / esecuzione?

3. Java è detto di non avere "late-binding". Questo ha qualcosa a che fare con programmi Java di essere leggermente più veloce di Python?

Sarebbe bello se si potesse anche darmi i collegamenti ai luoghi dove le persone hanno già discusso di questo; Mi piacerebbe saperne di più su questo. Grazie.

Answer 1

tardiva è un concetto molto diverso all'interpretazione.

A rigor di termini, un linguaggio interpretato viene eseguito direttamente dalla sorgente. E non passa attraverso una fase di compilazione bytecode. La confusione nasce dal fatto che il programma python è di un interprete, ma interpreta il byte-code, quindi è il linguaggio bytecode di Python che si descriverebbe come "interpretato". Il linguaggio Python stesso è un linguaggio compilato.

Java bytecode, al contrario, si sia interpretato e compilato, in questi giorni. Esso viene compilato in codice nativo da un JIT compiler e quindi eseguire direttamente sull'hardware.

tardiva è una proprietà del sistema tipo ed è presente nella maggior parte delle lingue in una certa misura, indipendentemente dal fatto che siano interpretati o compilati.

Answer 2

  

Come sarebbe Python essere diverso da un altro linguaggio interpretato?

che coinvolge i capelli-splitting. linguaggi interpretati e linguaggi "codice gestito" come C # ei linguaggi delle macchine virtuali (come Java) formano un continuum strano. Ci sono persone che diranno che tutti sono le lingue "interpretati" - linguaggio macchina, anche. Dopo tutto, i circuiti elettronici della CPU "interpretano" linguaggio macchina.

Il meglio che puoi fare è dire che "interpretato" significa che c'è uno strato visibile di software interpretare le vostre applicazioni byte-codici. "Non-interpretati" significa che il software è (più o meno) eseguito direttamente dall'hardware sottostante. "Codice gestito" le persone sono libere di continuare a dividere questi capelli.

  

Potrebbe dirmi che cosa "late-binding" si intende, nel contesto Python?

Le variabili non sono dichiarato di avere un tipo. La variabile è legata a un tipo il più tardi possibile -. Con l'assegnazione di un oggetto reale

  

è Java un interpretato / linguaggio compilato?

Sì. E 'compilato per i codici di byte. I codici byte vengono interpretati. Io preferisco chiamarla interpretato.

Tuttavia, la gente (per davvero oscuri motivi) in disaccordo. La presenza di qualsiasi tipo di passo "compilazione" - anche minima - confonde sempre le persone. La traduzione di bytecode non ha quasi alcuna rilevanza per l'effettivo comportamento del programma in fase di esecuzione. Alcune persone piace dire che solo lingue che sono tutto libero da ogni macchia di "compilation" di pre-elaborazione può essere interpretato. Non ci sono un sacco di esempi di questo più, dal momento che molte lingue sono stati tradotti dal testo human-friendly per interprete bytecode amichevoli. Anche Applesoft di base (indietro negli anni 80) ha avuto questo tipo di passaggio di traduzione svolto come digitato il codice in.

Alcuni di JVM do JIT. Alcuni non lo fanno. Alcuni sono una miscela. Dire che la JVM fa solo traduzione JIT byte-codice non è corretto. Alcuni di JVM fanno. Alcuni non lo fanno.

  

Come è diverso da Python in termini di compilazione / esecuzione?

Niente affatto. Il Java VM può eseguire Python. [Per la facilmente confusa, la parola "python" in questo contesto non può assolutamente significare "sorgente Python". Deve significare pitone bytecode.]

  

Java è detto di non avere "late-binding". Questo ha qualcosa a che fare con programmi Java di essere leggermente più veloce di Python?

Forse. programmi Java sono spesso più velocemente a causa di compilatori JIT che si traducono Java bytecode in codice macchina in fase di esecuzione.

Static ( "precoce") vincolante non ha lo stesso tipo di beneficio per Java che si ha con un linguaggio veramente compilato come C o C ++, dove non ci sono quasi controlli run-time di qualsiasi tipo. Java fa ancora cose come limiti di matrice controllo, che omette C nell'interesse della velocità di prima.

V'è in realtà poco pena per il "ritardo" vincolante. attributi Python e metodi vengono risolti utilizzando semplici ricerche del dizionario. Il dizionario è un hash; prestazioni sono abbastanza buone. Gli hash per i nomi possono essere messi in una piscina letterale "internato" stringa ammortizzare il costo del calcolo dell'hash.

Per il divertimento vero e proprio, guarda PyPy e RPython. Si tratta di un interprete Python che può fare la compilazione JIT. Si finisce con un interprete 2-tier. Il tuo codice è interpretato da PyPy. PyPy è interpretato da RPython. http://alexgaynor.net/2010/may/15/pypy-future -python /

Answer 3

C'è una connessione tra ciò che chiamiamo il il tempo di legame e il concetto di interpretazione / compilation .

Il tempo di legame è il momento in cui l'espressione simbolica è legata al suo valore concreto. Questo è più legato alla definizione del linguaggio di programmazione, ad esempio, scoping vs. statica dinamica delle variabili. O metodo statico vs metodi virtuali o tipizzazione dinamica vs tipizzazione statica.

Poi arriva l'implementazione del linguaggio. Più informazioni sono noti staticamente in anticipo, più facile è quello di scrivere un compilatore. Al contrario, il più in ritardo legato la lingua è, più è difficile. Da qui la necessità di fare affidamento sulle tecniche interpretative volte.

La distinzione tra i due non è rigida però. Non solo si può considerare che tutto è infine interpretato (vedi S. Lott risposta), ma parte del codice può essere compilato, decompilare o ricompilazione dinamicamente (ad esempio JIT) rendendo la distinzione molto disturbata.

Per esempio, il caricamento classe dinamica in Java va nella categoria "associazione tardiva": l'insieme di classe non è fissato una volta per tutte, e le classi può essere caricato in modo dinamico. Alcune ottimizzazioni può essere fatto quando sappiamo che l'insieme di classi, ma dovranno essere invalidato una volta una nuova classe viene caricato. Lo stesso accade con la possibilità di aggiornare un metodo con l'infrastruttura di debug:. JVM avrà bisogno di de-ottimizzare tutti i siti di chiamata sono stati il ??metodo era stato inline

Non so molto su Python, ma i praticanti Python preferiscono forse il termine "ritardo legato" per evitare tale confusione.

Answer 4

Credo che il malinteso comune che Python viene interpretato mentre Java viene compilato deriva dal fatto che Java ha un passo di compilazione esplicita - è necessario eseguire javac per convertire il file di origine .java in un file bytecode .class che può essere eseguito.

Come lei ha giustamente segnalo Python compila in modo simile i file sorgente in bytecode, ma lo fa in modo trasparente -. Compilazione e l'esecuzione è generalmente fatto in un unico passaggio, quindi è meno evidente per l'utente

La differenza importante è tra i primi e l'associazione tardiva e dinamico e tipizzazione statica. La distinzione compilato / interpretato è insignificante e irrilevante.

Answer 5

tempo di legame è quando si risolvono i nomi alle cose. Altri linguaggi dinamici tendono verso l'associazione tardiva. Questo può essere separata dalla interpretazione / compilation - per esempio, metodi Objective-C sono risolte in ritardo e in modo dinamico rispetto al C ++. Java fa gran parte di essa è vincolante al momento del caricamento della classe: dopo le C, ma prima di Python.

la mia citazione preferita da Stan Kelly-Bootle Computer contraddittori :

vincolante tempo n. Il momento in cui la tabella di hash viene danneggiato.

==> I progressi nel calcolo possono essere mappati contro la "tarda vincolante", che ha fatto pensare a mia cosiddetta CS cosiddetta carriera: passato d'oro, Grey presente, e il futuro roseo. Questa è la mia versione di ottimismo di Synge: l'erba è più verde, tranne a T = 0. Su EDSAC Io, le mie funzioni (subroutine 5CH carta-nastro) sono stati perforati, assemblati in parallelo, e lo avvolsero circa due settimane prima di ingresso. Questo è noto aspremature vincolante e chiede manualità con fasce elastiche. FORTRAN è venuto dopo, con un nuovo tipo di rilegatura: mazzi bagnati di carte che si rifiutavano di essere mescolate. Poi, con Algol e C, mi sono divertito statico (in fase di compilazione) vincolante, fino a C ++ ha portato le gioie attenuazione della dinamica (run-time) di legame. I miei obiettivi di ricerca in corso a ritardare il legame fino a ben dopo l'esecuzione. Io chiamo vincolante questo tempo della fine, come profetizzato nel Vangelo di Matteo: "... e tutto ciò che legherai sulla terra sarà legato nei cieli ..." (Matteo 16:19 KJV)

.