jump to navigation

Hemos evolucionado 24 agosto 2006

Posted by Jesús in Programación.
add a comment

Desde hace tiempo, tenía la sensación de que en la programación no habíamos evolucionado mucho. Al fin y al cabo, hoy en día casi todo se sigue moviendo en torno a C++/Java y alguna cosilla más, lo cual no es muy diferente a cómo estábamos hace 4 o 5 años. Ahora bien, estos días he tenido que hacer un poco de flashback en mi forma de programar debido a mis cacharreos con la DS, y me he dado cuenta de que hemos evolucionado, y mucho.

Veamos un ejemplo práctico: para manejar imágenes en Python, basta hacer algo como:

import Image  

img=Image.open("fichero.png")
img.resize((640,480))
img.save("fichero_salida.png")

Fácil, ¿no? Pues bien, estos días intento hacer algo parecido en C pelado, y mirando la documentación de libpng, me sale que para abrir un PNG hay que hacer algo parecido a esto:

char header[8];	// 8 is the maximum size that can be checked

/* open file and test for it being a png */
FILE *fp = fopen(file_name, "rb");
if (!fp)
	abort_("[read_png_file] File %s could not be opened for reading", file_name);
fread(header, 1, 8, fp);
if (png_sig_cmp(header, 0, 8))
	abort_("[read_png_file] File %s is not recognized as a PNG file", file_name);

/* initialize stuff */
png_ptr = png_create_read_struct(PNG_LIBPNG_VER_STRING, NULL, NULL, NULL);

if (!png_ptr)
	abort_("[read_png_file] png_create_read_struct failed");

info_ptr = png_create_info_struct(png_ptr);
if (!info_ptr)
	abort_("[read_png_file] png_create_info_struct failed");

if (setjmp(png_jmpbuf(png_ptr)))
	abort_("[read_png_file] Error during init_io");

png_init_io(png_ptr, fp);
png_set_sig_bytes(png_ptr, 8);

png_read_info(png_ptr, info_ptr);

width = info_ptr->width;
height = info_ptr->height;
color_type = info_ptr->color_type;
bit_depth = info_ptr->bit_depth;

number_of_passes = png_set_interlace_handling(png_ptr);
png_read_update_info(png_ptr, info_ptr);
...

…y paro porque la cosa sigue un rato más (el que quiera el ejemplo entero lo puede encontrar aquí). Y esto es sólo para abrir el PNG, ni hablemos ya de empezar a procesarlo y demás.

En fin, que juro por la cobertura de mi móvil que no volveré a decir que la programación no evoluciona (y que el monstruo espagueti volador bendiga a los creadores de Python 🙂 )

Programando en la Nintendo DS 23 agosto 2006

Posted by Jesús in Programación.
9 comments

Como orgulloso poseedor de una flamante Nintendo DS, y asiduo lector de libros, una de las primeras cosas que me pasó por la cabeza al ver las dos pantallas que tiene fue “esto como lector de libros puede estar muy bien”. Después de mirar un poco a ver si alguien había pensado lo mismo y había hecho ya un lector de libros, vi que la cosa estaba muy verde aún, y como a veces me pega el punto de cacharrear con estas cosas, busqué un poco qué posibilidades de desarrollo en la DS hay hoy en día.

Pues bien, la cosa está bastante factible: hay un kit de desarrollo basado en software libre y creado por aficionados, que se puede instalar en Windows con un asistente de los de siguiente->siguiente y lo deja todo listo para empezar a programar (en linux es un pelín más complicado montar el tinglado, pero tampoco mucho). La programación se hace usando la librería PALib, que es bastante completita y está muy bien documentada, tienen un wiki con toda la documentación y un montón de tutoriales. El principal problema es que para ejecutar software casero hay que comprarse el típico copión, que se enchufa al slot de cartuchos de la DS y permite meterle ROMs en tarjetas SD. La verdad es que vale una pasta, pero entre las posibilidades de desarrollo que da, y que además permite probar los juegos antes de comprarlos, creo que merece la pena.

Lo que sí me ha sorprendido es lo fácil que es programar un trasto de estos. Yo me esperaba una cosa más a bajo nivel (ensamblador por un tubo, interrupciones y tal), pero resulta que toda la gestión de sprites, fondos, planos de scroll, música y demás la hace ya por hardware la consola, por lo que el programador se puede centrar en el juego en sí. Imagino que el esquema es similar a todas las antiguas consolas de 16 bits tipo Megadrive y Super Nintendo, pero como es mi primer contacto con estas cosas, me ha llamado la atención. De momento, en los pocos días que llevo trasteando, ya he podido mostrar texto por pantalla(s) sin problemas (en un programa de 15 líneas, mirad si es fácil), y aunque el soporte de texto en PALib es un poco precario, la DS promete como lector de libros. Si al final encuentro el tiempo y consigo sacar adelante algo usable, ya lo publicaré en alguna parte…

¿Es el futuro funcional? 23 agosto 2006

Posted by Jesús in Programación.
add a comment

He encontrado estos días (no me acuerdo dónde) un articulín en el que se muestran las virguerías que permiten hacer algunos lenguajes de programación modernos, en este caso javascript (sí, esa cosa tan chunga que parece que sólo sirve para mostrar popups, quién lo iba a decir) pero que también son aplicables a otros lenguajes tipo Python o Ruby. El asunto se basa en hacer cosas que suenan como a sacrilegio a cualquier programador de C, Pascal o hasta diría que Java, como pasar funciones como parámetro y cosas así, pero que, bien usadas, pueden conseguir resultados sorprendentes.

Planteémosnos una pregunta: hoy en día, que cada vez vemos procesadores más paralelos (ya es normal tener una CPU con dos cores, el año que viene salen las de 4, y ya se habla de 8, 16, etc.), ¿podremos aprovechar todo ese paralelismo con los lenguajes convencionales? Al fin y al cabo, muchos de los lenguajes que conocemos a día de hoy no dejan de ser envoltorios sintácticamente atractivos para un paradigma totalmente lineal: la arquitectura von Neumann, usease, una instrucción detrás de otra, y saltamos de vez en cuando. Vale que tenemos toda una serie de facilidades tipo procesos, threads y demás, pero teniendo en cuenta que generan casi tantos problemas como solucionan (que si exclusión mutua, que si interbloqueos, etc.), podría parecer más un apaño que otra cosa.

¿No sería genial programar en un lenguaje verdaderamente de alto nivel, que no estuviera atado a la arquitectura von Neumann? Así, bastaría escribir el programa y luego, al ejecutarlo en nuestro flamante Athlon X64 (no porque sea de 64 bits, sino porque tendría 64 cores), automágicamente se haría uso de tanto paralelismo junto.

Y aquí llego al asunto: todo esto ya existe, y de hecho es casi tan viejo como la informática. Los lenguajes funcionales, tipo Lisp y compañía, se basan en un paradigma que no tiene nada que ver con el clásico modelo lineal, y por ello son altamente paralelizables. En realidad, y aunque tal vez Lisp tenga otros problemas, en los nuevos lenguajes que van apareciendo se deja ver una influencia funcional muy importante: basta ver las funciones anónimas o la definición de listas por comprensión. Con cosas como éstas se puede programar a muy alto nivel, de manera que, si el compilador/intérprete es lo bastante listo, la paralelización sea, no sólo posible (todo es posible en este mundo), sino bastante fácil.

En el artículo se pone el ejemplo del típico bucle para procesar todos los elementos de un array: si lo hacemos con el clásico for, estamos indicando explícitamente que el procesado debe hacerse linealmente, desde el primer elemento al último. Si por el contrario lo hacemos con una función como la map() de Python, a la que se le pasa el array implicado y la función que queremos aplicar, no indicamos explícitamente ningún orden, sólo que queremos procesar todo el array, por lo que el compilador es libre de hacer los cálculos en serie, en paralelo o como quiera. Mecanismos como éste son los que nos permitirán en el futuro seguir programando con independencia de los cambios arquitecturales en el hardware.

En fin, quién sabe, tal vez en 10 años estemos todos programando en Lisp (habrá que aprender, porque mi Lisp es bastante básico…), pero por lo menos hay que ir poniéndose las pilas con la programación de más alto nivel, ya que hasta cosas tan “clásicas” como Java se están apuntando al carro…