|
C# |
|
Entrevistas y reportajes |
Anders
Hejlsberg habla para Algoritmo |
|
Junio/2001 |
|
|
Marino Posadas es MVP en .NET Framework, Microsoft Certified Solution Developer (MCSD), MCAD (Microsoft Certified Application Developer en .NET), MCT(Microsoft Certified Trainer) y autor de numerosos artículos para revistas especializadas, así como de varias obras editadas por Editorial Ra-Ma en solitario y junto a Grupo EIDOS. |
|
|
|
|
No obstante, concedió una única entrevista, según nos confirmaba posteriormente la oficina de prensa, y fue en exclusiva para nuestra revista. A continuación transcribimos su contenido (traducido al castellano): M. Posadas: Ante todo, gracias por la deferencia que ha tenido con Algoritmo concediéndonos esta exclusiva. Comenzamos si le parece por su proyección histórica en el mundo del desarrollo... A. Hejlsberg: Es un placer hablar con publicaciones on-line como la vuestra, y por supuesto, no hay problema en abordar mi periodo de trabajo anterior. M. Posadas: La primera vez que me topé con un compilador de Pascal orientado a objetos fue en la versión 5.5 del producto, hace años ya...Tu como autor, ¿podías prever que aquellos primeros pasos iban a desembocar en todo este mundo de .NET? A. Hejlsberg: Aquello fue realmente un intento muy primitivo de construcción de un auténtico sistema orientado a objetos. Hay una curiosa historia acerca de como sucedió todo eso: nosotros tuvimos noticia de que Microsoft iba a sacar una versión del compilador llamada Quick Pascal, que iba a incluir extensiones de orientación a objetos, y eso sucedió unos 6 meses antes de la aparición, así que, rápida, -muy rápidamente en realidad- empezamos a trabajar en la versión orientada a objetos, basada en la 5.0, y que se convertiría más tarde en la 5.5, y conseguimos hacerlo en 4 meses y sacar la versión antes de que Microsoft sacara su Quick Pascal. Más adelante, es cierto que esa versión fue de algún modo, el germen del modelo de orientación a objetos que apareció en las primeras versión de Delphi, en el sentido de que disponíamos de punteros, reference types...No sé si esto resulto evidente para más de un usuario común de ambos compiladores... M. Posadas: Y más tarde trabajaste en el equipo de desarrollo de Java, ya en Microsoft... A. Hejlsberg: Si, fíjate que 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 M. Posadas: Lo que se llamó las WFC (Windows Foundation Classes)... A. Hejlsberg: Exacto. Así que decidimos, aportar algún tipo de valor añadido: ya sabes, mejorar el rendimiento del Java estándar, añadirle un aspecto más similar al de otras aplicaciones, etc, en definitiva hacer lo más adecuado de cara a nuestros clientes, que dispusieran de los controles típicos de Windows, la posibilidad de importar DLL's, de forma que Java fuera una buena experiencia de programación, pero por supuesto, esto no le interesaba a Sun, y todos sabemos como fueron las cosas posteriormente. M. Posadas: La siguiente pregunta, no ha sido idea mía en realidad, sino de José Antonio Álvarez, de Microsoft Ibérica, que me comento: "Pregunta a Anders cuando hables con el si había necesidad de otro lenguaje"... A. Hejlsberg: Bueno, no es una pregunta fácil, y ya me lo han comentado alguna vez. La verdad es que esto tiene dos perspectivas: por un lado podría pensarse que no, pero, de cara al programador, creo que no existían muchos lenguajes de alta calidad y orientados a objetos que facilitasen la programación de toda la inmensa gama de posibilidades que hoy requieren las aplicaciones, y personalmente, pensé que Microsoft sí que necesitaba ese nuevo lenguaje que permitiese, por ejemplo, al desarrollador de C++, adaptar más su productividad a las necesidades actuales y potenciara su creatividad y posibilidades de expresión. sí creo que había que dar un paso hacia adelante, en el sentido de crear un lenguaje más moderno, que aprovechara toda la experiencia y conocimiento adquiridos hasta ahora y que estuviera adaptado de forma nativa para los nuevos requerimientos que las aplicaciones actuales y sobre todo, las venideras, necesitarán. M. Posadas: ¿Podría decirse que .NET ha sido idea tuya o de otros arquitectos en Microsoft? A. Hejlsberg: No, no. Ha sido un conjunto de sugerencias de gente muy diversa en Microsoft, de las que yo sólo he sido uno de los partícipes. He sido uno de los Arquitectos de .NET y he estado implicado como Diseñador Jefe en el desarrollo de C#, junto con otras personas. Pero, bajo ningún concepto quiero asumir el mérito exclusivo de este conjunto de ideas por que es un trabajo colectivo. M. Posadas: Según mis datos, ha habido más de 1000 personas trabajando en .NET... A. Hejlsberg: Cierto. En el departamento completo, pero ahí hay que tener en cuenta que hay mucha gente en producción de documentación, control de calidad, beta-testing, marketing, etc. Pero es una división muy extensa, es cierto. M. Posadas: Y por otro lado, se dijo que C# había sido fundamentalmente concebido por ti y otras 3 personas solamente, entre las que estaba Peter Kukol. Tengo noticias de esto por un famoso e-mail que salió a la luz pública a propósito del contencioso Sun-Microsoft, y que tu dirigías a Bill Gates, con copia a Steve Ballmer, y otros directivos de la empresa, en el que se incluían frases muy significativas, acerca de la concepción del lenguaje y sus principios inspiradores... A. Hejlsberg: ¡Ah sí! Ya se al e-mail que te refieres. Bueno, en realidad Peter Kukol estuvo implicado en los primeros estadios de diseño, aunque posteriormente mis colaboradores fueron otros. (...) M. Posadas: ¿Eric Gunnerson? Te comento este nombre por su famoso libro de C#. A. Hejlsberg: Bueno, no realmente en el desarrollo, sino mas bien, -al igual que Kukol- en los primeros estadios de diseño, aportando ideas, etc. Después se ha convertido en lo que ahora llamamos "evangelistas" del lenguaje...editando su libro, artículos, etc. En la parte de diseño, diría que Peter Goldie y otras dos personas fueron mis colaboradores más asiduos, y uno de ellos ya había estado conmigo en el diseño de Delphi. M. Posadas: En ese e-mail, comentabas que estabas buscando -cito de memoria- "un cuidadoso maridaje entre C/C++ y Java, que produjera un lenguaje "limpio", desprovisto de cierta parafernalia incómoda y de los inconvenientes establecidos por tendencias excesivamente puristas... A. Hejlsberg: Incluso yo diría que entre C simple y Java. Se trataba, como tu has dicho, de eliminar toda una serie de "inconvenientes" según lo veían nuestros programadores y clientes, y al mismo tiempo, queríamos una versión en la que la seguridad fuera un factor importante. Y tampoco podíamos olvidar al gran colectivo de programadores de los que recibíamos sugerencias en el sentido de que les gustaría algo que les permitiera reutilizar código que ya estuviera probado en otras aplicaciones. Personalmente, siempre he pensado que Java planteó una serie de características que no parecían muy realistas, y eso es lo que nos llevó a "extender" la versión de Java 1.1 con una serie de características nuevas. Pretendíamos facilitar algo la vida al programador, en lugar de adoptar una posición férrea en lo que "debe y no debe hacerse de acuerdo con mi dogma". 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 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#. M. Posadas: Recuerdo que cuando Delphi salió al mercado, una parte de la prensa americana lo definió como el "asesino de Visual Basic" (VB Killer). Parece lógico preguntarte, pues... si crees que C# va a ser el "asesino de Java"... A. Hejlsberg: Ya me acuerdo, si. Bueno, no sé, realmente no sé. El tiempo lo dirá. De lo que sí estoy seguro es de que hemos hecho un trabajo muy serio, bien diseñado, y que hemos puesto a disposición de nuestros clientes algo realmente novedoso. De verdad, pienso que poner a disposición de todos una plataforma que ha sido pensada -desde el principio- para el manejo de Web Services, en lugar de incorporarlo como un parche o un añadido, el hecho de que sea una plataforma multi-lenguaje, donde lenguajes veteranos como el Cobol tienen cabida, simplemente por que existen, y hay mucho código fuente escrito para ellos. M. Posadas: Cuando leí lo del soporte de Cobol, inmediatamente pensé en la gran cantidad de software escrito para muchas de las llamadas "grandes cuentas": la banca, compañías de seguros, petroleras...que todavía siguen funcionando con programas Cobol. A. Hejlsberg: Por supuesto, creo que no es lógico llegar a una compañía y ofrecerle una solución en la que "todo" tiene que hacerse desde cero. En la mayor parte de las compañías importantes, esa postura, sencillamente, no es realista. La mayoría se negarían en rotundo. De esta forma, puede seguir utilizándose el código actual, y si se compila, bajo la plataforma .NET, se convertirá en código IL (Intermediate Language) y podrá interactuar con cualquier otro componente hecho en cualquier otro lenguaje del entorno, incluidos aquellos más alejados en filosofía, como el propio Visual Basic ó C#. M. Posadas: Por ejemplo, podría construirse un "envoltorio" (wrapper) de una vieja aplicación Cobol, de forma que la Interfaz de usuario fuera algo más actual, aunque el motor de datos siga siendo el mismo. A. Hejlsberg: Exacto. Y si lo que tienes es código compilado, del que no dispones del código fuente, siempre puedes utilizarlo también a través de módulo de interoperabilidad, aunque en este caso, no tengas más que algunas de las ventajas de .NET. Pero siempre vas a disponer de un buen número de posibilidades de integración. Incluso de migración desde Java a través de nuestra herramienta JUMP (Java Upgrade Migration Path). Y lo mismo puedo decirte de los componentes. Somos conscientes de que existen miles de componentes ActiveX y CORBA funcionando por ahí y simplemente no podíamos hacer oídos sordos a esa realidad. M. Posadas: Todo esto parece llevarnos hacia un sistema operativo en el que .NET sea parte nativa. ¿Para cuando el sistema que incluya de esa manera la plataforma .NET? A. Hejlsberg: Respecto a eso, Windows .NET Server, llevará incorporado .NET como parte nativa de la solución. Sin embargo, Windows XP en edición de consumidores, no va a llevar .NET incluido, pero fundamentalmente, debido a cuestiones de logística, empaquetado, etc, ya que no coincidíamos en las fechas, y realmente se trata de departamentos distintos. Pero, por supuesto que todas las versiones siguientes van a incorporarlo como parte natural del sistema, y al final todas las versiones de Windows, llevaran incorporado .NET, independientemente de las versiones anteriores en las que pueda instalarse como un Service Pack; ten en cuenta que la parte necesaria para la compilación y ejecución son solamente 11 Mb. M. Posadas: Otro asunto que nos preocupa es el de la migración. Por mi experiencia docente y como consultor, he podido comprobar que -al menos en España- existen, literalmente, miles de aplicaciones escritas en lenguajes que no son en absoluto orientados a objetos, e incluso, si contienen características de orientación a objetos (como Visual Basic), no se utilizan para nada. De acuerdo con esto, ¿cuáles serían tus recomendaciones para la migración? A. Hejlsberg: Bueno, antes de nada, si estamos hablando de aplicaciones hechas -por ejemplo- en Visual Basic, nosotros vamos a continuar soportando dicho código, y como te decía antes el módulo de interoperabilidad va a ser importante a ese respecto, ya que se puede extender una aplicación mediante .NET tomando componentes hechos en otros lenguajes, incluyendo versiones anteriores de Visual Basic, de forma que mucho del código escrito, probablemente no tenga que ser migrado en absoluto. En cierto sentido eso me recuerda el mecanismo de funcionamiento de los Web Services. Una vez que están construidos, muchos programadores no tendrán ninguna necesidad de saber cómo han sido hechos. Sólo necesitan una descripción y con eso basta para utilizarlos. Visual Basic 6 podrá utilizar Web Services, si quiere, aunque no haya sido pensada para crearlos. De forma que creo que más bien se trata de que las nuevas aplicaciones, las que tengan necesidad de hacerse desde cero, sí puedan beneficiarse de todas estas características. Depende de lo que queramos hacer. Además, existe una buena herramienta de migración desde Visual Basic, de la que me asegura el equipo de desarrollo que es capaz de migrar el 95% del código fuente. Pero, independientemente de esto, será una cuestión de enfoque. M. Posadas: A propósito de los Web Services, ¿podría decirse de ellos que son la extensión natural del concepto de componente, de tal forma que en vez de situarlo en un servidor de dominio, lo situamos en la red, y utilizamos una serie de estándares para publicarlo y para describirlo? A. Hejlsberg: Desde luego, creo que has hecho una descripción bastante acertada de su arquitectura. Una de las cosas más interesantes acerca de los Web services, es que tienen la ventaja de que permiten hablar a las máquinas entre sí, ya que están basados en un lenguaje como XML que es -realmente- independiente de la plataforma. Eso permite la comunicación sin ambigüedad entre máquina y máquina, en lugar de tener que comunicarse entre humanos y máquinas. Y todos los estándares que permiten la comunicaciones de este tipo están construidos sobre XML. Realmente creo que la forma de abordarlo y la facilidad y flexibilidad de construcción constituyen una revolución. Los Schemas (el lenguaje de descripción de ficheros XML), el protocolo de comunicaciones SOAP, el lenguaje de descripción de Servicios Web (WSDL), todos ellos están construidos así, y por eso, creo que esa es la forma en que tendrán que hacerse las aplicaciones distribuidas en el futuro. M. Posadas: (Aprovecho tus comentarios para intentar que esto sea una conversación, más que un salto de un sitio a otro.) Comentas la importancia de los estándares, y lógicamente, se me viene a la cabeza la situación con ECMA, la entidad que se está encargando de la estandarización del CLI (Common Language Interface) y del lenguaje C#. ¿Cómo están las cosas a la fecha? A. Hejlsberg: Parece que los trabajos están bastante avanzados a ese respecto. Sabemos que el grupo de trabajo quiere sacar una primera Recommendation oficial para cuando tengan su próxima reunión general. De todas formas, nosotros vamos a sacar el producto de acuerdo con nuestras fechas estimadas de depuración y producción, independientemente de la salida de dicha recomendación. También asumimos que probablemente, eso nos obligará a asumir una serie de cambios en el producto (de mínima importancia, pensamos) de forma que tendremos que asumir dichos cambios para la siguiente versión 1.1 ó como se llame finalmente. Date cuenta, que las modificaciones a los estándares que proponemos nos están obligando a hacer una serie de cambios, a veces significativos, y que lleva mucho tiempo y esfuerzo estar participando en algo como la estandarización, e incluso esa es una de las razones por las que el producto final tarda en ver la luz, por que cada vez que un cambio estructural de ese tipo tiene lugar, tenemos que hacer cambios, que a veces suponen un montón de trabajo. Existe, al menos una persona del equipo de desarrollo de C# que se reúne semanalmente con el comité. Y todavía ha supuesto mucho más esfuerzo la estandarización del CLI. M. Posadas: Y respecto a las otras plataformas, has comentado en la rueda de prensa, que se ha construido una versión académica del CLI para Linux, que supongo que será la que Steve Ballmer anunció el pasado mes de Marzo. ¿Por qué sólo académica y no comercial? A. Hejlsberg: Bueno, no conozco exactamente las razones para esa diferencia. Imagino que nos interesaba algo que pudiera dar a conocer nuestro proyecto en instituciones académicas, de forma que los estudiantes y profesorado puedan saber cómo funciona, y las ventajas que tiene, sin tener que -de momento- soportar toda la maquinaria que supone la producción comercial en un estadio todavía de producción del CLI. Estoy hablando de soporte a clientes comerciales, etc. M. Posadas: Estamos hablando de un ambiente (el universitario) en el que tu eres consciente de que el nombre de Microsoft no está muy bien visto, y no vamos a entrar en las razones históricas de eso, pero ¿piensas que este tipo de iniciativas y el hecho del cómo ha sido diseñado .NET puede ayudar a cambiar esa situación? A. Hejlsberg: Totalmente. Además de que los ambientes académicos son muy proclives a la investigación en los lenguajes, y una de las razones que nos ha movido a esa promoción ha sido precisamente eso, que a veces nos comentan cosas desde ambientes universitarios, preguntándonos por qué no puedo hacer eso o lo otro trabajando con Java, cuando otros lenguajes sí que lo tienen, etc. Y además el .NET Framework, es una gran plataforma de investigación, llena de posibilidades. Naturalmente, cambiar esa forma de pensar va a llevar tiempo, pero por lo que sabemos hasta ahora, -y yo estoy personalmente implicado con todo esto-, cada vez que una institución académica analiza el entorno recibimos respuestas positivas, y mucho interés por continuar con los trabajos. Y no solo en EE.UU. sino también en todo el mundo. Hace poco he estado en una universidad suiza, donde van a comenzar a enseñarlo como parte del programa académico. M. Posadas: Otra de las cuestiones que se plantean a la hora de considerar el uso de C# es su rendimiento. Especialmente, ahora con la Beta 2, se habla de factores del orden de 10 a 30 veces más rápido que Java. ¿Hasta que punto es eso importante? A. Hejlsberg: Bueno, no sé mucho acerca de eso, por que se trata de hablar de números y de "benchmarks" y eso es relativo. Yo no creo que el punto principal a la hora de seleccionar una u otra herramienta de desarrollo sea una cierta diferencia en el tiempo de ejecución, aunque sí es cierto que en ocasiones puede ser importante. Pero lo que si es cierto es que hemos invertido mucho tiempo en la optimización del MSIL y del JIT, y hemos conseguido unas prestaciones mucho más serias que las de Java, principalmente, por que pienso que hemos conseguido un acceso muy bueno a los registros del procesador, un excelente recolector de basura (Garbage Collector), escalabilidad multiprocesador (y aprovechamiento automático de las capacidades de cada CPU), incluso disponemos de diferentes recolectores de basura dependiendo del entorno en que se estemos haciendo las pruebas. Por ejemplo, el motor para los procesadores IBM, realmente está dado unas prestaciones espectaculares, ya que internamente, se utilizan diferentes algoritmos de optimización, dependientes de la naturaleza del procesador, y esto se nota en el rendimiento. En ese sentido pienso que estamos una generación por delante en la forma de crear aplicaciones distribuidas. A ese respeto las diferencias con Java son normales, puesto que ese lenguaje no se pensó -originalmente- para soportar características del lado del servidor ("server side"), mientras que la forma en que C# se ha diseñado desde su origen sí que incluye todas esas (y otras) características. M. Posadas: Como la oficina de prensa nos ha limitado el tiempo, y no nos queda mucho ya, no me gustaría terminar sin hacerte un par de preguntas que podíamos situar en el plano de lo personal. Así que empiezo por una de las más evidentes: ¿Qué te hizo cambiar tu trabajo en Borland (Inprise) por Microsoft? A. Hejlsberg: Pues verás, hubo varias razones para eso. Por un lado yo había estado en Borland más de 13 años, lo que supone una auténtica "vida" en ésta industria, y, ya sabes, 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. M. Posadas: ¿Vives en Redmond? A. Hejlsberg: No, vivo en Seattle (Wa). En una casa a las afueras de la ciudad. Muy cerca de Redmond. M. Posadas: Y para concluir este apartado de tópicos, ¿tienes algún hobby aparte de la programación? A. Hejlsberg: Bueno, en eso siempre he pensado que mi hobby principal es lo que hago. Se podría decir que practico mi hobby para vivir... pero, bueno, aparte de eso, acabamos de tener un niño, y hago vida de familia siempre que puedo. También me gusta eventualmente jugar al squash, al golf, me gusta mucho viajar, en fin, intento ver a mi familia en Dinamarca siempre que puedo, y respecto a España no es la primera vez que vengo, ya que antes había estado varias veces en la Costa del Sol, ahora en Barcelona y realmente es un país que me encanta. M. Posadas: Pues se nos acabo el tiempo. Muchísimas gracias por recibirnos, y ha sido una charla muy instructiva. A. Hejlsberg: No hay de qué, por supuesto. Gracias a vosotros por visitarme, y hasta una próxima ocasión. Enlaces de interés: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetconvers.asp Otros enlaces: Sun vs. Microsoft. La batalla entre Java y C#. http://www.zdnetindia.com/news/breaknews/stories/3891.html Para los nostálgicos que quieran pueden pasarse por: |
El director de
desarrollo más reputado en la actualidad, Anders Hejlsberg, que
cuenta en su impresionante currículo con la autoría de herramientas de
desarrollo como Turbo Pascal, Delphi, MS
Visual J++, y más recientemente, el lenguaje C#, apareció en la primera keynote de
apertura del 