Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.

Friday, May 26, 2006

 

Más razones para odiar el Visual Basic

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: , , ,


Comments:
Estoy de acuerdo con que C# es un lenguaje técnicamente más poderoso que VB.
Pero me parece que prolongar las discusión de cual lenguaje es mejor es un error y es tan vano como discutir cual color es más bonito.
Creo que este tipo de conceptos son personales y me parece un error involucrar "sentimientos" y "sensaciones" cuando se programa. En este sentido hay que tener la mente abierta y aprovechar las herramientas que se tienen para desarrollar aplicaciones d ela mejor manera sin sesgamientos ni preferencias.
 
me parece la misma pendejeria q hablar de linux vs windows... uff q estupidez y perdida de tiempo, si al final uno elige lo que más le acomode
 
Me parece el tema de siempre... Despreciar y desprestigiar a los demas "programadores" por que no usan un lenguaje que para "el" es el mejor. Al final, no se da cuenta, que .NET tiende a mejorar mientras lo suyo, queda estancado. Que facil es criticar cuando se cree Dios. Yo llevo 20 años en este mundo y he tocado de todo y siempre me ha fastidiado que hubieran tantos lenguajes, pero la realidad es que ahora se tiende a unificar al menos el concepto de programacion a una misma plataforma, y en parte .NET lo hace, asi, que deja de criticar y ser tan demagogo e intolerante y aporta algo de ayuda como hacen muchos desinteresados. (miedo me da tenerte de compañero de proyecto)
 
Estoy de acuerdo con que C# es un lenguaje técnicamente más poderoso que VB.

Bien.

Pero me parece que prolongar las discusión de cual lenguaje es mejor es un error y es tan vano como discutir cual color es más bonito.

¿Discutir sobre la potencia de un lenguaje te parece tan vanal como discutir sobre colores? ¿Dónde está la profesionalidad de cada uno entonces si hay que escoger una herramienta para llevar a cabo un trabajo? Habrá que discutir, digo yo, con la prolongación que sea necesaria, para llegar a una conclusión y tomar la decisión, ¿no?

Creo que este tipo de conceptos son personales y me parece un error involucrar "sentimientos" y "sensaciones" cuando se programa.

Dime, por favor, cuáles de las ventajas o inconvenientes que he enunciado, tienen que ver con sentimientos personales. Yo creo que todas las que he mencionado son objetivas, fácticas y concretas, al contrario que los sentimientos.

En este sentido hay que tener la mente abierta y aprovechar las herramientas que se tienen para desarrollar aplicaciones d ela mejor manera sin sesgamientos ni preferencias.

Estoy de acuerdo en que hay que tener la mente abierta. Pero hay que tenerla para todo, es decir, que los programadores de VisualBasic.NET tienen que asumir que el lenguaje que utilizan es menos potente, tiene más inconvenientes, y por tanto en nuestra profesión ese lenguaje podrá verse descartado en innumerables ocasiones frente a otra alternativa más potente y mejor.

Evidentemente que si tenemos que usar unas librerías o programas que ya están escritos en ese lenguaje, deberíamos aprovechar la implementación y retrasar la prioridad de la reescritura de código, pero aquí estamos hablando de dos lenguajes, C# vs. VB.NET, enunciando ventajas e inconvenientes en las que basarnos para tomar una decisión, una decisión que estará basada sobre todo en el máximo objetivo de la eficiencia (comercialmente hablando) de cara a que, pongamos que la decisión se haya de tomar en el entorno laboral, la empresa obtenga el máximo ratio de inversión-beneficio.
 
me parece la misma pendejeria q hablar de linux vs windows... uff q estupidez y perdida de tiempo, si al final uno elige lo que más le acomode

Abre tu mente, por favor, tal y como dice el usuario anónimo que escribió antes que tú, para comprender que está decisión es posible que se tome, no sólo en el ámbito personal (en el cual evidentemente usarás lo que más te guste, y aún así podría caber algo de discusión porque sino no debatiríamos sobre nada), sino también en un terreno profesional, visto desde un prisma en el cual se debe priorizar la eficiencia y se debe tomar una decisión objetiva antes de ponerse a implementar.

Porque en las empresas de software, sean de código abierto o no, normalmente no son los programadores los que deciden el lenguaje con el que quieren trabajar. Lo suele decidir un jefe de proyecto, o más bien un arquitecto de software, de cara a perseguir la mejor herramienta, la que va a ofrecer más productividad, menos problemas de mantenimiento posterior, etc.
 
Estoy cansado de programar en casi todos los lenguajes que comentáis y sin lugar a dudas me quedo con VB. Entiendo que el que trabaje en un entorno donde alguien decide por él lo que debe hacerse con un programa probablemente siempre trabaje haciendo una parte encapsulada que terminará junto con otras pequeñas partes hechas por otros tantos amantes del único leguaje que de verdad han aprendido.

Lo creas o no con VB se puede hacer absolutamente todo lo que puedes hacer con culaquier otro, hasta trabajar con punteros, que parece que es lo más de lo más. Estoy de acuerdo que en determinado tipo de funciones es más eficiente cualquier versión de C, pero está claro que si has tenido que hacer un programa completo te has encontrado con todas las barreras sin sentido que impone C y el tiempo extra que tienes que dedicar.
 
Punto 1: existen personas masoquistas que usan algun sabor de Basic aunque le de escalofrios a Andy Tanenbaum.
Punto2: existen personas a las que poco les importa los estandares y para nada la portabilidad.
Punto 3: Existen personas que saben y otras que dicen que saben
 
Estoy deacuerdo Visual Basic es malo, porque no existe mucha lógica en lo que se hace, especialmente en sus versiones anteriores. Eso provoca que muchas veces se desarrolle software de baja calidad o simplemente cueste más tiempo, dinero, etc... conseguir calidad en un software.

Las personas que han desarrollado software bajo standares de calidad se dan cuenta de este tipo de fallas.

Y si te gusta la programación(como es mi caso) los errores, la mala praxis, etc... en que se incurre en visual basic saltan a la vista.
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?

Categories

RSS of the category Gnome
RSS of the category Mono
RSS of the category C#
RSS of the category Programming
RSS of the category Mozilla
RSS of the category Web Development
RSS of the category Security
RSS of the category Open Source
RSS of the category Engineering
RSS of the category Misc
RSS of the category Politics

Contact with me:
aaragonesNOSPAMes@gnNOSPAMome.org

Archive
My Photo
Name:
Location: Hong Kong, Hong Kong
Follow me on Twitter