Antes de continuar explorando las bondades que nos trae MonoDevelop, es necesario comprender y evaluar las tecnologías que vamos a ocupar, ya que en primera instancia y para alguien que apenas se está empapando del Proyecto Mono, es necesario plantearnos el como y el porqué de las cosas, así como determinar cuales serán nuestras fuentes de confianza que usaremos regularmente para solventar nuestras dudas.

Este artículo esta destinado a tratar de justificar el uso de MonoDevelop y sus partes, enfocándome directamente en el desarrollo de aplicaciones visuales.

Como ya muchos saben, .NET no es mas que un framework de clases que podemos usar para desarrollar nuestros programas así como la maquina virtual que lo ejecutará. Pero para una mejor compresión prefiero preguntarle a Carlos Cortez, quien trabaja en Novell como Ingeniero de Sistemas Mono y directamente junto con Miguel de Icaza en el desarrollo del Proyecto.

Nexus: Como para principiantes, ¿Qué es Mono?

Carlos: Mono es una chingonería.

Nexus: ... (silencio sepulcral) ... ¿y para no tan principiantes?

Carlos: Mono una una libre implementación de la plataforma de desarrollo .Net, enfocada principalmente a sistemas Unix, y también con el propósito de brindar puentes de migración de Windows hacia Linux. El interés es tener un sistema de desarrollo multiplataforma, que permita la interoperación entre diversos lenguajes de programación, así como una arquitectura extensible, tal como .Net la tiene definida en un estandard ECMA.

Nexus: Segun se, .Net es un framework de clases, por lo tanto, ¿Mono es la implementación libre de dichas clases?

Carlos: Así es. La idea es implementar la extensa librería de clases de .Net. Hoy día, se han implementado la gran mayoría de las clases de .Net 1.0 y 1.1, así como algunas de .Net  2.0 (que es algo en lo que tenemos poco tiempo trabajando). Y aunque hay clases que no hemos implementado (principalmente porque necesitan acceso al API de WIndows), estamos hablando de que las clases ma? usadas ya están funcionando sin problemas.

Nexus: También entra en el tema la Maquina Virtual y el compilador para poder usar dichas clases. ¿Mono actualmente tiene terminados compiladores para diferentes lenguajes?

Carlos: Actualmente tenemos diversos compiladores, algunos con mayor madurez que otros. El compilador que más soportamos es el de C#, que soporta además la sintaxis de C# 2.0, y que ha alcanzado un muy buen grado de estabilidad. También tenemos compiladores para JScript, Visual Basic, que están en estados de desarrollo. Por cierto que es importante mencionar que tenemos un proyecto dentro del Google Summer Of Code, en el que un chico está implementando un compilador de Visual Basic con interesantes características.

Ahora bien, también es importante mencionar que hay proyectos cercanos a nosotros, en mayor o menor medida, que tienen compiladores para otros lenguajes; entre ellos cabe destacar Boo, un lenguaje con sintaxis basada en Python; IKVM, que permite ejecutar código intermedio producido por compiladores de Java (bytecode) en la máquina virtual de Mono, o incluso convertir ese bytecode a CIL (el código intermedio de .Net y Mono).

Nexus: Estas mencionando el CIL. Entiendo que es el resultado de una compilación de un lenguaje soportado por .NET, ¿me podrías ampliar este concepto?

Carlos: Las siglas CIL se refieren a "Common Intermediate Language", que es algo como "Lenguaje Intermedio Común", que es una representación de código independiente de la arquitectura. Este código intermedio es en efecto producido por los compiladores tanto de .Net como los de Mono, y tiene como propósito ser precisamente un código independiente, para que pueda ser ejecutado en las máquinas virtuales en cada una de las arquitecturas soportadas.

De esta forma, si compilaste un trozo de código en Windows, bien puedes llevarlo a Linux y ejecutarlo sin problemas. La idea es tener un lenguaje universal, por decirlo de alguna forma.

Nexus: Esto quiere decir, que ¿cualquier lenguaje podría portarse a .Net/Mono, siempre y cuando cumpla con las especificaciones del framework?

Carlos: Así es. Cualquier lenguaje puede tener un compilador que genere CIL, siempre y cuando cumplas con ciertas especificaciones, que se encargan de que los lenguajes puedan trabajar entre ellos sin problemas, para compartir código, extender funcionalidad, entre otras cosas. Esta serie de reglas está definida en el estándard ECMA, y lleva el nombre de CLS, que se refiere a "Common Language Specification".

Nexus: En plataformas Windows, se usan las clases Windows.Forms para el "diseño" de formularios, ¿estas están soportadas en el Framework de Mono?

Carlos: Esa parte es especialmente importante, por una serie de razones. La primera tiene que ver con que esas clases están definidas en .Net sobre el API de Windows para interfaces gráficas, y no implementadas en C#, como otras partes. Ello es importante porque, al querer soportarlas en Linux, nos damos cuenta de que no tenemos ese API disponible.

Tuvimos un par de intentos fallidos al implementar esta parte, y el intento actual -que es con el que hemos logrado mayor avance-, es el de implementarlas en C#, y acceder a la interfaz de bajo nivel de cada plataforma en una capa inferior, para llevar a cabo el dibujado.

Ahora bien, la versión 1.0 no la soporta básicamente, y las versiones actuales (la rama 1.1) la soportan cada vez más. La idea es que Mono 1.2, nuestra próxima versión grande, tenga un muy buen soporte para esta área. Y de hecho, trabajamos actualmente de forma importante en corregir bugs en Windows.Forms, y en cuanto se sienta que la implementación es lo suficientemente sólida, estaremos liberando Mono 1.2

En cuanto a Windows.Forms 2.0, te puedo decir que la soportamos parcialmente, ya que en este momento nuestro mayor objetivo es soportar en su totalidad a la versión 1.1

Nexus: Por lo tanto, ¿la solución inmediata fue la creación de Gtk# para que Mono adquiriera la habilidad de dibujar y manejar formularios?

Carlos: En realidad Gtk# tiene un papel diferente al de Windows.Forms. La idea de tener Gtk# fue la de brindar un API sencillo y de gran desempeño para las personas desarrollando para Gnome, y así explotar muchas de las bondades de Mono. El que Gtk# sea multiplataforma fue algo que se tuvo de forma natural, y es algo que se tratado de expandir.

El papel de Windows.Forms es brindar soporte para el código escrito para .Net, y brindar puentes de migración, como lo mencionaba.

Gtk# es nuestro API de GUI más sólido, y Winforms brinda la compatibilidad para muchas aplicaciones.

Nexus: Ahora, enfocándome en aplicaciones gráficas, poniendo los pies en la tierra y tomando en cuenta que no existe el puente de migración completa de Windows a Unix. ¿esta completamente soportada la migración de aplicaciones en Mono, con C# y Gtk# a plataformas Windows transparentemente?

Carlos: Me parece que hay dos cosas que tomar en cuenta en este caso: el diseño de la aplicación, así como el soporte de Gtk# y Mono en Windows.

En el caso del soporte de aplicaciones hechas con Gtk# para Windows, te puedo decir que tenemos instaladores de cada versión importante para Windows, que es independiente de las versiones de Mono. De esta forma, es posible que puedas no solamente funcionando Gtk# con Mono, sino también con .Net en Windows. Porque resulta que muchas veces se tiene disponible .Net en plataformas Windows, y lo único que quieres es el soporte de Gtk#. Puedes usarlo con ambos entornos sin problemas.

En cuanto a la forma en la que las aplicaciones están hechas, hay clases que evitan tener que lidiar con detalles del sistema. Un ejemplo sencillo es el separador de directorio, que en Windows es uno, y en los sistemas Unix es otro; en este caso, puedes simplemente utilizar una propiedad de la clase Path (ruta) que es la que tendrá en cada sistema el separador actual.

Desde luego que a veces existen detalles importantes que no pueden ser portados tan fácilmente. Pero cuando menos, existen varias formas de tener que disminuir la cantidad.

Nexus: Toda esta plática viene debido a la salida de un IDE llamada MonoDevelop, que aunque esta recién nacida (versión 0.11) ya tiene toda la pinta y la posibilidad de ser un RAD. ¿MonoDevelop es un proyecto del equipo Novell?

Carlos: MonoDevelop fue inicialmente un port de la versión 1.0 de SharpDevelop, que era un IDE para .Net que se ejecuta en Windows. Dicho IDE, aunque no tan completo como lo es Visual Studio, resultaba ser bastante bueno en el soporte de diseño de interfaces gráficas con Windows.Forms, así como con la edición de código.

Como parte de Mono era importante contar con un IDE que pudiera facilitar el desarrollo, especialmente para aquellos desarrolladores habituados a utilizarlos de manera constante. De esa forma, cuando se dio inicialmente el port, en Novell se trató de apoyar su avance. Después de algunos meses de trabajo, se logró tener con Gtk# (en Windows estaba desarrollado con Windows.Forms), y con todos los componentes, exceptuando el soporte para Windows.Forms, que por entonces estaba bastante incompleto.

Posteriormente, Luis Sánchez, un miembro del grupo de Mono en Novell tomó gran parte en el desarrollo, para comenzar a añadir funcionalidad en MonoDevelop, que por ejemplo no estaban en el original. Un ejemplo importante, fue el soporte para el diseño de interfaces para Gtk# (que solía hacerse escribiendo el código a mano, o usando Glade), que usaba un proyecto interno de Novell, llamado Stetic.

En otras palabras, no es un proyecto de Novell, sino más bien parte de Mono, el cual está claramente auspiciado por Novell. Existen, como en Mono, muchos colaboradores que no son parte de Novell.

Nexus: Una de las necesidades más importantes para los desarrolladores de aplicaciones de producción empresarial o de negocios es la de usar y manejar bases de datos, para ello me estoy interesando en MySQL Connector/Net el cual está escrito directamente en C# ¿Mono soportaría la adición de esta librería?

Carlos: Por supuesto. Estamos claramente conscientes de que es importante brindar soporte para el mayor número de tecnologías, y en el caso de las bases de datos, no resulta distinto.

En el caso de clases que soporte cierta tecnología, que provengan de colaboradores (empresas, grupos, o colaboradores), pedimos cierta consistencia; y en la parte de las licencia, que sea compatible con la sección en la que se piensa incluir (MIT/X11 es la que usamos para la librería de clases, por ejemplo).

Y en el caso de las que podríamos desarrollar como parte de Novell, te podría decir que también estamos muy interesados en abarcar el mayor número de tecnologías. Obviamente tenemos ciertas tareas con mayor importancia, y tratamos de enfocarnos en ellas. A veces es cuestión de tiempo el comenzar a soportar alguna tecnología en cuestión.

Finalmente, si una empresa requiriese soporte para algún componente, bien podría escribir el soporte mismo (como ha pasado con compañías como Mainsoft, que han contribuido secciones fundamentales para sus productos para la interacción entre Java y .Net), o bien podría requerirse a Novell el desarrollo mismo, el cual tendría que hacerse de manera formal y demás (desconozco los detalles).

Nexus: Por último, y para cerrar con broche de oro, te pido me des tus conclusiones y cual es la visión a futuro del proyecto Mono.

Carlos: Mono es una excelente opción para el desarrollo multiplataforma, RAD (Rapid Application Development), una extensa librería de clases (librería de clases propia), gran compatibilidad con .Net, y además la posibilidad de modificar el código para adaptarlos a sus necesidades.

Nuestra visión al futuro es tener la mejor plataforma de desarrollo para Linux, seguir brindando compatibilidad con .Net, y tener cada vez una comunidad mayor de programadores. Me parece que podríamos decir, sin temor al fracaso, que hoy por hoy Mono es una excelente herramienta de desarrollo, brindando puentes de desarrollo para los programadores del mundo de Windows, y brindando una mayor velocidad de desarrollo en los sistemas Unix.

Lo mejor está por venir.

Nexus: Muchas gracias por tu excelente aportación, vamos a continuar descubriendo este mundo y te tendré que molestar de vez en cuando para resolver diversas metas que me he propuesto.

Carlos: Muy bien. Un saludo desde la ciudad de Puebla

Después de esta buena plática creo que quedó bastante claro hacia donde nos podemos dirigir. Programando en C# con Gtk#, conectando a MySQL con MySQL Connector/Net y usando MonoDevelop ya tenemos un gran avance, por lo que para poner manos a la obra, en el siguiente artículo empezaré a hacer algunas pruebas y trataré de documentar lo mas detalladamente posible.

Mientras tanto aquí están algunos enlaces interesantes para empezar a leer un poco.

Proyecto Mono
MonoDevelop
Gtk#
MySQL Connector/Net
Un Libro de C# en español
Un Manual de Gtk# en español
La comunidad de Mono Hispano