Aria Beingessner fue en su momento integrante de los equipos responsables de implementar los lenguajes Rust y Swift, de modo que su opinión sobre el desarrollo de software no es una que podamos descartar sin más miramientos, ni siquiera cuando sostiene en su blog una teoría tan controvertida como la de que “el lenguaje C ya no es un lenguaje de programación”.
En primer lugar, acusa a C de fragmentación (“C está en realidad horriblemente mal definido debido a sus mil millones de implementaciones”) y de tener “una jerarquía de enteros totalmente fallida”; esto último se refiere a que, según el modelo de datos usado —LP32 para Win16, ILP32 para Win32 y Unix 32 bits, LLP64 para Win64 o LP64 para Unix 64 bits— el valor de enteros varía, pudiendo traducirse en datos ‘int’ de 16 o 32 bits, datos ‘long’ de 32 o 64 bits, equivalencias entre int y long o entre long y pointer, etc).
Sin embargo, para Beingessner ambos detalles son meramente accesorios: no es en eso donde reside su principal preocupación…
Una ‘lingua franca’ que limita a las nativas
“Mi problema es que, como C ha sido elevado a una posición de prestigio, su reinado ha resultado ser tan absoluto y eterno que ha terminado distorsionando por completo la forma en que nos hablamos entre nosotros. Rust y Swift no pueden limitarse a usar sus lenguajes, nativos y cómodas… sino que deben envolverse en un grotesco disfraz de la piel de C y hacer que su carne ondule de la misma manera que éste lo hace”.
A lo que Beingessner se refiere aquí, en su florido lenguaje, es al hecho de que C no es un mero lenguaje de programación porque se ha convertido en algo más que eso: en un “protocolo”, uno que “todo lenguaje de programación de propósito general necesita hablar”.
Es decir, cualquier lenguaje que desee acceder a la entrada de datos del usuario, escribir en la salida del sistema, manipular ficheros, etc… necesita interactuar con la interfaz de su sistema operativo. Y para ello, dado que la mayoría de sistemas operativos está desarrollado en C, cada lenguaje se ve forzado a llamar a las API de C a través de las interfaces de funciones foráneas.
En definitiva, que incluso si nunca jamás en nuestra vida llegamos a escribir código C, un desarrollador deberá manejar variables C, hacer coincidir estructuras y diseños de datos con los de C, etc. Y no sólo al comunicar el software con el sistema operativo: también al intentar comunicar dos programas entre sí.
“C es la ‘lingua franca’ de la programación”.
Y aunque fuera un lenguaje de programación, no sería de bajo nivel
Además, si somos precisos, aunque no coincidamos con la opinión de Beingessner, tampoco podemos considerar a C un lenguaje de programación de bajo nivel, que es como se le ha categorizado toda la vida.
Un lenguaje de bajo nivel es aquel que está ‘cerca del hardware’, en el que sus instrucciones vienen condicionadas por la estructura física de los computadores que lo ejecutan. Pero C se desarrolló en los años 70 con la mente puesta en las gigantescas computadoras PDP-11, no en nuestros pequeños equipos Intel o ARM.
Tal y como recoge este paper de 2018 publicado por la Association for Computing Machinery (titulado, precisamente, “C no es un lenguaje de programación de bajo nivel”),
“La causa originaria de las vulnerabilidades Spectre y Meltdown radica en que los arquitectos de procesadores no estaban tratando de construir procesadores rápidos, sino procesadores rápidos que exponen la misma máquina abstracta que un PDP-11. Esto es esencial porque permite a los programadores de C seguir creyendo que su lenguaje está cerca del hardware subyacente“.
“[…] Tal vez sea hora de dejar de intentar que el código C se ejecute rápido, y en su lugar pensar en cómo se podrían ser los modelos de programación de un procesador diseñado para ser rápido”.
–
La noticia
Hay quien opina que C ya no es un lenguaje de programación (otros se conforman con decir que no es un lenguaje de bajo nivel)
fue publicada originalmente en
Genbeta
por
Marcos Merino
.
