Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.
Saturday, June 11, 2005
AntiFUD Mono/.NET
Éste es mi segundo AntiFUD, quizás debería crear una sección con este nombre :D
El caso es que también me suele enfadar mucho los hilos de BarraPunto que se dedican a desprestigiar a la plataforma de desarrollo de Mono, por la única razón de que con ésta se intenta reutilizar/adaptar/imitar un lenguaje, un entorno de desarrollo y unas API's de Microsoft (pero que, deliberadamente, ha publicado sin peligro de patentes, aunque esto podría suponer otra discusión...) de un modo multiplataforma.
Además, puesto que es mi plataforma de desarrollo preferida, me apetece defenderla. Y voy a hacerlo objetivamente: comentando aspectos técnicos sobre ésta y comparándola con otras plataformas de desarrollo (al final, con la que queda más reñida es con Java, pero en resumen yo creo que ésta queda derrotada).
[Este "artículo" fue inicialmente publicado en la lista de correo de NAVE, al hilo de una conversación sobre plataformas de desarrollo y la deliberación sobre la creación de un posible "Mozilla Translator II". Al cabo de los pocos días, salió una noticia en BarraPunto sobre .NET, y decidí copiar estas reflexiones en un comentario (como véis, lo hice como anónimo, lo que a veces permite hablar como si estuvieras convencido de que llevas la razón... jejeje, aunque reconozco que seguro que hay cosas en las que me he colado :) ]
EMHO, la mejor forma de programar hoy en día es en C# con Mono, por las siguientes razones:
1. Completamente multiplataforma (si no sacas los pies del tiesto). [Esto lo tiene Java, PHP, Perl, Python, pero no siempre C++ (en ciertas circunstancias...)]
2. Muchas interfaces gráficas multiplataforma a elegir (Web, GTK#, QT#, wx.NET, e incluso SWF a partir de la versión 1.2 de Mono; aunque EMO esto no debe suponer el plantearse a hacer proyectos desde el principio con esta última librería, sino sólo como arreglo para portar aplicaciones ya hechas).
3. Es un lenguaje estáticamente tipado (su compilador tiene análisis semántico). Esta característica suele resultar muy reñida y levanta polémica entre los programadores. Mi opinión personal es que es mejor pues evita que ciertos errores se descubran en etapas posteriores del desarrollo, sin sacrificar demasiado la complejidad del lenguaje, y ofreciendo aún así una buena flexibilidad como ofrecen los dinámicamente tipados (a esto se suma que la "estaticidad" del lenguaje ofrece mejor rendimiento). [Esto lo tiene Java y C++, pero no lo tiene ni Perl, ni Python, ni PHP]
4. Es un lenguaje pseudo-interpretado (que no interpretado, como Perl y PHP, aunque tengo entendido que para estos se pueden generar ejecutables específicos para cada procesador). Eso significa que tiene la ventaja de independizarse de la arquitectura, sin sacrificar la etapa de compilación. Es decir, que lo que se encontrará el framework de Mono siempre será código intermedio validado, que haya pasado el filtro de la compilación, lo que es más eficiente. [Esto lo tiene Java, pero no lo tiene ni Perl, ni Python, ni PHP, ni por supuesto C++.]
5. El modo de programación predeterminado es con "código seguro", es decir, sin aritmética de punteros. [Esto lo tiene Java, PHP y Perl (y creo que Python), pero no C++.]
6. Tiene tratamiento avanzado de excepciones nativo (try-catch-finally). [Esto lo tiene Java, C++, PHP5, pero no Perl (lo tiene no nativo).]
7. Soporte total del paradigma de la Orientación a Objetos. [Esto lo tiene Java y C++, PHP se queda corto, Perl no tiene distinción entre lo público y lo privado (dónde quedó eso del diseño por contrato o el principio de ocultación de la información o abstracción, concepto importantísimo de un TAD) y Python creo que también se queda corto.]
8. Es LIBRE. [¡¡Esto no lo tiene Java!! Y sí que lo tienen PHP, Perl, Python, C++ (depende).]
La idea general es que, como podréis comprobar, tengo en buena estima a Java y creo que su único inconveniente es que no es libre. Si además sumamos el hecho de que los programadores de .NET pueden migrar ahora a Linux con Mono, pues para de contar...
Y sí, sé que muchos de estos puntos podrían ser discutibles, en el sentido de que muchos preferirán el rendimiento de C++ sacrificando la productividad. Pero lo que yo creo es que C# (con Mono) coge lo mejor de los dos mundos en muchos puntos a discutir (la "eficiencia" frente a la productividad y a la capacidad multiplataforma).
No podía resistirme; sobre todo al oir lo de que es imposible usar C# sin MS: en mi opinión no es difícil. Yo creo que si usas C# en una aplicación de "propósito general" (sin usar llamadas a sistema, P/Invoke...) y no consigues hacerla multiplataforma, es que has sido un poco chapucilla...
Actualización: He encontrado un enlace de un documento en el que se compara Java con C#, en el cual veo lo más destacable su capítulo "Las 20 cosas que tiene C# y no tiene Java". EMO estos 20 puntos son mucho más importantes/interesantes que las otras 7 cosas que tiene Java y no tiene C# (que se quedan en 6 porque gracias a Mono tenemos la portabilidad).
Actualización 9-SEP-2006: Cada vez me doy más cuenta de que la mayoría de la gente detractora de Mono no expone argumentos técnicos, sino básicamente legales/filosóficos respecto del uso de un estándar ofrecido por Microsoft. En general podemos recopilar todos estos miedos en este artículo de Seth Nickell, el cual me parece un poco catrastrofista y totalmente rebatible, cosa que ya ha hecho un desarrollador de Mono en un mensaje en Slashdot (probablemente sea el mensaje más reconfortante que haya leído nunca sobre este tema :).
Actualización 19-SEP-2006: Y para los que siguen recurriendo al socorrido tema de la eficiencia del código nativo frente al código administrado, aquí va un mensaje de un desarrollador de Mono que habla sobre la compilación directa a código nativo y de cómo es impredecible saber si el resultado será más rápido o no. La desmitificación que sustenta se basa sobre todo en que, como los ensamblados de código administrado tienen menor tamaño, la computadora tarda menos en leerlos y eso hasta puede significar una ganancia en velocidad con respecto al código ya compilado en lenguaje máquina.
Actualización 02-OCT-2006: No tiene desperdicio este e-mail de Jonathan Pryor, un desarrollador de Mono, que habla sobre ventajas de C# frente a Java (en concreto sobre ciertas librerías de clases de .NET comparado con las de Java).
Actualización 03-DIC-2006: Parece que después de la liberación de Java, quedan menos argumentos en favor de Mono, jeje. No importa, aquí rescato una entrada de un blog en la que la gente echa pestes sobre cómo están implementados los tipos genéricos en Java, en comparación a cómo lo están en .NET.
Actualización 06-FEB-2007: Empiezan a surgir casos de prueba en los que se demuestra que aplicaciones hechas en código administrado (C#) pueden ser igual o más rápidas que otras hechas en C++. Esto no es más que consecuencia de que gracias al JIT que precompila a código nativo el código IL de nuestra aplicación al invocarla, tenemos un rendimiento similar en el funcionamiento normal del programa; es decir que casi se podría decir que el único handicap en velocidad lo tenemos en el momento del arranque de nuestro programa.
Actualización 18-MAY-2007: Añadida mención nueva a Perl como poco POO, nada amigable con las excepciones, y muy críptico. Tachado lo de que Java no es libre :D
Actualización 29-SEP-2007: Más diferencias entre Java y .NET: los genéricos son globalmente mejores en este último.
Actualización 01-FEB-2008: Aunque esta entrada se centraba en C# (sobre Mono), podría haber argumentado también que Mono puede soportar muchos lenguajes. Sin embargo, este argumento ya no sería válido contra Java porque están surgiendo más lenguajes que compilan al bytecode de Java: Groovy, JRuby, Jython y Scala. ¡Muy interesante!
El caso es que también me suele enfadar mucho los hilos de BarraPunto que se dedican a desprestigiar a la plataforma de desarrollo de Mono, por la única razón de que con ésta se intenta reutilizar/adaptar/imitar un lenguaje, un entorno de desarrollo y unas API's de Microsoft (pero que, deliberadamente, ha publicado sin peligro de patentes, aunque esto podría suponer otra discusión...) de un modo multiplataforma.
Además, puesto que es mi plataforma de desarrollo preferida, me apetece defenderla. Y voy a hacerlo objetivamente: comentando aspectos técnicos sobre ésta y comparándola con otras plataformas de desarrollo (al final, con la que queda más reñida es con Java, pero en resumen yo creo que ésta queda derrotada).
[Este "artículo" fue inicialmente publicado en la lista de correo de NAVE, al hilo de una conversación sobre plataformas de desarrollo y la deliberación sobre la creación de un posible "Mozilla Translator II". Al cabo de los pocos días, salió una noticia en BarraPunto sobre .NET, y decidí copiar estas reflexiones en un comentario (como véis, lo hice como anónimo, lo que a veces permite hablar como si estuvieras convencido de que llevas la razón... jejeje, aunque reconozco que seguro que hay cosas en las que me he colado :) ]
EMHO, la mejor forma de programar hoy en día es en C# con Mono, por las siguientes razones:
1. Completamente multiplataforma (si no sacas los pies del tiesto). [Esto lo tiene Java, PHP, Perl, Python, pero no siempre C++ (en ciertas circunstancias...)]
2. Muchas interfaces gráficas multiplataforma a elegir (Web, GTK#, QT#, wx.NET, e incluso SWF a partir de la versión 1.2 de Mono; aunque EMO esto no debe suponer el plantearse a hacer proyectos desde el principio con esta última librería, sino sólo como arreglo para portar aplicaciones ya hechas).
3. Es un lenguaje estáticamente tipado (su compilador tiene análisis semántico). Esta característica suele resultar muy reñida y levanta polémica entre los programadores. Mi opinión personal es que es mejor pues evita que ciertos errores se descubran en etapas posteriores del desarrollo, sin sacrificar demasiado la complejidad del lenguaje, y ofreciendo aún así una buena flexibilidad como ofrecen los dinámicamente tipados (a esto se suma que la "estaticidad" del lenguaje ofrece mejor rendimiento). [Esto lo tiene Java y C++, pero no lo tiene ni Perl, ni Python, ni PHP]
4. Es un lenguaje pseudo-interpretado (que no interpretado, como Perl y PHP, aunque tengo entendido que para estos se pueden generar ejecutables específicos para cada procesador). Eso significa que tiene la ventaja de independizarse de la arquitectura, sin sacrificar la etapa de compilación. Es decir, que lo que se encontrará el framework de Mono siempre será código intermedio validado, que haya pasado el filtro de la compilación, lo que es más eficiente. [Esto lo tiene Java, pero no lo tiene ni Perl, ni Python, ni PHP, ni por supuesto C++.]
5. El modo de programación predeterminado es con "código seguro", es decir, sin aritmética de punteros. [Esto lo tiene Java, PHP y Perl (y creo que Python), pero no C++.]
6. Tiene tratamiento avanzado de excepciones nativo (try-catch-finally). [Esto lo tiene Java, C++, PHP5, pero no Perl (lo tiene no nativo).]
7. Soporte total del paradigma de la Orientación a Objetos. [Esto lo tiene Java y C++, PHP se queda corto, Perl no tiene distinción entre lo público y lo privado (dónde quedó eso del diseño por contrato o el principio de ocultación de la información o abstracción, concepto importantísimo de un TAD) y Python creo que también se queda corto.]
8. Es LIBRE. [¡¡Esto no lo tiene Java!! Y sí que lo tienen PHP, Perl, Python, C++ (depende).]
La idea general es que, como podréis comprobar, tengo en buena estima a Java y creo que su único inconveniente es que no es libre. Si además sumamos el hecho de que los programadores de .NET pueden migrar ahora a Linux con Mono, pues para de contar...
Y sí, sé que muchos de estos puntos podrían ser discutibles, en el sentido de que muchos preferirán el rendimiento de C++ sacrificando la productividad. Pero lo que yo creo es que C# (con Mono) coge lo mejor de los dos mundos en muchos puntos a discutir (la "eficiencia" frente a la productividad y a la capacidad multiplataforma).
No podía resistirme; sobre todo al oir lo de que es imposible usar C# sin MS: en mi opinión no es difícil. Yo creo que si usas C# en una aplicación de "propósito general" (sin usar llamadas a sistema, P/Invoke...) y no consigues hacerla multiplataforma, es que has sido un poco chapucilla...
Actualización: He encontrado un enlace de un documento en el que se compara Java con C#, en el cual veo lo más destacable su capítulo "Las 20 cosas que tiene C# y no tiene Java". EMO estos 20 puntos son mucho más importantes/interesantes que las otras 7 cosas que tiene Java y no tiene C# (que se quedan en 6 porque gracias a Mono tenemos la portabilidad).
Actualización 9-SEP-2006: Cada vez me doy más cuenta de que la mayoría de la gente detractora de Mono no expone argumentos técnicos, sino básicamente legales/filosóficos respecto del uso de un estándar ofrecido por Microsoft. En general podemos recopilar todos estos miedos en este artículo de Seth Nickell, el cual me parece un poco catrastrofista y totalmente rebatible, cosa que ya ha hecho un desarrollador de Mono en un mensaje en Slashdot (probablemente sea el mensaje más reconfortante que haya leído nunca sobre este tema :).
Actualización 19-SEP-2006: Y para los que siguen recurriendo al socorrido tema de la eficiencia del código nativo frente al código administrado, aquí va un mensaje de un desarrollador de Mono que habla sobre la compilación directa a código nativo y de cómo es impredecible saber si el resultado será más rápido o no. La desmitificación que sustenta se basa sobre todo en que, como los ensamblados de código administrado tienen menor tamaño, la computadora tarda menos en leerlos y eso hasta puede significar una ganancia en velocidad con respecto al código ya compilado en lenguaje máquina.
Actualización 02-OCT-2006: No tiene desperdicio este e-mail de Jonathan Pryor, un desarrollador de Mono, que habla sobre ventajas de C# frente a Java (en concreto sobre ciertas librerías de clases de .NET comparado con las de Java).
Actualización 03-DIC-2006: Parece que después de la liberación de Java, quedan menos argumentos en favor de Mono, jeje. No importa, aquí rescato una entrada de un blog en la que la gente echa pestes sobre cómo están implementados los tipos genéricos en Java, en comparación a cómo lo están en .NET.
Actualización 06-FEB-2007: Empiezan a surgir casos de prueba en los que se demuestra que aplicaciones hechas en código administrado (C#) pueden ser igual o más rápidas que otras hechas en C++. Esto no es más que consecuencia de que gracias al JIT que precompila a código nativo el código IL de nuestra aplicación al invocarla, tenemos un rendimiento similar en el funcionamiento normal del programa; es decir que casi se podría decir que el único handicap en velocidad lo tenemos en el momento del arranque de nuestro programa.
Actualización 18-MAY-2007: Añadida mención nueva a Perl como poco POO, nada amigable con las excepciones, y muy críptico. Tachado lo de que Java no es libre :D
Actualización 29-SEP-2007: Más diferencias entre Java y .NET: los genéricos son globalmente mejores en este último.
Actualización 01-FEB-2008: Aunque esta entrada se centraba en C# (sobre Mono), podría haber argumentado también que Mono puede soportar muchos lenguajes. Sin embargo, este argumento ya no sería válido contra Java porque están surgiendo más lenguajes que compilan al bytecode de Java: Groovy, JRuby, Jython y Scala. ¡Muy interesante!
Labels: CSharp, General, Mono, Programacion, SoftwareLibre, WebDev
# posted by knocte @ 12:24 am 
Comments:
<< Home
Bueno, algunas cosas de las que comentas no son del todo ciertas.
En cuanto a las interfaces gráficas, QT# está abandonado, y no sé el grado de madurez de wx.NET (en un principio iba a poner que tambien estaba abandonado, pero por lo que he visto en la web del proyecto en Julio de este año sacaron una nueva versión así que no debe estarlo)
Por lo demás, Python también tiene proceso de compilación, no tiene punteros, y es un lenguaje que tiene perfecto soporte de orientación a objetos.
De todas formas, la mayoría de críticas a Mono no son desde un punto de vista técnico, sino por el tema de patentes y de que en cierta medida supone una dependencia de Microsoft, con lo cual no estoy muy de acuerdo pero bueno.
En cuanto a las interfaces gráficas, QT# está abandonado, y no sé el grado de madurez de wx.NET (en un principio iba a poner que tambien estaba abandonado, pero por lo que he visto en la web del proyecto en Julio de este año sacaron una nueva versión así que no debe estarlo)
Por lo demás, Python también tiene proceso de compilación, no tiene punteros, y es un lenguaje que tiene perfecto soporte de orientación a objetos.
De todas formas, la mayoría de críticas a Mono no son desde un punto de vista técnico, sino por el tema de patentes y de que en cierta medida supone una dependencia de Microsoft, con lo cual no estoy muy de acuerdo pero bueno.
# posted by 
: Thursday, December 15, 2005 10:31:00 pm
: Thursday, December 15, 2005 10:31:00 pm
No te sulfures con lo que hay en barrapunto; leerás esto y otras tantas cosas más.
Un saludo.
Un saludo.
# posted by : Monday, December 19, 2005 12:18:00 am
: Monday, December 19, 2005 12:18:00 am
Hola, knocte, soy Ricardo. Ha sido entretenido leer la lista de 20 puntos que tiene C# y no tiene Java, pero la verdad es que, en el momento en que escribiste la entrada en tu blog, varios de ellos ya no eran ciertos: Java 1.5 tiene enumeraciones, anotaciones (los Attributes de C# parecen servir para lo mismo), el operador instanceof para, aproximadamente lo mismo que as y una sintaxis para for que es equivalente a foreach.
Otros elementos de esa lista me resultan /peligrosos/ para la confección de un buen programa, seguro y legible, tales como (en algunos casos) el boxing, los Properties y los Indexers (¡¡arrghh!!), los punteros y el código inseguro y la no detección de overflows. En los grupos de Java, hay quien argumenta que el hecho de que Java no tenga directivas de preprocesador y no exista ningún proyecto conocido que lo implementa significa que, realmente, no son necesarias para un buen programador. También se dice que un método debe devolver cero o un valor, y necesitar devolver más es una mala práctica de programación OOP (el caso del intercambio se implementaría con una clase con un constructor que admitiría los dos valores de entrada, dos getters y el método swap()).
Por último, el punto 20 es directamente un error por parte del autor. Por definición, los interfaces en Java son eso, interfaces, y no clases ("... a FileRepresentation class which has a graphical user interface may implement an IWindow and an IFileHandler interface. Both of these *****classes**** may have a Close method where in the case of IWindow it means to close the GUI window while in the case of IFileHandler it means to close the file").
Si una clase en Java implementa dos interfaces que declaran exactamente el mismo método, la implementación de esa clase será la que defina lo que realmente hay que hacer (y, en el mal ejemplo que pone el autor, lo que uno debe esperar del método Close() de una clase que implemente una interfaz IWindow y otra IFileHandler es que se cierren ambas cosas al ejecutar ese método). Lo más habitual, sin embargo, es que las dos interfaces, o bien la clase que las implementa, definan métodos distintos con el mismo nombre, pero listas de argumentos diferentes. La diferencia, en resumen, es que Java no implementa herencia múltiple por los problemas que su existencia en C++ acarreó durante los años.
Vaya, si uno quiere ser malo podría pensar que en tu artículo anti-FUD repartes algo de FUD. ;-)
Post a Comment
Otros elementos de esa lista me resultan /peligrosos/ para la confección de un buen programa, seguro y legible, tales como (en algunos casos) el boxing, los Properties y los Indexers (¡¡arrghh!!), los punteros y el código inseguro y la no detección de overflows. En los grupos de Java, hay quien argumenta que el hecho de que Java no tenga directivas de preprocesador y no exista ningún proyecto conocido que lo implementa significa que, realmente, no son necesarias para un buen programador. También se dice que un método debe devolver cero o un valor, y necesitar devolver más es una mala práctica de programación OOP (el caso del intercambio se implementaría con una clase con un constructor que admitiría los dos valores de entrada, dos getters y el método swap()).
Por último, el punto 20 es directamente un error por parte del autor. Por definición, los interfaces en Java son eso, interfaces, y no clases ("... a FileRepresentation class which has a graphical user interface may implement an IWindow and an IFileHandler interface. Both of these *****classes**** may have a Close method where in the case of IWindow it means to close the GUI window while in the case of IFileHandler it means to close the file").
Si una clase en Java implementa dos interfaces que declaran exactamente el mismo método, la implementación de esa clase será la que defina lo que realmente hay que hacer (y, en el mal ejemplo que pone el autor, lo que uno debe esperar del método Close() de una clase que implemente una interfaz IWindow y otra IFileHandler es que se cierren ambas cosas al ejecutar ese método). Lo más habitual, sin embargo, es que las dos interfaces, o bien la clase que las implementa, definan métodos distintos con el mismo nombre, pero listas de argumentos diferentes. La diferencia, en resumen, es que Java no implementa herencia múltiple por los problemas que su existencia en C++ acarreó durante los años.
Vaya, si uno quiere ser malo podría pensar que en tu artículo anti-FUD repartes algo de FUD. ;-)
<< Home
