sgoliver.net blog

Una cita no falta de razón:

“A día de hoy, la programación es una carrera entre los ingenieros de software tratando de construir mayores y mejores programas a prueba de idiotas, y el universo intentando producir mayores y mejores idiotas. Por el momento el universo va ganando”. Rich Cook.

Conclusión, tanto si estamos en un lado como en el otro, sigamos esforzándonos.

Un poco de humor para soportar el fin de mis merecidas vacaciones. Nadando entre millones de artículos pendientes de leer en mi Google Reader me encuentro una lista de los 10 lenguajes de programación más extraños jamás creados. Conocía ya algunos de ellos, pero otros me han llamado enormemente la atención tanto por su absurda sintáxis como por su dudosa utilidad práctica.

Entre los lenguajes mencionados se encuentran algunos como:

• Ook!, que según su autor está especialmente diseñado para orangutanes y tan solo usa 3 palabras reservadas (Ook., Ook! y Ook?).
• Whitespace, que viene a vengar la tremenda injusticia de los lenguajes actuales al ignorar los caracteres no visibles y basa toda su sintáxis en los espacios, tabuladores y retornos de carro.
• LOLCODE, que en España equivaldría a algo así como el lenguaje de programación HOYGAN, escrito completamente en mayúsculas y en inglés macarrónico.
• reMorse, que como puede deducirse fácilmente de su nombre basa toda su sintáxis en puntos y guiones.
• False, cuya sintáxis es indescriptible, tan solo comparable con lo que aparece al editar un fichero ejecutable con el bloc de notas. Para muestra un ejemplo de un programa que imprime todos los números primos entre 0 y 100: “99 9[1-$][\$@$@$@$@\/*=[1-$[%\1-$@]?0=[\$.' ,\]?]?]#”.
• Whenever, un lenguaje en el que la instrucciones no tienen por qué ejecutarse en el orden en que fueron escritas, sino en el orden que el intérprete del lenguaje decida. Absurdo? Esperpéntico? Inutil?

En fin, en la lista original se mencionan algunos lenguajes más igual de surrealistas, pero se han olvidado de uno de los más importantes, Brainfuck, para mí el rey de todos los lenguajes de programación esotéricos, con una sintáxis también basada en signos de puntuación de lo más variopinto.

¿Cuál de estos lenguajes elegiréis para vuestro próximo proyecto? ¿Alguien se atreve a proponerlos en su empresa?

Un poco de humor para hacer algo más ameno el día. Navegando por un montón de noticias atrasadas he encontrado un artículo que me ha hecho sonreir al menos por un momento.

Entre la enorme cantidad de metodologías o filosofías de desarrollo y pruebas de software que nos inundan hoy día (dígase por ejemplo TDD, DDD, …) el autor del artículo citado ha encontrado un nuevo patrón que ha dado en llamar Desarrollo de Software al estilo Paris Hilton, o siguiendo la nomenclatura tradicional PDD (Paris Driven Development).

En tono jocoso (en el que la pobre Paris sale bastante mal parada), el autor define que esta estrategia de desarrollo se basa en cuatro pilares principales (traduzco muy por encima y añado mis comentarios):

1. Nunca aprender nada nuevo, o dicho de otra forma, ¿para qué aprender cosas nuevas si ya me defiendo con mi lenguaje de siempre? Obviamente el mundo del desarrollo de software obliga a estar aprendiendo continuamente si no quieres quedarte obsoleto, pero es cierto que esta tendencia de muchos programadores se observa con más frecuencia de la debida.
2. Pensar que eres el centro del universo. Esto también es bastante común, y no sólo en relación a la programación. Desgraciadamente, en todos los lugares imaginables hay personas que creen que el mundo gira alrededor de ellas, sin embargo, es especialmente grave encontrar este patrón en un equipo de desarrollo. La programación es normalmente un “deporte de equipo”, lo contrario no trae nada bueno, el sol hace ya bastante tiempo que dejó de girar alrededor de la tierra.
3. Parecer ocupado pero no hacer nada. Todo un clásico, no hay mucho más que decir, tan sólo una frase extraída del mismo blog: “La productividad se mide en resultados tangibles, no en el tiempo y energía invertidos”.
4. Hacer responsable a otros de tus propios errores, o como dice la n-ésima ley de Murphy: “Lo bueno de trabajar en equipo es que siempre puedes echar la culpa a otro”.

Afortunadamente no soy testigo diario de la utilización de esta metodología, al menos no en su máxima expresión, pero visto lo visto sólo me gustaría hacer una pequeña encuesta, ¿se utiliza en vuestro trabajo habitual la metodología PDD? ¿Conocéis mucha gente que la utilice? Por el bien de todos, espero que no.