¿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.



10 comentarios en “¿Por qué C++ Builder?”

  1. Dentro de la multitud de herramientas para C y C++, sin duda la mejor con muchísima diferencia es C++ Builder. Está a años luz por delante de todos los demás IDES. Unir la comodidad de la VCL con la potencia de C++ es algo que pocos pueden hacer (hacerlo bien, me refiero).

    Muy buen artículo y muy buen explicado, como es habitual en ti cuando hablas de informática, por cierto.

    Respecto a Lazarus, sabes que suelo hacer bastantes cosas con él, y en lo personal solo lo uso cuando me apetece cambiar, o para programas «basurillas» que considero no importantes. El gran problema de Lazarus es que no puedes fiarte de él, tiene muchos errores e incluso algunos de sus componentes de la paleta visual, cuando los metes en el formulario el depurador «traga» sin problemas, pero al ejecutarlos cascan. En lo personal no lo considero un competidor de Delphi, a no ser que lo mejoren y mucho. Por otro lado, también sabes que es notoriamente más lento. También tiene fallos en el diseñador de formularios (la rejilla se la he tenido que desactivar, a veces se vuelve «loca»), y cosas por el estilo que te hace comprobar al poco tiempo que están aún muy verdes. Obviamente la intención es buena, y un aplauso para ellos (bastante hacen haciéndolo gratis), pero a la hora de hacer una aplicación seria, yo no me confiaría a Lazarus.

  2. Coincido en todo lo que dices bianamaran. C++ Builder es el mejor IDE RAD que existe, tal vez porque es el único. En el pasado hubo algún intento de liberar junto a Watcom, también su herramienta RAD: Optima/Power++ que sin embargo quedó en nada. Es una lástima puesto que a finales de los 90 Optima++ tenía muchísimo potencial.

    Respecto a Delphi no tiene rival para aplicaciones Win32 y Win64. Con cada vez más tecnologías basadas en el Bytecode, y la muerte de Visual Basic, si queremos código nativo y visual, probablemente Delphi sea el IDE más productivo.

    Estoy de acuerdo contigo también en Lazarus. Un esfuerzo loable, que de momento sólo está bien por la compatibilidad con otras plataformas. Esperemos que Lazarus evolucione y eso fuerce a Embarcadero a tener que innovar. Echo de menos aquellos tiempos de Borland.

  3. Amén.

    (No obstante, el precio que tiene ahora el producto, queda completamente fuera de cualquier principiante o desarrollador independiente).

  4. El tema de los precios de las licencias es algo de lo que en Embarcadero son conscientes rfog. La dificultad estriba en diferenciar los usuarios que lo usarán gratis de aquellos que lo usarán con fines comerciales.

    Para ello pusieron a disposición las ediciones Starter que son gratuitas, no obstante, al estar tan recortadas salvo para fines de aprendizaje no tienen demasiada utilidad.

  5. Muy buen articulo Guti! Muy interesante el repaso histórico.

    Creo que alguna vez ya lo comenté en el pasado, pero tus articulos donde relatás la historia y evolucion de los compiladores, son muy interesantes.

    Saludos y gracias por compartirlo.

  6. En visual c++ no pude hacer mucho, por eso me pasé a VB, hasta .Net la dependencia de librerías era la muerte, ahora .Net resuelve eso precisamente teniendo .Net instalado, que está por default desde windows xp, pero si no está pues he ahí el problema.

  7. Distribuyendo todos los dlls se resolvía el problema, cierto, hice eso. Lazarus no lo he usado, programé un poquito en una versión de delphi que venía de regalo con una revista de informática allá por el año 2000 (uhhh), pero creo que era una versión muy viejita y no llegué muy lejos. De ahí me dediqué a VB 5/6 y luego el paso a .net

Deja un comentario