[escepticos] No pienses en un elefante

[Luis Rodriguez]

Hola:

> 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...
>

Todo lo que comentas era cierto hace unos años (y en algunos casos lo sigue
siendo ahora), pero creo que cada vez más el
discurso de la eficiencia de C es más discutible. Por un lado, el generar
código objeto optimizado es cada vez más complicado y los compiladores cada
vez más complejos. Antes la diferencia entre C y cualquier otro lenguaje
era abismal (de órdenes de magnitud), ahora la cosa está mucho más
apretada. En todo caso, estas diferencias son relativas y lo que antes
suponía pasar de un tiempo de respuesta, digamos  1 sg a 5 sg, ahora, puede
suponer hacerlo de 1ms a 5ms (en algunos casos, puede no ser tolerable,
pero en la mayoría de las ocasiones sí).

En cuanto a los ejemplos que comentas, existen multitud de librerías
especializadas en hacer ese tipo de tareas. Sólo necesitas conseguir los
"bindings" adecuados y puedes programar todas esas cosas desde lenguajes
"más lentos" sin que se penalice apenas la eficiencia (un ejemplo: OpenGL.
Puedes conseguir "bindings" para casi cualquier lenguaje, con lo que te
aseguras eficiencia en las operaciones de renderizado ya que las llamadas a
las funciones son a código compilado y optimzado).

El tema de la eficiencia es complejo, en todo caso, y depende de muchas
cosas, no sólo del lenguaje escogido.


Un saludo.




>
> > 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.
>
> > 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.
>
> >> 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
> >
> 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).
>
> > 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
>
> Pero en ese caso sí que es absurdo e innecesario. La mayoría de tareas
> realizadas en un software de gestión se pueden hacer con cualquier
> lenguaje de scripting, y va sobrao...
>
> > 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.
> >
> Así es; en la época en que yo usaba ASM sí era necesario,
> especialmente para máquinas orientadas a juegos (Gameboys, Megadrives,
> MSX, etc.). Ahí tenías que hacer cosas como enviar un comando por el
> puerto del chip de video, contar un número de ciclos de reloj
> determinados y enviar otro comando, etc. La precisión de reloj te
> venía del generador de interrupciones del propio chip de video (1/50
> s.) y tenías que contar los ciclos exactos de reloj que te consumía
> cada instrucción del Z80 o el 68K para medir los tiempos y retornar de
> la interrupción a tiempo (o incluso para enviar los comandos al chip
> de sonido del tal manera que la música siempre sonase "a tempo").
>
> De hecho, todos los juegos comerciales de la época estaban programados
> en ASM porque no había otra forma.
>
> Pero qué divertido era :-D
>
>
>
> --
> http://misshapenreality.blogspot.com/
> _______________________________________________
> Escepticos mailing list
> Escepticos en dis.ulpgc.es
> http://correo.dis.ulpgc.es/mailman/listinfo/escepticos
>