Penso che ci sia una distinzione da fare, tuttavia non è necessariamente tra "Compiled" e "Managed". Questi non sono opposti; una lingua può essere compilata e non gestita, o interpretata (non compilata) e gestita, o entrambe o nessuna delle due.
Un linguaggio "compilato" è semplicemente uno in cui esiste un passaggio che trasforma il codice sorgente scritto dallo sviluppatore in un "bytecode" più regolare, che è ciò che viene eseguito dalla macchina. La "macchina" può essere il processore reale o una "macchina virtuale" che esegue operazioni aggiuntive sui bytecode per tradurli in istruzioni macchina "native". L'antonym per un linguaggio "compilato" è un linguaggio "interpretato", in cui il codice sorgente viene trasformato in istruzioni bytecode in fase di esecuzione, riga per riga mentre vengono eseguiti, senza un passo di compilazione. Un ibrido tra di loro è "jitting", da "JIT" (Just In Time), che di solito è interpretato come un passo una tantum dalla macchina in esecuzione; una riga di codice (o funzione o file sorgente) viene interpretata al primo avvio, ma le istruzioni native prodotte vengono mantenute in memoria in modo che il runtime non debba rieseguire l'interpretazione di nuovo sulle esecuzioni successive di quel codice.
Un linguaggio "gestito" è un linguaggio progettato per produrre programmi che vengono consumati all'interno di un ambiente runtime specifico, che include quasi sempre un interprete bytecode; una "macchina virtuale" che prende il codice del programma ed esegue una trasformazione aggiuntiva specifica per macchina o ambiente. L'ambiente può anche includere la gestione della memoria, come un "garbage collector" e altre funzionalità di "sicurezza" che servono a mantenere il programma operativo all'interno della sua "sandbox" di spazio e strumenti, tuttavia tali funzionalità non sono l'unico dominio dei runtime "gestiti" . Praticamente tutti i linguaggi interpretati potrebbero essere considerati gestiti, poiché richiedono che l'interprete sia in esecuzione sotto le righe del codice "utente" in esecuzione. Inoltre, i linguaggi JVM e .NET (Java, Scala, C #, VB, F #, IronWhatever) sono compilati in un linguaggio intermedio o IL, che è superficialmente simile nella forma e nella funzione a un linguaggio assembly binario, ma non aderisce a 100 % a qualsiasi set di istruzioni "nativo". Queste istruzioni vengono eseguite dalla JVM o dal CLR di .NET, che le traduce in modo efficace in istruzioni binarie native specifiche dell'architettura della CPU e / o del sistema operativo della macchina.
Quindi, le lingue possono generalmente essere descritte come "compilate" o "interpretate" e come "non gestite" (o "native") e "gestite". Ci sono linguaggi che possono essere descritti come qualsiasi combinazione di questi eccetto il possibile "interpretato nativo" (che sarebbe vero solo per gli opcode esadecimali scritti a mano, dove ciò che è scritto dallo sviluppatore è ciò che viene eseguito); se consideri il livello di interpretazione come un "runtime" (che è facile da argomentare e difficile da argomentare contro), tutte le lingue interpretate sono "gestite".
Se vuoi diventare tecnico, quasi tutti i programmi rivolti a un sistema operativo multitasking sono oggi "gestiti"; il sistema operativo creerà una "macchina virtuale" per ogni programma in esecuzione, in cui il programma pensa (o almeno non deve sapere altrimenti) che è l'unica cosa in esecuzione. Il codice può effettuare chiamate all'interno di se stesso e ad altre librerie di riferimento come se quel programma fosse l'unica cosa caricata in memoria; allo stesso modo, le chiamate per allocare RAM e altra memoria più alta per archiviare e manipolare dati e dispositivi di controllo sono codificate come se l'intera architettura di memoria fosse disponibile. La VM (e il sistema operativo dietro di esso) traduce quindi vari puntatori di memoria nella posizione effettiva del programma, i suoi dati e gli hook sui driver di dispositivo, ecc. Questo è spesso fatto applicando un offset di memoria (ogni VM riceve un blocco di 2 GB o qualsiasi altra cosa della memoria, a partire dall'indirizzo X che il programma può trattare come se X fosse l'indirizzo 0) e come tale è molto economico da fare, ma ci sono altre cose che il kernel del sistema operativo è responsabile, come la pianificazione dei processi e l'inter- processo di comunicazione, che sono più difficili da gestire. Tuttavia, questo schema di base non è generalmente considerato "gestito", in quanto il programma non deve sapere che è gestito da una macchina virtuale e spesso è ancora responsabile di mantenere la sua memoria allocata "pulita". Un programma che è stato progettato per essere eseguito sulla riga di comando MS-DOS può essere eseguito su sistemi operativi Windows più recenti che non hanno più nemmeno l'ambiente MS-DOS al di sotto di essi; al programma viene invece assegnato un ambiente di "console virtuale" e, a condizione che non provi a lasciare questa "sandbox" cercando di accedere direttamente alle aree protette della memoria, funzionerà abbastanza felicemente.