lunes, marzo 13, 2006

Horizontes

¿Qué razones hay para migrar a .NET? A primera vista, es difícil encontrarlas. Borland, por ejemplo, justificó algunas de sus decisiones estratégicas respecto a Delphi.NET mediante un símil equivocado: comparó la transición a .NET con la que tuvo lugar hace tiempo desde DOS hacia Windows. ¿Por qué convenía al programador realizar esa transición? En mi caso, el motivo fue disponer de toda la memoria física que admitían los procesadores de 32 bits (¿quién se acuerda de la barrera de los 640KB?). Claro, por entonces trabajaba con algoritmos geómetricos que consumían mucha memoria... Para otros, el motivo fue la nueva interfaz gráfica, o la novedad de poder "dibujar" sobre la impresora, gracias al GDI, de la misma forma en que se dibujaba sobre pantalla. Especialmente con la llegada de Windows 95, el programador que daba el salto recibía como recompensa una interfaz gráfica que por entonces parecía muy difícil de programar. No es que el cliente final del programador exigiese tal interfaz: es que al usar esa interfaz, la aplicación ganaba en valor subjetivo. Y por supuesto: en determinados tipos de aplicaciones, una interfaz gráfica era lo apropiado.

¿Ocurre algo similar con la migración a .NET? Aparentemente no... pero hay varias sorpresas. Veamos primero lo de la memoria. ¿Cuál compilador de 64 bits está usted utilizando ahora mismo? En mi caso, uso Visual Studio.NET. Las alternativas son Java (y ya conoce una parte de lo que opino sobre Java), y algún otro compilador nativo, probablemente caro y bastante limitado en herramientas de soporte para el desarrollo. Es verdad que una aplicación típica de gestión no necesita el espacio de memoria que ofrecen los 64 bits, pero no todo el monte es orégano. Se avecina otro cambio importante: la aparición de Windows Vista, con Avalon sustituyendo a la obsoleta GDI. No se trata de un retoque en el estilo visual: Avalon significa gráficos acelerados por hardware, gráficos 3D sin excesivo esfuerzo, controles mucho más potentes, soporte para vídeo y audio, incluyendo reconocimiento y síntesis de voz...

Pero hay más ventajas y posibilidades en .NET, y no hay que esperar al futuro para sacarles partido. Y lo mejor de todo es que cualquier aplicación de gestión puede aprovecharlas. No obstante, se lo voy a explicar haciendo referencia a XSight Ray Tracer. La clave está en la extensibilidad. De entrada, XSight RT es fácilmente extensible. No existe una primitiva para crear pirámides en este momento. Para añadir pirámides, tanto al motor como al lenguaje, basta con declarar una clase que implemente la interfaz IShape. Pero eso lo permite cualquier lenguaje orientado a objetos, ¿no? La diferencia se nota cuando hay que "registrar" la clase para que el núcleo de la aplicación la encuentre. En .NET, el núcleo utiliza reflexión para que sólo sea necesaria una instrucción. En Windows nativo, necesitaríamos definir un mecanismo de registro partiendo de cero... e incluso si todo saliese bien a la primera, habría que tener mucho cuidado con los problemas asociados a las DLLs.

Una aplicación como XSight RT, necesita matemáticas a toneladas. Por ejemplo, la apariencia del mármol en la segunda imagen se logra combinando un patrón regular con una función de ruido espacial. Extender esta funcionalidad siempre ha sido complicado. POVRay, por ejemplo, implementa un sencillo intérprete de funciones y proporciona un conjunto básico de funciones matemáticas primitivas. ¡Pero se trata de un intérprete común y corriente, una simple máquina de pila interpretada! XSight puede hacerlo mejor: basta extender el lenguaje de escenas con funciones matemáticas, que pueden compilarse sobre la marcha a código IL... ¡y este código IL se convierte en código nativo para ser ejecutado! No hace falta que el código generado pase por el disco duro: en .NET v2.0 existe un nuevo API simplificado que permite generar código sobre la marcha para métodos, sin tener que declarar antes toda una clase.

¿Y qué hay con las aplicaciones de gestión? Classique, para Windows nativo, permite definir fórmulas para calcular los gastos de envío. En la última versión (en algún momento lo pasaré a .NET), para evitar complicaciones, la fórmula se "compilaba" a Transact SQL, para que fuese ejecutado remotamente por el servidor, a petición del cliente. ¿Y qué hay de los motores de scripts? Bien, es cierto que se podía usar el motor de JScript en Windows nativo, igual que ahora se puede usar Visual Studio for Applications, para incorporar un motor de JScript, o incluso de C#, dentro de cualquier aplicación. ¿La diferencia? En Windows nativo, el motor de scripts estaba basado en un intérprete, pero en cualquier caso, los modelos de objetos del host y del motor de scripts eran muy diferentes, y se complicaba la comunicación entre ambas partes. En .NET, en cambio, las dos partes implicadas coexisten dentro del CLR. Eso significa, en primer lugar, que el código script no se interpreta, sino que también se ejecuta como código nativo. Además, al usar el mismo modelo de objetos del anfitrión, aparecen muchas opciones de comunicación interesantes. Por ejemplo, se puede declarar en JScript.NET una clase que use como ancestro una clase declarada en C#.

Y estoy sólo arañando la superficie...

12 Comments:

Blogger Dani Coll said...

Hola Ian,

No pierdes una para cargar contra los de Scott Valley eh ? :-)

Hombre, yo creo que las que dices sí són razones interesantes para cambiar a .Net, pero opino que la principal (y que obligó a Borland al cambio) es que quien construye el SO es también quien decide la librería de clases y toda la framework que se construye encima. Las demás razones : Soporte multilenguaje, entorno de ejecución más seguro, programación para múltiples dispositivos, control de versiones de funciones externas,... son también de peso, aunque no tan definitivas.

Para desgracia de Borland (o DevCo), mientras el SO sea Windows, habrà que asumir los cambios de arquitectura que vengan de Redmond y - para mi aquí está el quid de la cuestión -implementar un lenguaje capaz de sacar lo màximo a la librería de clases, complementándolo con las mejores herramientas de desarrollo. Si lo consigue, Delphi vivirà muchos años (aunque sin su VCL nativa). Si no, para que utilizar un lenguaje o productos de terceros cuando puedes utilizar un producto como C# pensado especialmente para .Net ?

Saludos.

lunes, marzo 13, 2006 2:30:00 p. m.  
Blogger Ian Marteens said...

:) Hola, Dani:

Lo del SO es interesante, porque durante la mayor parte del tiempo, Microsoft manejó un API patatero para Windows... dejando espacio para Borland. Lo raro, por lo difícil que es ver ese tipo de cambios, es que Microsoft invirtió la tendencia. Versión "populachera" de la Segunda Ley de la Termodinámica: las cosas (en un sistema cerrado) siempre se complican. Y sin embargo, en este momento se han simplificado.

El otro problema: ¿puede Linux sustituir por completo a Windows? Paso de meterme en el lado cliente, porque además, es el que menos conozco de Linux. Mi opinión: si es para manejar protocolos TCP/IP "de toda la vida", sí. Pero para aplicaciones GRANDES (de verdad) creo que no. Esa es la parte de la historia que casi nadie conoce. No lo voy a explicar ahora (por espacio, y para demostrarlo, también). Por ejemplo, pregúntale a alguien: ¿quién copió a quién: J2EE, o MTS/COM+? Y la siguiente pregunta: ¿tiene alguna importancia la funcionalidad de J2EE/MTS/COM+? Lo mismo me equivoco (para eso están los comentarios), pero creo que no todo el munto sabe de qué va el asunto... y no es extraño, porque se trata de una especialidad muy concreta dentro de la programación (aunque muy importante).

Por cierto, ¿qué te parece Chrome?

lunes, marzo 13, 2006 3:45:00 p. m.  
Blogger Dani Coll said...

Sobre Chrome sólo puedo dar una opinión superficial ya que no lo he utilizado. Sólo he leído algún artículo y algunos ejemplos del lenguaje.

Semánticamente parece interesante y construido por gente que realmente le han dado vueltas a como expresar de una manera más sencilla el código (propiedades implícitas, Case .. type of, threads..). En ese sentido es un avance.

La gente de Chrome ha escogido dedicar todos sus esfuerzos a la construcción de un lenguaje, renunciando a implementar su propio IDE y herramientas de desarrollo.

No estoy seguro que esta sea una solución de futuro. Para mi, para el desarrollo de software es casi tan importante el lenguaje como sus herramientas. La programación cada vez se acerca más a los paradigmas MDA y en estos las herramientas de diseño son casi tan importantes como el lenguaje en sí.

Chrome representa una solución intermedia, de compromiso, para la comunidad Delphi. No perdemos nuestro apreciado Object-Pascal (que además nos lo ofrecen "tuneado") y aprovechamos un IDE ya construido y rápido.

No es la solución más valiente pero quizá es la solución más inteligente teniendo en cuenta los cambios que se avecinan con Vista/Avalon y demás. Construir IDEs propios puede ser meterse en un lío y no conseguir ni mejorar VS ni ser un negocio rendible (Sin hablar que me parece que incluso SQL Server 2005 precisarà VS2005 para gestionarlo).

Esto va exactamente en la dirección que la estrategia comercial de Microsoft desea: "Si usted quiere, programe en el lenguaje X, pero siempre utilizando nuestro IDE y nuestras herramientas". Y es que Microsoft está trabajando y moviendo sus fichas de manera magistral : por primera vez a la siempre sabida buena estrategia comercial se une la calidad en sus decisiones y productos técnicos (Anders eres un demonio !)

Por mi parte, yo no me veo programando en Chrome. Voy a esperar a ver como acaba el "culebrón" Delphi y si DevCo da la campanada perfecto (no lo creo), y si no C# es un buen lenguaje. De Anders Sí me fio : es caballo ganador.

Saludos

lunes, marzo 13, 2006 10:58:00 p. m.  
Anonymous Marto said...

Hola Ian, ¿te acuerdas de mi? ;)
Veo los argumentos de Dani más convincentes que los tuyos, pero reconozco que eso es una cuestión 100% discutible. Lo que me sorprende es que sueltes algo como "Pero para aplicaciones GRANDES (de verdad) creo que no" refiendote a Linux respecto a Windows... después dices que no lo vas a explicar por espacio, pero creo que una afirmación como esa merece una explicación, no te parece?
Supongo que primero deberíamos definir qué es grande, pero existen casos de éxito documentados de aplicaciones nada menospreciables montadas en entornos libres.
Otra cosa es discutir si el desarrllo es más rentable en una plataforma o en otra, pero de ahí a defender que una de ellas no es válida me parece temerario.

lunes, marzo 13, 2006 11:47:00 p. m.  
Blogger Ian Marteens said...

Hola, Marto:

Me refiero a aplicaciones que tengan una carga de 700 a 800 usuarios conectados bajándose datos y actualizándolos en todo momento... de ahí para arriba. Para eso hacen falta los llamados servicios corporativos... que vienen de serie en cualquier Windows, y que sin embargo, hay que pagarlos muy caros en otras plataformas... para después descubrir que no son tan buenos y extensibles. Evidentemente, explicar qué son los Enterprise Services en un comentario no es para hacerlo un día sí y otro también.

Sobre rentabilidad: no se trata sólo del dinero invertido, sino también de las horas de trabajo para echarlo a andar. Por supuesto que todo puede implementarse en ensamblador, y sin hacer una sola llamada al sistema operativo. Pero la empresa que lo haga así, seguro que va a la quiebra. ¿Para qué usar Delphi si todo lo puedo hacer con Fortran?

Ah :) y temerario por parte mía sería hablar de estas cosas "teóricamente", por lo leído en libros, sin haberlas puesto en práctica y comprobado las alternativas. Lamento que mi abuelita no esté por aquí cerca para echarme una mano, y sea yo mismo quien tenga que decir que el mío no es el caso. Hace unos nueve meses comprobé que una aplicación mía de este tipo hecha en tres meses para una compañía que luego absorbió el Citibank, seguía funcionando perfectamente en el Citigroup, en la división de créditos para el consumo. Año 1999: Delphi 5 y SQL Server. Algo sabré del tema, digo yo...

martes, marzo 14, 2006 4:12:00 a. m.  
Blogger Dani Coll said...

Desde mi ignorancia (no he programado nada o casi nada en Linux), me da la impresión que las opiniones de Ian se refieren sobretodo a la "facilidad" o "productividad" que puede ofrecer Linux respecto Windows, más que a su capacidad técnica como SO para implementar cualquier solución.

Linux es libre. Sí. Pero ser libre tiene sus ventajas y también sus inconvenientes. Si eres libre, puedes adoptar los diferentes standares y con ello ser muy portable y flexible. Puedes desarrollar en multitud de plataformas y lenguajes y aprovechar las diferentes sinergías que se producen.

Pero, el principal inconveniente de ser "tan libre" es que las herramientas de desarrollo también lo són en todos los sentidos: hay muchas, algunas demasiado especializadas, algunas provienen de organizaciones libres, otras son propietarias,... y todo esto obliga a mantener capas y capas de software para hacer que los productos sean eso : libres.

Abusar de las capas de abstracción siempre ha sido un problema en la ingeniería del software. Si hay demasiadas, el rendimiento cae en picado.

Creo que este es el sentido de la opinión de Ian (va por ahí ?)

Saludos.

martes, marzo 14, 2006 8:30:00 a. m.  
Blogger Ian Marteens said...

:) Uff, pues lo voy a tener que explicar entonces, pero mejor en un post normal, porque es un poco largo. Enterprise Services, o servicios corporativos, es un API muy concreto: ofrece object/resource pooling, transacciones declarativas, just-in-time activation, más control sobre el modelo de concurrencia y activación... El equivalente de esto no existe directamente en Linux, simplemente porque Linux no tiene de momento nada parecido a COM. Si montas un J2EE, no tienes la misma flexibilidad que en Windows... porque de entrada, con Delphi no puedes tocar los objetos creados con Java: es tan simple como esto, y la gente suele pasarlo por alto. Pero incluso con J2EE, la funcionalidad ofrecida que debe asemejarse a esto de los Enterprise Services de Windows es menos buena (la culpa es de Sun, en este caso). En realidad, J2EE es una típica respuesta tardía de Sun a la creación de MTS allá por la época de Windows NT 4.

Además, COM+ va a ir sustituyéndose gradualmente por Indigo (o Windows Communications Foundation, en la neojerga).

Abusar de las capas de abstracción siempre ha...

Hay mucho de cierto en esto, e incluso lo puedo redactar de forma bastante chocante: la P.O.O., aplicada a la comunicación remota, es un fracaso. Lo pongo así para que llame la atención. Si alguien no lo ve claro, que me lo diga... :)

(esto de escribir POO para Programación Orientada a Objetos me hace sentir incómodo. En inglés, "poo" es "caca").

martes, marzo 14, 2006 12:10:00 p. m.  
Blogger Ian Marteens said...

... y por cierto, si Mono triunfa, que no tengo ningún motivo para creer lo contrario, entonces ya Linux contaría con el sistema de objetos compartibles en tiempo de ejecución que tanto necesita. En la época del auge de Delphi, cuando la gente que no se metía alegaba que no se fiaban de la estabilidad de Borland (era el argumento que más se oía el siglo pasado), les decía que, si Delphi se la pegaba, el sucesor tendría que haber asimilado las enseñanzas de Delphi. Eso es lo que ha sucedido con .NET. Con los sistemas operativos se puede decir algo parecido: si en un momento dado Windows se la pega, será por la aparición una alternativa que ya tenga todas las ventajas que ofrece Windows. Y una de esas ventajas, quizás la fundamental, es que desde una aplicación escrita en Delphi podíamos acceder a clases programadas en C, C++, Visual Basic e incluso JavaScript.

Es una ventaja tan evidente, y a la vez tan trasparente y común que ni siquiera nos damos cuenta cuando la usamos. Es como el aire. Está ahí y no lo notas, excepto cuando el viento sopla muy fuerte. Eso sí, vete a la Luna sin escafandra y luego cuéntame qué tal...

martes, marzo 14, 2006 12:18:00 p. m.  
Blogger Dani Coll said...

Ian,

Estoy de acuerdo en tu último comentario pràcticamente en todo.

Sólo decir que como "sistema de objectos compartibles en tiempo de ejecución" en Linux sí hay alternativa si consideras CORBA.

Otro cantar son todos los problemas que conlleva CORBA : complejidad, orientado a conexión, rendimiento bajo, poco escalable...

Mono puede ser la respuesta.

Saludos.

martes, marzo 14, 2006 6:44:00 p. m.  
Blogger Ian Marteens said...

... y precio. Otra cosa que no se decía en voz alta, pero durante mucho tiempo, al menos mientras le seguí la pista, el Visibroker perdía memoría, bastante memoria. Y lo de siempre: los cuatro gatos que lo usaban se quejaban pero no acababa de aparecer un parche.

Mono, efectivamente.

martes, marzo 14, 2006 7:53:00 p. m.  
Blogger Dani Coll said...

.. más sobre Chrome y sus razones para migrar (o no) a .Net

Why upgrade .Net ?

Algunos de los comentarios, me suenan ;-)

jueves, marzo 16, 2006 3:13:00 p. m.  
Blogger Ian Marteens said...

:) Juro que no lo había leído antes. La verdad es que me inhibo bastante de entrar en las páginas de Chrome por Freya: son productos con mucho en común (¡excepto, repito, que ya Chrome funciona!) y es fácil "contaminarse", en el mejor sentido de la palabra. Tampoco he pedido una beta, de momento, y por las mismas razones.

Por cierto, el comentario de Magruder es gratuito y muy poco elegante. Cuando uno se manifiesta con ese fanatismo sobre un tema puramente técnico, es uno mismo quien atrae las dudas sobre la propia cabeza. Ni siquiera se trata de que el comentario original tenga un tono sarcástico. Too bad...

jueves, marzo 16, 2006 4:03:00 p. m.  

Publicar un comentario

<< Home