Nuevo blog

Este es mi nuevo blog. Es el tercero que empiezo. El primero lo empecé en 2004 y lo cerré en 2006 para mudarme al difunto freaks-unidos.net, donde empecé el segundo. Después de siete años, el sitio cayó y parece que no volverá a levantarse, así que decidí abrir este nuevo blog. Me queda pendiente publicar las antiguas entradas en algún lado.

La temática del blog será la misma de siempre, temas de tecnología, programación y algo de cultura o política de vez en cuando. Espero no dejarlo tan abandonado como el anterior.

Super Mario Bros

Hace unas semanas se celebró el aniversario 25 de Super Mario Bros. Hace unos días, alguien preguntó en StackExchange en qué lenguaje de programación estaba escrito. En Reddit surgieron varios comentarios interesantes:

abadidea:

Hi, I am a NES programmer! It is actually not that hard if you grok manual memory management. The 6502 instruction set is simple (but not at all orthogonal) and the NES has a lot of
hardware registers that do Interesting Things for you. The only serious limitation in my mind is the extremely limited color capabilities of the PPU, the NES’s equivalent of a GPU.

NES in a nutshell: you have 2Kb of onboard RAM. There’s an 8Kb window where your cartridge can patch more in. It can even bankswitch to have different sets of 8Kb. You have a 32Kb program
ROM window and that too can be bankswitched, usually in 8 or 16Kb sections. Graphics have an 8Kb window, two pages of 256 8×8 tiles. The remaining space in the 64Kb memory is various
hardware registers where you do your IO and configuring the graphics and sound generators. There is only one timer available, the TV refresh signal. On an NTSC NES it will raise an
interrupt 60 times a second, and on a PAL one, 50.

El CPU 6502 corría a sólo 1.79Mhz. Las limitaciones técnicas eran grandes. Aún así, Super Mario Bros no fue el mejor juego logrado para el NES. El mejor, en mi opinión, fue tal vez Super Mario Bros 3, una verdadera joya.

Creo que programar con limitaciones es más divertido, aunque no más productivo. En ese sentimiento se inspiran concursos como Java 4k o Sizehack. De vez en cuando es bueno programar por diversión, y sólo por diversión.

Por aquí está un clon de Super Mario Bros escrito en Javascript y HTML:

http://jsmario.com.ar/

Me pregunto cuales serán sus requerimientos mínimos.

Humble Indie Bundle

The Humble Indie Bundle es un experimento bien interesante. Varias compañías desarrolladores de videojuegos independientes han decidido vender cinco de sus juegos en un sólo paquete. Lo interesante es los clientes pueden pagar lo que quieran por el pack de cinco juegos. Desde un centavo de dólar hasta el infinito.

Además de eso es interesante ver que los juegos no tienen DRM, se pueden descargar las veces que uno quiera una vez comprados y están disponibles para los tres sistemas operativos más comunes: Windows, Mac OS X y Linux.

Un lado interesante es que el experimento ha dado buenos resultados. En pocos días se ha recaudado más de un millón de dólares. También es interesante ver las estadísticas de ganancias, en donde Linux y Mac OS X tiene una buena tajada. Entre los dos casi se llevan el 50%. Otra cosa curiosa es que el promedio de aporte por sistema operativo es: $14.55 para Linux, 10.99 para Mac OS X y 7.98 para Windows (al momento de escribir esto). Esto es importante porque en cierto modo ayuda a derrumbar el mito que dice que los usuarios de Linux no quieren pagar por el software, excusa usada por muchos vendedores de software para no sacar versiones para Linux. También, por supuesto, se muestra que el mercado de Linux no es tan despreciable como se pensaba.

A mi me parece que está bien pagar por buen software y cobrar por hacerlo. Compré este paquete con gusto. Compraría más buen software para el sistema operativo que uso. Me gusta el software libre pero me molesta que sea difícil imaginar como combinar el cobrar por él y que sea libre. Ya sé que en la teoría se puede, pero en la práctica no parece tan fácil. De todos modos iniciativas como The Humble Indie Bundle parecen una forma de hacer este tipo de cosas. Los juegos ahora los están liberando.

También me gusta escribir software sólo por diversión. Y lo he hecho varias veces. Y muchas cosas las he abandonado. Eso también lo hacen mucho desarrolladores de software libre. Últimamente siento que Linux en el escritorio está en declive. Hay muchas cosas que se han abandonado. Y conozco muchos desarrolladores que se pasaron a Mac. Si hubiera una versión de pago de Ubuntu yo la pagaría si supiera que se está avanzando más.

La web

En estos días hubo una discusión en el blog de Sergio sobre la web. Sergio escribió por qué le gusta la web. Yo iba a responder ahí, pero lo que escribí se me alargó y además quería revivir el blog, así que decidí publicarlo aquí. Primero voy a dar una descripción de lo que, a mi juicio, es la historia de la web. Esto no está precisamente en orden cronológico y puede tener errores si mi memoria ha fallado. Las correcciones son bienvenidas.

La web no fue diseñada para hacer aplicaciones. La web fue diseñada como un medio para compartir documentos conectados por enlaces en Internet. El detalle aquí fue la web se popularizó de una manera increíble, llevando a que se quisiera usar para muchas otras cosas más. El resultado de todo esto es que la web tal y como la conocemos actualmente es sólo una suma de hacks sobre aquel sistema de documentos con enlaces.

Uno de los primeros hacks fue CGI. La web, como el correo electrónico o el FTP, no estaba diseñada para correr programas. Pero a alguien se le ocurrió que sería interesante que se pudiera mostrar contenido creado dinámicamente por un programa. Junto con el CGI vinieron los formularios. Y el sistema de documentos ahora también servía para ingresar información y mandarla a un servidor web, el cual podía responder y generar un documento personalizado acorde a los datos ingresados.

Después vino la explosión de la web. Y el primitivo sistema era cada vez insuficiente para mostrar los contenidos que se querían. Llegaron lo GIFs animados, los MIDIs de fondo, los frames, las tablas para hacer el “layout” de la página, los “blink”, etc. Aquí vino el primer colapso de la web. Resultó que hacer sitios web era un trauma increíble. El código HTML de cualquier página medianamente compleja era horrible. Decidieron que había que cambiar muchas cosas. Crearon CSS para separar el contenido de la presentación, comenzaron las campañas en contra de los frames y las tablas. Pero ahí no terminó todo. Con la web cada vez más popular, ya no queríamos sólo documentos bonitos, ahora queríamos cosas parecidas a las aplicaciones de escritorio: menús desplegables, drag and drop, etc.

En esa carrera por ampliar un centímetro más las capacidades de la web, los navegadores dejaron de ser simples visualizadores y se convirtieron en entornos de ejecución. Aparecieron los lenguajes como Javascript o VBScript. Con esto las páginas, originalmente pensadas para ser estáticas, se volvieron dinámicas. Con Javascript era posible cambiar la página a medida que corre un programa en el navegador. Esta abominación se llama DHTML. Luego, resultó que no era tan útil sólo tener páginas dinámicas, que no pudieran comunicarse con el exterior. Y casi por casualidad, en algún momento de la guerra de los navegadores, a alguien se le ocurrió agregar una función de Javascript que pudiera acceder a un servidor web. Y nació otra abominación: AJAX.

En el lado del servidor las cosas tampoco eran fáciles. El esquema de trabajo de la web era bien simple: el cliente manda una petición de un documento y el servidor la recibe y manda el documento. Se acabó, eso era todo. Pero ahora la web no era para mostrar documentos, sino para ejecutar aplicaciones. Había un problema enorme y era que el esquema de petición-respuesta de la web no tenía un concepto de sesión. ¿Cómo saber que una petición fue realizada por el mismo cliente que antes hizo otra relacionada? Los hacks para que hubieran sesiones en HTTP no se hicieron esperar: nacieron los campos de formulario ocultos, las crípticas largas cadenas HTTP GET con información de la sesión, etc.

Y esta es la historia de la web: hack tras hack, machetazo tras machetazo. La historia del desarrollador web es un continuo batallar por hacer que algo funcione en una forma para lo que no fue diseñado. La web es una mala experiencia para el usuario y para el desarrollador.

Una mala experiencia para el usuario se evidencia en varios sitios. ¿Alguien ha probado YouTube en HTML5? (por cierto HTML5 es el último machetazo de moda) ¡Qué mal que funciona! Por Dios, estamos en 2010, hacer un sencillo reproductor de vídeo debería ser trivial ¿no? Si a los brillantes desarrolladores de Google les cuesta hacer esto, ¿qué podríamos esperar de hacer un editor de vídeo como Adobe Premier? Tocará esperar al 2050. Mis experiencias con Google Docs también son frustrantes. Son programas con características muy simples, más simples que sus equivalentes de escritorio de hace décadas, y llenos de bugs, incluso cuando corren en Chrome.

Hay un aplicación web que me gusta, a pesar de que es bastante simple: Flickr. Pero no dudo de que sus desarrolladores sudaron bastante.

La web también es mala experiencia para los desarrolladores, especialmente en el lado del cliente. Por ejemplo, si en una aplicación de escritorio yo quiero pintar un cuadro, simplemente digo algo como pintar_cuadro(x, y, w, h). En la web, para crear el mismo efecto hay que crear un bloque donde iba a ir un párrafo, sólo que sin ponerle ningún texto adentro. Utilizar CSS para que ese cuadro tenga el tamaño y apariencia deseado, que se ajuste adecuadamente al documento, que no corra el texto a su alrededor. Luego hay que decirle que tenga la propiedad de ser invisible. Y por último, para lograr el efecto “pintar cuadro” hay que hacer que la propiedad del cuadro pase de “invisible” a “visible”. Y eso que no hablamos de los hacks que se tienen que hacer para X y Y navegador. Es por esto que la gente no hace esto a mano, sino que usa herramientas como JQuery o GWT. Pero estas capas hacen las cosas lentas y son difíciles de extender. Por eso, por más que uno tenga un computador potente, la aplicación web funciona como si estuviera en un 286.

Para aplicaciones con interacciones sencillas la web está bien. Pero cualquiera que esté al tanto de las innovaciones en experiencias de usuario e interfaces, sabrá que la web se queda muy corta. Hacer aplicaciones web que tengan una interacción con el usuario medianamente compleja es una labor titánica hoy en día. No conozco ninguna aplicación web que me convenza. Y las que más o menos impresionan, tienen un excesivo trabajo de sus desarrolladores.

Otra cosa: la web sólo permite un lenguaje en el cliente: Javascript. Y según la gente de StackOverflow.com, es uno de los lenguajes con cosas más raras que existen.

Bueno, aparte de rajar. Me gustaría decir que hay cosas de la web que me gustan mucho: La ubicuidad, como mencionaba Sergio. Que chévere es poder acceder a las cosas desde cualquier PC y tener ahí los datos y todo. (Aunque esto a veces puede ser una pesadilla, preguntenle a mi amigo Diego Escalante a quien Google le cancelo sin motivo aparente su cuenta y quedó frito). Que bueno que las aplicaciones sean multiplataforma. Que se actualicen automáticamente, etc. Hay algunas tecnologías que usan las ventajas de la web, con mayor flexibilidad en el desarrollo: un ejemplo es Silverlight o Flash/Flex/Air. Pero no me gusta mucho que detrás de estas estén empresas tratando de ser amo y señor de la web. A mi me gustan los estándares. Pero HTML5 me desilusiona. La W3C debería replantear todo, ya no queremos más hacks sobre lo mismo, sino algo que realmente esté diseñado para lo que debe hacer.

Segunda GUADEC

A menos que algo extraordinario ocurra, este año asistiré por segunda vez a GUADEC. La primera vez, en Birmingham, la pasé muy bien. Esta vez será en Estambul, lugar que, según he escuchado, es uno de los más bellos en el mundo. Estoy muy emocionado por este viaje. Muchas gracias a la Fundación GNOME por patrocinar gran parte de mis gastos.

Distributed Version Control

Actualmente se está dando una avalancha de migraciones desde sistemas de control de versiones centralizados (Subversion) hacia sistemas distribuidos. Prácticamente todos los grandes proyectos de software libre o ya migraron o están en discusiones sobre la migración o están usando sistemas paralelos.

A diferencia de lo que sucedió con Subversion, donde también hubo una avalancha de migraciones desde CVS, en esta ocasión hay varias buenas alternativas, lo que hace la cosa mucho más interesante. La guerra entreGitMercurial y Bazaar, está generando un montón de innovaciones en el campo del control de versiones. Nos está beneficiando mucho a nosotros los usuarios.

La carrera por popularidad la va ganando Git con proyectos como Linux, X.org, freedesktop.org, Wine, OLPC, entre otros. Mercurial va muy cerca con proyectos como Mozilla, OpenSolaris, OpenJDK, Xen, entre otros. Bazaar va en último lugar siendo usado por Ubuntu y otros más.

Git está escrito en C y muchos de sus comandos son scripts de Shell y Perl. En consecuencia, el soporte de Git en Windows es muy pobre. Mercurial está escrito principalmente en Python. Algunas rutinas cuello de botella están escritas en C. Mercurial funciona muy bien en Windows. Bazaar es 100% Python. Funciona muy bien en Windows. Mercurial y Bazaar son extensibles via Python.

Git va en primer lugar en cuanto a velocidad, Mercurial de segundo, Bazaar de tercero.

Git tiene una interfaz de usuario difícil de comprender. Mercurial y Bazaar son muy fáciles de usar.

En cuestión de documentación, Mercurial se lleva el primer puesto, Bazaar el segundo y Git, de lejos, el tercero.

Elegir uno de los tres es una tarea complicada. Hay un millón de páginas y entradas de blog que hablan a favor de uno u otro. Como van las cosas es muy posible que haya que aprender a usar los tres, al menos a un nivel básico. Mi elección personal ha sido Mercurial, por su documentación, facilidad de uso y velocidad.

Mi experiencia en las últimas semanas con Mercurial ha sido muy placentera. Los sistemas distribuidos no solo dan una gran ventaja para proyectos grandes y con muchos contribuyentes, sino también hace las cosas mucho más fáciles en proyectos pequeños de uno o pocos desarrolladores. Empezar a versionar un proyecto nunca fue más fácil.

Tengo muchos pequeños proyectos que no están versionados, por ejemplo los de PyWeek. No lo hago porque me da pereza arrancar un nuevo repositorio de Subversion, importar, hacer checkout… Con Mercurial es tan fácil comenzar un nuevo repositorio que nunca más tendré un proyecto no versionado.

La velocidad es un factor muy importante a la hora de que a uno no le de pereza usar un sistema de control de versiones. Con Mercurial todas las operaciones se sienten instantáneas. En cambio Subversion se siente taaan lento, incluso usado localmente.

El poder clonar repositorios fácilmente me da más seguridad. Sé que es menos probable que se pierdan datos. Sitios como freehg.org y github.com son lo máximo.

Trabajar al estilo Branchy Development se siente muy bien. Ahora tengo la costumbre de crear un branch por cada nueva característica, por pequeña que sea. Trabajar paralelamente cada cosa en un branch aparte es muy cómodo, ya que una cosa no rompe la otra. Además todo el historial termina mucho más organizado. Luego cuando todo está listo, un merge sin traumas.

A la hora de colaborar a un proyecto de software libre, me parece fundamental el hecho de que uno siempre tiene acceso al sistema de control de versiones. A diferencia de Subversión donde sólo el que tiene acceso decommit puede usarlo. El sistema de red de confianza del que hablaba Linus Torvals en el famoso vídeo de Git, también me parece una forma más natural de hacer las cosas.

Hay dos cosas que no me gustan de Mercurial. Una es que el soporte para Subversion es bastante pobre. No hay algo tan bueno como Git-svn. La otra es que la forma de hacer branches haciendo clones todavía se siente muy Subversion, me gusta más el estilo Git (Ivan habla de ello más detalladamente). No uso Git porque en el trabajo eventualmente me toca hacer ciertas operaciones en Windows. Sin embargo, como dije antes parece que dominar Git va ser esencial pronto. De todos modos aprender Mercurial me ha servido para entender muchos conceptos que no entendí bien cuando comencé a leer sobre Git.

Dolor de cabeza con Python

Un problema de usar lenguajes dinámicos es que, al no tener etapa de compilación, no es posible detectar muchos de los errores sino hasta que se lanza alguna excepción mientras el programa se ejecuta. Un problema peor es cuando por alguna razón el error no produce una excepción y el programa termina funcionando erróneamente si dar ninguna pista sobre dónde puede estar el problema.

Examinen este pedazo de código en Python:

class MyClass:
	pass

if MyClass() < 1:
	do_something()
else:
	do_something_else()

o algo más curioso todavía:

if MyClass() < float('-infinity'):
	do_something()

do_something() siempre se ejecuta.

Lo correcto debería ser que al hacer este tipo de comparaciones se lanzara una excepción. La única forma de poderlo hacer debería se cuando sea explícito que el objeto puede compararse.

Noten que este código si lanza una excepción del tipo TypeError:

a = MyClass() + 1

Según lo que me dijeron en #python, parece ser que todos los objetos en Python están habilitados para hacer comparaciones. Esta es la razón por la cual se pueden ordenar fácilmente listas con cualquier tipo de datos en ellas. Debido a que arreglar esto supondría un corte con la compatibilidad hacia atrás, sólo podremos disfrutar de una adecuado comportamiento hasta que tengamos Python 3.0. Si esto hubiera estado listo ahora mismo me habría ahorrado un gran dolor de cabeza buscando un error.

Scratch

Quedé impresionado con Scratch, el nuevo lenguaje para introducir a los niños en la programación desarrollado por el MIT Media Lab. Lo bueno es que es libre (Licencia MIT), aunque sólo está para Mac y Windows, pero dicenque ya lo están portando para el X0 del proyecto OLPC. ¡Que bacano sería ser niño y tener este juguete!

Mas rapido, pero mas lento

En estas vacaciones de diciembre, fui a visitar a mi familia en Medellín. Mi tía Patricia tenía un viejo computador portátil Toshiba Satellite Pro 440 CDT que ya no usaba y decidió regalárselo a mi Papá. Es un portátil que ya tiene sus 11 años, pero, dado que mi papá escasamente usa el PC para leer y escribir correos electrónicos, navegar por Internet y de vez en cuando escribir una carta, le sirve perfectamente. Por supuesto, como buen entusiasta de software libre, pensé que si se le instalara Linux se podría explotar más su potencial. Sin embargo, rápidamente descubrí algo que me dejó atónito y me motivó a escribir esta entrada en mi blog.

El Toshiba Satellite Pro 440 CDT tiene las siguientes características:

Procesador
Intel Pentium MMX de 166 Mhz
Memoria
32 MB
Disco Duro
2 GB.
Software
Microsoft Windows 98 y Microsoft Office 97.

Después de ver las características tan bajas del equipo, hay algo que me da muchísima tristeza. Office arranca mucho, muchísimo más rápido que el OpenOffice de mi PC. Casi cuatro veces más rápido. Aún cuando mi PC tiene 32 veces más memoria que el portátil y un procesador con 20 veces más Mhz. No estoy muy seguro de esto pero, en mi opinión, Office 97 y OpenOffice 2.0 tienen prácticamente la misma funcionalidad.

Después de jugar un rato con el portátil me di cuenta que la velocidad general de sistema, arranque del sistema operativo, apertura de archivos, etc es bastante buena, muy comparable a la de mi PC. Es cierto que hay varias cosas que no pueden ser iguales, por ejemplo, creo que el portátil explotaría antes de poder usar algo como F-Spot o editar imágenes de 8MP con GIMP. La interfaz de mi PC también es más bonita, con más resolución y efectos interesantes. En fin, creo que hay un millón de cosas que no podría ser iguales, pero en el caso de programas como OpenOffice y Office, que son prácticamente iguales, el hecho de que haya un rendimiento similar, o incluso superioridad en el computador de 11 años de edad, me parece algo desgarrador.

¿Qué es lo que pasa? Culpo a los programadores. Somos especialistas en derrochar toda cantidad de recursos que tengamos disponibles. Anteriormente los computadores venían con 32 MB de memoria y los programas tenían que funcionar con eso, y funcionaban. Eso hacía que los programadores se interesaran por mejorar el uso de los recursos. Ahora hay abundancia y se puede derrochar.

Aunque hoy en día tenemos hardware decenas de veces más rápido que hace diez años, parece ser que la calidad y rendimiento de los programas no ha crecido en la misma proporción (si es que ha crecido en algo).

Hay casos mucho más extremos aún. En el mundo del desarrollo de juegos siempre se ha mantenido una tradición de explotar al máximo las capacidades del PC. Es quizás por esto que los juegos son los únicos que parecen mostrar un verdadero avance proporcional a los adelantos en hardware. Recuerdo cuando alguna vez escribí un sencillo juego para PlayStation. El sistema contaba con la miserable cantidad de 1MB de memoria de vídeo y 2MB de memoria de sistema. A mi me parecía demasiado difícil hacer algo con tan pocos recursos, sin embargo los expertos hacían juegos espectaculares con eso. Sabían usar muy bien los recursos.

El tema no necesariamente da para comparar programas viejos con nuevos. Hoy en día también hay buenos programadores que saben utilizar adecuadamente sus recursos. Hay un perfecto ejemplo de dos programas contemporáneos que tienen funcionalidad muy similar pero difieren enormemente en el uso de recursos: uTorrentAzureus.

La descarga de uTorrent es de 170KB, la de Azureus es de 9.4 MB, eso es 57 veces más, todo esto sin contar detalles como que Azureus requiere un runtime de Java (~50MB) y que viene en un instalador comprimido (bz2) mientras que uTorrent viene en un ejecutable standalone listo para ser ejecutado. El consumo promedio de Memoria de uTorrent es de 4.6MB, mientras que el de Azureus es de 40MB. El consumo de CPU es difícil de medir, pero los desarrolladores de uTorrent dice puede correr hasta en un CPU 486, eso ni siquiera cumple los requisitos mínimos del runtime de Java, en el caso de Azureus.

Ambos programas tienen casi las mismas funcionalidades, Azureus era el más popular, sin embargo, gracias a la superioridad en rendimiento de uTorrent, este le ha ganado el puesto y su popularidad crece en forma exponencial.

Hay otra razón por la cual hay tanta diferencia en estos programas: El lenguaje de programación. Aceptémolo, por más que varios estudios aseguren que la velocidad de los programas escritos en lenguajes como Java, C#, Python, Lisp, etc. sea igual o, algunos se atreven a decir, superior que C o C++, la verdad es que en la práctica todos los programas realmente eficientes están escritos en C o C++. uTorrent está escrito en C++, Microsoft Office está escrito en C++. Azureus está escrito en Java, OpenOffice está en gran parte escrito en Java. Pero ojo, esto no quiere decir que todos los programas de C++ sean necesariamente eficientes.

Es cierto que otros lenguajes hace al programador más productivo y en general más feliz, pero creo que es difícil negar que con C y C++ se puedan obtener programas más rápidos. ¿O tal vez sea mejor decir que con un poco más de esfuerzo a la hora de programar, esfuerzo al que casi siempre nos obliga C++, se obtengan mejores programas?

C++ siempre me encantó y lo usé mucho para muchos proyectos. Hace un tiempo me enamoré de Python y ha pasado bastante tiempo desde la última vez que usé C++ ¿Será que es tiempo de abrir el baúl y volver a sacar esos conocimientos de C++? ¿O será mejor seguir con los lenguajes de alto nivel y más bien tratar de hacer esfuerzos para lograr un balance entre felicidad del programador y eficiencia del programa?

MonoHotDraw

Por estos dias estoy programando MonoHotDraw, que es el séptimo intento por hacer una librería de diagramación para MonoUML. Se llama MonoHotDraw porque está basado en el diseño de HotDraw y JHotDraw. MonoHotDraw está escrito en C# con Mono y usa varias herramientas de GnomeGtkCairoPango, etc.

Aquí hay un video de una aplicación que estoy escribiendo para una tarea de universidad que usa MonoHotDraw. Es un sencillo editor de mapas mentales. Se supone que debo entregarlo el 18 de diciembre. Tengo que apurarme y convertirlo en algo decente.

Por cierto, YouTube no me reconoció el video correctamente. Termina instantaneamente. Google Video si lo reconoció, aunque la resolución está fea. ¿Alguien sabe como convertir videos ogg theora en avi xvid o algo compatible con YouTube?

Actualización.

Olvidé decir que MonoHotDraw se encuentra disponible en el repositorio Subversion de MonoUML. La licencia de MonoHotDraw es LGPL, aunque tal vez la cambie a MIT X11. ¿Qué opinan ustedes?