knocte :: MonoTema

La idea de la plataforma .NET acerca de la interoperabilidad entre lenguajes de programación es fantástica, porque permite que los programadores puedan usar el trabajo de otros sin que usen el mismo lenguaje. Esto es muy beneficioso, sobre todo para el software libre, pues en éste actualmente hay gran diversidad de lenguajes y poca coordinación entre ellos. Por eso, en mi opinión, Mono es la mejor alternativa actual para desarrollar software: todo lo que escribamos se encontrará disponible automáticamente para todos los programadores de .NET, independientemente del lenguaje que éstos otros utilicen. Si nos empeñamos en seguir usando diferentes plataformas de desarrollo, en lugar de diferentes lenguajes bajo una misma plataforma, seguiremos en el nivel de estancamiento de siempre con el software libre.

Es por esto que, bajo ciertas circunstancias, la diversidad sí es mala. Por ejemplo, la diversidad en máquinas virtuales o runtimes (Perl, Python, Java, Mono, ...) hace que el principio de .NET de interoperabilidad sea impracticable (con excepción de ciertos proyectos de conversion de bytecodes de un tipo a otro). Otros podrían decirme: "vale, puestos a elegir una máquina virtual, ¿por qué escoger la de Mono y no otra?", pues porque por el momento es la única que dispone de más de un compilador (porque compiladores a bytecode de Java sólo los hay de lenguaje Java, y compiladores a bytecode de Perl sólo los hay que compilen lenguaje Perl, etc.). Por tanto, usar Mono siempre, y luego escoger tu lenguaje favorito, debería ser lo que idealmente tuviera que hacer todo programador, tanto de software libre, como de privativo (porque también la interoperabilidad es buena en la empresa, aunque ésta desarrolle productos privativos).

Otro punto negativo que encuentro a la diversidad radica ahora dentro de la propia diversidad de lenguajes que soporta Mono. A pesar de que, como ya he dicho, esto es muy beneficioso en general, en mi opinión no lo es sólo en ciertos casos particulares, por ejemplo en aquellos en los que nos encontramos con un lenguaje de programación de muy baja calidad, como es el Visual Basic.

Reconozco que Visual Basic fue un gran paso en la programación, pues brindó la oportunidad de adentrarse en este mundo, de una manera no excesivamente compleja, a mucha gente (quizás haya gente que esto en sí le parezca algo malo, pero en este caso me tengo que negar porque yo también empecé con este lenguaje, mucho antes incluso de empezar la carrera). Pero en Visual Basic no todo eran bondades: algunas de sus capacidades supuestamente pensadas para hacer más sencilla la programación, a la larga generaban problemas de mantenimiento y malos hábitos al programador. Es decir, el programador podría hacer un desarrollo bastante rápido, a costa de prolongar sus fases de testeo y de revisión.

Un ejemplo de esto es la permisividad que tenía Visual Basic 6: la opción de no declarar las variables generaba en innumerables ocasiones comportamientos inesperados de la aplicación como consecuencia de una simple refactorización de un fragmento de código (ejemplo: si cambiamos el nombre de una variable, en lugar de considerar el compilador un error al encontrarse el nombre antiguo de la variable en otro lugar, no notificaba el error y presuponía que el programador quería inicializar una nueva variable vacía).

Sin embargo Visual Basic introdujo un concepto que ya disponía Java: la administración automática de la memoria. Y de aquí surgió C#: de intentar hacer un C++ que tuviera la facilidad de Visual Basic (y casualmente salió algo muy parecido a Java). Sólo por el mero hecho de crear C#, Microsoft estaba reconociendo que Visual Basic era un lenguaje muy malo. Pero no quiso desterrarlo totalmente, porque muchos malos programadores seguían programando con él, y lo que hizo fue hacerle un lavado de cara: intentó corregirle los problemas más acusados de los que adolecía y le denominó "Visual Basic .NET".

Esta estrategia seguramente le permitió a Microsoft no perder cierta cuota de mercado que de otra manera habría permanecido en VB6 durante mucho tiempo hasta migrar a C# (o incluso a Java). Y respeto bastante esta decisión, alegrándome de que además se quisiera mejorar un poco este lenguaje. Sin embargo, a la nueva versión le sigo viendo problemas, y creo que estos problemas vienen inherentemente provocados porque el lenguaje, en el fondo, es malo y es difícil parchear algo que inicialmente es de baja calidad (es decir, que algunos de estos problemas que yo sigo viendo podrían tener solución, pero otros no).

Y voy a ser bastante explícito; en la versión VB.NET 20005 se dan los siguientes problemas:

- VB.NET permite inicializar variables de tipo Structure a Nothing, mientras que hacer lo equivalente en C# (asignar null a una de tipo struct) es un error de compilación. ¿Por qué iba a permitir un lenguaje igualar a NULL una variable que no es un puntero? Aunque los lenguajes administrados no disponen de aritmética de punteros, por debajo, un objeto en .NET es una referencia a una posición de memoria si representa la instancia de una clase (un objeto), o bien NULL si aún no se ha instanciado. Las estructuras no son clases, y por tanto las instancias de ellas no son objetos: ¿qué sentido tendría entonces igualarlo a null? Sería como si quisieramos igualar a null un entero, cosa que ahora es posible en C# pero mediante Nullable Types, es decir, indicando que el tipo es int? en lugar de int, pero para ello el programador ha de explicitarlo. Una vez más, tenemos entonces que en VB.NET se hace uso de Nullable Types sin que el programador lo haya solicitado en absoluto.

- Al usar un campo no inicializado de una variable de tipo estructura (Structure en VB.NET y struct en C#), VB.NET notifica una advertencia (warning) mientras que C# notifica un error. ¿Y por qué ocurre esto? Porque VB.NET automáticamente inicializa por omisión los valores de una estructura si se le iguala a Nothing (cosa que permite como ya hemos visto en el punto anterior), y por tanto, debe permitir al programador usar esos valores por defecto. Esto, que podría ser una fuente de problemas en etapas posteriores al desarrollo, no se ha tenido en cuenta, y por un momento cuando me topé con esta ambigüedad llegué a pensar (por indicación de un programador de este lenguaje) que en VB.NET no hacía falta reservar memoria con New ya que lo hacía automáticamente el compilador si asignabas la variable a Nothing y usabas uno de sus campos (pero en realidad esto devuelve un NullReferenceException, menos mal, VB.NET no es tan malo; lo que estaba ocurriendo es que creí que el fragmento de código que no estaba arrojando esta excepción hacía referencia a una clase en lugar de a una estructura). Vamos, que el programador de VB.NET está tan mal acostumbrado por su propio lenguaje que cualquier cosa a la que no le encuentra explicación presupone que es causada por una "feature" del lenguaje en lugar de por un "bug".

Código de ejemplo de los dos últimos puntos:

C# code-snippet:

using System;
using System.Collections.Generic;
using System.Text;

namespace Cesharp
{
    public struct Pepe
    {
        public string sJuan;
        public string sLuis;
    }

    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("begin");

            Pepe oPepe;// = null;
            oPepe.sJuan = "soy Juan";

            Console.WriteLine("Juan: " + oPepe.sJuan + " | Luis:"
                + oPepe.sLuis  // línea conflictiva
                );

            Console.WriteLine("end");
        }
    }
}

VB.NET code-snippet:

Structure Pepe
    Public sJuan As String
    Public sLuis As String
End Structure

Module Module1

    Sub Main()

        Console.WriteLine("begin")

        Dim oPepe As Pepe = Nothing

        oPepe.sJuan = "soy Juan"

        Console.WriteLine("Juan: " + oPepe.sJuan & " | Luis:" & oPepe.sLuis)

        Console.WriteLine("end")

    End Sub

End Module

- Al tratar con Visual Studio .NET 2005, el generador automático de código de Visual Basic no escribe por omisión el Namespace, tal y como hace con C#; lo que redunda en que el programador de VB no tienda a estructurar su código correctamente en una jerarquía de ámbitos (o incluso que ni siquiera conozcan lo que es un "ámbito").

- El modelo de eventos en VB.NET varía bastante con respecto a C# (comparado con otras áreas en las que sólo varía la sintaxis y apenas la semántica) y en mi opinión éste es bastante más complicado. Con sólo decir que por culpa de esta forma de implementarlo, VB.NET contiene muchas más palabras reservadas que C# (el cual las sustituye normalmente por simples operadores)... ejemplos: Handles, AddressOf, ByVal...

- Visual Studio .NET 2005 adolece de ciertas carencias técnicas actualmente referentes a la interoperabilidad entre lenguajes que permite .NET. Por ejemplo: el comando "Go To Definition" sólo funciona entre proyectos del mismo código (si se hace desde código C# apuntando a una clase de VB.NET, el Visual Studio abre el explorador de ensamblados/proyectos o un pseudo-archivo de definición al que le subtitula con la coletilla "[from metadata]").

- Y muchos más que iré añadiendo a esta lista a medida que me vayan surgiendo... (BTW, ¿es la fealdad de su sintaxis un inconveniente válido? ;)


En otro orden de cosas, el compilador de Visual Basic.NET de Mono no está terminado, por lo que usar este lenguaje, de momento, implica problemas de portabilidad. Y una de las razones de que este compilador no se le cuide tanto como al de C# quizás sea que en general los buenos programadores le tienen tanta tirria a este lenguaje que prefieren no verlo ni en pintura. ¿Por qué iban a malgastar esfuerzos en desarrollar un compilador para un lenguaje así? Sin embargo, desde otro punto de vista sí puede ser beneficioso en pro de la portabilidad (para proyectos o equipos que ya estén usando VB.NET y por tanto no se encuentren ya en la situación inicial de decidir lenguaje o descartar lenguajes), ya que permitiría que más programadores de .NET pudieran usar Mono y eso traería más aplicaciones al mundo de software libre (a pesar de que, en teoría, no habría impedimento práctico en ello porque el resultado de lo que compilen es lenguaje intermedio que puede ser interpretado perfectamente por el runtime de Mono). Es por esto por lo que uno de los proyectos de Mono en las becas de Google Summer Of Code es terminar este compilador.

Le ofrezco mucho ánimo al programador que se vaya a encargar de esa tarea, pero al resto os aconsejo que migréis cuanto antes a otro lenguaje distinto de VB.NET. Ocurre una situación análoga a las API's de System.Windows.Forms: es deseable tenerlas implementadas en aras de la portabilidad, pero para desarrollar proyectos desde cero es mejor GTK# porque es técnicamente superior (por ejemplo, el sistema de layout que tiene no es como el de SWF que funciona solamente con coordenadas absolutas, lo que permite un redimensionado automático de todos los controles sin dolores de cabeza para el programador), y porque (ya sin hacer referencia a la analogía con VB.NET) es una parte de la API no estandarizada en el ECMA que podría desembocar en posibles problemas legales (donde existan las patentes) para su implementación.


Moraleja: la diversidad [de lenguajes] y la compatibilidad [en pro de la portabilidad] son buenas, pero hacer la buena elección es algo aún mejor.

Post-moraleja: además de ser un detractor de VB.NET, también lo soy de los lenguajes no estáticamente tipados.


ACTUALIZACIÓN: Resulta que, para más inri, los programadores de VB son tan comodones que debieron pedir a Microsoft en su día cierta compatibilidad hacia atrás de algunas funciones, palabras clave y sintaxis específicas que pertenecieron al legado de VB6, es decir, cosas absolutamente obsoletas y nada equivalentes a la API de .NET. ¿Qué ocurre? Que los programadores no dejan de quitarse los malos hábitos de usar este tipo de cosas porque el Visual Studio .NET no incluye una opción para descartar la librería que permite todo esto (Microsoft.VisualBasic.dll), y además esto va también en detrimento de la portabilidad. Más información aquí, y cómo evitarlo.


Actualización: Una vez más, amplío esta entrada con lo que podría ser el peor error de diseño de este lenguaje: ¡¡¡NO HACE FALTA HACER CASTS!!!

Como lo oyes, por ejemplo, la clase System.Random, cuyo constructor recibe un Integer, puede ser instanciada pasándole un tipo Long (DateTime.Now.Ticks, por ejemplo), sin que se queje el compilador (obteniendo un bonito error en tiempo de ejecución cuando pongas el código en producción). Otro ejemplo: tienes una función que devuelve Boolean, la refactorizas y le cambias el tipo de retorno por Integer, recompilas y ¡¡¡¡no da ningún error!!! (con los lenguajes decentes, el compilador te avisa lo que tienes que cambiar cuando haces una refactorización que pueda afectar a otras zonas de código).

¿A qué os recuerdan estos comportamientos tan patéticos? BINGO! ¡A los lenguajes dinámicamente tipados!

La próxima vez que me pregunten por un lenguaje dinámicamente tipado que compile código intermedio del CLR no responderé Ruby.NET ni JScript.NET, ¡responderé VisualBasic.NET! ¿Y un lenguaje de scripting? Ya no diré Boo, diré VB.NET.

Labels: CSharp, General, Mono, Programacion