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

 

17 comentarios en “Anders, ¿por qué creaste los delegados?”

  1. Este razonamiento ya lo había leído en otros sitios. Pero yo creo que no te cuentan toda la verdad. El que los punteros son un foco de quebraderos de cabeza es algo que sabe cualquiera que haya trabajado un poco en C. Y está claro de las bondades de los delegados para código administrado. Pero la mayor parte de los sistemas operativos y aplicaciones importantes están desarrolladas en C ó C++.

    El punto de inflexión de todo esto fue el sp2 de Windows xp. Y se dieron cuenta que había punteros a funciones dentro de las aplicaciones de terceros que llegaban hasta anillos del núcleo más internos de lo que se pensaba. Para solucionar esto en aplicaciones escritas en C++, no hay punteros. Así que lo debieron solucionar de otro modo. Qué posiblemente fuera refactorizando el núcleo de Windows.

    También está el tema de los drivers. No hay ningún fabricante que se los tome todo lo en serio que se merecen. Y Microsoft saco un sistema de certificados para estos, aunque no ha sido todo lo eficaz que esperaba. Para Windows Vista y 7, han creado un anillo nuevo, en la que los drivers tienen que utilizar funciones de más alto nivel, las cuales se preocupan de que los parámetros que se le pasan sean correctos. Con el consecuente pérdida de rendimiento.

  2. Marino, ahora sí que me has dejado muerto del todo (no por ti, sino por Anders)… Desconocía la historia del por qué de la creación de los delegados… De hecho voy a escribir un post en mi blog sobre el tema y vuelvo aquí (espero que hoy mismo, si tengo tiempo).

    [Para adelantar acontecimientos, diremos que Anders tardó 6 meses cuando podría haber tardada… mmmmm… ¿10 minutos? A lo que intuyo Anders no tiene ni p*ta idea de C++…]

  3. Andrés, te garantizo (Paco Marín era testigo conmigo en la entrevista), que no lo he copiado de ningún sitio. De hecho había más razones, -y alguna de ellas más sofisticada- pero el núcleo y el verdadero motivo de esto fue como te digo. Y el motivo central era reducir las BSOD en aplicaciones (el sistema, claro, ya es otra historia).

    Y son palabras textuales de Hejlsberg. De hecho, todavía conservo una grabación de esa entrevista con él, que cambiaré de formato y probablemente colgaremos en la Web de dotNetMania.

    Saludos

  4. Rafael, el asunto es que Hejslberg se llevó a unos cuantos miembros de su equipo (Peter Golde, Scott Wiltamuth) junto a otros que “fichó” y que ya estaban en contacto con él, (a raiz de conversaciones de alto nivel sobre cómo debería ser un “Garbage Collector” óptimo) a Canadá y ahí es donde se concibió .NET como plataforma. No es que tardará 6 meses en dar con esto. Es que tenía que pensar en todas las posibles repercusiones de algo así, y una de las repercusiones (junto a sugerencias de su grupo de trabajo) le hizo que no olvidase los punteros (si el programador los quería), y de ahí los métodos “unsafe”, que personalmente me encantan, por que si tengo que implementar un algoritmo raro y doy con el en la red y está en C/C++ y el autor me merece confianza, puedo clavarlo y tener todas las ventajas del rendimiento.

    Saludos

  5. En cualquier caso, parece que la estrategia ha sido muy acertada, sin ella no hubiera sido posible Linq, EF, expresiones lambda, etc, tal y como los conocemos hoy en día.

  6. Me encanta lo que cuentas. No obstante, cuando comento el tema de los delegados con compañeros que trabajan en Java, me cuesta poder comentar sus ventajas frente al enfoque utilizado en Java, por ejemplo una inner class que implementa un determinada interfaz (los famosos listeners)… podría alguien darme luz y argumentos ?

    Un saludo.

  7. Me parece una solución genial, pero más allá de la implementación en sí, lo que me causa admiración es la capacidad de Anders para abstraer el problema y analizarlo con perspectiva (out-of-the-box thinking). No sólo eso, también es capaz de explicarlo de forma tan metódica y ordenada que hace que parezca fácil lo difícil, de modo que cualquiera pueda llegar a entenderlo.

    Esto me hace recordar una metáfora de Spolsky, que compara a los programadores con cantantes de ópera, y afirma que en el mundo de la programación como en el de la ópera hay gente buena y gente muy buena, pero sólo unos pocos elegidos son capaces de llegar a notas y escalas a los que la gran mayoría no podrían llegar jamás, por mucho que se esforzaran, ya que el talento natural es innato. Este es claramente el caso de Anders.

    @Andrés: Decir algo positivo acerca de Anders a estas alturas y que no suene repetido es algo complejo, más que nada porque mucha es la gente que le admira. No en vano, es uno de los ingenieros más influyentes dentro de la compañía y sus aportaciones no sólo se limitan a C# y .Net sino que muchos otros equipos acuden a él con prototipos, especificaciones y/o diseños en busca de “first-quality feedback” (awesome-quality, diría yo), especialmente en lo referente al diseño de lenguajes de programación, aunque no limitado exclusivamente a ello.

    Muy interesante el post, Marino.

    Saludos,
    M.

  8. Un post muy interesante!

    @Jordi
    Pues buena pregunta… Aquí tienes un artículo sobre el tema, aunque es de sun (y un poco antiguo)
    http://java.sun.com/docs/white/delegates.html
    Y como siempre una discusión sobre el tema en stackoverflow no podía faltar:
    http://stackoverflow.com/questions/1973579/why-doesnt-java-have-method-delegates

    @Marino
    Por otro lado, delegates aparecieron por primera vez (que yo recuerdo) en aquella aberración llamada Visual J++. Según se menciona en al artículo que enlazo antes, Sun estuvo evaluando algo parecido para Java pero lo descartaron después de consultarlo con Borland que tenía algo parecido para Delphi (donde si que estuvo el bueno de Anders).
    Aquí hay la definición de los delegados de Visual J++ y tampoco veo que se diferencien tanto de los de C#:
    http://msdn.microsoft.com/en-us/library/aa260511(VS.60).aspx
    Sabes si Anders participó en Visual J++ por casualidad?

    @Rafa
    Y tu post, donde está? Jjejeeeee… 🙂

    Un saludo a todos!!!

  9. @Eduard:

    Sí, Anders participó en Visual J++. Si mal no recuerdo (no porque lo viviera en su época porque me pilló con 13 años, sino porque lo he leído posteriormente), Anders llegó a Microsoft en 1996, y el concepto de delegate fue incorporado a VJ++ en 1998.

    En cuanto al “affair” en torno a los delegates en VJ++ y la respuesta de Sun en cuanto a su exclusión de Java, aquí están las dos versiones de la historia.

    a) Whitepaper de Sun, hablando sobre la “maldad” de los delegates de Microsoft: http://java.sun.com/docs/white/delegates.html

    b) Respuesta oficial de Microsoft (“The truth about delegates”): http://msdn.microsoft.com/en-us/vjsharp/bb188664.aspx

    Creo que la lectura de ambas versiones, y la perspectiva que nos dan los 12 años transcurridos desde entonces, dan para reflexionar bastante… : )

    Saludos,
    M.

  10. @A todos: gracias por vuestros comentarios y aportaciones. Como veo que existe cierto interés por la parte histórica y las circunstancias que concurrieron en la creación de todo esto, voy a añadir otro post explicando lo que me dijeron al respecto Anders, Don Box y algún otro (el correo de Hejlsberg a Gates no tiene desperdicio).

    @Eduard: Efectivamente, en la entrevista, me dijo que -inicialmente- entro con la idea de crear una nueva plataforma de aplicaciones (.NET Framework) y para ese proyecto fallido (en su aceptación popular) que fue VJ++.

    Saludos

  11. @todos: Realmente me alegro de la acogida que ha tenido esto. Son temas que yo pienso que complementan lo que ya es sabido. Lo manido. Y -por lo menos a mí- me han ayudado a entender los auténticos porqués de algunas cosas. Os puedo garantizar que Anders, lo decía muy en serio (por momentos se le veía concentrado y hasta preocupado, como si se estuviera acordando de las discusiones que -sin duda- tuvo con otros hasta decidirse por esa solución).

  12. Echt informatieve blog post hier mijn vriend. Ik wilde alleen maar commentaar geven en bij te houden van de kwaliteit van het werk zeggen. Ik heb bookmarked uw blog zo nu en ik kom terug om in de toekomst meer mijn vriend te lezen! Ook goed gekozen kleuren op het thema het goed gaat met de blog in mijn bescheiden mening:)

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *