Effective Text Editing

I saw the video 7 Habits For Effective Text Editing 2.0 that arhuaco recommended months ago. I was tempted to start learning Vim, but after thinking for a while, I came to the conclusion that there is no good reason for learning Vim. I still don’t get why people likes Vim that much. Most of the features that Bram Mooleenar showed in the video have been present in other tools for years and, in my humble opinion, they work much better than in Vim. Other things Bram talked about are just too crazy for me (He suggested that word processing would be more productive if we edit every paragraph in Vim and then copy-paste it on Microsoft Word… WTF!!)

Here are my habits for effective text editing:

Golden Rule: Use the best tool for the Job. I have learned that using a generic text editor for everything leads to be very unproductive. I like to use JEdit as my generic Text Editor. I love it for things like XML, C/C++, this weblog, etc. It has all the advanced features I need in a text editor. I used to use it for C# and Python but I discovered that using an specialized IDE for these languages is thousands of times more productive. Now I use MonoDevelop for C# and PyDev for Python.

The most important features I need when editing source code that can be hardly founded in a generic text editor are:

  • Good Code Completion. Note the “Good” word is remarked. Some generic text editors have support for code completion but most of the time is very, very poor. For C#, MonoDevelop is the open source tool with the best code completion out there (ok, maybe #develop has good code completion too). For Python it’s a bit more difficult due the dynamic nature of the language. I have tested many editors and IDEs and I think PyDev has the best code completion (I’ve heard that Wing IDE has good support too). Code completion is specially useful when you’re working with large libraries like GTK+.
  • Refactoring Operations. Rename, go to definition, go to parent definition, encapsulate, look for references, etc. They are essential features, it’s impossible to be effective without them.
  • Integrated Debugger. This one is missing from MonoDevelop. Hopefully will be there for the next release. It’s lovely how with a simple click you can create a break point in your code, run it, and it will stop right there, then you can easily watch every object state and even add some code (on dynamic languages).
  • Version Control Integration. Automatic add, remove, rename subversion files. Easily track the changes on the files. I love the ChangeLog integration of MonoDevelop. Eclipse has a good support for Subversion too.
  • Integrated UI Editors. It saves a lot of time if you’re writing GUI applications.
  • Task list. If you put notes on your source code comments such as: TODO, FIXME, NOTE, HACK, etc. It will generate a list with all notes present on all files, so you can look for pending things easily. This feature is present in MonoDevelop, PyDev and JEdit. I love it.
  • Integrated Help. Put the cursor on a word, hit F1 and automatically open the help browser with the page for the class or method description for the object or definition you selected.

There are other cool features that I like and most of the time are present in a good generic text editor:

  • Code folding.
  • Easy comment, uncomment of lines.
  • Advanced search and replace.
  • Diff viewers. JEdit has a Diff plug in, but I prefer Meld.
  • Splits. Actually I have not seen a tool with a split support as good as JEdit.


Last week I went to Lima (Perú) to attend Involucrate+GNOME. I really had a good time. Special Thanks toDiego, who invited me. Of course, I’ve got everything what I’ve seen in peruvian tv for years and never had the opportunity to taste. Inca-Cola, Chicha Morada, Cremolada, etc. I also verified that no one can eat a Margarita cookie as a normal cookie, leafs must be eaten first 😛

En Peru

Photo Stolen directly from Tatiana’s FlickrMore Photos on Flickr

Comming soon…

  • PyWeek: March 30th. Of course, I’m not going to miss it.
  • Summer of Code 2008. Receiving applications on March 24th. I’m Trying again. Last year I couldn’t apply because I was in London and I suspended my studies. I hope the third one is going to be the winning one.
  • GUADEC 2008 Istanbul. Registration and sponsorship requests open!

Game bits

Making an Indie MMO
I found the video of Daniel James‘s presentation for the Game Developers Conference Independant Game Summit. Very interesting. I’m impressed to see how Puzzle Pirates was made by only six people. There are also various interesting tips for MMO developers out there.

Igda scholarships
Igda will award 25 scholarships for the Game Developer Conference 2007. It will be in San Francisco on February 18-22.

Open Liero
Liero was one of my favorite freeware games of all times. I was very pleased to see that there is an open source implementation around similar to what OpenTTD is for Transport Tycoon Deluxe.

Urban Terror
These days, I can be found playing Urban Terror, a tactical like Counter Strike. Urban Terror is based on Quake III Arena and is completely open source. My nick name is Kira. Yes is because of Death Note.

PyWeek Ended

PyWeek is over. It was absolutelly fun!. My final entry is not what I would call a finished product, but it’s not bad. A couple of hours before the challenge end, the pyweek.org server went down. We had to send a md5 sum of our final entries to one of the event’s coordinators via e-mail.

Video of my game:


My code and more detailed comments in my PyWeek Entry Page.


Tomorrow, I’m going to participate in the fifth edition of PyWeek. PyWeek is a challenge in which participants must develop a video game in one week using Python. I like the idea because it brings a possibility to finish a project and have some fun by the way.

Some of the games created during PyWeek are really awesome. It’s amazing the fact that they were made in only one week. My favorite games of previous editions of PyWeek are:

I also like the competition and challenge feeling that you can breath in PyWeek.s

It’s possible to participate in two categories: Individual and Team. This time I am going to participate as Individual. I am thinking in use PyGame only. Even when some people are talking about Panda3D. I also want to use Blender to create pre-rendered sprites. I have been learning it secretly for a while. The result has been exactly what I expected: I suck as a graphic artist. My models are absolutely ugly, but at least I can do something for a game. By the way, now I prefer Blender to Wings3D for 3D modelling.

Screenshots of my attempt to model an aircraft with Blender. I also tried some kind of cell-shading or toon-shading redering:

If I suck with Blender. I prefer not even talk about my talent with sounds and music.

See you in one (py)week!


These days, a lot of people on GNOME planet are talking about Vala, a new programming language aimed to facilitate the development of applications and libraries for the GNOME platform. Vala is very similar to C#, but what is interesting about it, is that it’s perfectly integrated with the Glib/GObject object system. The compiler translates the Vala source code into C. It uses GObject to create classes and interfaces, and GIDL metadata for introspection. This has some advantages: there is no need for any additional runtime, Vala programs are compatible at ABI level with C programs, writing bindings for existing GNOME libraries is really easy and straightforward. Alberto Ruiz wrote about how simple was to write a binding for GtkMozEmbed. After look at howtraumatic were the Java bindings for Gtk, or how difficult has been the creation of GStreamer bindings for Mono, I think this is the best feature of Vala.

Anyway, I think Vala still lacks some key tools in order to become a real choice for GNOME developers. In the case of Mono, there is a great advantage called MonoDevelop. Days ago, version 0.15 of this awesome IDE was released. With no doubt, I think this is the best IDE for GNOME. The GUI editor, the subversion integration, the localization support and autotools integration are very appreciated features. Of course, is not perfect, It lacks a debugger and fixes for some annoying bugs, but it’s a very active project and has a great community behind it.

And talking about languages, at the end of this month, it should be released the alpha version of Python 3.0. On June, Guido van Rossum published a report about the final decisions concerning Python 3000. I am very happy with most of the changes, it was time to break some backwards compatibility. Python will be even better that what it is now.

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:

if MyClass() < 1:

o algo más curioso todavía:

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

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.


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:

Intel Pentium MMX de 166 Mhz
32 MB
Disco Duro
2 GB.
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?