¿Por qué C++ Builder?

Empecé usando C++ Builder en 1996 con la versión 1.0, muchos lo conocíamos todavía como Ebony, el nombre en clave del producto. Desde entonces, he sido un apasionado de este entorno de desarrollo, en realidad ya lo era antes con Turbo C, lo que no dejan de ser un argumento más en favor de mi nombramiento como Most Valuable Professional en Embarcadero Technologies.

En aquellos años, la programación Windows era muy tediosa. Si en algún momento habéis programado para Windows de verdad, os sonarán los conceptos de bucle de proceso de mensajes, identificador de ventana, y aún recordaréis muchas de las funciones de su API. Todo cambió cuando en 1991 apareció Visual Basic, un proyecto que permitía desarrollar aplicaciones Windows dibujando sus componentes, un paradigma que luego sería conocido como RAD (Rapid Application Development), y que mediante el uso de conceptos como formularios, controles y eventos permitía que el programador se centrase en el código en si mismo, reduciendo enormemente el esfuerzo necesario para componer la interfaz de usuario.

Lamentablemente, Visual Basic no había surgido como un entorno de desarrollo ni como un lenguaje de programación, sino que era solamente una herramienta para la creación de prototipos iniciada en 1987 (se llamaba Tripod y la escribió Alan Cooper). Para hacer breve la historia, digamos que en 1988 Bill Gates la vio, y decidió modificarla para ser un entorno de desarrollo. Juntó Embedded Basic que se había creado para el proyecto Omega que se canceló (un ambicioso proyecto previo a Access que pretendía combinar lo mejor de éste, con lo que luego sería SQL Server). El caso es que gracias a aprovechar código ya existente, pudieron lanzar al mercado Visual Basic en un tiempo récord. Su concepto era tan innovador, que rápidamente fue un éxito. Ahora, programar para Windows era algo que podía ser tan sencillo, como antaño sobre DOS.

Las ventas superaron con creces las expectativas de Visual Basic, y se convirtió en un estándar de facto que duraría casi una década. Empezaron a crearse aplicaciones cada vez más complejas con VB, y fueron descubriéndose las carencias debidas a su origen. Visual Bsaic era un lenguaje interpretado, así que era bastante lento, algo que no cambiaría hasta 1997 con Visual Basic 5, y que ya generaba código nativo, tampoco es que fuera un alarde en cuanto a rendimiento, pero comparado con sus predecesores la mejora fue notable.

Había un hueco para la competencia, y éste se llenó de dos formas. Por un lado con PBWin de PowerBasic, que careciendo de todas las funciones RAD, si que generaba código nativo muy eficiente y compacto, y que permitía que los desarrolladores escribieran en PB las partes críticas de sus programas, mientras que el resto seguía siendo VB.

Pero el más importante fue Delphi que apareció en 1995. Dos años antes que Microsoft fuera capaz de hacer que Visual Basic generase código nativo, Borland lo logró con Delphi. El concepto de Delphi era muy similar al de VB. Un diseñador de formularios visual, un modelo de componentes que ellos llamaron VCL, y todo ello combinado con el lenguaje de programación Object Pascal que tan bien conocían de los tiempos de Turbo Pascal y Borland Pascal. A nivel de lenguaje, Delphi era mucho más potente que VB, y también más complicado, lo que causó que sólo una parte de los desarrolladores VB se pasaran a Delphi. Aquellos que necesitaban rendimiento, y aquellos que estaban familiarizados con el lenguaje Pascal.

Incluso en el tiempo en que Microsoft Visual Basic logró generar código nativo, el de Borland Delphi era más eficiente, pero además contaba con una importante ventaja. Delphi podía evitar el uso de runtimes o dependencias externas. Tal como ocurría en el pasado con MS-DOS, en Delphi podíamos enlazar nuestros programas estáticamente, así acabábamos teniendo un ejecutable único (standalone), con todas sus dependencias incrustastas en tiempo de enlazado. En Visual Basic eso nunca fue así, recordaréis los habituales MSVBVMxx.DLL que contenían las bibliotecas dinámicas con los runtimes, y que eran necesarios con los ejecutables de VB para que pudieran funcionar. Un hecho sorprendente, puesto que ya en los tiempo de QuickBASIC muchos años atrás, existía la posibilidad de enlazado estático.

Estamos ya a mediados de la década de 1990, y Delphi ofrece un nivel de rendimiento nunca antes visto en Visual Basic. Pese a que Delphi era capaz de solucionar el 80% de las necesidades en cuanto a desarrollo de software, era insuficiente en determinados tipos de programas en cuanto a eficiencia y potencia. Generalmente software de bajo nivel que seguía escribiéndose en lenguaje C.

En 1996 aparece Power++, un entorno RAD que partía de una inmejorable base. El premiado y eficiente compilador de Watcom C/C++ considerado el más eficiente del mercado, junto con un entorno visual. Pese a sus grandes posibilidades, no llegó a cuajar, tal vez sus características RAD estaban algo lejos todavía de lo que ofrecía Delphi o VB, o la enorme cantidad de bugs en las primeras versiones desalentaron a los programadores.

Llegamos al punto en el que comenzaba el artículo, en 1997, Borland decide hacer los mismo que Optima++, crear un entorno RAD basado en el lenguaje de programación C++. Sin embargo toma una decisión que después se demostraría clave. Aprovechar su experiencia con Delphi, y hacer que el modelo de componentes VCL, fuera el mismo que el de Delphi. Ello acortó tiempos de desarrollo, costes, y redujo la posibilidad de errores. Por fin había una herramienta única en el mercado, ofreciendo:
1) Desarrollo RAD.
2) Lenguaje C++.
3) Generación de aplicaciones nativas.
4) Enlazado estático.

No he hablado aún de Microsoft Visual C++, que para mi fue la gran desilusión. Si en algún momento de sus más de 20 años de historia acompañado de la denominación Visual, esperábamos algo de tipo RAD, eso nunca fue así. Incluso con su librería de controles MFC (Microsoft Foundation Classes) no era visual. La creación del interfaz de usuario, implicaba escribir código, algo que con C++ Builder no era necesario. Se que desde hace años, Visual C++ permite RAD, pero solamente lo hace con los WinForms de .NET, así que por mucho que generemos código nativo, siempre dependeremos del .NET Framework para la parte visual, y del código manejado, al menos en esta parte. Perdemos la tercera característica, aplicaciones 100% nativas.

Incidentalmente el origen de Delphi, le aportaba una dualidad muy interesante a C++ Builder. Podíamos codificar a medio nivel como siempre se había hecho en C/C++, o bien a más alto nivel usando los tipos abstractos de datos de Delphi. Cadenas, listas, etcétera. Años antes de que existieran bibliotecas como Boost, y antes de que STL (Standard Template Library) se hiciera popular, podíamos trabajar transparentemente con el tipo de datos string en C++ (AnsiString/String), dándonos una enorme facilidad. En caso de ser necesario para interactuar con otros componentes, o por motivos de eficiencia, el clásico char* seguía estando ahí. Lo bueno es que ambos eran interoperables y fácilmente convetirbles. De manera que C++ Builder te permitía programar casi como en Delphi si querías, o al más puro C++ cuando necesitabas rendimiento.

Rápidamente se permitió que C++ Builder compilara también el mismo Pascal de Delphi. Podían aprovecharse módulos y componentes de Delphi en C++, y así ir convirtiendo aplicaciones existentes de manera progresiva.

No todo era perfecto, y el compilador de C incluído, el conocido por todos BCC, no estaba a la altura de sus competidores, ni en cuanto a optimizaciones, ni en cuanto a soporte de estándares. Era natural, Borland había quedado fuera del mercado de compiladores de C desde principios de los años 90, debiendo incluso recurrir a Intel para solucionarlo. Por otro lado, la librería de clases VCL, esa que decíamos que estaba escrita en Delphi, nunca llegó a reescribirse en C++ como se pensó inicialmente, por lo que a nivel de rendimiento, siempre estuvo algo por detrás de otras.

Después de aquello vinieron algunos años oscuros (2001-2005), y C++ Builder quedó estancado. Sorpresivamente, no aparecieron nuevos competidores, ni aparecieron nuevos que le amenazaran el liderazgo, por lo que cuando se volvió a retomar, tampoco había alternativas.

El tiempo fue pasando, y aunque a una velocidad desesperante para muchos, las novedades que tanto esperábamos fueron llegando. Tuvimos soporte Win64, y recibimos un nuevo y eficiente compilador basado en CLang, capaz de rivalizar con el resto de compiladores. Así que en lo que a mi respecta, salvo la VCL que sigue escrita en Object Pascal, del resto, puedo decir que es el entorno de desarrollo Windows perfecto. Me permite escribir en mi lenguaje favorito (C/C++) con el que verdaderamente disfruto, y a la vez ser altamente productivo gracias a sus ayudas visuales.

El IDE sigue siendo muy bueno como en sus tiempos dorados, claro que el resto han ido mejorando, y ahora están a la par con él, o incluso ligeramente por detrás. Para compensarlo, se ha ido extendiendo, no solamente a nivel de manejo de base de datos, otro nicho en donde C++ no estaba cubierto, sino en el desarrollo de aplicaciones multiplataforma, gracias entre otras cosas a FireMonkey, los componentes multiplataforma herederos de CLX.

Desde 1995 la mayoría de mis programas están en C o C++. Es el único lenguaje con el que dispongo de control total sobre lo que hace mi código, y el único que me permite el esmero en los detalles. FileOptimizer es solamente un ejemplo entre tantos otros.

Estamos en 2018, y si bien Delphi, el hijo predilecto, siete la amenaza de Lazarus, que en algunos aspectos es superior, el relegado C++ Builder sigue siendo el líder indiscutible, ofreciendo características que nadie más ofrece.