Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.
Wednesday, November 16, 2005
Entrevista a Miguel de Icaza sobre Mono
He leído en Monologue una referencia a una pequeña entrevista muy interesante que se le ha hecho a Miguel de Icaza.
Como resumen, cabe destacar los siguientes puntos:- Mono no se posiciona como una parte de Gnome, ni como su único objetivo, si no que pretende conseguir un entorno de desarrollo multiplataforma muy productivo: En la actualidad hay mucho FUD sobre este tema. Es posible que muchas aplicaciones pensadas específicamente para Gnome empiecen a desarrollarse en Mono, pero eso no significa que todo vaya a girar en torno a él. Además, se puede usar Mono con QT, ¿por qué no? Mono no tiene una dependencia sobre Gnome, es un runtime y un compilador más. El único inconveniente es que las librerías QT son para C++ y para poder utilizarlas con Mono hay que desarrollar unos bindings, los cuales se desarrollaron pero actualmente el proyecto habría que resucitarlo: QT#.
- La eficiencia de Mono es notoria: es ya más eficiente que otros runtimes usando interfaces gráficas (como Perl/Gtk o Python/Gtk), lo que demuestra los eficientes resultados del trabajo de optimización del equipo de desarrollo de Mono. Es más, incluso hay otros tests que demuestran que Mono incluso es más rápido en algunas cosas comparado con el framework de Microsoft.
- El proyecto Mono se puede posicionar como uno de los líderes de calidad en el mundo de desarrollo de código abierto: y es que siguen una metodología de trabajo muy estricta con respecto a esto. Prefieren la calidad a la rápidez, teniendo como prioridad arreglar bugs en lugar de implementar más y más funcionalidades. Desde la experiencia os certifico que esto es cierto porque de momento en el Bugzilla de Ximian no he notificado ningún bug que no se haya resuelto aún. Además, el uso intensivo que hacen de NUnit, desarrollando un test nuevo cada vez que corrigen un bug, asegura la calidad del proyecto a lo largo del tiempo evitando los defectos de regresión.
- La integración con OpenOffice cada día es mayor: incluso se están desarrollando componentes en C#.
Actualización: añado a esta entrada un enlace a uno de los primeros correos de Miguel de Icaza acerca de la relación de Mono con Gnome, cuando Mono aún estaba en sus inicios. Un must-read para cualquier entusiasta de Mono.
Actualización 06-FEB-2007: parece que el proyecto Qyoto/Kimono ha eclipsado al abandonado QT#, y esperemos que tenga larga vida. Yo por mi parte voy a investigarlo (que ya hay algunas cosas que me enfadan de Gtk#). PD: Pido disculpas a NcTrun que al final le dejé sin respuesta. A ver si un día de estos continuo el hilo y seguimos con la charla (sí, lo sé, alguno se habrá dado cuenta que me gusta resucitar entradas de casi años de antigüedad, jejejej).
Labels: CSharp, General, Mono, Programacion, SoftwareLibre
Comments:
<< Home
Hay que tener muchas ganas para resucitar QT#
En uno de los e-mails a la lista de QT#, puedes ver a Marcus, uno de los developers de QT# muy cansado del tema.
Y la verdad es que lo entiendo, porque como dice, puedes encontrar mucho pique. En el vídeo de Miguel de Icaza en la UOC, se ceba bastante con KDE. La realidad es que la peña que se mueve con Mono tiene mucha relación con gnome, y que en ocasiones hay pique contra KDE. Y como dice Marcus, desde los mundos de KDE tampoco se debe apreciar extraordinariamente Mono. O sea que tienes que tener una voluntad muy fuerte para desarrollar QT# para aguantar comentarios de unos y de otros, y tampoco sé cuánto soporte ha tenido nunca QT#.
La realidad es que aunque Mono no tenga relación con Gnome y pueda tirar de WxWidgets gracias a wx.NET, de SWF, y de otros GUI toolkits... pues GTK# se lleva la palma y con mucho, y aunque dentro de gnome haya quien no le mole mono, en los planets (tanto a nivel mundial como "local") de gnome y los de mono suele haber gente en común, y se suelen vincular uno con el otro.
O sea, yo uso gnome, pero también me parece que mono debería dar soporte a qt#, por ejemplo. Vamos, KDE está ahí, es usado, y hay mucha gente a la que le gusta. No sé, no me molan esas "competencias" dentro del Open Source.
En uno de los e-mails a la lista de QT#, puedes ver a Marcus, uno de los developers de QT# muy cansado del tema.
Y la verdad es que lo entiendo, porque como dice, puedes encontrar mucho pique. En el vídeo de Miguel de Icaza en la UOC, se ceba bastante con KDE. La realidad es que la peña que se mueve con Mono tiene mucha relación con gnome, y que en ocasiones hay pique contra KDE. Y como dice Marcus, desde los mundos de KDE tampoco se debe apreciar extraordinariamente Mono. O sea que tienes que tener una voluntad muy fuerte para desarrollar QT# para aguantar comentarios de unos y de otros, y tampoco sé cuánto soporte ha tenido nunca QT#.
La realidad es que aunque Mono no tenga relación con Gnome y pueda tirar de WxWidgets gracias a wx.NET, de SWF, y de otros GUI toolkits... pues GTK# se lleva la palma y con mucho, y aunque dentro de gnome haya quien no le mole mono, en los planets (tanto a nivel mundial como "local") de gnome y los de mono suele haber gente en común, y se suelen vincular uno con el otro.
O sea, yo uso gnome, pero también me parece que mono debería dar soporte a qt#, por ejemplo. Vamos, KDE está ahí, es usado, y hay mucha gente a la que le gusta. No sé, no me molan esas "competencias" dentro del Open Source.
¡Hombre Pablo! Gracias por tu primera aportación al blog.
Me ha parecido muy interesante tu comentario; y coincido completamente contigo en que los fanatismos y demás enfrentamientos del mundo OpenSource no hacen otra cosa que perjudicarlo.
La verdad es que me gustaría ser yo mismo el que resucitase el proyecto QT#, sólo por el deseo de que las partes (en este caso KDE y Gnome) se encontrasen en este punto y aprendiesen a ser un poco más plurales.
Aunque, viéndolo desde otro punto de vista, quizás debieramos emplear esfuerzo en otra dirección, por ejemplo, en crear un nivel de abstracción por encima de QT y GTK, desde el cual se pudiera enfocar a cada uno en tiempo de compilación. Esto, no sólo es complicado, sino que por el contrario está hecho ya, como bien me indicó Jonan un día que charlabamos de esto por Jabber, y se llama XUL. Porque si te fijas Firefox se renderiza con GTK, y hace unos meses empezaron a salir noticias de que ciertos hackers habían conseguido portar (salvo algún pequeño detalle pendiente) Mozilla/Firefox a QT (aunque parece que desgraciadamente el proyecto ha debido caer en saco roto, sólo por la ausencia de nuevas noticias por el momento).
Lo que ocurre es que no sé cómo se podría integrar todo esto para poder usar XUL sin tener que usar JavaScript ni XPCOM, pero sí usar C# con Mono por debajo. A lo mejor la solución es esperar a que Miguel de Icaza se ponga manos a la obra con XAML, ¡quién sabe!
Me ha parecido muy interesante tu comentario; y coincido completamente contigo en que los fanatismos y demás enfrentamientos del mundo OpenSource no hacen otra cosa que perjudicarlo.
La verdad es que me gustaría ser yo mismo el que resucitase el proyecto QT#, sólo por el deseo de que las partes (en este caso KDE y Gnome) se encontrasen en este punto y aprendiesen a ser un poco más plurales.
Aunque, viéndolo desde otro punto de vista, quizás debieramos emplear esfuerzo en otra dirección, por ejemplo, en crear un nivel de abstracción por encima de QT y GTK, desde el cual se pudiera enfocar a cada uno en tiempo de compilación. Esto, no sólo es complicado, sino que por el contrario está hecho ya, como bien me indicó Jonan un día que charlabamos de esto por Jabber, y se llama XUL. Porque si te fijas Firefox se renderiza con GTK, y hace unos meses empezaron a salir noticias de que ciertos hackers habían conseguido portar (salvo algún pequeño detalle pendiente) Mozilla/Firefox a QT (aunque parece que desgraciadamente el proyecto ha debido caer en saco roto, sólo por la ausencia de nuevas noticias por el momento).
Lo que ocurre es que no sé cómo se podría integrar todo esto para poder usar XUL sin tener que usar JavaScript ni XPCOM, pero sí usar C# con Mono por debajo. A lo mejor la solución es esperar a que Miguel de Icaza se ponga manos a la obra con XAML, ¡quién sabe!
Bueno, solo quiero comentar un detalle. Sobre la frase de "O sea, yo uso gnome, pero también me parece que mono debería dar soporte a qt#, por ejemplo."...
Mono es un Framework de desarrollo. Dar soporte a QT?... y a ncurser? ...y a tk? ...y a motif? ...y a windows.forms?...etc
A lo que me vengo a referir es, mono debe de centrar su esfuerzo en el Framework. Es cierto, que dado que los desarrolladores de Mono, muchos trabajan en Gnome/GTK, pues son los mismos que desarrollan GTK#, pero GTK# no es parte de Mono, es un proyecto aparte, igual que wx#, u otros. Mono no da de lado a ningun toolkit...si yo me desarrollo mi propio toolkit en C++, nada me impide poder adaptarlo a .NET con bindings...la limitación es la gente que quiera dedicarse a ello, y parece que en QT# la gente a acabado cansada.
Fijaros que ni GTK# ni el nuevo Windows.Forms 100% hecho en .NET por la gente de Mono, es una dependencia de Mono en si... pues en principio, mono es un framework de desarrollo para "lo que sea" (notese que está entre comillas, entendiendo que en principio es para lo que sea, salbo que se demuestre alguna limitación :P)
Mono es un Framework de desarrollo. Dar soporte a QT?... y a ncurser? ...y a tk? ...y a motif? ...y a windows.forms?...etc
A lo que me vengo a referir es, mono debe de centrar su esfuerzo en el Framework. Es cierto, que dado que los desarrolladores de Mono, muchos trabajan en Gnome/GTK, pues son los mismos que desarrollan GTK#, pero GTK# no es parte de Mono, es un proyecto aparte, igual que wx#, u otros. Mono no da de lado a ningun toolkit...si yo me desarrollo mi propio toolkit en C++, nada me impide poder adaptarlo a .NET con bindings...la limitación es la gente que quiera dedicarse a ello, y parece que en QT# la gente a acabado cansada.
Fijaros que ni GTK# ni el nuevo Windows.Forms 100% hecho en .NET por la gente de Mono, es una dependencia de Mono en si... pues en principio, mono es un framework de desarrollo para "lo que sea" (notese que está entre comillas, entendiendo que en principio es para lo que sea, salbo que se demuestre alguna limitación :P)
[^bgta^]:
Completamente de acuerdo con lo que dices, cuando releí mi post (después de publicarlo) me di cuenta. En plan es como "qué huevos" decir esa frase tan arrogante. Lo que tenía en la mente era que Mono no debería infravalorar esfuerzos en el desarrollo de QT#, por ejemplo. Vale, oficialmente no lo hace, e incluso enlazan al proyecto... pero a nivel de desarrolladores igual el "pique" sí está ahí (de hecho, ya ves lo que Marcus dice en esa lista). Que no pretendo generalizar a todos los desarrolladores de Mono (ni siquiera a una mayoría), o que no ocurra en otros proyectos. Con el resto del comentario 100% de acuerdo.
Knocte:
Ya lo siento, en esos aspectos técnicos sobre el grado de dificultad de hacer un nivel de abstracción por encima de QT y GTK, me pierdo demasiado. Dices que XUL lo hace, pero bajo qué condiciones? Quiero decir, que unos hackers han conseguido hacerlo... bajo qué circunstancias? Porque, pensando desde la mayor de las ignorancias posibles, dudo que hayan podido conseguir tener una librería de widgets con la eficiencia que puedan tener GTK o QT y con unos widgets tan avanzados como los que puedes encontrar en cada librería, no? En cualquier caso, no me disgusta para nada que haya esfuerzos más o menos paralelos como puedan ser GTK y QT, o sea, me daría pena que se unificasen o que se perdiese uno de los dos. La diversidad en Open Source me parece bastante interesante. Cuando decía que no me molaban esas "competencias", me refería más a que no sé, yo podría usar gnome y tú KDE y que la cosa no fuese más allá. Me refería más a las discusiones etc. que pueden generarse.
Completamente de acuerdo con lo que dices, cuando releí mi post (después de publicarlo) me di cuenta. En plan es como "qué huevos" decir esa frase tan arrogante. Lo que tenía en la mente era que Mono no debería infravalorar esfuerzos en el desarrollo de QT#, por ejemplo. Vale, oficialmente no lo hace, e incluso enlazan al proyecto... pero a nivel de desarrolladores igual el "pique" sí está ahí (de hecho, ya ves lo que Marcus dice en esa lista). Que no pretendo generalizar a todos los desarrolladores de Mono (ni siquiera a una mayoría), o que no ocurra en otros proyectos. Con el resto del comentario 100% de acuerdo.
Knocte:
Ya lo siento, en esos aspectos técnicos sobre el grado de dificultad de hacer un nivel de abstracción por encima de QT y GTK, me pierdo demasiado. Dices que XUL lo hace, pero bajo qué condiciones? Quiero decir, que unos hackers han conseguido hacerlo... bajo qué circunstancias? Porque, pensando desde la mayor de las ignorancias posibles, dudo que hayan podido conseguir tener una librería de widgets con la eficiencia que puedan tener GTK o QT y con unos widgets tan avanzados como los que puedes encontrar en cada librería, no? En cualquier caso, no me disgusta para nada que haya esfuerzos más o menos paralelos como puedan ser GTK y QT, o sea, me daría pena que se unificasen o que se perdiese uno de los dos. La diversidad en Open Source me parece bastante interesante. Cuando decía que no me molaban esas "competencias", me refería más a que no sé, yo podría usar gnome y tú KDE y que la cosa no fuese más allá. Me refería más a las discusiones etc. que pueden generarse.
jajaja, no pasa nada :-)
ya, la segunda actualización de un post de año y pico es cañero :-D
Pues sí, esperemos que tenga larga vida
Post a Comment
ya, la segunda actualización de un post de año y pico es cañero :-D
Pues sí, esperemos que tenga larga vida
<< Home