El rey ha muerto. ¡Viva el rey!

Justo hace un rato me he enterado de una noticia que, espero, sea para bien y no para mal, porque si no, éramos pocos y parió la burra.

¡Borland ha vendido, definitivamente, su división de desarrollo!

La compra una empresa que se llama Embarcadero Tecnologies y que se dedica a la creación de herramientas multiplataforma para bases de datos. La noticia se puede leer aquí, y sólo con el primer párrafo es suficiente.

Considero que puede tratarse de una noticia preocupante en extremo. Veamos quién compra. Una empresa multiplataforma de bases de datos. Para qué le sirve C++ Builder. Pues para nada. ¿Y Delphi? Pues tres veces lo mismo. Ahora bien, JBuilder, el IDE para PHP, eso sí que es interesante.

Triste y decepcionante. Adiós Delphi, competencia de Visual Basic. Adiós C++ Builder, competencia de Visual C++.

Qué triste…

Pero a lo mejor no, quizás Embarcadero + CodeGear le den caña a Delphi y a C++ Builder. Quizás vuelvan a reinventar, a innovar de igual modo que lo hacían hace unos años, sorpendiéndonos con productos maravillosos como C++ Builder, Kylix,… Y quizás le den caña a Microsoft y la fuercen a espabilarse como ya hicieron en su momento, y que de una vez saque un Visual Studio sin 40.000 bugs reconocidos, que no reviente cada dos por tres, quizá…

Qué bonito es soñar…

Primer asalto: VB.NET contra C#

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… 😀



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.