[escepticos] No pienses en un elefante

[Borja Marcos]

On 22 Aug 2012, at 20:01, José Ángel Morente <joseangel en morente.org> wrote:

> Por supuesto que no. Todo lo demás son lenguajes para NO programar, es
> decir, para que el lenguaje en sí o alguna librería mágica programe
> por ti :-P

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.

Para todo el resto de cosas, no necesitas eso y de hecho es contraproducente. C para programar aplicaciones es un desastre. De hecho, 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.

Dependiendo de la complejidad de la tarea que tengas que llevar a cabo, te encontrarás con que usando C pierdes un montón de tiempo haciendo idioteces como tener en cuenta que el tamaño de esto es tal y el tamño de lo otro es cual, etc. Piensa sin más en los problemas de portabilidad que se encuentra la gente que no está acostumbrada a programar para múltiples plataformas Unix, donde es normal tener que lidiar con distintos órdenes de bytes en los enteros, etc.

> Depende para qué, de la costumbre que tengas, y de la cantidad de
> código reutilizable que hayas acumulado con el paso de los años. A mí
> me costó mucho trabajo aprender a programar C porque sin querer
> pensaba en ASM, lenguaje con el que me sentía "liberado".
> 
> Pero hoy en día con los compiladores de C que hay, no tiene mucho
> sentido el ASM salvo que quieras tener un control muy preciso a muy
> bajo nivel (por ejemplo, programar un driver), y ni así, ya que el C
> bien utilizado (no como si fuese un lenguaje de alto nivel, que es muy
> frecuente verlo) te permite optimizar tanto como en ASM.
> 
> Un amigo mío (y excelente programador) sostiene que para él el C no es
> más que un macro-macro-assembler. El tío es de los que estudia el
> compilador que va a usar, analiza el código generado por éste y luego
> programa en C imaginándose ya el código compilado resultante.

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

En cualquier caso, si el programa es mínimamente complejo, la velocidad depende en mucha mayor medida de tu elección de algoritmos, estructuras de datos, y de la propia naturaleza del problema que del lenguaje de programación empleado (eliminando por supuesto intérpretes). Y la diferencia en dificultad de mantenimiento hace que en muchos casos merezca la pena usar lenguajes "menos eficientes". 

Por otro lado, estas obsesiones con el ensamblador me recuerdan a la época en la que la gente perpetraba programas de contabilidad en ensamblador para MSDOS, o un casi si cabe más disparatado: el de un amigo hace 20 años que quería añadir "red" a una aplicación que había hecho, y cuando le recomendé un paquete de TCP/IP me contestó que no, que él quería controlar directamente las tarjetas Ethernet porque era más eficiente. Cuando le expliqué que eso era mucho más complejo de lo que parecía, y le pregunté qué pasaba si, por ejemplo, el cliente unía dos oficinas con un router. La repsuesta fue que si iba a poner interconexión, que eso era "otra funcionalidad" y que ya lo haría él.

En fin, no tengo nada en contra de los que encuentran divertido usar ensamblador, pero excepto si estás trabajando en un generador de código para un compilador en general no lo necesitas.




Borja.