500 Internal Server Error

Sorry, something went wrong.

A team of highly trained monkeys has been dispatched to deal with this situation.

If you see them, show them this information:

oS5k8ddl4_mhnwSf3tpqJoNjWFPbPwB1xXHt8_5xSI7Nu6fKv2ghgtVD-rYF
VjiyL6NrcvQclc-0aGySc_Y_OKKClCZ6E-RcXYZBQEBjOYEgaGixOnp19Irc
Cpj-ZURpqed4kysfmU7_5AgFw5-R_Il1g7bNl0di3i7laoE4UgLgoyqyNMZm
iwts6EPlk8FyTqmqKINhH4wHOEvFdJ2U4S_aX_cjpRnpmme1ez3O52VswgO6
HdokcFud9SKKWUQa6Sgqueb99ZnHRSYOqiJ6URp1Sh9HbhYm76B7KHCB90gf
UH6j4sTwaLodfFF6GYEbuyjgtT0aykaAnepdH4liFfRQJAyJw-ETfUp3qSgl
yjUq-LPqFaDZ5sAerdqIRBuDcBWgsHK2blSswoKWDCdzZJ-6WvAs54J4Yw6w
NzJ7Dgip5uy7MWm8vkTWyseDptQXco5W8IDV08xP98oakJ0feHT9fYEwJxE8
3qW-ijnOWebpAMcm5eZNKlmUnm2l5dB6Sw7HkwbmbpuZc6BXn7tS8uzXJBVP
p4EAnfutd4qXz_LEyiXcEXn0R0u2g08ez_wNIPxcyzEWaG3SGl3SpW9ajxQB
tROABWoHBAsSMLnF-SQCRWG-C18kRg-XCuVAitvcLihwBjeOHlkioQ4uXDDJ
-Km6-ExcE9h6d8tjUoS7JFULClYb92kPG6JSuNJ8ZvdUJd-v00p5MOKA78F_
Lz0fD2OfI8c2_qbvdQM6yofJoK6rRQU9_EFGQ7E5Xtjbd9uKw_GcQeDDwzPm
uUaZmIzLi3S2HVVtQQObZnxmn_Pg2zUcn3AEEWs-2OPRnoa6C311o2OID-3J
7yYT_h76AWI02TdH5m1BBqjRiQImAwJ10w04vvrRegZMX7CrmfmzBU7Ax2ZF
s1e36icCyGPE3kBMtnZ3c7N4B0hM2zty9mTMoAQt6mSt4sk3x2pi6ZaBgUnV
v2uL4c-ERAcDRY5A3pGbckbotLKhfnE1Z4-t3t_8E9_kEuex9NC_dVgeMKYB
NKaNnPDpYPwI_PnMV_sZnSZ1jthrjplqBb8xs9KCy7m-Lt7h7UH-NAFPwY9n
KdrXdEnn3MdCkMfoo_FeVMOWuZUMGxqJztzxgp4kfxjMO7eke7CEYxiEiI8t
ew6t4fnX2hdDqaVj-3nyPlJ7JLDqb0Cn6gzff-diBUHcSIcUcR1v5soWSCPO
936_dMBqii3zi_czqFglg0ZNtEo_1_sfF3bI-i2dX1ozyQ8P_hpTArn1xAz8
rK0UUuUnda5RqgLcrPMj5u94BVj3rTGEsM-GawqjdS2DpQknEbKgcLbTHoTq
LPQkwFWKaEkNThYUo2kHbVtHKmmNqIWkFo7VAQfoGZXwGyxx9M-7pQuza7OR
UJOqFNcNykk6gJaFk7U601kgG6W7t_eg1uOCks4rKaEgv0h6ZL6KMDIvOnAe
USh3TzZXHlUbMAQRPBdIAAigZspRR6UW0H5zOnNCl3Kjp7y1X_oDSiEiP8-T
epiNn2wFDf6BKkdpQVm_tTeyrDsCVeK-cac6OVg19HXSA6YaGFQhW0ghJaLH
4SGs6HkMZxqH6d2CGJLXJc-8XfyplJ6xH4HC7b3UdshPj1XoLCepNrdfP22f
Cm06dXfvfRHOHMvCww56qOcENgrDPkSMRpIN36KvaXD_i232Jc357zBUsjPA
EzqdsfptTke7s--JORs1me0LtmdfSmNgP2Jv6W0SGxXuf343hw0fwMP6L6W_
oagTJYPrBwOdZ93ncl8pASJSTmI8dssW_U87M9Zx-6SFzuQdCdqEoqhtcxNy
EHfzb53Fec8jrfIeAUUVNK0ZBzJpBVHIF_VWGeRZv_U7VyRHLUi7fYZVqRjs
lYl6c6EuLNNt2L4NS1zrCqHckH9amNSJBS8-2bSYSxoVhXn36fPVJq3oRKHy
DKpIzu3GfeVhuIdpqwQZKo3KmbuozfXQbxkQJjWsoaeUxab_GiRyICumXJ35
xNw1QsAUZ_XKfRJgHdij44Bdi3GXx5xRk3oshw4AiEm0BBprl3yxBZ1HaTX6
IgppcYCeaKjmUpk47tpRDMlLH068gvMwwnr6lkHuXnykXxgFiKyfc-VZeiIe
Lsrgetwpq-Uc5uvMDAEdOeqYg6AYMEfiU_Or22MmqDCUxiz6x42evNQKjDPf
yLXnbXKOLttDWpDN-9oXXm41MjrLUDeB0QvJPKImlO5szdQjzi_GgDc9qM3G
e62uVZRZvRD8awL2h7U8Oe6cGycD-hsBNRaE5BttTy2JaKvOqsSvmsUgxW_k
-3XLwqWbQOQUFqwES3VloYswjZebgBc_pLM0dUjUUMau8F7JNf2XK2_wIxFJ
1gRPjBValiXPTLaBdCs-gOqn9_nNhrwH1LfNsUBHD3EZEqzebpt4ZI5E2sIH
1tH_LUcuXFkt_xpSJfYs2CpVAtZesVMScowkTawiDpHYOWPutLhyoO98DIk5
CD7P2gLir2gUkPoRkbjj-i8sSHD0dNoJMAb1Co4AYobA0t0c25N1F819K5ou
7tdnuSxoq3MTdwbJWJeO9bwPpp_weyzOyi-6TLO0dKF2VL2eRI_AERmg6Tjd
MXVdzL_Ri9O71bBxEH6eZmH0bT1BKS_guMNdGSRuX5ZjMbqL0gnmXkrrCxTj
bm7A-mjSOHKl6fVudDYXpIhg2Nd_endbSpoUfLmASxaZYgVVKDojrbu4RsgW
yvu4tkeLSFQdy3ertiGevJQ7Ra61RStmAhXcl0Q_MgqcMxHu-hXyEFFFv5J0
hSAAH5XhkqQA9eHHQiCU6ZaEY50v3fkAYG2d9064ITv_nRtEVequk2SPnrWl
x2TrYjpr7IbmPHaBa5yIxnqL-fj_6a7lAd1Ekb2v104GQfXHwmHrEEeLSq6m
OvENOAg5N28ArKV0Qc969MFkfnsiwH389dl0P-EBdjlAXeItIQJFe0c3rkEF
bAGm193TgfJUCUjEVFGffBHe77B0IBNcodBAtO6M2A8Xit4oWVBUFrLCsTdx
2G7CXOkW-0uFfV1LSznF2KuQegYRDqvHpw3CiHIYb3qqtDzp_iWTp32rE-F4
moiFgFK0PPmMGY6XnH5eLvOhhZBLEwPsdcNN1fP1r7MMmyNBNQGOQ-EQ8gLZ
ehTNkYfnWuiwciLHksVNXybnu7snOBnKy_jQ9k8QW_QkKeUn7mZCPQwDAMlo
t_LBgbuDNmnv8dnIR5Qn1XFAkTJOR8iKCAT2uI3HT9XBDfJy1NGPjbixYOB6
x6OGFCGZsOdxrUCuTey9XUjf1n6oQuQE7XSMKxL6stFCF9VUPh19Pe0T7lT0
79PWoQzgioRDPumuhWxMsnVc3tSyV9J_AinWyGdDB3zJ5y_MIePDXg_ZaMrE
OKDK7GM1cYrgyqdcxovDXjP8Hylyiw5aWZVotYGpbtqcmkTh8oInLID9FQhu
qnKO6rjUamuMZEQEOz98oMx9iZv_RAJNgUgPD5IC3Be2EOE_CdbxVdGiv1FZ
TNyDyNBbIrNgbSi9KwvzOiyHd1GenBNuhkieumPqGYLaCXkO6lmb7sRFQx1d
Zx0bPq1rGznY_jjUeeUDI_ZZqX5ZqYK8m1mgkmYVPE-PeJOAqIXfDH5Qfe5e
ukbvimtGRffHBQUJnQ0LKcEm74cLwJmnU-1ACkSNveYaqNnC2W807YMy8Axo
5vR9hI3OyOnK4TYdoPfn3o_T2yPebyKuyrAR0fmwrtMVixfVXxhNcAE0anx2
jxhofzFK_agCWajED9BjCEXuLRPENcVAfuHCiAQry9RbnkjoEuRkDVz6I0kz
hEj8UkTuw7USDBGIyff_KmyZ0TrgxC6uJ8t1W5-PH0RLTwyoIQyjppPKy0uf
aw-eFfBzJGIyj9r2V0TL7EPgvMczIvbU4d8j0FyfrWsk9DG95HpdAOwgVoCf
VT7l8kwBzGSMlD4161w95ijTFA_oNowh8i2rPuSYk37Zme7VYlzKuFHP5PF4
VnEjw1QbMxkk22BE9WeMc_G7RSk4qkyi9LOCG_b9Zi1vcwoWCBDpIxiypbkK
BONDYhqPew8cwOKBIHXu_JL2c_xj5kDRg2xl0cv2_rySScE50XJ1dlU_7pha
MHrbr02MnT4_Bc9X9-9H6-5i9_pJzmGb8Q6MQTJBM5aiXTBlN07bVxJbZeBS
5UQxQrI5OQxmo-3ajg98qkG61fGzKh2l7Y6s_eGNrCgiXlLJPh_ZtxBPjipo
Z0lc3P4ChuuECqxCb9RwhNhmcMzIip2ttIbTHN-3gP8OlbonqDCEkQU5LqCf
PuoeZ7FKpKOGLotuBttyGEgll-SNB97murpo8Mmx9endQHHRJGTPuyLBl_iZ
8N4iWXGNLImMJaDBscLLuxtt0i7QvC5rwq2IZbNTNXDCeYu1yNvdcMVaba0e
9sZN9Fm3Fi2EW7PWEejAz-XdjIQWh2ufxwf-BoEdofL5C5MixNNhTQjiF7_0
s9qqDhJwrkvFtKT05QzAKzF43wOV81t0Um5Akra6eECxRqMUOH1BsB4HJzQ2
ZFgMNlhkZmNyhTfwmj5o3CDeVVJnttd1MvlnNnLdZuvM1K6wcfwg0xshQwOt
wYAngs9J3VTlVJR4AT4kFr7iM-AxMQwQyDnuQq2h_jzsUxbvrv704yrfzMUz
JrT5EJZgE_-dcISs-A9hKVs_RX2eCVYpltBxj3BgKR_PH9zZ7rB9Of6IhVT6
HekYWNSMi_AQIYtyvOEdi7W2M2cBmC1GhuZ6oZCCPqYizeuk9hPgQWo3dJKV
E4hR5s9s1dPMAj_u2wDSbNs9SGEjB9ALEfY0aRAfJ449BTw55nIdTYpWwd8F
Y-6GLJY5dT5AaDPV-X3JKT6JanvgPSNp5xebjwi_hH9fo9_JmgdUIKjZ7l9T
Px8p6P19WT7cKzN64xeYWKS2qwvnM7hxbuxW31Sttp0yed1X6yHaRBmw4JQ5
45sPARx9

Por supuesto, me alegro del “cese del conflicto armado” pero a qué precio, me pregunto yo. Algo tendré que decir dado que tengo mi propia opinión. Y esto es lo único que diré:

Espero que no afecte a las elecciones. Espero que la gente indiferente no piense “¡anda!, pues esta clase política no será tan mala después de todo”. Porque lo es.

De todas formas, las posibilidades de una reestructuración importante del gobierno han pasado de bajas a escasas.

Eso es todo.

BOLA EXTRA: ver el comunicado de ETA me ha puesto nervioso (estrictamente, casi me hace hervir la sangre), pero claro, qué van a decir, no van a soltar “lo sentimos mucho, somos unos asesinos y los nuestros están bien entre rejas, ¡colgadnos!”. Esto es propaganda. Espero que la estrategia de nuestros políticos esté a la altura de las futuras negociaciones y, por lo que más respeten, espero que se les siga dando caña.

Bien, y si me encuentro algo como esto:

                            var newLine = $("<div>").addClass("menuWindow").html('<ul id="topWindowMenu">' + addLi('search' + incidenceId, 'Search', 'opMenuWindow search') + addLi('mine' + incidenceId, 'Assign to me', 'opMenuWindow mine')  +  addLi('delegate' + incidenceId, 'Delegate', 'opMenuWindow delegate') + addLi('transfer' + incidenceId, 'Transfer', 'opMenuWindow transfer') + addLi('task' + incidenceId, 'Task', 'opMenuWindow tasks') + addLi('print_incidence' + incidenceId, 'Print', 'opMenuWindow print') + addLi('save_incidence' + incidenceId, 'Save', 'opMenuWindow save') + addLi('refresh' + incidenceId, 'Refresh', 'opMenuWindow refresh') + '</ul>');

¿Ahora qué hago? Son 664 caracteres. Más de 8 folios, uno al lado del otro.

EDIT: Una apreciación paterna. De 664 caracteres, los 7 primeros son tabuladores destinados a mejorar la claridad del código. Es decir, el 1.05% de la línea está destinada a mejorar la legibilidad.

Resulta que últimamente, en el trabajo, dedico mucho tiempo a Javascript. Es un lenguaje que cada vez me gusta más: flexible, simple y ortogonal. Es increíble a dónde se llega con 4 reglas bien aplicadas. Eso sí, se enseña MUY mal. Por ello, recomiendo encarecidamente leer la (re)introducción a Javascript por parte de Mozilla:

(…) Javascript probablemente sea el lengauje más incomprendido del mundo.

Volviendo al tema de este post, en Javascript hay dos “valores” especiales: null y undefined. ¿Pero qué significan exactamente y cuándo usar uno u otro? La mejor respuesta la he encontrado en StackOverflow. Traduzco la parte más divertida:

(nombre es undefined)

Programador: ¿qué es nombre?
Javascript: ¿nombre? ¿qué es un  nombre? No sé de qué hablas, ni siquiera has mencionado nombre antes. ¿No te referirás a otro lenguaje?

(nombre = null)

Programador: ¿qué es nombre?
Javascript: no lo sé

(…)

La clave para entender la diferencia radica en la noción de existencia. Si una variable es:

• undefined: para Javascript, no existe. O bien no ha sido declarada o jamás se le asignó un valor.
• null: para Javascript, la variable existe. En algún momento, explícitamente, la variable se estableció a null.

Las principales confusiones vienen de que, en Javascript, las expresión:

undefined == null

es verdadera por efecto del “type coercion” (otro día hablamos más de ello).

No obstante os recuerdo que el operador == no funciona en JS cómo están acostumbrados la mayoría de los programadores. El operador de comparación al uso en JS es === y la expresión:

undefined === null

es falsa como cabía esperar.

Así que, a la hora de usar uno u otro debemos ver si estamos preguntando por la existencia de una variable. Si es el caso, usaremos undefined. En caso de que preguntemos por si la variable contiene un valor seguro o no, como ocurriría en Java, C++ o C# usaremos null.

http://jsperf.com/jquery-dom-creation-techniques

Su ventana de resultados no sólo muestra la mejor y peor ejecución sino una muestra de la desviación típica y una comparativa entre los distintos fragmentos. Además, antes de publicar un test, si nuestro código lanza excepciones, se nos avisará convenientemente. El único fallo que le he visto es que si nuestro código no es gramaticalmente correcto, la página de testing se cuelga en vez de avisarnos. Pero bueno, siempre podemos usar Firebug.

¡No dejeis de echarle un vistazo!

Resulta que el viernes a última hora, un compañero de trabajo y yo modificábamos el mismo archivo pero realizando tareas completamente distintas. Mientra él ajustaba ciertos detalles de apariencia, yo trataba de mejorar algunos aspectos del comportamiento. Mi compañero tiene la costumbre (para mí, arriesgada) de realizar un sólo envío (al finalizar la jornada) al repositorio de versiones mientras que yo suelo subir versiones estables cada menos tiempo (un par de horas o así). El caso que a eso de las 12.00h del viernes mi jefe nos pide mezclar los archivos. Para ello primero subiría los cambios mi compañero y luego yo.

Cual es mi sorpresa cuando mi compañero, abrumado y enfurecido, me pregunta que por qué he subido yo primero y me acusa de haber realizado un montón de cambios. A esto le sigue una sucesión de frases que, sin faltar al respeto en ningún momento, me tachan de soberbio, afirmando que sólo tolero el código que yo creo, que “lo de los demás no vale” y que “por eso tengo encontronazos con todo el mundo” amén de que tengo la mala costumbre de pisar el trabajo de los demás*.

(*) Este asterisco viene de una vez en la que sí metí la pata y me cargué sus cambios al desestimar un conflicto. Volver a una versión anterior y resolver la mezcla me llevó 10 minutos. Es lo bueno de los repositorios de versiones, nada se pierde.

Mi respuesta es invitarlo a comprobar que no he realizado ningún cambio reciente, que el último es de las 10.00h de la mañana y que mi trabajo también incluye la modificación de esos archivos. También le propongo mezclar yo los archivos dado que estimo que no me llevará más de 15 minutos pero él insiste en que ha cambiado demasiado y que la mezcla llevará al menos una hora. Trato de que considere que tales cambios sólo son producto de que mi editor de texto ha reemplazado los tabuladores por espacios y que por eso parece mucho más de lo que hay…

En este momento llegan mis jefes que preguntan que qué pasa. Mi compañero insiste en que he realizado un montón de cambios, que subí los cambios si cerciorame de que nadie estuviera tocando el archivo y que la mezcla durará una hora. De nuevo indico mi intención de asumir la responsabilidad y de mezclar yo dado que reconozco que no pregunté si alguien estaba usando el archivo porque, para mí, el proceso de mezcla es parte del ciclo de desarrollo. Finalmente tomo la siguiente decisión: que se desestimen mis cambios y se reemplace mi versión por la suya. Una vez hecho esto afirmo que podré reconstruir los cambios en unos 15 minutos que es lo que me llevará mezclar el código con mi versión local.

Primeramente indico al visor de diferencias que no tenga en cuenta los espacios en blanco lo que convierte los dos grandes bloques de modificaciones en algunas líneas sueltas. A continuación resuelvo la mezcla en 20 minutos. Ni más ni menos. Compruebo que mis cambios en ese archivo a penas llegan al 10% de los totales. Pero la verdad, esto ya lo sabía.

Lo que me dejó preocupado y es fuente de esta reflexión fueron las acusaciones respecto a lo de que “sólo lo mío vale”. Reconozco que llevaba un cabreo mayúsculo, me dolía la cabeza y apenas podía concentrarme pero me armé de valor, me tragué el orgullo y decidí hablar con mi compañero para decirle en qué no estaba de acuerdo asi como para pedirle disculpas por el estado de preocupación al que le había llevado y dilucidar aquello referente a mi soberbia. Le dije que no era quien para juzgar mi relación con mis compañeros (dado que no he tenido ningún encontronazo con ellos) y que no entendía a qué venía eso de que “sólo lo mío vale” cuando en muchas ocasiones no sólo he estado de acuerdo con él sino que he defendido su posición.

Esto llevó al quid de la cuestión. Reveló que ya se las llevaba guardando un tiempo porque encontraba código que él había escrito, cambiado a algo que hacía lo mismo pero escrito de una manera distinta y he de reconocer que esto es totalmente cierto. Hay código que él escribía con el que yo no me sentía cómodo y cambiaba mientras trabajaba en él. Así, la pregunta es ¿tengo derecho a cambiar el código con el que estoy trabajando?

Quizá a respuesta dependa del escenario y, principalmente, de la metodología de trabajo. Con una división clara de responsabilidades, la situación no debería producirse. La representación estaría diferenciada de la funcionalidad y dado que nuestras tareas serían distintas, el código de cada cual debería presentarse invisible de cara al otro.

Ahora bien, aquí seguimos la metodología scrum y se anima a la existencia un equipo multidisciplinar: no debe haber un sentimiendo de “su trabajo y mi trabajo” sino de “nuestro trabajo”. Entiendo que para esto un ideal es contar con “miembros polivalentes”: cada uno quizá experto en algo en particular pero con voluntad para asumir otro tipo de tareas no relacionadas con sus áreas directas o para identificarse con los objetivos del proyecto. Con el proyecto en sí

Esto significa que si sé de todo, no puedo tener preferencias manifiestas. No puedo rechazar un trabajo porque no es mi área o no me interese: un día toco representación, otro día comportamiento y otro algoritmia o diseño del sistema. Ahora, ¿puedo refactorizar el código que resulta ser mi trabajo en un momento dado? Parece que la respuesta obvia es “si funciona, no lo toques” pero ¿y si no estoy a gusto con mi entorno de trabajo? ¿Si me cuesta leerlo o encontrar alguna funcionalidad es obtuso?, ¿si hay redundancia innecesaria o tramos muertos de código?, ¿nombres desafortunados?, ¿fallos de concepto? No estoy diciendo que en el código de mi compañero haya nada de esto, tan sólo lo cuestiono a un nivel general. Si el código, en definitiva, está mal escrito y me resulta un engorro… ¿entonces qué? Y lo que es peor, si eso va a hacer que produzca un código del que no me siento orgulloso, ¿debería bajar mis estándares por respetar la metodología de otro?

Y para ser del todo franco, a veces sí he pensado que mis refactorizaciones resultan en un mejor código y aquí la pregunta muta y adquiere un aspecto más social y problemático: ¿estoy despreciano el trabajo de otro por llevar a cabo la refactorización? ¿Es un acto de soberbia por mi parte?

La respuesta es muy personal, toma forma analizando la intención tras nuestros actos. No os voy a mentir, a veces, al ver código de mis compañeros he pensado “¿qué m**rd* es esto?” y me he apresurado a cambiarlo convencido de que mi código era “mejor”. Sin embargo, pocas veces hay nada personal en mi proceso de crítica. No pienso que fulano sea peor profesional por escribir peor código… a lo mejor no es lo suyo, cada cual tiene sus fuertes. Creo que la respuesta definitiva tiene que ver también con la predisposición personal a asumir el mismo tipo de situación. ¿Y si fuera mi código el cuestionado? ¿Cómo me sentiría al verlo cambiado por otro haciendo lo mismo?

El trabajo de uno es una cuestión muy personal, un reflejo de los ideales personales, de los mínimos de calidad, una especie de espejo del alma. Valorar el trabajo es tener amor propio. Sus autores, antes de irse a la cama y en privado, saben cuándo un trabajo les representa más o menos, cuándo han puesto más o menos esfuerzo en la labor; sin embargo, ante la crítica externa, el trabajo se convierte en una especie de hijo al que hay que proteger a toda costa. Nuestro carácter se torna defensivo, consideramos el cambio como un insulto a nuestra capacidad, como una ofensa a nuestra inteligencia y a nosotros mismos. Continuando con la metáfora, nos comportamos como esos padres que regañan al profesor por exigir a sus hijos unos cuadernos libre de faltas de ortografía.

Al término de la charla con mi compañero recibí unas disculpas también. He obtenido dos buenos resultados de mantener esa conversación y escribir todo esto:

La primera es que los problemas deben hablarse inmediatamente. Lo he puesto en práctica con mi novia durante 6 años (gracias Bea por escucharme en los buenos y malos momentos), con mi familia, con mis amigos (gracias también a todos por el apoyo prestado) y ahora, profesionalmente. Tengo la certeza de que es lo correcto.

La segunda es que, para mantenerme coherente a mis ideas, debo mostrarme abierto a la crítica y humilde en el talante. Desde que trabajo, me voy a la cama con la sensación del deber cumplido y bien cumplido, eso debería ser suficiente. Si encuentro mi código cambiado preguntaré por qué y esperaré una respuesta convincente.

El efecto colateral que encuentro es que he perdido parte de la confianza a la hora de trabajar y mezclar archivos, no quiero pisar el trabajo de nadie pero tampoco quiero demorar el mío. No me parece justo. Si le toca mezclar a otro, que lo haga, yo estoy dispuesto a ayudar cuanot esté en mi mano… Pero como no hay mal que por bien no venga, ahora me fijo muchísimo más en las mezclas. x)

Esta vez fueron otros 45 minutos; me puse muy nervioso y me trababa cada dos por tres. Es lo más negativo que observé de mi actuación: que me faltaban las palabras. De nuevo se dividió en dos partes: durante la primera tuve que describir mis experiencias trabajando y durante la segunda hacer algo de programación y analizar mis propios algoritmos. Salí muy convencido de que esta parte la había hecho bien pero, mira tú por dónde, hoy mismo me di cuenta de que hubo un par de problemas en mis respuestas.

En fin, espero que mis errores ayuden a otros. Vamos con el contenido de la entrevista.

Tienes 6 minutos para describir tus mejores experiencias de trabajo, qué aspectos te gustaron y cuáles no.

Iba a contar tres de mis experiencias y sólo me dio tiempo a dos: mi trabajo como investigador para el grupo NIL y mi trabajo como autónomo para Kurma y Buroges. El primero porque me introdujo en el mundo de la investigación y este me gustó mucho. Además derivó en una arquitectura reutilizable y práctica. El segundo porque me enseñó a administra mi tiempo, a gestionar mi propio trabajo y a responder de cara a mis jefes directamente.

Lo que no me gusta de mis trabajos es no encontrar el por qué de un fallo. No encontrar la solución no es muy problemático pero no encontrar la causa de una fallo es muy frustrante y lo mejor es dejarlo un rato y volver a ello un poco más tarde.

Escribe una función que imprima los números primos hasta un máximo dado. ¿Cómo justificarías que la solución es correcta? ¿Qué complejidad tiene?

Bueno, el algoritmo que implementé fue la criba de Eratóstenes con la mejora de avanzar sólo hasta la raíz del máximo. Cuando dije que iba a implementar esa solución me quedé atrancado con la palabra criba porque no tenía ni idea de cómo era en inglés.

Este es el código que dí*:

def primes(max):
    limit = int(max **.5)
    sieve = [(n, True] for n in range(1,max+1)]
    sieve[0][1] = False # 1 is not prime
    i = 1
    while i<=limit:
        n = sieve[i]

        # Mark multiplies
        m = 2
        r = m * n
        while r <= max:
            sieve[r][1] = False
            m += 1
            r = m * n

        # Skip already marked
        i += 1
        while i<=limit and not sieve[i][1]:
            i += 1

    for n, is_prime in sieve:
        if is_prime: print n

* Miento, creo que no es el código que  di exactamente y probablemente ahí estuviera uno de mis errores. Es muy probable que me colara en la inicialización de i por tratar de hacer las cosas mejor de lo que debiera en vez de fáciles. Ya veis, primer consejo: primero fácil.

El caso es que ese código obtiene los números primos así que vayamos con las siguientes preguntas.

Justificar que la respuesta es correcta no es fácil: lo que tienes que justificar es que la criba de Eratóstenes no puede imprimir otra cosa que no sean números primos porque todos los múltiplos han sido marcados. Comprobar si la salida son primos viendo si pueden factorizarse, desde luego, no es una opción dado que la factorización no es un problema resoluble en tiempo polinómico.

Por otro lado, la complejidad de la solución, que yo dije, fue O(n). Lo cual, pa empezar, ya está mal. El entrevistador me hizo darme cuenta de que esto no es así porque dependen de la distribución de los primos en el segmento. Todo se debe a este bucle:

        # Skip already marked
        i += 1
        while i<=limit and not sieve[i][1]:
            i += 1

Tal es el que hace que sea impredecible cuándo parará. De no existir el bucle, la complejidad se encontraría en O(n · sqr(n)) no obstante. ¿Por qué? Porque el bucle exterior opera sqr(n) veces mientras que el interios, como mucho, opera n/2 veces (al tachar todos los pares, por ejemplo). Luego el número de iteraciones es sqr(n) · n/2 que pertenece a O(n · sqr(n)). Primer fallo.

Escribe una función que obtenga la mediana de 3 números enteros. ¿Cuántas comparaciones son necesarias? ¿Cuál es la complejidad del problema de la mediana?

Creo que este lo hice bien. Para evitar el follón de ponerme a hacer comparaciones decidí resolver el problema así:

def mediana(a, b, c):
    return sorted([a, b, c])[1]

El entrevistador dijo que era una solución muy elegante pero que quería saber cuántas comparaciones eran necesarias. Le dije que si el problema era equivalente ordenar el vector, el número de comparaciones debía ser 3 poruqe el método de ordenación por selección sólo necesitaba 3 comparaciones.

En cuanto a la complejidad, dado que el problema de la mediana es equivalente a ordenar el vector, tenemos que con un buen algoritmo de ordenación como quicksort o mergesort, la complejidad se va a O(n·log n).

Sabía que lo del número de comparaciones era cierto, pero para demostrároslo en este artículo quería implementar la solución sólo con comparaciones. Ha costado pero aquí está:

def mediana(a, b, c):
    min = a
    med = b
    max = c
    if med < min:
        min, med = med, min
    if max < med:
        med, max = max, med
    if med < min:
        min, med = med, min
    return med

Pensada del tirón no es fácil. Lo mejor es desarrollar el bucle de la ordenación por selección. La idea radica en mantener las relaciones entre min, med y max, a saber: min <= med <= max. Esto puede determinarse en dos comparaciones: min <= med and med <= min que es precisamente el efecto obtenido al no entrar por ninguno de las dos primeros if. El tercero está ahí para comprobar que, tras el cambio del segundo if el valor en min sigue siendo menor que el medio, y corregirlo en caso contrario.

Tienes muchos archivos en tu disco duro y necesitas saber si están repetidos. Describe cómo lo harías. Complejidad.

Se refiere a repetición del contenido. Se trata del problema de ver si dos archivos son iguales. Esto se puede hacer utilizando algoritmos de digest y hashes. Si las claves resultantes no son iguales, seguro que los archivos no son iguales. En caso contrario, si quisiéramos asegurarnos al 100% compararíamos los archivos bien restándolos en memoria, bien poco a poco si no cupiesen enteros. Si no necesitamos el 100% de certeza, podemos aplicar otros algoritmos de hash.

Aquí la fastidié en la complejidad. Pensé: “para tener todas las comprobaciones necesitas el productos cartesiano de los archivos”. Y lo pensé convencido de que así no habría repeticiones por el orden. Convencido porque en el trabajo me había enfrentado a una cosa similar en la que el producto cartesiano sí era la respuesta… pero no aquí. Evidentemente si tienes el conjunto de ficheros {F1, F2} y haces el producto cartesiano consigo mismo, resulta que el conjunto resultante es { (F1, F1), (F1,F2), (F2.F1), (F2, F2)}. Resultando que, donde sólo necesitabas una comparación, te salen 4. La respuesta correcta es la misma que el problema de los apretones de manos. Es decir, ¿en una fiesta de N personas, si todo el mundo se dé la mano con todo el mundo, cuántos apretones hay?.

Bueno pues habrá 1 + 2 + 3 + 4 + … + N-1. Lo cual supone N(N-1)/2 por lo que sí, la función pertenece al O(N^2) pero no siguiendo el razonamiento que yo había hecho. Además, esto es suponiendo un tamaño de archivo pequeño en comparación con el número de archivos en el disco duro. El bucle encargado de lanzar las comparaciones iteraría N(N-1)/2 veces y dentro realizaría una (o varias) operaciones de hash con complejidad en (seamos buenos) O(l) donde l es el tamaño medio del archivo. Mi scrummaster y estudioso de la narrativa interactiva, Mel Hython, me hizo ver que todo dependía de la relación entre l y N. Considerando l como la media del tamaño del archivo tendríamos L = l · N con L el tamaño total de todos los archivos. Así, despejando l tendríamos que l = L/N y por tanto la complejidad quedaría como N(N-1)·L/N·2 = L(N-1)/2. Como N puede variar entre 1 (muy pocos archivos muy grandes) a L (muchos archivos muy pequeños), la complejidad varía entre O(L) (cuando N=1) y O(L^2 ) (cuando N=L).

Y bueno, eso es todo. Como veis, el último fallo bastante tonto. Lo podría haber sacado de haber pensado un poquito pero me traicionaron los nervios y razoné de forma equivocada… Me alegro no obstante de haberme dado cuenta de mis fallos y sé que he aprendido de ellos. También he aprendido que no trabajo bien bajo tanta presión… Ay.

Una anécdota antes de terminar es que recibí el último correo, avisándome de que estaba fuera del proceso, a nombre de otro. Así, viendo la estructura del mismo parecía el típico correo genérico así que supuse que no era el único en recibir malas noticias hoy De todas formas escribí a mi contacto en recursos humanos para que me lo aclarara y, no habrían pasado ni cinco minutos, me llamó al móvil para decirme que, desafortunadamente, el mail sí que era para mi: que según el entrevistador, lo había hecho bien “pero no lo suficiente” y que lo volviese a intentar en 12 meses. Le contesté pidiendo que si podía echar un vistazo a los informes sobre mí, que esp me ayudaría a mejorar. Los estoy esperando, pero no creo que reciba nada.

Y esa ha sido mi corta historia con Google. No me preocupa demasiado, no es malo para nada e, insisto, ando muy contento donde estoy y seguro que más de uno hasta se alegra de que no me vaya.

Buscando cosas que no tenían nada que ver, descubro el módulo pprint que seguro que, a la hora de depurar, os resuelve la vida a más de uno. Se trata de un módulo que aúna funcionalidad para representar tipos de datos arbitrariamente complejos de manera “bonita” (el módulo se llama pretty-print).

La funcionalidad más básica la proporciona la función pprint() del módulo. La función toma los siguientes parámetros:

• object, el objeto que quieres imprimir.
• stream, opcional, dónde lo quieres imprimir. Por defecto en la salida estándar.
• indent, opcional, cuántas sangrías (indentaciones) por nivel. Por defecto 1.
• depth, opcional, nivel máximo a partir del cual los objetos más profundos se reemplazan por ‘…’. Por defecto, desactivado.
• width, opcional, anchura máxima antes de romper una línea. Por defecto 80.

Os dejo una comparación para que veais a qué me refiero:

import pprint

a = {'nombre completo':{'nombre':'Salvador', 'apellidos':'de la Puente'}, 'edad':25, 'puestos':[('programador .NET',2006),('administrador de sistemas', 2008),('investigador', 2010)]}
print a
pprint.pprint(a)

Y su salida:

>>> print a
{'edad': 25, 'nombre completo': {'apellidos': 'de la Puente', 'nombre': 'Salvador'}, 'puestos': [('programador .NET', 2006), ('administrador de sistemas', 2008), ('investigador', 2010)]}
>>> pprint.pprint(a)
{'edad': 25,
 'nombre completo': {'apellidos': 'de la Puente', 'nombre': 'Salvador'},
 'puestos': [('programador .NET', 2006),
             ('administrador de sistemas', 2008),
             ('investigador', 2010)]}

¿Veis qué útil?

Fueron unos 45-50min de entrevista en Inglés con uno de los ingenieros de Google. Para mi el tiempo se me hizo eterno y entre los nervios, el calor, el teléfono y mi dicción inglesa, me dio la impresión de que lo había hecho fatal aunque reconocía que era fácil. De hecho la sensación era “avergonzado de lo mal que lo había hecho para lo fácil que era”. Afortunadamente no fue así.

La entrevista se dividión en tres partes: una parte de teoría y dos problemas. Aunque me habían pedido Java o C++, me pude defender perfectamente en Python y a continuación os cuento un poco la entrevista, cómo respondí y cómo me hubiera gustado responder…

En Python ¿Qué diferencia existe entre una tupla y una lista?

Lo primero que respondí fue que la tupla es inmutable mientras que la lista no. Sin embargo el entrevistador estaba más interesado en las diferencias a nivel semántico. No entendí lo que quiso decir hasta que me dijo “Si tuvieras que devolver un entero, una cadena y un objeto de una función… ¿qué usarías?” Aquí –dije– usaría sin duda una tupla.

Sí, la diferencia a la que se refería era a la del concepto matemático detrás de la tupla. La tupla es la forma de representar los elementos del producto cartesiano de dos conjuntos. Los conjuntos pueden no tener nada que ver entre sí. Visto de otr forma, como leí una vez por ahí, una “tupla es una estructura de C ligera“. Cuando trabajas con listas, se supone que los tipos de los elementos son el mismo o están relacionados.

¿Por qué en Java no hay que liberar la memoria de un objeto?

Bueno, pues porque Java tiene un mecanismo llamado recolector de basura (garbage collector) encargado de contabilizar qué objetos están siendo referenciados y cuáles no y liberar el espacio de los que no.

¿Qué implicaciones en rendimiento tiene el recolector de basura?

A esta no supe responder. Por supuesto, las hay, pero no sabía cuantificarlas. No obstante, mi coleg Adri me pasó este artículo de IBM sobre el recolector de basura que afirma que la sobrecarga inducida por el recolector de Java apenas sobrecarga el rendimiento e incluso hace que la reserva de memoria sea más rápida de lo que es en C.

¿Qué es una función lambda y para qué se utilizan?

La primera vez que dijo lambda no lo entendí así que le pedí si podía escribir la palabra en el Google Doc que compartíamos. Cuando vi escrito lambda afirmé y contesté.

Las funciones lambda son funciones sin nombre que devuelven una sola expresión. En python una función lambda tiene la siguiente pinta:

>>> (lambda x:x**2)(9) # Esta función sin nombre, aplicada sobre 9, devuelve el cuadrado de 9
81

Las funciones lambda son útiles en el contexto de uso junto con funciones de segundo orden. Esto es, funciones capaces de acepta otra funciones o devolver nuevas funciones. Algunas funciones de segundo orden son map, filter, sort… Os dejo un ejemplo de utilidad:

def elevado_a (exponente):
return lambda x : x**exponente # Devuelve una nueva función que eleva al exponente dado

cuadrado = elevado_a(2) # Ahora cuadrado es una función que eleva a 2
cubo = elevado_a(3) # Ahora cubo es una función que eleva a 3

print cuadrado(5) # Imprimirá 25
print cubo(3) # Imprimirá 27
print elevado_a(4)(2) # Imprimirá 16 (2 elevado a 4)

¿Diferencias entre un set y un hash set en la STL?

Creo que esta pregunta me salió muy bien. La STL es la Standard Template Library de C++. Primero le dije que hacía mucho tiempo que no tocaba la STL aunque estaba acostumbrado a tratar con los tipos de datos que formaban la librería. De esta forma me preguntó la diferencia entre un set (un conjunto) y un hash set (un conjunto hash).

La diferencia radica en el rendimiento de acceso e inserción. Normalmente, los conjuntos se implementan utilizando un árbol de búsqueda por lo que tanto la inserción como la recuperación de un elemento se realizan en O(log n) para el caso medio.

Con un hash set, el conjunto se implementa como una tabla hash por lo que los accesos e inserciones se realizan en O(1) para el caso medio. En el caso peor, si se producen un montón de colisiones y todos los elementos se encuentran en el mismo bucket de la tabla hash, si estos buckets están bien implementados es posible que sean árboles de búsqueda por lo que a las malas, tendrá el mismo rendimiento que un set normal.

Haz una función que, tomando una lista de listas que representa los píxeles de una imagen, rote la imagen 90º a la derecha.

Este fue el primero de los problemas. Lo primero que respondí es que el problema se resolvía con cuaterniones pero que para 90º seguro que podía obtener otra solución más sencilla.

La clave estaba en darse cuenta de que la rotación a la derecha era como obtener la traspuesta del array bidimensional y luego tomar cada fila al reves. La refleja de la traspuesta. Así, dada la sigiuente imagen:

[
  [1, 2, 3],
  [4, 5, 6]
]

El objetivo era obtener:

[
  [4, 1],
  [5, 2],
  [6, 3]
[

La solución que implemente fue:

def rotate(image):
l = len(image[0])
new_image = []
for pixel in range(l):
aux = reverse([subelement[pixel] for subelement in image])
new_image.append(aux)

return new_image

Podría haber recorrido los píxeles directamente al revés, pero bueno, así queda claro que es la refleja de la traspuesta y me curo en salud.

Considera un tablero de ajedrez, un alfil en una casilla y una casilla objetivo a la que tiene que llegar el alfil. Crea una función que devuelva en cuántos movimientos llega el alfil a la casilla.

Esta es la última pregunta y la que peor creía que me había saludo. No obstante, bien pensado, tampoco destiné más de 15  minutos (que no es mucho) a cada probelma por lo que imagino que eso, sumado a que el entrevistador no hacía más que repetir la frase "make sense" eran indicadores de que iba por el buen camino. Mi desconcierto vino de la representación del tablero de ejemplo (donde SS y TT son origen y destino respectivamente:

00 SS 02 TT 04 05 06 07
08 09 10 11 12 13 14 15
16 17 ...

El caso es que mi cerebro se dividió entre una solución numérica, que trabajara con los números de las casillas buscando alguna relación entre ellos y otra algoritmica, calculando las diagonales y demás. Tenía claro que si no se llegaba en 1 movimiento, se llegaba en 2 (siempre que estuviera en el mismo color, claro). Pero no lo dije.

En un rato el entrevistador me preguntó si no había localizado una cota y le dije que sí, que la cota era evidentemente 2. Entonces, al decirlo en alto me di cuenta de que era siempre 2 a menos que ya estuvieran alineados.

Para ver si estaban alineados podría calcular la diagonal pero la iluminación me vino justo antes del fin de la entrevista, cuando me di cuenta de que si estaban alineados por la diagonal entonces, entre el origen y el destino debía haber un cuadrado, por lo que bastaba con ver si la distancia entre las coordenadas X e Y del origen y el destino eran iguales. Así de tonto:

def movements(source, target):
ss = (source % 8, int(source / 8))
    tt = (target % 8, int(target / 8))
if abs(ss[0]-tt[0]) == abs(ss[1]-tt[1]):
        return 1
return 2

Y eso fue todo, la próxima entrevista la tendré este Viernes, ya os contaré (qué nervios).

Este esquema de memoria es muy versátil porque representa listas de elementos. Casi cualquier estructura de datos puede representarse en una lista y, utilizando punteros, las listas no tienen por qué ser homogeneas. Podemos guardar en ellas de todo e identificar cada objeto guardado por el índice dentro de la lista. En otras palabras, por su posición.

Traducir una lista de objetos a un segmento de la memoria es tan simple como conocer el número de elementos, el tamaño de los mismos y la posición del primero.

Sobra decir que al concepto de lista está unido, muy fuertemente, el concepto de orden y posición.

Si hablamos de colecciones de elementos sin orden, como por ejemplo un conjunto, dónde no nos interesa en qué posición está un objeto, tan sólo si está o no está, encontramos que las listas dejan de resolver el problema elegantemente. Sin duda añadir un objeto a una lista es tan sencillo como añadir un nuevo elemento a una lista… ¿o no? Es un conjunto y en los conjuntos, formalmente descritos, no hay dos elementos iguales por lo que nos convendría no tener repeticiones. Así que antes de insertar un objeto habrá que buscarlo en la lista lo que en el mejor de los casos, tiene una complejidad de O(log n) y en el caso medio, de O(n). En palabras sencillas, buscar es una tarea sencilla pero cara en colecciones muy grandes.

Además, encontrar un objeto del conjunto, al no tener un orden predeterminado (nadie nos asegura que siempre metamos A primero, B segundo,  C tercero…), requiere una búsqueda también. Y eliminarlo, por definición requiere primero encontrarlo, así que tres cuartos de lo mismo.

Con esto en mente, un pedazo de ingeniero eléctrico, Dudley Allen Buck, describió un nuevo tipo de memoria llamada asociativa o direccionada por contenido. Esta memoria toma un objeto entero y lo busca en su interior pero esta búsqueda está hecha de tal forma que el acceso sigue siendo constante. ¿Magia? Nop, ¡ingenio!

La solución por hardware es muy simple aunque el diseño final de la memoria resulta más complicado que las memorias RAM corrientes. Consiste en, mediante circuitería, comparar el elemento que se desea recuperar con toda la memoria. Evidentemente, un circuito de comparación por cada bit en la memoria son muchos miles de millones de circuitos de comparación lo que encarece notablemente el coste.

La solución por software es más complicada pero mucho más barata y consiste en utilizar una tabla hash. La idea, no obstante, es muy sencilla: tomamos un objeto, le hacemos alguna transformación y lo convertimos en un número y tomamos el numero como la posición en una lista donde debería ir el objeto.

Ahora, si queremos comprobar si  un objeto está en el conjunto, basta con realizar la transformación e ir a mirar justo a ese lugar de la lista.

A esa transformación se la llama función hash y a la lista de elementos, tabla hash.

Funciones hash

Las funciones hash son procedimientos matemáticos que condensan información. Toman un objeto complejo y devuelven por lo general un número entero que lo representa de alguna manera llamado valor, código o clave hash.

Tienen muchos usos y se espera de ellas que cumplan una serie de propiedades:

• Bajo coste. Si el procedimiento de cómputo del valor es costoso, entonces lo que ganamos evitando la búsqueda, lo perdemos realizando la transformación.
• Determinista. La función no puede depender de un estado o involucrar un procedimiento aleatorio o el valor obtenido para un objeto podría no ser siempre el mismo con lo que perderíamos la ventaja de la búsqueda.
• Continuidad. Objetos similares deberían producir números cercanos. Es como funciona la corrección automática de términos de búsqueda de Google, por ejemplo. Quiere decir que “complejo” y “conplego” deberían convertirse en números muy parecidos.
• Rango variable. El rango es el conjunto de todos los posibles valores de salida de una función. El rango de una función hash es, por lo general, finito. Esto significa que puede producir hasta un número fijo de resultados y no más. Aun así, existen generadores de  funciones hash que, indicando el tamaño del nuevo rango, producen una nueva función hash que puede ser:
• Diferente a la función para el rango anterior por lo que aplicar la nueva función a un objeto devendrá en un valor hash distinto del que se hubiese obtenido con la función vieja.
• Parecida a la función para el rango anterior por lo que es muy probable que al aplicar la nueva función a un objeto, el resultado sea el mismo o muy similar al que se hubiese obtenido previamente.
• Minimización de colisiones o uniformidad. Llegamos al cogollo del asunto. Hemos dicho que el rango de una función hash es finito por lo que si el conjunto de datos de entrada es más grande que el rango, lógicamente algún valor se tendrá que repetir (intenta empaquetar 90 libros en 20 cajas, a ver cómo lo haces). Pues bien, cada vez que la función produce el mismo valor para un par de objetos se dice que ha habido una colisión. Es deseable que las funciones hash minimizen el número de colisiones y que distribuyan los datos de entrada uniformemente sobre el rango (en el ejemplo de los libros, es deseable que haya como mucho, 5 libros por caja).

Tablas hash

Las tablas hash también reciven el nombre de diccionarios porque son conjuntos de pares clave-valor donde la clave es el resultado de aplicar la función hash sobre el valor. Se dice que la búsqueda se realiza por clave para recuperar un valor.

Ahora que sabemos qué es una función hash, basta con pensar que una tabla hash es una lista con un número de posiciones disponibles igual al rango de la función hash. Como hemos comentado anteriormente, la función hash puede producir que dos objetos distintos nos lleven a la misma posición, por ello una tabla hash no guarda directamente los elementos sino una lista de los mismos.

Así, cada posición de la tabla hash se denomina bucket o cubo porque almacena los objetos con el mismo valor hash.

Algunas tablas guardan el elementos más accedido primero y luego los demás de manera que cuando se trata de buscar un elemento en concreto, se le aplica la función, se obtiene el valor, se visit la posición correspondiente y se compara con el primer elemento. Es muy probable que se trate de este pero, si no lo es, sencillamente se busca en la lista del bucket.

Las tablas hash poseen un determinado umbral de llenado. Una vez rebasado, la tabla se expande para poder albergar más elementos. La nueva tabla puede requerir una función hash distinta así que le toca extraer todos los elementos, pasarles la nueva función y volverlos a incluir en la nueva. Otro procedimiento consiste en crear una nueva tabla y conservar la vieja, buscar en ambas, insertar sólo en la nueva y cuando la vieja quede vacía, eliminarla.

La principal ventaja de una tabla hash es, sin duda, la velocidad. La desventaja principal es que elegir una función de hash que funcione bien de forma general es prácticamente imposible y escoger una para un tipo de datos dado es más una cuestión de arte e intuición. Si no se escoge la función hash cuidadosamente, el número de colisiones podría dispararse y el rendimiento decaer considerablemente.

Usos y aplicaciones

Muchos lenguajes de programación modernos incluyen las tablas hash como tipo de dato básico. El uso de tablas hash tiene sus máximos exponentes en:

1. Arrays asociativos. Listas cuyos índices suelen ser cadenas de texto, aunque también podrían ser cualquier cosa. Por ejemplo, el número de teléfono de 555-666-777 está en un array asociativo indexado bajo el nombre de “John”.
2. Indexación de bases de datos. Si sabemos de antemano que en una base de datos vamos a realizar búsquedas de un determinado campo, podemos usar una tabla hash aplicada sobre este campo para recuperar la información rápidamente.
3. Conjuntos. Un conjunto es, directamente, una tabla hash. El orden no importa y (dejando a parte o resolviendo las colisiones como hemos visto) la función hash nos permite ver si el elemento está contenido o no en tiempo constante.
4. Representación de objetos. Muchos lenguajes de programación modernos como Perl, Python, Lua o Javascript usan tablas hash para representar sus objetos. Las claves suelen ser los nombres de sus miembros o métodos (sean funciones, tipos simples o tipos compuestos) mientras que los valores son punteros a los respectivos miembros o métodos.

Conclusiones

De todos sus usos, la representación de objetos es la más interesante. Los lenguajes verdaderamente orientados a objetos, los cuales definen su entorno de ejecución en base a sí mismos, gozan de un dinamismo y versatilidad extremas. Practicamente cualquier cosa puede representarse como un conjunto de propiedades con nombre y valor, esto es, un diccionario. Además, la inclusión de tipos ejecutables (es decir, variables que pueden contener programas) permiten todo tipo de transformaciones en los objetos: añadir métodos, quitarlos, redefinirlos…

Desde mi punto de vista, me parece la memoria del futuro, una especie de estructura de datos universal.