Comenzar\u00e9 por afirmar: esto no es ciencia exacta. Todo c\u00f3digo generado para .NET termina inevitablemente en MSIL, el cual es luego ejecutado por la m\u00e1quina virtual de la plataforma y optimizado mientras ejecuta, lo que permite que el programa aproveche al m\u00e1ximo los recursos del sistema y de la m\u00e1quina donde corre. Asimismo hace el programa f\u00e1cilmente portable de un sistema a otro. Esta t\u00e9cnica 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 \u00faltimos tres a\u00f1os.<\/p>\n\n\n\n\n\n\n\n
Dejando Java a un lado, lo anteriormente expuesto implica que no haya diferencia alguna al elegir VB.NET o C#. A\u00fan m\u00e1s: \u00bfpor qu\u00e9 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. \u00bfO no? En la pr\u00e1ctica algo tan aparentemente sencillo se complica un tanto si agregamos algunos factores m\u00e1s. C# es el lenguaje insignia de la plataforma .NET. As\u00ed me lo dijo Johan Lindfors, evangelista de Microsoft, cuando nos encontramos por primera vez en una de las ediciones de MSDN all\u00e1 por el 2002. Cuando Microsoft saca a la luz una nueva versi\u00f3n de su compilador C#, las novedades introducidas se ver\u00e1n realizadas en VB.NET luego de una versi\u00f3n m\u00e1s de la plataforma o del Visual Studio. En el mejor de los casos. Por ejemplo, la introducci\u00f3n de Generics en C# (Microsoft Template Library en C++ existe desde 1999)<\/em> con el Visual Studio 2005 y la versi\u00f3n 2.0 de la plataforma .NET no permiti\u00f3 a los desarrolladores de Visual Basic poder utilizar de inmediato las grandes ventajas que los Generics<\/em> ofrecen. Ese grupo se vio obligado a esperar la siguiente edici\u00f3n del Visual Studio o cambiar de lenguaje. As\u00ed de simple.<\/p>\n\n\n\n De todas maneras, \u00bfcu\u00e1l 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\u00f3n de ser imparcial. Revelar\u00e9 que prefiero al C# desde el punto de vista sint\u00e1ctico, ya que se asemeja al C\/C++, los cuales domino desde hace muchos a\u00f1os. El no haber trabajado nunca con Visual Basic facilita a\u00fan m\u00e1s mi elecci\u00f3n. El estatus de lenguaje insignia de .NET hace que mi decisi\u00f3n por el C# sea irrevocable. A diferencia de C# que naci\u00f3 con la plataforma, Delphi y VB han venido evolucionando y ajust\u00e1ndose 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\u00f3digo independientemente del lenguaje que utilice.<\/p>\n\n\n\n Para concluir mi primer art\u00edculo en esta revista ilustrar\u00e9 los Generics<\/em>. Todo el que conoce .NET sabe bien que cualquier clase hereda del tipo base System.Object alias object<\/em>. El primer ejemplo nos muestra c\u00f3mo podemos crear una lista de objetos y almacenar en ella cualquier tipo, ya que todos son descendientes de El siguiente ejemplo, basado en Generics<\/em>, nos ense\u00f1a a crear la misma lista, pero ya indicando el tipo que vamos a almacenar. Ya aqu\u00ed el compilador se encargar\u00e1 de impedir almacenar otro tipo que no sea el que hemos prometido almacenar. Tampoco ser\u00e1n necesarias las conversiones de tipos, lo que har\u00e1 la lista m\u00e1s r\u00e1pida y efectiva.<\/p>\n\n\n Como hemos visto, los Generics<\/em> ayudan a crear programas robustos con listas seguras. Su utilizaci\u00f3n no solamente est\u00e1 limitada a listas. Par\u00e1metros, m\u00e9todos, interfaces, delegates<\/em>, entre otros, son ejemplos donde los Generics<\/em> pueden aportar su granito de arena en la creaci\u00f3n y mantenimiento de sistemas de negocios, supervisi\u00f3n, etc.<\/p>\n\n\n\nobject<\/code>. \u00a1Superflexible! Peligroso a la vez. Cuando vayamos a buscar lo que tenemos almacenado, \u00bfc\u00f3mo saber d\u00f3nde tenemos un entero y donde una cadena? Podremos, pero ya tendremos que examinar el objeto almacenado. Encima de esto tenemos la \u00abperformance penalty\u00bb de In boxing<\/em> y Out boxing<\/em>. Toda conversi\u00f3n pasa por el tipo objeto, lo cual implica p\u00e9rdida de tiempo en operaciones pr\u00e1cticamente innecesarias.<\/p>\n\n\n\nusing System.Collections;\nArrayList list = new ArrayList();\nlist.Add(10); \/\/aqu\u00ed hemos almacenado un entero\nlist.Add(Math.PI); \/\/ aqu\u00ed hemos puesto el n\u00famero PI\nlist.Add("Esto me huele mal"); \/\/ y aqu\u00ed almacenamos una cadena\n\/\/ justo en este caso sabemos que el primer elemento a\u00f1adido es un entero\nint iFromList = Convert.ToInt32(list[0]); \/\/ Out Boxing al convertir object en entero\n\/\/ as\u00ed como el segundo elemento es uno de tipo double\ndouble dFromList = Convert.ToDouble(list[1]);\n<\/pre><\/div>\n\n\n\n using System.Collections.Generic; \/\/ aqu\u00ed le prometemos al compilador que vamos a crear una lista de enteros\nList<int> intList = new List<int>();\nintList.Add(30); \/\/ OK\nintList.Add(-1); \/\/ OK\n\/\/ la siguiente l\u00ednea dar\u00e1 error de compilaci\u00f3n ya que se trata de violar\n\/\/ el contrato con el compilador (hab\u00edamos decidido una lista de enteros, \u00bfno?\n\/\/ intList.Add(Math.PI);\n\/\/ error de compilaci\u00f3n al tratar de almacenar un double\n\/\/ la lista nos devuelve enteros, no hay necesidad de Out Boxing\nint iFromGList = intList[0]; \/\/ aqu\u00ed prometemos una lista de cadenas\nList<string> stringList = new List<string>();\nstringList.Add("Esta es la melod\u00eda que me gusta");\n<\/pre><\/div>\n\n\nPara saber m\u00e1s…<\/h2>\n\n\n\n