Lenguaje de programación C (problemas del lenguaje C)

• Problemas de memoria: no recibe ayuda de herramientas como GC, análisis estático, etc.

• Comportamiento indefinido: se usa principalmente en entornos de bajo nivel y hubo muchas exigencias de optimización, por lo que aumentó el comportamiento indefinido para optimizar. No logra atrapar dos objetivos a la vez: rendimiento de bajo nivel y portabilidad.

• No es adecuado para programación a gran escala: ausencia de módulos y de un gestor de paquetes. Incluso cosas ampliamente usadas como #pragma once no tienen un estándar.

[ffdd270]

Gracias por compartir un buen artículo. Solo quería dejar un comentario por un punto menor que me generó duda.

• Quizá no existían cuando lo escribiste originalmente en 2011, pero ahora ya han aparecido varios gestores de paquetes para C. También está Conan, y está vcpkg de Microsoft. En comparación con npm, todavía tienen algunas carencias (vcpkg aún tiene la gestión de versiones en beta, y Conan tiene menos documentación que vcpkg), pero están mucho mejor que en la época en que no había nada.

[lifthrasiir]

Soy el autor del texto (jaja...). Actualmente el sitio está en una fase de lanzamiento suave y estoy escribiendo artículos de forma experimental, así que les pido comprensión porque el contenido puede seguir cambiando continuamente. Yo mismo también les doy seguimiento, pero también recibo opiniones por correo electrónico, así que ténganlo en cuenta.

Como comentaste, vcpkg parece ser actualmente el gestor de paquetes más prometedor, y Conan en realidad también es un proyecto que existe desde hace bastante tiempo (no está tan lejos del momento en que se escribió el texto original). Sin embargo, la característica más importante de estos proyectos es que son sistemas de meta-build que no tienen por sí mismos un sistema de build. (Si pensamos que CMake, su principal objetivo de soporte, también es un sistema de meta-build, quizá hasta sea un sistema de meta-meta-build...). Por lo tanto, es difícil que resuelvan de forma directa los problemas que se originan en el propio sistema de build. En vcpkg se ven rastros de que esto se ha considerado más; por ejemplo, si en un mismo proyecto se necesitan distintas versiones de una misma dependencia (a través de rutas de dependencia diferentes), es posible dividir el enlistment, pero eso no deja de ser una forma de esquivar las limitaciones del propio sistema de build. En cambio, con Rust y Cargo, en ese caso no hay problema en compilar ambas versiones y referenciarlas desde un solo crate.

Además, parece que actualmente vcpkg ni siquiera tiene en Visual Studio una integración de herramientas al nivel de NuGet (solo integración con MSBuild...), y tampoco parece estar muy integrado con los gestores de paquetes de las distribuciones Linux/BSD. Este problema también es uno de los mayores a los que se enfrentan hoy los gestores de paquetes por lenguaje; lenguajes nuevos como Rust lo están resolviendo atacándolo por separado, pero si se trata de un gestor de paquetes para C/C++, necesariamente debería apuntar a integrarse con los sistemas existentes, y eso todavía avanza con mucha lentitud. Solo después de que esta parte se resuelva se podrá decir que herramientas del tipo de vcpkg se han vuelto de uso general en el desarrollo con C/C++. Que eso aún no ocurra es la razón principal por la que en el texto valoré a la baja los sistemas de paquetes. (La proliferación de las single-file library que mencioné en el texto también es una prueba indirecta de que sistemas como vcpkg no están logrando resultar tan atractivos.)

[ffdd270]

Muchas gracias por la respuesta tan detallada. Al fin y al cabo, como la base es = ㅁ=.. build, parece que hay una barrera imposible de superar en comparación con npm u otros gestores de paquetes. Da la impresión de que vcpkg últimamente está pensando mucho en el tema de las versiones, pero no parece que vaya a ser fácil superarlo.

A veces pienso que el sistema de módulos de C++20 podría ser la respuesta a este problema, pero entonces el alcance ya se sale del lenguaje C (...). Parece que al lenguaje C no le queda más que un camino lleno de espinas. Incluso si ahora se estableciera C20, la tasa de adopción de nuevas versiones no sería tan alta como en C++..

[functor]

Gracias por tu buena opinión.

Mi opinión personal es la siguiente. Que existan varios gestores de paquetes para C es algo positivo, pero el problema parece ser que estos gestores de paquetes no se usan mucho. Más precisamente, como el legado de C ya es enorme, me da la impresión de que no hemos llegado demasiado lejos como para resolver los problemas mencionados arriba. Por eso, ¿no será que hay cada vez más intentos de migrar a lenguajes nuevos como Rust?

[ffdd270]

Ahora que escuché lo que dijeron y lo pensé de nuevo, creo que el enfoque de esos gestores de paquetes de arriba no está tanto en prolongar la vida del lenguaje C, sino en prolongar la vida de los programadores que no tienen más remedio que usar C.

Ahora que ya es momento de mudarse a una casa nueva (C++, Rust...), cuando necesitas muebles de la casa vieja como OpenGL o Lua, antes, sin un gestor de paquetes, había que moverlos a mano (hacer el linking, correr make, perder pelo porque no coinciden las versiones de DLL o lib... ver errores LNK y querer lanzarse por la ventana...). Pero ahora, como ya hay gestor de paquetes, se pueden trasladar de forma limpia, como una mudanza profesional. Como ya hay tantísimas cosas hechas, seguro que también habrá momentos en que haya que seguir usándolas en la casa nueva...

Ahora que el mayor mérito ya no está en las ventajas del lenguaje en sí, sino en toda la experiencia acumulada hasta ahora, realmente se siente que es un lenguaje que se está muriendo (...

[galadbran]

Parece que, por muchos motivos, Rust es el que más fuertemente tiene la imagen de ser el próximo C/C++. (Aunque, entre varios lenguajes considerados como “el siguiente”, también tiene relativamente la imagen de ser el más complejo... jaja)

[dalinaum]

Parece que Rust no solo se ve difícil en la imagen, sino que en realidad también lo es.