Quasi tutte le lingue convenzionali oggi rappresentano l'intenzione dei programmatori come sorgente di testo, che viene quindi (diciamo per semplicità) tradotta in qualche codice bytecode/macchina e interpretato/eseguito da una VM/CPU.
C'era un'altra tecnica, che, per qualche ragione, non è così popolare in questi giorni: "congelare" il tempo di esecuzione della VM e scaricare/serializzare l'ambiente (collegamenti di simboli, stato, codice (qualunque cosa sia)) in un'immagine, che è quindi possibile trasferire, caricare ed eseguire. Conseguentemente, non si "scrive" il codice in un modo usuale, ma si modifica l'ambiente con nuovi simboli, mentre in "tempo di esecuzione".
vedo grandi vantaggi di questa tecnica:Codice come immagine di sistema (ambiente runtime serializzato) vs origine (testo)
- Power-potenziato REPL: è possibile introspezione il codice come lo scrivete, parzialmente valutarla, testare direttamente e vedere gli effetti delle modifiche. Poi torna indietro se hai incasinato e fallo di nuovo, o affidalo finalmente all'ambiente. Non c'è bisogno di un lungo ciclo di compilazione-run-debug;
- Alcuni dei soliti problemi relativi ai linguaggi dinamici (che non possono essere compilati, poiché il compilatore non può ragionare sugli ambienti in modo statico) sono dimenticati: l'interprete sa dove si trova e può sostituire i riferimenti simbolici con offset statici e altre ottimizzazioni;
- È più facile per il cervello del programmatore: "scarica" diverse informazioni contestuali sul codice dalla tua testa, cioè non devi tenere traccia di ciò che il tuo codice ha già fatto in una struttura di variabili/dati o quale variabile contiene cosa : lo vedi direttamente davanti ai tuoi occhi! Nel solito modo (fonte di scrittura), i programmatori aggiungono nuove astrazioni o commenti al codice per chiarire gli intenti, ma questo può (e lo farà) diventare disordinato.
La domanda è: quali sono gli svantaggi di questo approccio? C'è qualche serio svantaggio critico che non vedo? Lo so, ci sono alcuni problemi con esso, vale a dire:
- provare a costruire un sistema di moduli con esso, non si tradurrà in un inferno dipendenza o di gravi problemi di collegamento
- problemi di sicurezza
- cercano di controllo delle versioni tali immagini e consentire lo sviluppo simultaneo
Ma questi sono, IMHO, risolvibile con un buon design.
EDIT1: relativo allo stato "chiuso, principalmente basato su opinioni". Ho descritto due approcci esistenti ed è chiaro ed evidente che uno è preferito rispetto ad un altro. Se le ragioni di questo sono puramente "basate sull'opinione pubblica" o se esiste una ricerca per sostenerlo, non mi è noto, ma anche se sono basate sull'opinione pubblica, se qualcuno elencherebbe le ragioni per cui sviluppare tale opinione, dovrebbe, in realtà, rispondere alla mia domanda.
Cosa ti fa pensare che i linguaggi dinamici non possano essere compilati?Tutte le implementazioni attualmente predisposte per la produzione di ECMAScript/JavaScript, Python, Ruby, PHP, Perl, Clojure, Erlang, Smalltalk, molti Schemi, molti CommonLisps, hanno compilatori. Bot l'originale basato su Ruby e l'attuale implementazione self-hosting di CoffeeScript sono puri compilatori AOT statici. La versione originale di V8 era un puro compilatore, la versione corrente ha più compilatori cooperativi, ma ancora nessun interprete, in nessun punto della storia di V8 ha mai interpretato nulla. Naturalmente, Smalltalk è solitamente compilato. –
Ricerca del linguaggio del kernel, macro di prima classe, ambienti di prima classe: c'è una discussione molto approfondita su lambda-the-ultimate su questo argomento. – artemonster