Comenzaré por afirmar: esto no es ciencia exacta. Todo código generado para .NET termina inevitablemente en MSIL, el cual es luego ejecutado por la máquina virtual de la plataforma y optimizado mientras ejecuta, lo que permite que el programa aproveche al máximo los recursos del sistema y de la máquina donde corre. Asimismo hace el programa fácilmente portable de un sistema a otro. Esta técnica ha sido copiada por Microsoft de Sun y de su comunidad Java que en esta materia llevan la delantera aunque la distancia entre los dos bandos ha disminuido considerablemente durante los últimos tres años.
Dejando Java a un lado, lo anteriormente expuesto implica que no haya diferencia alguna al elegir VB.NET o C#. Aún más: ¿por qué limitarnos solamente a C# o VB.NET? Delphi, por ejemplo, es uno de los lenguajes que compila para .NET. Las preferencias del programador son entonces las que deciden. ¿O no? En la práctica algo tan aparentemente sencillo se complica un tanto si agregamos algunos factores más. C# es el lenguaje insignia de la plataforma .NET. Así me lo dijo Johan Lindfors, evangelista de Microsoft, cuando nos encontramos por primera vez en una de las ediciones de MSDN allá por el 2002. Cuando Microsoft saca a la luz una nueva versión de su compilador C#, las novedades introducidas se verán realizadas en VB.NET luego de una versión más de la plataforma o del Visual Studio. En el mejor de los casos. Por ejemplo, la introducción de Generics en C# (Microsoft Template Library en C++ existe desde 1999) con el Visual Studio 2005 y la versión 2.0 de la plataforma .NET no permitió a los desarrolladores de Visual Basic poder utilizar de inmediato las grandes ventajas que los Generics ofrecen. Ese grupo se vio obligado a esperar la siguiente edición del Visual Studio o cambiar de lenguaje. Así de simple.
De todas maneras, ¿cuál es el mejor, C# o VB.NET? La respuesta no es exacta ni objetiva. Debido a que no soy periodista, no me veo en la obligación de ser imparcial. Revelaré que prefiero al C# desde el punto de vista sintáctico, ya que se asemeja al C/C++, los cuales domino desde hace muchos años. El no haber trabajado nunca con Visual Basic facilita aún más mi elección. El estatus de lenguaje insignia de .NET hace que mi decisión por el C# sea irrevocable. A diferencia de C# que nació con la plataforma, Delphi y VB han venido evolucionando y ajustándose a .NET y es por ello que sus sintaxis no me parecen tan limpias y elegantes como la de C#. Independientemente de todo ello, cada cual debe valorar sus preferencias, su experiencia y eventuales posibilidades de cambio de un lado hacia el otro sea cual fuere. A fin de cuentas, el hecho de escribir un programa en un determinado lenguaje no lo hace mejor que su autor. En otras palabras: un buen programador escribe buen código independientemente del lenguaje que utilice.
Para concluir mi primer artículo en esta revista ilustraré los Generics. Todo el que conoce .NET sabe bien que cualquier clase hereda del tipo base System.Object alias object. El primer ejemplo nos muestra cómo podemos crear una lista de objetos y almacenar en ella cualquier tipo, ya que todos son descendientes de object. ¡Superflexible! Peligroso a la vez. Cuando vayamos a buscar lo que tenemos almacenado, ¿cómo saber dónde tenemos un entero y donde una cadena? Podremos, pero ya tendremos que examinar el objeto almacenado. Encima de esto tenemos la "performance penalty" de In boxing y Out boxing. Toda conversión pasa por el tipo objeto, lo cual implica pérdida de tiempo en operaciones prácticamente innecesarias.
using System.Collections;//aquí hemos almacenado un entero
ArrayList list = new ArrayList();
list.Add(10);
list.Add(Math.PI); // aquí hemos puesto el número PI
list.Add("Esto me huele mal"); // y aquí almacenamos una cadena
// justo en este caso sabemos que el primer elemento añadido es un entero
int iFromList = Convert.ToInt32(list[0]); // Out Boxing al convertir object en entero
// así como el segundo elemento es uno de tipo double
double dFromList = Convert.ToDouble(list[1]);
El siguiente ejemplo, basado en Generics, nos enseña a crear la misma lista, pero ya indicando el tipo que vamos a almacenar. Ya aquí el compilador se encargará de impedir almacenar otro tipo que no sea el que hemos prometido almacenar. Tampoco serán necesarias las conversiones de tipos, lo que hará la lista más rápida y efectiva.
using System.Collections.Generic;
// aquí le prometemos al compilador que vamos a crear una lista de enteros
List<int> intList = new List<int>();// OK
intList.Add(30);
intList.Add(-1); // OK
// la siguiente línea dará error de compilación ya que se trata de violar
// el contrato con el compilador (habíamos decidido una lista de enteros, ¿no?
// intList.Add(Math.PI);
// error de compilación al tratar de almacenar un double
// la lista nos devuelve enteros, no hay necesidad de Out Boxing
int iFromGList = intList[0];
// aquí prometemos una lista de cadenas
List<string> stringList = new List<string>();
stringList.Add("Esta es la melodía que me gusta");
Como hemos visto, los Generics ayudan a crear programas robustos con listas seguras. Su utilización no solamente está limitada a listas. Parámetros, métodos, interfaces, delegates, entre otros, son ejemplos donde los Generics pueden aportar su granito de arena en la creación y mantenimiento de sistemas de negocios, supervisión, etc.
Black Hat por Email
Black Hat por Feed
No hay comentarios:
Publicar un comentario