1 puntos por GN⁺ 2024-12-25 | 1 comentarios | Compartir por WhatsApp
  • Desde C++11, el lenguaje y su ecosistema cambiaron mucho, y C++ se convirtió en un lenguaje que revive la diversión de programar en el proceso de crear y experimentar directamente
  • Durante un tiempo, muchos desarrolladores recordaron C++ como un lenguaje agotador por el exceso de metaprogramación con plantillas y una cultura centrada en estándares y patrones
  • Cambios como auto, nullptr, range-for, lambdas, <chrono>, smart pointers y <thread> transformaron mucho el estilo de programación en C++
  • El C++ moderno ofrece muchas opciones, desde sistema de archivos, gestión de paquetes, GUI/TUI, gráficos, matemáticas, IA y acceso a APIs del sistema operativo, lo que facilita crear directamente lo que uno quiere
  • Siguen existiendo desventajas como errores del compilador, herramientas de build, cumplimiento del estándar, complejidad histórica y RAII, pero las posibilidades creativas superan esas incomodidades

Por qué C++ volvió a ser divertido

  • Al crear un pequeño juego roguelike, se implementaron túneles para conectar habitaciones usando el algoritmo de Dijkstra para la generación del mapa, y en ese proceso C++ no estorbó demasiado la experimentación
  • También fue posible experimentar dibujando directamente la interfaz de usuario de FTXUI en una ventana de renderizado de SFML, y en el proceso se aprendió sobre el manejo de Unicode en C++
  • Estas tareas no fueron fáciles, pero sí fueron posibles en la práctica, y la sensación de “esta idea realmente funcionó” es lo que hace divertido a C++
  • La razón para empezar a programar no era generar más dinero para multimillonarios, pelearse con motores de renderizado ni satisfacer a las cúpulas de proyectos open source, sino el placer de implementar ideas

El cansancio de la época de la metaprogramación con plantillas

  • Desde fines de los años 90 hasta principios de los 2000, en C++ había una fuerte tendencia a aplicar la metaprogramación con plantillas a todo, y esa etapa se presenta como un punto de inflexión que volvió menos divertido a C++
  • Se debatía, por ejemplo, que sumar dos números con plantillas era más rápido que sumarlos directamente, pero aparece el caso de que la salida real en ensamblador era la misma
  • La percepción de que el comité de estandarización de C++ era poco proactivo para ofrecer una buena usabilidad a los programadores también amplificó la experiencia negativa
  • En esa época, C++ quedó en la memoria como un lenguaje con muchos corchetes angulares <> y sintaxis compleja, pero con poco beneficio a cambio
  • Java también pareció atractivo al principio por su garbage collector y su enfoque amigable para desarrolladores, pero luego generó un cansancio similar por el exceso de boilerplate y patrones de diseño

Cómo C++11 cambió la sensación del lenguaje

  • Las funcionalidades agregadas en C++11 se consideran un cambio que modificó mucho la percepción de C++
  • Las funcionalidades principales son las siguientes
    • auto: palabra clave de inferencia automática de tipos que reduce la carga de repetir el mismo nombre de tipo
    • nullptr: representación de puntero nulo que corrige problemas de NULL en C
    • range-for: bucle que, junto con auto, simplifica el recorrido de contenedores
    • lambda expressions: lambdas que pueden cambiar mucho el diseño y la usabilidad de las APIs
    • <chrono>: biblioteca de tiempo con seguridad de tipos que permite expresiones como 100ms
    • <regex>: funcionalidad de expresiones regulares incluida en la biblioteca estándar
    • unique_ptr, shared_ptr: smart pointers para manejar propiedad y conteo de referencias
    • <thread>: funcionalidad que incorpora multithreading al ecosistema base del lenguaje
  • C++11 cambió la filosofía y el estilo del lenguaje sin descartar las formas existentes, y en ese sentido se lo recibe de manera similar a ES6 en JavaScript

Opciones del ecosistema moderno de C++

  • El C++ actual incluye buena parte de las funcionalidades que se esperan de otros lenguajes
  • Las herramientas y bibliotecas presentadas como ejemplos son las siguientes
  • La calidad del ecosistema varía según el componente, pero en general se evalúa como superior a lo experimentado en JavaScript y Python
  • En particular, FTXUI y la STL se mencionan como ejemplos de buen diseño y usabilidad

La amplia posibilidad de implementación que crea la “diversión”

  • La razón por la que C++ es divertido no es solo que haya agregado funcionalidades modernas, sino la posibilidad de implementación de crear casi cualquier cosa
  • Las apps de escritorio pueden crearse usando fenster, SFML o Qt, o tratando directamente con APIs del sistema operativo
  • Para sonido, el rango de opciones va desde alternativas rápidas como SFML hasta herramientas comerciales como Wwise
  • Para gráficos 3D existen muchas opciones, como OpenGL, Vulkan, Direct3D y Ogre3D
  • En el área de matemáticas hay bibliotecas como BLAS, Eigen y GMTL
  • Aunque no exista la biblioteca necesaria, se puede crear accediendo directamente a la ABI de C o C++ y a las APIs del sistema operativo, y ese proceso de construcción directa se vuelve parte de la diversión

La libertad creativa de un lenguaje fuera de moda

  • Se evalúa que C++ tiene un lenguaje y un ecosistema de alta calidad, pero como no es un lenguaje de moda en este momento, recibe menos atención del tipo de personas que arruinan lenguajes
  • La comunidad de C++ se describe como un entorno que no interfiere demasiado sin importar qué se quiera crear
    • Se pueden intentar libremente proyectos como bibliotecas de matrices, bibliotecas GUI, motores de juegos o juegos extraños
  • El trabajo creativo necesita tanto una etapa en la que primero se sacan las ideas hacia afuera como una etapa posterior de crítica fría y mejora de calidad
  • En otros lenguajes, se considera que las organizaciones, el liderazgo y la presión de la comunidad obstaculizan la experimentación en las etapas intermedias de la creación
  • Las amplias posibilidades de C++ y su cultura relativamente menos propensa a imponer vergüenza pueden crear una experiencia creativa

Fortalezas de cppreference.com

  • cppreference.com se evalúa como documentación de programación de primer nivel entre los lenguajes usados
  • Sus ventajas son las siguientes
    • Todas las palabras clave y bibliotecas están organizadas como documentación de referencia
    • La mayoría de los elementos tienen ejemplos que funcionan en la práctica
    • Indica la versión del estándar de C++ en la que se introdujo cada funcionalidad
    • Enlaza con documentos del estándar y materiales de referencia relacionados
    • Tiene un buscador basado en DuckDuckGo, por lo que es fácil encontrar cosas aunque uno escriba mal o no conozca el término exacto
    • También explica conceptos importantes como Copy elision con ejemplos
  • Lo que le falta es una guía sobre cómo instalar compiladores en distintas plataformas
  • Como no hay tantos compiladores y plataformas de C++, también habría margen para agregar una guía de inicio

Problemas de C++ que todavía persisten

  • Esto no significa que C++ sea un lenguaje perfecto; como otros lenguajes, tiene muchos puntos incómodos
  • En Windows, configurar compiladores y herramientas de desarrollo por una ruta que no sea la de Microsoft es difícil, y para eso se creó directamente un script de instalación en PowerShell
  • Las principales incomodidades actuales son las siguientes
    • Más del 95% de los mensajes de error del compilador se consideran de los peores de la industria
    • Las herramientas de build son difíciles de usar, y también se sufrió un problema con Meson que ignoraba las indicaciones de paquetes instalados y usaba bibliotecas del sistema rotas
    • Faltan incentivos para lograr que los fabricantes de compiladores sigan el estándar
    • C++ es muy complejo por su historia, y conviven el viejo estilo de asignación en heap y raw pointers, el estilo de metaprogramación con plantillas, el estilo centrado en la stack posterior a C++11 y un estilo más nuevo centrado en struct
    • RAII a menudo estorba en situaciones de configuración realistas, y se considera necesario un punto intermedio entre los constructores de inicialización al estilo de otros lenguajes y el RAII actual
  • Aun con estas desventajas, las incomodidades de C++ no llegan al punto de arruinar la diversión, y C++ ya no es como la imagen del pasado de un lenguaje centrado en corchetes angulares y punteros
  • El código de layout de GUI de FTXUI es un caso que muestra una sintaxis tan moderna que, si uno no supiera que es C++, podría parecer otro lenguaje

1 comentarios

 
GN⁺ 2024-12-25
Opiniones de Hacker News
  • Estoy cerca de ser un hater de C++, pero eso es porque odio tener que trabajar con C++ en código laboral que necesita confiabilidad y con colegas en los que no se puede confiar del todo.
    En proyectos personales, ha sido uno de los entornos de programación más satisfactorios que he probado, y poder controlar la ejecución con un nivel de detalle tan fino es realmente emocionante.
    Dejé C++ hace unos 10 años y no pienso volver, pero en mis proyectos actuales la confiabilidad a largo plazo es lo más importante, así que Rust + CI/CD encaja perfecto.
    Aun así, extraño esa emoción de diseñar e implementar un programa para que se ejecute exactamente como yo quiero, y que eso sea gracias a mi pericia e intuición.
    ¿Querría que la gente con la que trabajo se moviera por esa motivación? Para nada, pero personalmente es una diversión inolvidable.
    El sistema de build y la gestión de paquetes son una pesadilla, el preprocesador parece una broma sádica, la sintaxis es horrible y en tiempo de ejecución hay demasiada basura que exige años de experiencia para no dispararse en el pie con una ametralladora.
    Pero, en cierto sentido, ese dolor aumenta la alegría de finalmente sacar un ejecutable envuelto en inteligencia, sangre, sudor y lágrimas.

    • Es una de las descripciones de C++ con las que más me identifico.
      Usé C/C++ durante varios años en el trabajo y no quiero volver.
      Pasé demasiado tiempo depurando código ajeno, lidiando con problemas de integración ambiguos y haciendo funcionar spaghetti de sistemas de build.
    • El trabajo también debería ser tan divertido como los proyectos personales.
      Siento que en los últimos 10 años la industria tecnológica perdió esa idea, y culpo a las grandes tecnológicas que meten a la mejor gente en prisiones para adultos con buena comida y sillas acolchadas.
      Las startups también se volvieron menos divertidas, y la industria de VC fomentó una ventana de pensamiento estrecha, con demasiadas startups clonadas que hacen lo mismo y demasiadas modas.
      Uso C++ en cada proyecto nuevo porque me da la confianza de que puedo construir lo que haya que construir cuando haga falta.
      Los frameworks, especialmente cuando tratan el núcleo del proyecto, muchas veces no se comportan como quiero, así que no me dan ganas de seguir usándolos.
      Si puedes construirlo tú mismo, constrúyelo; si no, usa un framework.
      Si puedes construirlo tú mismo, C++ es una herramienta excelente que puede hacer cualquier cosa y no se interpone en lo importante.
      Lenguajes como Rust pueden quejarse de que estoy haciendo algo peligroso, pero en C++ puedo expresar directamente el modelo que tengo en la cabeza.
      A veces pienso en punteros, y los punteros son una herramienta realmente buena.
      Recuperemos la diversión, no solo en la vida personal, sino también en el trabajo.
  • Este artículo parece algo confuso.
    Toca muchos puntos, pero es difícil extraer por qué eso lleva a la conclusión de que C++ es más o menos divertido.
    También confunde que llame al C++ moderno de calidad extremadamente alta y al mismo tiempo hable de problemas de legado generalizados y herramientas terribles.
    Dice que unique_ptr es excelente pero que realmente odia RAII, y también resulta extraña la afirmación de que la metaprogramación antes estaba en todas partes pero ahora ya no.
    Si miras concepts, no parece ser así, y la idea de que C++ tiene las mejores bibliotecas gráficas o que instalar Python es más difícil que C++ también parecen fijaciones del autor poco relacionadas con el argumento.
    Al final, parece que al autor C++ le resulta divertido por una combinación compleja de factores personales, y eso está bien.
    Por su rendimiento y su carácter técnico, también he tenido mis experiencias de programación más divertidas con C++, pero en el desarrollo de software real C++ es malo por muchas razones que ya conocemos.
    C++ es un lenguaje profundamente contradictorio, marcado por décadas de legado y política, e ignorar la realidad de C++ es el mayor error en las discusiones sobre C++.
    Mi actitud actual hacia C++ se parece más al cansancio, y ya no quiero seguir saltando los obstáculos que C++ ha puesto durante tantos años.
    No hace falta seguir golpeando a un caballo muerto desde hace demasiado tiempo; podemos dejar que C++ simplemente sea C++.

    • Creo que esa frase resume bien el punto del artículo.
      A mi parecer, más que confuso, el texto muestra que el autor se está divirtiendo y quiere compartir esa alegría lo más posible.
      No es tanto un ensayo argumentativo bien armado ni un texto que intente convencer activamente, sino algo más cercano a “si te identificas sin que tenga que convencerte, quizá tú también te diviertas”.
      Es totalmente comprensible que, si vienes cansado de recibir golpes de la realidad en el trabajo comercial, te parezca que no tiene sentido.
      Yo últimamente, justo con JavaScript, me estoy divirtiendo muchísimo, y si escribiera un texto parecido, seguramente alguien agotado por 10 años de JavaScript comercial lo leería igual de mal.
      Aun así, me alegra que el autor se esté divirtiendo y haya decidido compartir esa diversión.
  • Pasé 3 días enlazando estáticamente una dependencia de terceros en un proyecto C++ para que funcionara en Linux/Windows/macOS.
    Ese paquete no estaba en conan/vcpkg; solo había un repositorio de GitHub con una combinación rara de Makefile/cmake.
    Estoy lejos de ser experto en cmake/cpp, pero en la mayoría de los lenguajes modernos esto no sería un problema con cosas como pip install, cargo add, npm install o go get.
    Aunque leas de principio a fin un libro sobre los detalles de la semántica de C++, trabajar en un proyecto real sigue siendo doloroso.

    • Las dependencias y la cadena de herramientas de build de JavaScript son tan inescrutables como el Makefile más desordenado.
      Es sorprendente que hayamos terminado llegando a algo como los autotools versión JavaScript.
    • Me da curiosidad saber qué fue específicamente lo difícil.
      Compilar estáticamente código ajeno o modificarlo para que compile en otras plataformas a veces es complicado, pero el enlazado en sí normalmente se reduce a directorios de include, rutas de bibliotecas y especificar bibliotecas.
    • Visto al revés, si quisieras usar ese tercero desde otro lenguaje “moderno”, me pregunto qué mejoraría.
      Si nadie lo empaquetó para vcpkg/conan, probablemente tampoco esté en pip/cargo/npm.
      Si fue difícil en C++, en otros lenguajes podría ser mucho más difícil.
      Dicho eso, aquí también se ve que algunas partes históricas de C++, en especial la historia del build, están en un estado muy malo.
      Si está en vcpkg, la dificultad de instalación queda exactamente al nivel de otros ecosistemas.
  • Periódicamente intento trabajar en C++ en lugar de C, y siempre sigue un patrón parecido
    Aprendo una nueva técnica de C++, escribo código pensando que algo va a mejorar, me topo con errores del compilador y luego paso el resto del día aprendiendo por qué no puedo hacer lo que quiero
    Normalmente estoy atado a C++14, y algunos problemas se corrigieron en versiones posteriores, pero aun así
    De verdad me gustaría amar C++; en teoría ofrece un C más potente que debería aumentar la productividad, pero al final la carga cognitiva es tanta que por lo general termino usando “C con clases” y sigo adelante

    • Hay un punto en el que aprender es divertido, y parece que el autor original todavía está ahí
      En 2003 usé mucho C++ en tiempo real y lo odié, pero el año pasado escribí la mayor parte de mi código en C++ y por fin me empezó a gustar
      Las lambdas y auto fueron el punto de inflexión que hizo que dejara de odiar C++
      También usé un poco las plantillas, pero sobre todo para evitar llenar de ramas cada variante de la misma función
      Gracias a las lambdas pude escribir código como me enseñaron al principio los profesores de la familia Lisp con onda SICP
      Con unique_ptr, la asignación tampoco me resultó desagradable
    • He visto mucho código malo escrito por gente que acaba de aprender una función y quiere usarla
      No hay que hacer eso: primero hay que pensar cómo se va a usar el código y luego usar una función si resuelve el problema
      Es problema → solución, no al revés
      Por ejemplo, las plantillas de C++ suelen ser horribles, pero el duck typing en tiempo de compilación o agregar padding automáticamente con base en sizeof() a veces resulta muy útil
    • Mi experiencia con C++ fue exactamente así
      Al principio era programador de C# y estaba aprendiendo C por un proyecto embebido, y el flujo fue tal cual
      C++ tiene muchas funciones geniales que parecen potentes cuando encajan exactamente con la aplicación
      Pero cada vez que probaba una función nueva, lo que yo quería hacer siempre era un caso límite que no funcionaba en esa situación, y después de horas o días de intentarlo me rendía y simplemente lo escribía en C
    • C++, como la mayoría de las tecnologías, funciona mejor si uno invierte el esfuerzo de aprenderlo bien
      Claro que hay lenguajes como Python o Ruby que se salen un poco de esa tendencia
    • ChatGPT o Copilot ayudan mucho con esa parte
      Normalmente copio el texto del error y les pido que lo descifren
  • C++ es realmente divertido, y creo que las quejas de la gente dependen mucho del contexto
    Muchos desarrolladores de C++ odian el lenguaje, pero a veces ese odio está mal dirigido
    En realidad, muchas veces están lidiando con un producto legacy hecho por gente que no usaba muy bien el software
    A mí me pasó algo parecido con Rust: me asignaron a un proyecto Rust existente de la empresa, y dentro de una base de código vieja había muchas convenciones que chocaban entre sí
    Había tipos de manejo de errores que no componían bien, malas abstracciones de clases, bloques unsafe innecesarios, y fue uno de los proyectos más dolorosos que he hecho
    Es fácil culpar a Rust, pero en realidad era simplemente mal desarrollo de software
    Es cierto que C++ tiene defectos, pero buena parte del dolor que siente la gente viene de lidiar con mal código que sería un desastre escrito en cualquier lenguaje

    • En casi cualquier otro lenguaje salvo C, no estás invitando a una corrupción arbitraria de memoria cada vez que escribes v[x]=y
      En std::optional de C++, si llamas *v cuando v está vacío, eso se vuelve comportamiento indefinido
      El punto de un optional es contener un valor que puede estar vacío, así que cuesta entender por qué meter comportamiento indefinido en la operación más común cuando el optional está vacío
      Habiendo usado bastante C++, el problema es que todos los programadores del proyecto tienen que ser 100% perfectos el 100% del tiempo
      Puedes ejecutar verificadores de memoria y el modo de depuración de STL, pero si no los ejecutas también en release, tienes que esperar que tu suite de pruebas toque todas las cosas raras que podría hacer un usuario tonto o malicioso
      En una época en la que el software se volvió tan importante, y Rust parece acercarse al rendimiento de C++, me pregunto si vale la pena usar un lenguaje en el que muchas funciones básicas son muy difíciles de usar de forma segura
      Incluso sigue empeorando: llamar a un std::function vacío lanzaba un assert, pero el nuevo std::copyable_function convirtió eso en comportamiento indefinido
    • Me cuesta estar de acuerdo con eso
      El sistema de tipos es molesto y, aun así, no obtienes una verdadera seguridad de memoria
      El parsing más irritante es realmente irritante, y también conserva rarezas heredadas de C como el decaimiento de punteros
      Encima le agrega soluciones nuevas como std::array, pero no logra eliminar la forma anterior
      También es un problema que siga dependiendo del preprocesador para imitar un sistema real de importación de módulos, lo que trae aparejados rodeos como la organización del código de clases o el modismo pimpl
      En esencia, tiene tantos defectos, y tan grandes, que ya es difícil encontrar la belleza dentro de él
    • Es cierto, pero cuanto más complejo es un lenguaje, mucho más fácil es crear un desastre imposible de entender
      En cambio, un proyecto en un lenguaje blub sencillo suele ser bastante fácil de descifrar, sin importar el estado de la base de código
    • Aunque ya es antiguo, vale la pena ver el FQA de C++, que es bastante gracioso: https://yosefk.com/c++fqa/
  • Me alegra que alguien encuentre placer en C++, pero personalmente, después de haberlo sufrido durante más de 20 años, ya creo que hay que terminar con C++
    Es simplemente un desastre
    Si de verdad necesito control de bajo nivel, uso C aunque tenga sus defectos; si no, Rust, Python, etc. me hacen mucho más feliz

    • De acuerdo
      Aun así, C++ seguirá existiendo
      Hay demasiado código escrito en ese lenguaje, sin duda es una buena habilidad para aprender, y también hay trabajos que pagan muy bien
      Para mí, el lenguaje se interpone demasiado y se siente excesivamente complejo
      Conozco el discurso de que “C++ moderno” es excelente, que no hace falta aprender las versiones viejas y que con cada versión nueva se vuelve más simple
      El problema es que las bases de código que te tocan en la práctica no son C++ moderno
      Usan todas las funcionalidades que han salido hasta ahora, son difíciles y están llenas de trampas
      Quien haya usado C++ durante años solo en su propio proyecto puede desarrollar cierto nivel de expertise y volverse inmune a la complejidad, pero no es realmente un buen lenguaje
    • Una de las cosas que con el tiempo hizo a C++ más tolerable es que se volvió más fácil reemplazar naturalmente la mayor parte por implementaciones que se comportan como uno espera y cuyo comportamiento está suficientemente definido
      Cosas como cambiar los tipos de datos principales, la biblioteca estándar, etc.
      Especialmente desde C++20, la base para esos reemplazos se siente bastante nativa y expresiva
      Muchos de los proyectos nuevos en C++ que veo adoptan con fuerza esta dirección
      Poder crear con facilidad un lenguaje específico de dominio a nivel de sistema para una aplicación es una fortaleza de C++
    • En un proyecto derivado de Ultima que estaba haciendo con C++/SDL2, solo tomé algunas funcionalidades de C++
      Lamentablemente no lo terminé, pero recuerdo clases, std::function, std::unordered_map, std::string y std::unique_ptr
      Me cuesta imaginar leer código ajeno si no está escrito en un estilo parecido
      Como no escribo programas grandes profesionalmente, lo más difícil fue ir más allá de los patrones de programación como el patrón Visitor
      Me habría gustado que C++ se hubiera detenido en C++11
      Parece que ahora el comité quiere meterlo todo en el lenguaje, y C++ se ve como un megagigante que soporta todos los estilos de programación de nicho
    • C++ es un desastre total
      Pero es un desastre divertido, y me gusta escribir en C++
      A veces eso importa
      Mi relación con Rust es mucho más fría
      Respeto Rust y, sobre todo en contextos donde es difícil defender el uso de C++ —como en el trabajo—, lo uso si creo que Rust es lo correcto, y considero importante lo que Rust hace
      Pero aunque hasta ahora he hecho bastantes proyectos en Rust, escribirlo me resulta aburrido
      En aspectos fundamentales es mejor, pero al menos para mí es menos disfrutable
    • ¿Rust no es también un lenguaje que intenta ofrecer el mismo control y bajo nivel que C?
      Si abres el sello de unsafe, puedes castear explícitamente enteros a punteros y, por ejemplo, controlar hardware mediante E/S mapeada en memoria, ¿no?
  • Este texto es una larga diatriba de alcance amplio, y solo las letras “C++” pueden activar a la gente y hacer que se ignore buena parte
    A mí también me pasa a veces
    Para las quejas, se puede saltar a la sección “It's Not All Puppies and Butterflies”
    Al autor le impresionó mucho C++11, y después de ignorar C++ a propósito durante casi 20 años, yo sentí algo parecido
    Está bien que haya presentado paquetes y bibliotecas con los que se puede jugar, pero aun así meter otra biblioteca en mi proyecto sigue siendo doloroso con frecuencia
    Me vienen a la mente los headers de un solo archivo
    FTXUI es interesante
    Y, de verdad, cppreference.com es increíble
    La documentación de Python también es bastante buena, pero nunca he visto una documentación tan buena como cppreference.com

    • cppreference.com, tal como su nombre indica, es excelente como documentación de referencia
      La documentación de Python está dispersa en varias partes, es incompleta en muchos lugares y carece de un estilo editorial consistente
      Pero, según el framework Diataxis, abarca bastante bien varios tipos de documentación, no solo referencia
      Quienes escriben esa documentación tienen en cuenta explícitamente ese framework para buscar maneras de mejorarla
      Aun así, sigue siendo un trabajo open source basado en voluntarios que se mueve casi del mismo modo que el desarrollo de código
    • Después de aprender C++ en la escuela y la universidad, pasé de inmediato a Python/JavaScript en el trabajo, y este texto llenó muchos huecos sobre C++ que no conocía
      Desde hace un tiempo quería acercarme más “al sistema”, y aprender Rust por mi cuenta tampoco ha sido fácil
      Al ver este texto, me da esperanza de que tal vez sea posible volver a aprender C++
      Hola, CMake… no, quizá debería decir Meson
  • Estoy de acuerdo en que C++ es excelente si un equipo talentoso sabe usar bien C++ moderno y empieza un proyecto nuevo
    Es un lenguaje divertido y potente; tiene buen rendimiento y, aunque es complejo, la depuración y la optimización son relativamente intuitivas
    Tuve la oportunidad de trabajar en una base de código de unos 5 años, escrita con estándares posteriores a C++11, y fue muy disfrutable por varias de las razones que menciona el texto
    En cambio, una base de código vieja que evolucionó durante 20 o 30 años, o una base de código que no haya sido mantenida por gente competente, será una experiencia completamente distinta

    • Empecé mi vida como desarrollador con PHP, haciendo temas personalizados de WordPress con plugins para tipos de datos especiales, y aprendí trabajando
      A los 21 años, la empresa me ofreció pagarme la matrícula, así que volví a cursar una carrera de ciencias de la computación, que más tarde cambié por informática
      El primer día de la clase de “Introducción a la programación”, en cuanto toqué C++, me enamoré
      Comparado con PHP 7, que usaba entonces, el sistema de tipos, la depuración y el ecosistema eran excelentes
      Con permiso de mi gerente, creé APIs basadas en C++ para algunas aplicaciones existentes de la intranet, para que PHP las llamara por websockets, y pude aprovechar el sistema de tipos y el rendimiento
      Esos sistemas todavía se usan a diario en toda la empresa, y el mantenimiento tampoco fue un problema
      Incluso aunque corren en un entorno bastante peculiar llamado IBM Pase for i
      Ahora, después de haber usado Rust y Axum, para crear APIs así preferiría mucho más el ecosistema de Rust, pero C++ también merece reconocimiento
      Especialmente si vienes de lenguajes web como JavaScript sin TypeScript o PHP, es un lenguaje realmente excelente
    • Bajo la condición de una base de código vieja que evolucionó durante 20 o 30 años, o que no fue mantenida por gente competente, no se me ocurre otro lenguaje que no vaya a ser horrible
      De hecho, creo que preferiría C++ a varias posibilidades que puedo imaginar, por ejemplo C, Java o Fortran
      La excepción podría ser C#, pero no sé si ya es lo bastante viejo como para entrar en esa categoría
  • Aunque se diga que C++ incorporó expresiones regulares y que son bastante buenas, es difícil decir que std::regex sea buena.
    Como tiene mal rendimiento y poco soporte para Unicode, en general conviene evitarla.

    • El linter que usamos en mi empresa también obliga a no usar std::regex.
    • Me pregunto si habrá algún problema en la especificación que cause la degradación de rendimiento.
  • Aprendí C++ y también lo disfruté, pero no profundicé demasiado.
    Siempre me gustó más C y, de hecho, hay muchas bases de código de primer nivel que uno puede leer para aprender mejor C, como el motor de juego de Dune o utilidades de Unix.
    Últimamente estuve probando un poco Rust y ya no veo una razón fuerte para usar C++.
    La combinación de un sistema de tipos potente inspirado en la programación funcional y buen rendimiento parece difícil de superar; casi parece un lenguaje perfecto.
    Aun así, seguro hay razones de legado por las que hay que usar C++.
    Tal vez motores de juegos, programación embebida u otros tipos de acoplamiento con sistemas heredados.

    • En el trabajo alterno entre C++ y Rust y, sinceramente, en el C++20/23 moderno se están corrigiendo muchos puntos dolorosos prácticamente copiando a Rust.
      Si se trata de una base de código nueva en C++, se puede hacer bastante limpia.
      Pero a estas alturas no entiendo muy bien por qué alguien crearía software nuevo en C++.
      C++ tiene muchas molestias.
      La gestión de librerías/paquetes no está estandarizada, los headers duplican código y la biblioteca estándar depende de la implementación y es casi ilegible.
      El estándar tiene comportamientos extraños, la gente se apoya en comportamiento indefinido sin saberlo, hay problemas de uso antes de asignación, y las fugas de memoria por problemas de ownership y conteos de referencias incorrectos aparecen de forma sutil.
      Hay que hacer todo const en vez de que sea el valor por defecto; para garantizar noexcept hay que revisar las excepciones de todo lo que se llama, y los errores al trabajar con la biblioteca estándar son difíciles de leer.
      El código fuertemente orientado a objetos es, en la práctica, deuda técnica.
      El LSP de C++ no funciona de forma estructural revisando el árbol de sintaxis abstracta para encontrar definiciones como en Rust, así que navegar y entender la base de código es más lento.
      Rust da soporte explícito de primera clase a nostd, pero en C++ para desactivar la biblioteca estándar se necesitan flags específicos del compilador y es difícil verificar que se haya hecho bien.
      Por eso, la razón de usar C++ por sistemas embebidos me resulta poco convincente.
      En Rust también hay motores de juego como bevy, aunque todavía son nuevos, y si uno quiere puede integrar Rust al scripting de Godot.
      El audio de bajo nivel también es igual de fácil en Rust, y se puede manejar multiplataforma con un solo crate.
      En general, creo que el punto central es el código legado y la resistencia al cambio.
    • El legado es enorme en muchas dimensiones, no solo en apps escritas en C++.
      Incluye la cantidad de usuarios, el conocimiento y los materiales publicados y disponibles, libros, cursos, blogs, artículos, videos, bibliotecas de software, y además la alta compatibilidad con C, otro lenguaje enorme.
      Para alguien que lleva más de unos años en este campo, esto es casi sentido común de la industria del software.
      Yo nunca usé mucho C++, así que ni siquiera podría decir que soy un principiante hecho y derecho, pero en su momento compré y leí libros clásicos de C++ del creador del lenguaje, Bjarne Stroustrup, Scott Meyers y otros, y llegué a entenderlos en cierta medida.
      En cambio, sí usé mucho C en producción durante años, incluso en productos comerciales exitosos.
      https://www.stroustrup.com/applications.html
      https://www.stroustrup.com
      https://en.m.wikipedia.org/wiki/Bjarne_Stroustrup
      https://en.m.wikipedia.org/wiki/Scott_Meyers
    • C++ tiene sentido cuando se necesita baja latencia pero no importa demasiado la corrección.
      Por eso creo que el desarrollo de videojuegos será lo que más tiempo permanezca en C++.
      Si al 0,001% de los usuarios se les cae el juego por un fallo de segmentación, la actitud es más o menos: ¿y qué?
    • El trading de alta frecuencia también es una posibilidad.