Primer asalto: VB.NET contra C#

Publicado 5/5/2008 12:05 por Rafael Ontivero

Mañana por la tarde se va a desarrollar un evento por difusión Web que seguro no va a dejar indiferente a nadie, ya que, aparte del tema, dos pesos pesados del desarrollo van a pelearse para dirimir cuál de los dos lenguajes estrella del .NET es el mejor. El que quiera suscribirse al evento, que no es presencial, puede hacerlo aquí.

Los integrantes del evento son Guillermo Som, alias El Guille y Marino Posadas, ambos MVP de sus respectivas áreas. Y la batalla promete ser de proporciones épicas (un pajarito me ha dicho que Guille va a llevar un BFG que ha conseguido sustraer de los almacenes secretos de Doom en Marte, y que cuenta con casi mil cargas). De Marino no sé nada, pero seguro que se ha traído un par de Estrellas de la Muerte al completo...

...

¿Qué? ¿Ah, si? Pues vaya. Que no, que esto no va de liarse a mamporros. Que se trata de una charla amigable, o al menos así se espera que sea. Yo por si acaso me llevaré la armadura de protección de Luis Wu, pero que conste que es sólo por si acaso. :-)

Y no pienso perdérmelo, desde luego que no. Aunque en otro WebCast en el que me suscribí no pude entrar por temas del Passport, que no me funcionaba bien... Vamos, perderme la oportunidad de lanzar alguna puya hiriente a la altura de los fondillos... :-D

...

Bueno, ahora en serio. Preveo que va a ser un evento que uno no debería perderse por nada del mundo. Oír hablar a Guillermo es un placer superior a leerlo, y Marino tampoco le va detrás.

Pero el motivo de esta entrada no es dar jabón a nadie. Es emitir mi opinión personal sobre el tema, o más bien ampliar (y confirmar) las opiniones de otros que ya las han emitido.

Antes de seguir, el lector debería echarle un vistazo a esta entrada de Jorge Serrano y a esta otra de Sergio Tarrillo. Comulgo con ruedas de molino con ambas, pero me gustaría ampliar un poco el tema, y de paso barrer para casa.

Jorge ha dicho que los lenguajes en .NET son un skin sobre el propio .NET, lo que es verdad hasta cierto punto, o al menos puede serlo en el caso de C# y VB.NET (no puedo opinar con motivo de causa ya que desconozco el VB.NET por completo, aunque no hay motivo para dudar de las opiniones de ambos), pero desde luego no lo es en el caso del C++/CLI.

Por desgracia, pese a las afirmaciones de Microsoft de que C++/CLI seguirá siendo un lenguaje de primera dentro de la plataforma .NET, no es cierto. Y no lo es porque no soporta WPF, ni creo que WCF ni WWF, que son las tecnologías disponibles y emergentes en el .NET 3.5. Y que conste que las máquinas de estados son una de las cosas más utilizadas dentro de C++ como lenguaje de sistemas (lo digo por WWF).

Si he comprendido bien la tecnología WPF, podría ser el sustituto de las plantillas de recursos del C++ tradicional, ya que funciona de manera similar pero con mucha mayor potencia. Es decir, un cuadro de diálogo nativo no es más que un bloque de código binario que lo describe y que Windows interpreta. WPF es lo mismo, pero integrado dentro de una aplicación .NET. Mientras que el recurso nativo a la hora de crearlo es un fichero de texto con una serie de comandos, el de WPF, siendo XML, tiene la misma funcionalidad (o mejor dicho, más funcionalidad). Quizás sea la tecnología del futuro, cuando Windows sea .NET de verdad (quizás dentro de tres o cuatro versiones más como poco). Y podremos olvidarnos del aborto de Windows Forms (*).

Bueno, pues siendo C++ el lenguaje de sistemas para .NET, se queda sin eso, y sin muchas otras características.

Pero volviendo al tema que nos ocupa, con C++/CLI se pueden hacer cosas que no es posible hacer con C# y supongo que tampoco con VB.NET, entre las que destaca la destrucción determinista. También es mucho más fácil (y rápido, tanto en tiempo de desarrollo como de ejecución) la interoperabilidad con código nativo, sobre todo si tenemos el fuente y podemos recompilar.

De ahí que quiera matizar un poco el tema. Igual que el C++/CLI es más adecuado para los propósitos arriba citados, y teniendo en cuenta que el compilador está a años luz por delante del de C# y supongo que del de VB.NET, quizás debamos añadir que a veces lo mejor es elegir el lenguaje más adecuado a la tarea. La pega, como ha dicho Sergio en otro contexto pero que también se puede aplicar a este, es que debes sentirte confortable con el C++/CLI, y eso requiere un esfuerzo mucho mayor que para C# o VB.NET...

Y ahora déjenme tomarme mi pastilla roja: ¡¡C++/CLI forever!!

(*)PS: El comentario de Periquito me ha hecho reflexionar un poco... no por el hecho de afirmar que Windows Forms sea un aborto, que lo es, sino por no dar algunas razones. Vamos allá.

  • Windows Forms construye el aspecto visual a partir de un método llamado InitializeComponents(), que contiene un listado de código fuente. Pues bien, dependiendo de si los controles se construyen dentro de dicho método o fuera, se construirán de manera diferente y tendrán diferene aspecto visual y, de hecho, a veces no podrás construirlos fuera de ese método según quieras que estén o tengan los padres que desees.
  • Windows Forms no respeta la jerarquía de objetos. Es decir, los eventos tienen un parámetro que se llama Sender y que se supone representa al componente que ha generado el evento. Como los eventos se controlan a nivel de ficha (es decir, a nivel de la clase que representa a la ficha), bueno es saber quién ha disparado el evento, sobre todo con aquellos compartidos. Pues no, en muchos controles, Sender es la propia ficha, pero la ficha la podemos obtener mediante this, así que se trata de lo que yo llamo una chapuza y otros un desafortunado error de diseño.
  • ¿Dónde están los eventos de doble click en algunos controles? Esos eventos no se disparan. Entonces, ¿por qué están?
  • ¿Te gusta el diseñador visual? ¿Se te cae frecuentemente? ¿Va a una velocidad aceptable con fichas con muchos controles? Hablando en puridad, el diseñador no pertenece a Windows Forms propiamente dicho, pero se añade a la lista de problemas.
  • Algunos controles no funcionan bien (o al menos no lo hacían antes del SP1, ahora no lo sé) si se controlan por código. Intenta poner por código un Splitter en según qué posicion, cierra la ficha y vuelve a abirla. Hay varios controles complejos que hacen cosas raras si los controlas por código.
  • Velocidad. Son lentos, muy lentos, ya que se construyen en tiempo de carga por código y no hay una máquina binaria que los construya, y el pintado ya no digamos.
  • Seguro que hay más cosas, pero de momento creo que valen.
Comparte este post:

Comentarios

# re: Primer asalto: VB.NET contra C#

Monday, May 5, 2008 2:24 PM by periquito

Rafa, me encantan tus comentarios. Imagino que nunca dejan indiferente a nadie por ser un "transgresor" ;)

Windows Forms fue un adelanto aunque se quedaba corto en algunos aspectos y para otros se queda desfasado, como podria ser las interfaces enriquecidas, pero esto se puede decir que es algo posterior. Seguro que a muchos les ha ahorrado tiempo de desarrollo, tan mal esta?? como para llamarlo aborto?

# re: Primer asalto: VB.NET contra C#

Monday, May 5, 2008 4:54 PM by Rafael Ontivero

Periquito, he actualizado el texto.

A ver si se muestra (a veces pasa un rato) y te convence lo añadido.

:-P

# re: Primer asalto: VB.NET contra C#

Tuesday, May 6, 2008 9:24 AM by periquito

Has usado el FlowLayoutPanel? pues usa unos cuantos de ellos sobre un panel, por ejemplo, y ya verás qué rápido es hacer scroll y que bonito queda el flickering.

En ocasiones Windows Forms hace cosas raras al trabajar con colores que tienen transparencia.

Además de lo que has comentado tu, el modelo de diseño es bastante inflexible, intenta modificar el cs del diseñador, en cuanto hagas algún cambio visual studio te modificara el archivo y posiblemente tus cambios.

El diseñador "peta" de vez en cuando y a veces no basta con cerrar el form y volverlo a abrir, sino que tienes que reiniciar visual studio...

El scroll de algunos componentes (sino son la mayoria de los que disponen de esta funcionalidad) a veces no aumenta de forma correcta cuando añadimos nuevos controles al contenedor.

Si al final te voy a tener que dar la razón y todo. O tal vez es que ayer estuve demasiado contento al leer tu post... ;D

# re: Primer asalto: VB.NET contra C#

Tuesday, May 6, 2008 1:12 PM by Descontento

Me parece patético que a estas alturas, con la versión .NET 3.5 en la calle aún se hagan charlas como esta y se intente confundir, intencionadamente o no a la gente sobre si uno es mejor que otro basándose en la mayoria de los casos en absurdeces. Programa en lo que te sientas más cómodo y punto pelota..................

# re: Primer asalto: VB.NET contra C#

Tuesday, May 6, 2008 2:55 PM by Rafael Ontivero

Descontento, me parece que andas desencaminado... No sé el contenido de la charla, aunque hace como una semana que estuve con Guille casi un día entero y no soltó prenda, pero me apuesto lo que quieras a que el tema va de cómo hacer lo mismo con cada lenguaje, es decir, si la característica A no está directamente presente en un lenguaje, cómo llegar a simularla.

De todos modos, apenas faltan unas horas para saberlo.

# re: Primer asalto: VB.NET contra C#

Tuesday, May 6, 2008 6:16 PM by Descontento

Teniendo en cuenta a los ponentes, la verdad, mucho más no se puede esperar ...

# re: Primer asalto: VB.NET contra C#

Tuesday, May 6, 2008 6:42 PM by Miguel j

A ver como lo defiendes, tienes en el blog del Guille la noticia sobre de que van a hablar.

www.elguille.info/.../02_evento_secondNUG_mayo.aspx

""Nos desvelaran secretos y trucos de sus defendidos y veremos si es cierto aquello de que lo que se puede hacer con uno, se puede realmente hacer con el otro.""

P A T É T I CO.... primero deberían aprender de que hablan, dudo que alguno de los dos se hiciera una aplicación medio grande alguna vez en su vida y sino pregúntaselo

# re: Primer asalto: VB.NET contra C#

Tuesday, May 6, 2008 6:58 PM by Rafael Ontivero

Yo creo que os estais equivocando con el contenido del evento.

Lo mejor que podéis hacer es asistir y opinar.

# re: Primer asalto: VB.NET contra C#

Tuesday, May 6, 2008 9:30 PM by abreulj

Como lo dicen al principio del Post, dos pesos pesados VB vs C#, uno siempre elige sus cabaliitos de batalla, (el mio es C#),  pero de que se puede hacer de todo con ambos, eso que a nadie le quepa la menor duda.