Esta duda surge en Python porque, a primera vista, la única diferencia es que una usa corchetes, y la otra paréntesis: No importa si tengo una lista o una tupla, puedo acceder a sus elementos con [indice], y con cualquiera puedo hacer asignación múltiple (a, b = [1, 2])…

Lentamente las diferencias empiezan a aparecer:

• Las tuplas, como los strings, son inmutables: Una vez que una tupla tiene un valor, no se puede cambiar, sólo crear una nueva.
• Debido a lo anterior, las tuplas son hasheables: Se puede crear un diccionario que use como índice tuplas—pero nunca listas.

Estas diferencias técnicas son las más importantes, y las que justamente las definen.

Ahora, ¿Cuándo es mejor cada una?… En muchos casos realmente no hay diferencia: Si a cualquiera de las dos puedo acceder por índice, o con for… Pero podemos tomar una pista de un lenguaje más estricto: Haskell.

En Haskell, una tupla de 2 elementos es de un tipo diferente al de una de 3 (y no se las puede acceder por índice). Además, las tuplas pueden ser heterogéneas, mientras que las listas son homogéneas. Eso es, puedo tener una tupla (int, String, String), pero una lista puede contener sólo un tipo de datos (Claro, ese tipo puede ser una tupla… pero divago).

Entonces, lo «correcto» (con comillas) es que, si a todos los elementos se los va a tratar de una misma forma (sea con un for, o con map), usamos una lista, pero si cada elemento tiene un significado diferente, lo mejor es una tupla.

void envejecer(struct persona_s *persona) {
    persona->edad++;
}
 
envejecer(tordek);

Edit: Epa. Si no, no compila…

Al omnisciente Google emití una plegaria de ayuda para ver de qué venía tanta alharaca, y me choqué primero con 960 Grid System, que parece ser el más simple de la familia.

Lo usé para armar un diseño que necesitaba rápido, y en seguida vi la mayoría de sus ventajas y desventajas:

Pros:

• Diseñar con “grillas” (grids) da resultados bastante buenos, con una apariencia ordenada.
• Si nos mantenemos dentro de los márgenes que el sistema de grillas propone, armar los diseños es rapidísimo y simplísimo.
• Todos los problemas de compatibilidad de navegadores son cosa del pasado. Claro, sólo en la parte de división en columnas y eso.
• Los templates que traen para Photoshop y demás facilitan el diseño.

Contras:

• ¿División de contenido y presentación? ¿Qué es eso?
• Diseños fijos¹.
• Cambiar una columna implica cambiar las demás para realinear.
• La necesidad de agregar la clase clearfix en un elemento vacío es poco semántico.
• El tamaño no es algo que se pueda decir «minúsculo»².

Los frameworks CSS tienen una utilidad innegable. Ayudan a armar un diseño muy rápidamente, sin tener que preocuparnos por si va a andar o no en “el otro navegador”.

Por otro lado, puristas de la separación³ se van a quejar de que usar un framework CSS vence el propósito de usar CSS: estamos poniendo en el HTML las clases que determinan el tamaño de cada columna, en vez de poner eso en el CSS, como corresponde. Al poner clases sin significado (¿Qué es un «grid_3»?) a los elementos, estamos agregando información que no es nada semántica, y no ayuda en nada a un parser, pero este problema se minimiza si usamos, además de las clases de grid, ids y clases significativos.

En fin, los frameworks pueden dar resultados excelentes si lo que buscamos se presta al diseño en grillas, además de hacerlo rápido y fácil, y sólo los muy extremistas tienen lugar para quejarse —y aún así, tienen una opción de usar los frameworks «correctamete», usándolos primero para «ver cómo va a quedar», y después armar su propia hoja de estilos destilada—.

Acá estoy, probando mi nuevo Window Manager, XMonad. Es un “tiling window manager”, lo que significa que cada ventana ocupa todo el espacio disponible, dividiéndo la pantalla (en realidad, cada escritorio virtual) según lo necesite.

Entre las cosas más grosas que tiene:

(Casi) no necesito usar el mouse.

Hay unos cuantos que se oponen a que abandone a la rata. Algunos infractores son Amarok (el botón de menú de mi teclado no hace nada en la lista de canciones) y las aplicaciones en Java (que, directamente, no puedo usar). Casi todo lo demás, lo hago usando la tecla Windows, acompañada de alguna letra, para navegar las ventanas, o dividirlas, o demás.

Haskell.

Haskell ya es groso de por sí; que XMonad esté programado en Haskell significa el fin de cuelgues y caídas, porque es casi imposible poner un bug.

Las divisiones de ventanas.

Un screenshot habla más que 1k DWORDS¹

Se banca dos monitores. Pero bien.

Lo que siempre quise con KDE era tener un escritorio en cada monitor, y XMonad sí me deja; con Mod-[1-9] cambio la pantalla actual (que elijo con Mod+{w,e}) a uno de los escritorios.

Lo único que no está tan bueno es toda la configuración que requiere para empezar a usarlo; aunque es extremadamente personalizable.

Pruébenlo, si creen en eso de que el mouse es malo y lento, o simplemente tienen ganas de probar algo nuevo. Yo lo uso porque me gusta maximizar mis ventanas tanto como tener varias a la vista :P…

[Comentario humorístico, indirectamente religioso]

Disclaimer: Esto es tan solo una traducción. No representa la opinión del autor de este blog, ni ninguno de sus participantes. Sólo lo estoy haciendo porque quiero visitas en mi blog, y estoy poniendo contenido que, aparentemente, no respeto, en un espacio personal.

—Pero, —algunos se quejarán— ¿y si me equivoqué? ¿Y si después de que lo hice me dí cuenta que no lo quería?

Bien, primero: Si te diste cuenta después, el botón de “estás seguro” no te salva. Obviamente, la opción no es “Ja, lástima, para qué hacés click ahí”. Existe una que sirve de verdad, y que hace mucho nos dimos cuenta que se puede: Deshacer.

Si en Windows se me ocurre borrar un archivo, va a la papelera. Si me equivoqué, lo recupero. Si en Thunderbird borro un mensaje, está en la basura.

Aparte, ¿para qué cambiar el significado de las cosas? Tengo un botón borrar. ¿Qué hace ese botón? ¿Borra? No. Me muestra una ventana que me pregunta “¿Estás seguro?”, y al hacer click en “Sí”, recién borra. ¿Desde cuando “Borrar” significa “Preguntame si quiero borrar”, y “Sí” significa borrar?

Y es imposible quejarse acerca de implementarlo. Si nuestra aplicación usa alguna forma de base de datos, tenemos una marca de “Borrado”. Si usa el sistema de archivos, una carpeta donde almacenamos los archivos ‘Borrados’.

Confirmar es inutil, Deshacer es divino, o como quieras ponerlo, basta de preguntas, y hacé lo que dije.

Se lo pueden bajar de la página de su autor, y, como todo plugin de vim, lo único que tienen que hacer es descomprimirlo en su .vim/plugins.

No tiene muchos comandos, pero tampoco los necesita:

• :BlogList para ver la lista de todos los posts;
• :BlogNew para crear uno nuevo;
• :BlogOpen id para editar uno; y
• :BlogSend para, finalmente, publicar…

Veamos qué tal….

Edit:

Hasta ahora, me gusta; en particular porque me molestan los WYSIWYG porque lo que ves no se parece en nada a lo que sale (Y no te dan la mitad de los tags… a menos que uses el editor HTML, sacándole todo el chiste.)

Ah, y se banca categorías, tags, y varias otras cosas (aunque no me deja editar el texto del permalink).

Ceceo ya es un poquito más lindo; sólo estás a una bajada y un make de distancia de poder hacer, simplemente '(a b c) => (a b c).

No es la gran cosa, pero es un Lisp…

Y mi problema con bison eran los malditos strings de C; estaba guardadando el puntero al string, en vez de una copia. Ahora sí.

Bueno, sigue sin tener un recolector de basura, pero qué se le va a hacer.