¿Por qué se requieren CIL y CLR en .NET?

Vi esta bonita imagen aquí . Aprendí que todos los compiladores que admiten el lenguaje .net convierten el código fuente al CILformato. Ahora Microsoft nunca está incorporando .NETtodo el sistema operativo escribiendo un CLR para todos los sistemas operativos. Entonces, ¿por qué mantener un formato de código intermedio y un CLR para ejecutar ese CIL? ¿No es un dolor de cabeza con el que lidiar? ¿Por qué Microsoft eligió ser así?

EDITAR Este tipo de arquitectura tiene su precio. Reducirá el rendimiento, ¿no? Java hace esto para mantener la independencia de la plataforma, ¿por qué razón lo hace .NET? ¿Por qué no mantener un simple compilador de C simple? Cualquier forma también requerirá un compilador para convertir el código a CIL si necesito agregar un nuevo idioma, la única diferencia que haría es el idioma de destino. Tat es todo.

Porque solo necesitan escribir un compilador para C # a CIL, que es la parte difícil. Hacer un intérprete (o más a menudo, un compilador Just-In-Time) para el CIL por plataforma es relativamente fácil en comparación con escribir un compilador de C # a un código ejecutable (por plataforma).

Más allá de eso, el tiempo de ejecución puede manejar cualquier cosa que se compile a CIL. Si desea un nuevo lenguaje (como F #), solo tiene que escribir un compilador para él y automáticamente obtiene mágicamente todo el soporte de la plataforma para cosas que admite .NET.

Ah, y puedo tomar un .NET dll y ejecutarlo en Windows o en Linux a través de Mono sin recompilar (suponiendo que todas mis dependencias estén satisfechas).

En cuanto al rendimiento, es discutible. Hay "precompiladores" esencialmente que toman el CIL y hacen binarios nativos. Otros argumentan que los compiladores justo a tiempo pueden hacer optimizaciones que los compiladores estáticos simplemente no pueden hacer. En mi experiencia, depende mucho de lo que esté haciendo su aplicación y de la plataforma en la que la esté ejecutando (principalmente lo bueno que es el JITer en esa plataforma). Es extremadamente raro para mí encontrarme en un escenario donde .NET no sea lo suficientemente bueno .

.NET tiene un lenguaje intermedio (CIL / MSIL) e implementaciones específicas de la plataforma de un tiempo de ejecución independiente de la plataforma (CLR) por la misma razón que Java. Microsoft pretendía que C # compitiera directamente con Java, y lo hace, en los sistemas operativos a los que se dirige Microsoft (el suyo).

Las ventajas, aunque .NET solo es compatible con plataformas Windows (u otros sistemas operativos que tienen un funcionamiento similar a .NET como Mono / Linux), son similares a Java:

• Tiempo de ejecución de memoria administrada: a diferencia de C / C ++ no administrado, los desarrolladores de C # / VB.NET no tienen que preocuparse por controlar estrictamente la vida útil de los objetos. Al igual que Java, el CLR tiene un recolector de basura que libera automáticamente objetos en el montón que dejan alcance. Si bien esto puede parecer menor para alguien acostumbrado a tiempos de ejecución no administrados, tiene la ventaja secundaria extrema de desalentar la "magia negra" de la aritmética de puntero que es tan común en C / C ++.
• Independencia de plataforma: Windows Vista y Windows 7 funcionan de manera diferente a Windows XP. Windows 8 funciona de manera diferente. Las versiones de Windows Mobile, incluido Windows 8 Mobile, funcionan de manera diferente nuevamente. Hardware diferente, arquitectura diferente, capacidades diferentes. Si bien el entorno de destino sigue siendo importante para un desarrollador .NET, la cantidad de conocimiento especializado se reduce mucho en comparación con lo que se debe saber para construir un programa C / C ++ compatible para todos estos sistemas operativos. AC # dev obtiene mucho más de forma gratuita.
• Compatibilidad con aplicaciones web: todavía no he visto una aplicación web orientada al servidor orientada al cliente escrita desde cero en C ++. El servidor web , claro, Apache, ISS, generalmente se ejecutan contra un tiempo de ejecución no administrado por razones de velocidad / eficiencia. Sin embargo, C ++ no es un lenguaje utilizado para crear aplicaciones web. C # es (como es Java). Fue diseñado desde cero para admitir la próxima generación del paradigma ASP de Microsoft. Este es un código diseñado para ejecutarse en un sandbox; qué sandbox (el complemento ASP.NET para ISS o el CLR "de escritorio") es relativamente poco importante.
• Independencia de lenguaje / tiempo de ejecución: un compilador de C ++ toma el código fuente de C ++ y produce código de ensamblaje para una arquitectura de procesador utilizando un lenguaje de máquina. Para admitir una arquitectura diferente y / o lenguaje de máquina, se debe escribir un compilador completamente nuevo (y se debe compilar un conjunto completamente nuevo de bibliotecas de tiempo de ejecución). El compilador AC # toma el código fuente de C # y produce CIL, que el JITer específico del hardware se traduce en código de máquina. El mismo JITer puede traducir cualquier programa CIL sin importar el idioma de origen (y hay varios; C #, VB.NET, F # y una gran cantidad de puertos de idioma "Iron" como IronHaskell, IronRuby, IronLisp, etc.). El mismo compilador puede convertir un idioma en CIL que cualquier JITer puede ejecutar, sin importar el hardware.
• Concéntrese en el código "correcto": para los desarrolladores de C ++, hay muchas formas "correctas" de hacer algo, según lo más importante; eficiencia de memoria, eficiencia de CPU, independencia de hardware, independencia del sistema operativo, etc. El código puede verse drásticamente diferente cuando cada uno de estos es la prioridad. C # fue diseñado por un grupo que tomó en serio las lecciones conceptuales de Fowler y sus colegas (que estaban trabajando para reformar el diseño del código dentro de la comunidad C ++ al enseñar principios orientados a objetos a una comunidad que en gran medida pasó de C), como así como las lecciones prácticas aprendidas por los lenguajes anteriores (incluido Java, y su obediencia casi fanática al Objeto todopoderoso, cuando un buen puntero de función de estilo C ++ haría el trabajo de manera mucho más limpia y no sería menos objeto) orientado).

Por razones antimonopolio, MS tiene cuidado de no ser visto "interfiriendo" demasiado en otras plataformas importantes como Android, Mac OSX / iOS y Linux; sin embargo, sí tiene equipos en desarrollo para las tres plataformas. Hay una versión de Office para OSX desarrollada por MS, hay numerosas aplicaciones que incluyen aplicaciones de interoperabilidad de Office para iOS y Android, Skype (ahora un producto de Microsoft) se ejecuta en Linux e incluso se ha visto que Microsoft contribuye al kernel de Linux (principalmente en un mentalidad de virtualización).

El sistema operativo Windows está disponible para diferentes tipos de CPU, actualmente principalmente x64, x86, Intel, ARM.

CIL / CLR es independiente de esa plataforma de hardware: el entorno de ejecución de IL "abstrae" estas diferencias. Por ejemplo, un ensamblado .NET compilado para "cualquier CPU" generalmente puede ejecutarse en Win64 como un proceso de 64 bits, y Win32 como un proceso de 32 bits, sin la necesidad de proporcionar diferentes ejecutables.

Además, el CIL permite que los metadatos se almacenen en ensamblajes que no es posible fácilmente con archivos DLL nativos (es posible, por supuesto, MS hizo esto antes con componentes COM, pero esa tecnología nunca fue tan fácil de manejar como los componentes .NET). Eso hace que la creación de componentes de software sea mucho más simple y es la base de la reflexión / introspección en todos los lenguajes .NET.