La mia comprensione è che la parte della JVM era che il codice poteva "funzionare ovunque", ma il codice CLR era progettato per funzionare solo su Windows: quindi perché avere una macchina virtuale?
So che il runtime CLR si occupa della garbage collection, ma ci sono linguaggi raccolti da garbage che ancora vengono compilati al codice nativo.
L'unica cosa che posso pensare è che Microsoft potrebbe aver voluto fare leva per mantenere basso il prezzo dei chip Intel.
My understanding is that part of the point of the JVM was that the code could "run anywhere", but CLR code was designed to run only on Windows
"Windows" non è un sinonimo di "x86" - anche alla fine degli anni '90 Windows funzionava su DEC Alpha, MIPS, x86 e persino su PowerPC e nei primi anni 2000 quando .NET 1.1 era rilasciato Windows supportava anche IA-64 (Itanium) e AMD64 erano all'orizzonte, mentre Windows CE (il sistema operativo della smart-device allora dominante) funzionava su x86, ARM, SH-3 e MIPS. Il caso di un runtime multipiattaforma compilato in JIT in esclusiva per Windows era (e rimane) ancora abbastanza convincente.
Certo, possiamo solo speculare sul ragionamento dietro lo sviluppo CLR, ma molte ragioni forti possono essere dedotte dalla storia:
Java è stata la prima macchina virtuale multipiattaforma (e la libreria, completa di GUI e pacchetti web-server) a decollare, ma Microsoft non ha controllato e i loro tentativi di estendere la piattaforma a loro vantaggio non hanno funzionato ( vedi "J ++") - se Microsoft non riuscisse a catturare la nuova generazione di programmatori Java (che vedevano VB al di sotto di loro, e che non volevano pasticciare con C / C ++), avrebbero perso il controllo del software desktop ecosistema: perché comprare Windows se il software desktop funziona bene su Mac, Solaris, ecc?
Sul lato server, ASP 3.0 "classico" è stato messo in secondo piano da PHP e JSP - Microsoft avrebbe potuto dedicare del tempo a migliorare l'ASP separatamente, ma ha deciso di rendere ASP.NET (quindi chiamato "ASP +") una parte integrante anche su .NET Framework: questo è stato un vantaggio per gli sviluppatori perché ha permesso il riutilizzo del codice a livello di oggetto, cosa che prima era impossibile (ad esempio, usare le classi C ++ in VB) o molto difficile (usando COM / DCOM).
Quindi CLR offre 3 vantaggi principali rispetto allo status quo contemporaneo:
E una serie di vantaggi proprietari per Microsoft:
È un modo per progettare compilatori moderni, ovvero avere un front-end separato dal backend .
Il compilatore front-end traduce la lingua in una lingua intermedia che il back-end può selezionare e compilare in modo nativo.
Questo rende il compilatore modulare dove è più facile passare da implementazioni back-end. Ad esempio, in Java esistono troppe JVM e il motivo per cui esistono è dovuto al fatto che javac non ne sa nulla, produce solo codice byte che la macchina virtuale può elaborare.
In .Net per esempio, C # e VB.Net producono IL che il CLR può compilare ed eseguire. Ciò significa che Microsoft ha creato una VM per qualsiasi lingua che produce IL.
Ritorno a Java, ci sono troppe lingue JVM. Perché pensi che sia il caso? Poiché il progettista di linguaggi non ha bisogno di preoccuparsi di scrivere una VM che è molto difficile, può progettare la propria lingua, compilare in IL e farla girare su qualsiasi VM.
Avere la VM o il back-end è un modulo completamente separato è così vantaggioso, è possibile avere team che lavorano sul backend facendo ottimizzazioni di codice, JIT, GC, ecc. e altri che lavorano sulla progettazione della lingua.
Tuttavia, penso che GC sia un'eccezione qui, dove penso che la lingua dovrebbe sapere se un GC esiste o meno (non sono a conoscenza di un linguaggio che ti permette di disattivare il GC), ma questa è l'unica cosa il linguaggio deve saperlo, ad esempio in Java è possibile passare dall'implementazione GC con pochi argomenti del programma. Non è fantastico?
......
Leggi altre domande sui tag virtual-machine clr