[escepticos] No pienses en un elefante

[Borja Marcos]

On 23 Aug 2012, at 09:26, José Ángel Morente <joseangel en morente.org> wrote:

> 2012/8/23 Borja Marcos <BORJAMAR en sarenet.es>:
> 
>> Pues creo que te equivocas del todo. C es un lenguaje de programación de sistemas, más cerca del ensamblador que de un lenguaje de alto nivel. Es apropiado en los casos en los que, por simplificar, necesitas que los bits que ves en un programa se conrrespondan de manera biunívoca con bits representados en la memoria, procesador, etc.
>> 
> Sí; y para cualquier aplicación que necesite una eficiencia extrema:
> audio, video, juegos, rendering, CAD...

Te sorprenderías de la cantidad de cosas que se hacen basándose en sistemas de desarrollo intermedios, por muy eficientes que tengan que ser. Y es que es de cajón. O te apoyas sobre un conjunto de abstracciones o cualquier tarea no trivial es inabordable, y el código imposible de mantener. Especialmente en el mundo de los juegos ahora mismo. 

Y dado que las prestaciones del hardware se han disparado, más que nunca puedes intercambiar una pequeña penalización en prestaciones por una mayor facilidad de mantenimiento.

>> Para todo el resto de cosas, no necesitas eso y de hecho es contraproducente. C para programar aplicaciones es un desastre. De hecho,
> 
> Aplicaciones, ¿de qué tipo? Si me hablas de aplicaciones de gestión,
> te doy la razón.

Programación de sistemas: especialidad en la que básicamente, por resumirlo en una frase, necesitas que la información que manejas esté reflejada exactamente en la memoria del ordenador igual que la estás manejando. Me refiero a drivers (en los que, por ejempo, tienes que acceder a registros de E/S y manejar interrupciones), protocolos de comunicaciones, etc.

En un lenguaje de alto nivel acabas trabajando sobre una máquina ideal, y te da igual que el procesador sea de 32 bits o de 67. Te da igual también en qué orden maneja los enteros. Y eso no es nada malo, sino que es necesario. Las abstracciones son la herramienta que te permite manejar un problema complejo.

Por supuesto que se pueden hacer muchas cosas en C, pero no es el lenguaje adecuado para cantidad de cosas y te obliga a perder cantidades ingentes de tiempo, como digo yo, "bailando la samba": copiando bytes de un lado a otro y contándolos.


>> buena parte de los problemas que hay hoy día con programas que "cascan", viene de usar un lenguaje inadecuado: C, C++ u Objective C. Los > problemas de seguridad tan extendidos, en forma de "desbordamientos", vienen de utilizar esos mismos lenguajes inadecuados.
> 
> Norl. Eso pasa también con lenguajes como Delphi también. El problema
> no es del lenguaje, sino de que dicho lenguaje te permita el acceso
> directo a memoria. Y lenguajes con punteros hay más que el C.

Con la diferencia de que para "optimizar" han cogido Pascal, que teóricamente comprobaba todo antes de usarlo, y se las han saltado como si fuera C.

>> A no ser que estés haciendo algo realmente crítico, hoy día no tiene ningún sentido programar en ensamblador. Y de todas formas, cierto, en C haces prácticamente lo mismo. Recuerdo haber hecho drivers con interrupciones y todo en Turbo Pascal hace 20 años :D
>> 
> Sí, pero en esa época sí que se notaba la diferencia entre el código
> generado por un compilador y el tuyo propio (sobre todo en
> compiladores Turbo-xxxxxxx).

Y ahora es más absurdo todavía programar en ensamblador, porque de una serie a otra de un procesador te puedes encontrar que tus trucos de optimización de convierten en contraproducentes. Por ese motivo se trabaja ahora en la línea de LLVM, que compila a un código intermedio, y después hace una segunda compilación de LLVM al procesador final.





En fin...