La historia de la creación de .NET

A propósito de mi “post” anterior sobre los delegados, varias personas han comentado su interés por saber algo más de la historia de la creación de .NET, y algunas de las curiosas circunstancias que se dieron, así que aquí va lo que yo sé por entrevistas con el propio Hejslberg, Don Box, y algunos otros. Hejlsberg es un tipo totalmente vocacional, y en otra entrevista decía “I got into programming not because I wanted to make a lot of money, or because someone told me to. I got into it because I just got totally absorbed by it. You just could not stop me“. De hecho, a la pregunta de porqué se había ido de Borland, respondió: “pensé que era el momento para mí de buscar nuevos retos. El tiempo que pasé en Borland fue excelente, pero por otro lado el tener la oportunidad de trabajar con algunos de los más brillantes diseñadores de la industria informática de hoy, me resultaba muy atractivo“.

(Hejlsberg en Tech-Ed 2007)

Hejlsberg entró en MS en 1996 con una oferta irresistible. Él mantenía correspondencia desde su época de arquitecto en Borland con algunos líderes tecnológicos de diversas compañías, entre los que estaban Brian Harry (MS), personal de IBM, de universidades, etc. Y uno de los motivos de esas discusiones trataba de cómo debería de ser un Garbage Collector (las discusiones sobre este tema son abundantes en la red), y sobre cómo se podría hacer una nueva plataforma de ejecución que mejorase las prestaciones de J2EE (más de 10 años después de la creación de éste). Gates quería conseguir una plataforma similar pero mejorada, que aprendiese de los fallos y mejorase y actualizase sus posibilidades. Y Hejlsberg era el candidato idóneo.

En 1996 (los datos económicos no vienen de su parte sino por otra via) MS le ofreció $1,5 millones + stock options por liderar el proyecto. Borland respondió con una contraoferta y entonces MS dobló su oferta, que -además- incluía carta blanca para fichajes de su propio equipo. Fin del debate.

El propio Hejslberg me decía lo siguiente respecto a sus propósitos iniciales: “yo me incorporé a Microsoft en Noviembre de 1996, y mi primer trabajo fue asumir la construcción (como Arquitecto principal) de Visual J++. El proceso de construcción ya había comenzado y yo de hecho me incorporé a lo que después fue la versión 1.1 del producto y  no era la forma idónea de abordar una implementación así, por que había que integrar como fuera Visual J++ dentro de Visual Studio, y tampoco podía decirse que estuviéramos usando el modelo de objetos idóneo en ese momento. Era como tomar la idea de C++ y poner Java 1.1 en su lugar, no tenía el “feeling” real de Java“.

Lo cierto fue que -en un momento dado- y debido al contencioso que mantenían MS y Sun se “despistó” un correo de Hejlsberg a Gates, con copia a los principales líderes técnicos vinculados al proyecto (Peter Kukol, Nathan Myhrvold, el fundador de MS Research, etc), donde contaba lo siguiente: “Ya tenemos planeada la arquitectura de la nueva plataforma y las líneas generales de cómo vamos a implementarla. También está muy avanzado el trabajo con el nuevo lenguaje. A falta de un nombre mejor, vamos a llamarlo J++”. Este lenguaje, finalmente, fue C#, por que a alguien se le ocurrió que # era en realidad como 4 signos +, y Anders afirmaba que se había inspirado en muchos otros lenguajes antiguos, no solo en C++ y Java, sino en Haskell, ML y varios más.

Respecto a C#, Anders añadía: “En C#, sin embargo, hemos podido abordar el problema completamente desde cero. Hemos considerado todas estas cosas, y hemos eliminado aspectos engorrosos, como la gestión de memoria, el manejo de punteros, y hemos hecho hincapié de forma muy especial en la seguridad de tipos y la conversión, etc, para permitir una mayor flexibilidad sin que eso suponga una pérdida de las posibilidades. Se puede seguir utilizando las características “antiguas”, como código no seguro, mediante una declaración explícita, o puede usarse código totalmente seguro. Esta es una de las características de flexibilidad más importantes dentro de C#”.

Otros dos pilares fundamentales a tener presentes en la construcción de la plataforma eran los servicios Web y XML como sintaxis (XML no es y nunca será un lenguaje en sí, sino una sintaxis, una forma de escribir datos con su descripción y su arquitectura. De ahí que de origen a distintas “gramáticas” que describen actividades diversas: MathML, CML VRML…), y MS ya se había anticipado y participó de forma activa en la construcción del estandar (ver documento oficial del estándar en W3C, donde aparece entre los firmantes de la especificación, Jean Paoli de MS, junto a personas de Sun, Netscape y el mundo académico.

Paralelamente, Don Box, que también colaboraba con W3C, pero en la creación del estándar SOAP, se incorporaría a MS junto a Peter Drayton, y varios más en lo que ya era una carrera imparable y bien definida en la construcción de esta plataforma…

Stan Lippmann

Entre ellos, a muchos les sorprendió encontrar a Stan Lippmann, que se convertiría en Arquitecto de Visual C++ .NET , principalmente centrado en las Extensiones Administradas del lenguaje. Durante más de una década estuvo en los Bell Laboratories donde trabajó junto a Bjarne Stroustrup (alma mater de C++) en las primeras versiones de cFront , la implementación de C++ de Bjarne.

El resto es más conocido. Cuando recupere algún dato más, lo comentaré por aquí, como lectura veraniega intrascendente…)

Saludos

 

Anders, ¿por qué creaste los delegados?

Eso le pregunté a Anders Hejlsberg, el arquitecto principal de .NET y “alma mater” del lenguaje C#, la primera vez que lo entreviste, hace ya 10 años. La respuesta me dejo helado, por que no me esperaba algo así, y dió lugar a muchos paréntesis en mis clases donde explicaba esto con más detalle. Hoy lo quiero compartir aquí, ya que se sale de la mera teoría. Su respuesta: “No me quedó más remedio…” (¿?)

Ante mi sorpresa, Hejlsberg profundizó en el tema comentándome que, cuando Gates le hizo la correspondiente oferta (IRresistible, por que implementaba la interfaz “no puedo decir que no”), una de las cosas que antepuso fue terminar con las infames BSOD’s.(pantallas azules, ya sabéis). Así que, como es un científico, abordó el problema de forma científica, y comenzo por hacer una análisis estadístico de cuáles eran sus causas. Resultó que el 90% eran debidas a drivers, y ahí solo podían ponerse serios con los fabricantes y poco más. PERO, el 10% restante, que era por causa propia, obedecía ¡en su 99%! a solo dos razones: Punteros a función perdidos y problemas “Casting” (conversión de tipos). La gaussinana resultante tenía un aspecto similar a este: (Y me hizo un dibujo parecido al que adjunto aquí):

 

1º Objetivo cumplido: focalizar el problema y reducirlo al máximo.

Ahora venía el segundo: dar con una solución -única a ser posible- que resolviese ambos. Y aquí es donde entra la auténtica genialidad de este danés. Vuelve a pensar en los orígenes de los dos problemas y se da cuenta de que en los dos casos se relacionan con la llamadas a métodos. Le da una vuelta de tuerca más y vuelve a replantearse las bases de la Teroría General de la Información, para identificar al problema concreto dentro del modelo teórico: (primera página de  cualquier libro sobre el tema): Emisor – Receptor – Canal e Información transmitida. Pero…¡eso es el sistema de eventos!  Emisor -> La clase que llama usando un método. Receptor -> Otra (o la misma clase) que recibe (en otro método). CANAL (el vacío del entorno de ejecución – que el sustituirá por un entorno ADMINISTRADO) e Información transmitida (los valores que pasamos al receptor).

2º Problema resuelto: el modelo sobre el que se actuará queda indentificado de inicio como parte del modelo general de la TGI. Y sus partes, también: el CANAL y la recepción de los tipos esperados.

¿Qué faltaba? Lo que siempre se ha hecho en Informática para resolver problemas propios de las llamadas directas: poner un intermediario. UN DELEGADO. Las llamadas ya no se harán nunca de forma directa, sino a través del delegado, que -al estar administrado por el CLR- no intentará llamar a algo que no está disponible. Problema del puntero a función resuelto por la vía del canal (y por la eliminación de los punteros, claro).

La solución a la segunda causa, decía Hejlsberg, “me pareció trivial, una vez resulto lo anterior”. Basta con que el delegado que hace las llamadas TENGA LA MISMA SIGNATURA (recordemos, mismos tipos de parámetros y mismo valor de retorno), que el receptor, y, ¡adiós a los problemas de “casting”!, y, por ende, adiós a los problemas de las BSOD por esas causas.

Hejlsberg se fue a Canada durante 6 meses a pensar sobre el asunto, pero una vez planteado al problema, afirmaba que lo resolvió en un fin de semana (al menos en teoría). Su gran apoyo: el trabajo serio, con método y los conocimientos profundos de los fundamentos. Hasta hoy no he visto nada que contradiga esos principios.

Saludos y buen verano.

PD: Se admiten comentarios, apostillas y todo tipo de opiniones. El tema creo que lo merece.

Marino