¿Es el fin de C++?

¡El fin de C++ se acerca!

¿El fin de C++? ¡Con todo lo que hay hecho en C++! ¿Estás segura?

No, vale, no. En verdad, al igual que Kotlin ha supuesto una bajada en el número de proyectos desarrollados en Java, Carbón se postula como el lenguaje que tomará el relevo en el ecosistema de C++.

Pero Carbón no es un lenguaje usable aún. Creo haber escuchado a Bjarne Strostrup decir que el lenguaje aún estaba en un estado muy inicial.

Cierto.

Por supuesto, Jarne no ha sido solo el creador de C++, sino uno de los grandes propulsores y quien ayudó a su estandarización. Pero, ¿sabías que en un inicio Stroustrup hubiese preferido no hacer C++?

Antes de continuar, un inciso. ¿Te gustaría apoyar a nuestro canal? No olvides que puedes suscribirte y activar la campanita para no perderte futuro contenido. También se agradecen me gustas. Y además, si nos prefieres en formato podcast, podemos acompañarte desde Spotify. Ahora sí, continúa.

El origen de C++.

Entonces, Strauss-Ztrub no quiso hacer C++.

En varias entrevistas ha dicho que él necesitaba hacer una serie de programas con unas características muy concretas y que necesitaba un lenguaje muy específico.

¿Muy específico? ¿Cómo de específico?

Que tuviese unas características de orientación a objetos principalmente.

¿Te refieres a aquella metodología que vimos en el vídeo de Alan Kay? La que acuñó e implementó en Smalltalk.

Sí, justo a eso me refiero. El problema fue que Smalltalk no era accesible, principalmente por el precio de su licencia de uso. De hecho, lo comentamos también en el vídeo que hablamos de Erlang. Ericsson no consiguió acceso a hacer sus pruebas con Smalltalk y por tanto decidieron continuar con Prolog.

¿Es posible que el hecho de la inaccesibilidad de Smalltalk costase su poca adopción?

Este es un tema muy interesante, quizá para un futuro vídeo, pero no nos desviemos del asunto ahora.

Vale, volviendo al tema. Entonces, Strauss-Trupp no pudo conseguir un lenguaje con las capacidades de la orientación a objetos.

Parece que era un requisito en los laboratorios Bell, donde trabajaba, y ante la falta de lenguajes que cumpliesen sus necesidades, se lanzó a crear uno él mismo.

Estoy empezando a pensar que es una práctica bastante habitual. Esto también lo hicieron los chicos de Ericsson, ¿no?

Sí, es más habitual de lo que parece. Ahora que lo pienso, quizás podríamos hacer un top de lenguajes que surgieron porque no existía otro mejor.

¡Otra estupenda idea para un vídeo! Según los comentarios que haya a favor de la idea, lo hacemos. ¡Ya sabéis! ¡Dejad vuestro comentario!

Volviendo al tema, Strauss-Troub no consiguió un lenguaje que cubriera sus necesidades. Tuvo que hacer uno por sí mismo. Mismo. La pregunta es: ¿por qué C++?

Según cuenta él mismo, tenía en la oficina de al lado a chicos bastante inteligentes como Dennis Ritchie o Ken Thompson. Hacer una extensión del lenguaje C para incorporar esas características que le eran demandadas parecía lo más obvio.

Vamos, que tenía a quienes preguntar en caso de duda.

No solo eso, el lenguaje C tuvo mucho éxito tanto dentro como fuera de la compañía. Eso facilitó la aceptación y posterior adopción de otro lenguaje que estuviese basado en C.

¿Y por qué no le pusieron D? Sería lo más lógico sabiendo que C proviene de B, ¿no?

Esa carta la agotaron. Si hubiese escrito un lenguaje llamado D, hubiesen esperado un lenguaje completamente diferente y eso hubiese generado algo de rechazo. Se podría haber convertido en un estigma.

¿Un estigma? Nadie lo hubiese querido adoptar por miedo a que surgiese el lenguaje E?

Algo así. El nombre C++ fue una buena decisión y a la vez un nombre que evocaba al propio lenguaje C en su nombre, ya que el++ es un operador de incremento y en el lenguaje C se emplea para decir que una variable que antecede o precede será incrementada.

Un nombre nerd para el nuevo lenguaje.

Sea lo que sea, funcionó. Un lenguaje orientado a— Espera, espera, que C++ no era un lenguaje orientado a objetos.

¿Pero no hemos dicho que se extendió de C para añadir la orientación a objetos?

Una cosa es que un lenguaje sea orientado a objetos y otra es que tenga orientación a objetos.

¡Ah!

Esa no la vi venir. ¿Me lo puedes explicar un poco mejor?

Vale. Un lenguaje orientado a objetos debe especificar objetos y usarlos en su código. Es obligatorio. Mientras que un lenguaje con orientación a objetos tiene objetos pero son opcionales.

¿En C++ la orientación a objetos es opcional?

Sí, de hecho puedes escribir un código que sea de tipo C sin nada de objetos y funcionará.

Curioso.

Bueno, siendo así... Un lenguaje con orientación a objetos. Mucho mejor. Una de las críticas de Alan Kay a lenguajes como Java o C++ fue la forma en la que se implementó la orientación a objetos.

Pero es similar a sus ideas, ¿no? Tenemos clases, creamos objetos con atributos y métodos. ¿Qué está mal?

El principal factor de la orientación a objetos era el intercambio de mensajes. Cada objeto debe ser independiente en memoria y en ejecución y debe enviar un mensaje a otro objeto. La ejecución de métodos, que no dejan de ser funciones con contexto, rompe con esta idea.

Pero la implementación de los mensajes agregaría mayor complejidad, ¿no?

En verdad, ese fue el principal punto a favor de la implementación realizada por Stroustrup. Sus ideas se alejaron de las ideas de Smalltalk y de Alan Kay, pero se acercaron a la idea de C de un código mucho más eficiente y más rápido.

Más rápido y eficiente, suena bien. ¿Este lenguaje entonces cubría las necesidades requeridas? ¿Para qué se requerían?

La tesis doctoral que escribió Stroustrup se basaba en Simula. A Stroustrup le gustaban esas ideas porque consideraba que eran necesarias para escribir código escalable.

¿Código escalable? ¿Qué quiere decir eso?

En este caso escalable tiene que ver con los equipos de trabajo, es decir, que muchas personas puedan cooperar en escribir un solo programa, y de hecho lo querían emplear para agregar capacidades de computación distribuida a UNIX.

¿Es que el lenguaje C no podía hacer esto?

No de forma fácil. La idea de C++ era agregar las características necesarias para simplificar la creación de código, así que tomaron ideas no solo de Simula y C, sino también de otros lenguajes como Ada, CLU, Algol 68 y ML. Las características de C++. Las características enumeradas de C++ parecen una lista de deseos.

O la carta para los Reyes Magos.

Te puedes hacer una idea, porque no solo incluían características de orientación a objetos. Agregaron características muy dudosas en cuanto a claridad, simplicidad o buenas prácticas en el código.

¡Uuuuh! ¡Empezamos fuerte! Cosas malas, trapos sucios, salseo... Ejem. ¿Puedes poner un ejemplo?

La herencia múltiple. En los libros de programación siempre ponen el ejemplo de la catalogación de los animales. Creando la clase de animales y en herencia se crean las clases mamíferos, ovíparos, y en herencia de mamíferos la de perro y gato, y de ovíparos la gallina y paloma.

Eso parece herencia simple porque cada clase hereda de una sola clase, ¿no?

Exacto. El problema vendría si definimos la clase ornitorrinco. ¿Qué hacemos que herede de mamífero y ovíparo?

No sé, no me parece correcto.

Ni a ti ni a nadie le parece eso correcto, pero ahí está la característica.

¿Qué otras características pueden considerarse malas prácticas? No te quedes solo en esa.

La sobrecarga de operadores.

¿Un operador como la suma o la multiplicación?

Sí. En caso de definir una clase para números complejos llamada Complejo, podemos sobrecargar el operador de la suma y hacer que cuando un complejo se sume a un número la suma se haga de forma compleja según las matemáticas.

Esto no suena muy descabellado.

Aunque este ejemplo no tiene nada de malo y puede ser perfectamente válido, la sobrecarga que se puede hacer de los operadores puede romper de alguna forma la comprensión que tenemos de la suma.

¿Como los retos de inteligencia que hay en las redes sociales donde reinventan los operadores para hacernos adivinar un número?

Algo así. El trabajo de escribir código se puede convertir en un desafío constante.

Pero entonces, ¿el lenguaje en sí es una pesadilla? ¿Cómo es que se popularizó?

Quien ha escrito código en C++ y después ha cambiado a otros lenguajes siempre extrae lo negativo antes, porque hay bastante negativo. Pero hay dos hechos innegables con respecto a C++ y ambos se pueden ilustrar con dos citas de Strauss-Zahl.

¿Dos citas? ¿Esta vez son aspectos positivos?

Bueno, en la primera cita Strostrup dice que con C es fácil dispararse en el pie. Es decir, con C es fácil cometer errores. Con C++ es más difícil dispararse en el pie, pero cuando lo haces te vuelas toda la pierna.

Bueno, si nos quedamos con la parte positiva, es más difícil cometer errores, ¿no?

La segunda frase viene a colación de la negatividad que estamos arrojando. Stroustrup decía que solo hay dos tipos de lenguajes de programación: unos de los que la gente se queja y otros que nadie usa.

Tiene sentido, si no usas un lenguaje puedes tenerlo muy idealizado.

Ascenso de C++. Desde que se publicó la primera versión de C++ en 1985 no ha dejado de crecer.

Aunque su segunda versión salió en 1989 y las siguientes han llegado con cuentagotas. ¿No se le dedicaron muchos recursos?

Uno de los problemas de C++ es que es un lenguaje muy complejo. Cada característica tiene el potencial de romper el código antiguo. En las primeras versiones, dada su pequeña adopción, no era problemático, pero a partir de 1998 cada característica ha tenido que ser probada al máximo para evitar problemas.

Entonces, ¿siguen publicando mejoras y nuevas características al lenguaje? Si va mejorando... ¿Por qué tanta queja?

En principio porque C++ no es un lenguaje fácil de programar.

Pero puedes optar por otro en caso de querer algo más fácil, ¿no?

Sí, pero si la compañía para la que trabajas es Google y tiene millones o miles de millones de líneas de código escritas en C++, entonces no puedes simplemente cambiar el lenguaje.

¿Google tiene miles de millones de líneas escritas en C++?

No solo Google, también otros como Microsoft.

O sea, que sucede como con COBOL, ¿no? Quieren cambiar pero no pueden.

En algunos casos, como en Google, sí que quieren cambiar. Hay otros casos donde les gusta la dinámica tal y como está y no quieren realizar cambios.

¿En otros casos como Microsoft no es un problema?

Hay empresas donde el código no suele perpetuarse durante demasiado tiempo. Microsoft son expertos en reescribir grandes proyectos desde cero. Si siguen eligiendo C++, no es porque están atados a él o porque no puedan cambiar, sino porque es el mejor que se adapta a sus necesidades. La llegada de Carbón.

Parece que Carbón se postula como posible sucesor. Sin embargo, nos preguntamos: ¿Por qué Carbón podría suponer un cambio para C++ ¿Y no otros como Rust o Go que llevan más tiempo compitiendo?

El gran problema de migrar el código de C++ a otro lenguaje es reescribir. Rust y Go son lenguajes muy diferentes. La reescritura no es una simple traducción, hay que cambiar la forma en la que se hacen las cosas.

¿Y en Carbon no se cambiaría?

Carbon está diseñado para convivir con C++, por lo que si tienes un proyecto con miles de ficheros Y agregas Carbón a ese proyecto, cambias solo un fichero y todo funciona.

Vale, eso significa que con Carbón no cambias la forma de hacer las cosas.

En verdad sí.

¡Ya sí que no entendí nada!

Hay un factor determinante a la hora de migrar el código y el ecosistema.

¿El ecosistema?

Sí, se llama así a las herramientas que empleamos para convertir ese código fuente en el programa en ejecución.

De acuerdo. Supongo que Go y Rust en ese caso tienen un ecosistema diferente de C++.

Exacto. Si queremos migrar un proyecto de C++ a Rust, primero hay que crear un proyecto Rust, después comenzar a escribir el código en Rust. No se permite C++.

Entiendo. Es un cambio de todo o nada.

Carbon utiliza el mismo ecosistema que C++. El código se compila de forma compatible con C++. Y por tanto interactúan sin problemas.

Ah, el cambio es gradual. Así quedan más claras las ventajas. Pero, al ser Carbon otro lenguaje diferente o mejorado de C++, ¿no te parece que se estaría repitiendo la historia de cuando C++ fue creado a partir de C?

Es algo que aún no sabemos. Carbon está aún en fase de diseño y queda aún bastante para que sea una realidad. A día de hoy no sabemos si llegará a ser un reemplazo o un complemento para C++. Pero sí que hay gente descontenta con cómo funciona C++.

¿Y no hubo gente descontenta con C++ cuando se creó Java? Sí, pero... ¿Y no hubo gente descontenta con C++ e incluso Java cuando se creó C#?

Sí, ciertamente.

Por tanto, lo que está claro es que siempre va a haber gente trabajando en C++.

Es muy posible. No en vano C++ desbancó en 2022 a Java según Tío B. Conclusiones.

C++ es un lenguaje creado con una serie de características para hacer fácil la implementación de ciertos tipos de software, entre los que se suelen encontrar videojuegos y sistemas operativos principalmente.

Motores de videojuegos como Unreal lo emplean activamente.

Google también estuvo desarrollando su sistema operativo Fuchsia con C++.

Está claro que C++ es un lenguaje que está muy vivo y que ha influenciado a muchos otros lenguajes de programación.

Y vosotros, ¿qué pensáis?

¿C++ ha sido menospreciado a lo largo de su historia o por el contrario se le ha sobrevalorado? ¿Java y C# constituyeron un verdadero desafío o Rust y Go son los que realmente han constituido el verdadero desafío? Déjanos tu comentario.