El programador (una apología)

Me apetece hacer apología del puesto de programador, porque creo que es necesario por dos motivos fundamentales y relacionados: no se le considera un puesto apetecible por ser jerárquicamente bajo y no se tiene conciencia de que la experiencia en la programación sea útil. En resumen, que el puesto de programador no se considera de futuro[1]. Pero no es el futuro profesional del programador[2] de lo que quiero hacer apología, sino de la labor del programador en si: difícil pero necesaria y apasionante[3].

Los buenos programadores son imprescindibles para que este mundo funcione. En la eterna, manida y estéril discusión de las atribuciones profesionales se suele denostar la labor de programador en favor de la figura del arquitecto de software. No voy a entrar aquí en lo importante de una buena dirección y coordinación en un proyecto de desarrollo (que lo es), sino de lo importante que es el trabajo de base. Porque el de programador en un puesto intrínsecamente bajo desde el punto de vista jerárquico. ¿Significa eso que es un trabajo rutinario, sin retos ni creatividad? En absoluto. Es un trabajo muy decisivo, a veces creativo y de gran responsabilidad casi por definición.

Es difícil porque hacer software es intrínsecamente difícil[4][5] Y el creer que toda la dificultad se puede abstraer del programador hacia arriba en la jerarquía no deja de ser una especie de pensamiento mágico alejado de toda realidad. Es prácticamente imposible hacer un análisis y diseño completos sin resquicios y teniendo en cuenta todos los detalles del sistema final, tanto funcionales como de rendimiento y seguridad. Es muy frecuente que aparezcan aspectos dependientes de que la implementación sea óptima y adecuada al uso del sistema final.

Es de una gran responsabilidad porque, entre otras cosas, es muy fácil hacerlo mal y no es trivial descubrirlo[6]. El programador moldea con sus manos el sistema final que va estar funcionando, transforma en realidad, en funcional, un concepto ideal. Y es el que más directamente que se da de bruces con las limitaciones del mundo real, de las herramientas y los sistemas. Es el que, si es brillante, es capaz de dar soluciones a esas limitaciones o al menos no acrecentarlas. Pero un programador no muy hábil o simplemente poco disciplinado o descuidado puede provocar errores, tanto fáciles de detectar como demasiado sutiles para ser detectados cuando deben, en la fase más temprana posible del desarrollo.[7]

Tengo que decir que lo que yo entiendo por programador es lo que a veces se denomina "desarrollador", algo un poco más amplio que solo tirar líneas, pero me niego a renunciar a usar el término: me gusta decir programador, me gusta programar.

[1] Y es posible que no lo sea :( Me gustaría pensar que, por lo que cuento después, lo es.
[2] Bueno, hay muchos futuros dentro del desarrollo. Uno, ascender. Otro, especializarse. Pero bueno del futuro profesional prefiero que hablen los comentaristas...
[3] Obviamente hay mucho que comentar de los aspectos sociales del programador, que pueden condicionar, pero no hablaré de ellos. Para saber más pasa por aquí ( bueno, o por aquí)
[4] "The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence" No silver Bullet, Frederick P. Brooks
[5] Un poco más actual: Software Is Hard, Kyle Wilson
[6] Me gusta mucho la frase de Brian Kernighan: "Depurar es el doble de difícil que escribir el código por primera vez. Entonces, si escribes código tan inteligentemente como te sea posible, no vas a ser, por definición, suficientemente listo para depurarlo" Depurar es otra habilidad quizás no demasiado valorada del programador experto.
[7] Metodologías de desarrollo y/o testeo adecuadas y acordes con el proyecto aceleran la caza de errores, pero la disciplina y experiencia del programador son la base del desarrollo de calidad.

"El programador (una apología)" en barrapunto

¿Está acabando internet con el contenido extenso?

Se suele recordar mucho últimamente que el vídeo mató a la estrella de la radio por aquello del cambio de formato y de la (no) adaptación de la industria musical a esos nuevos formatos. Lo mismo seguramente se puede ampliar al resto de los contenidos culturales, en el amplio sentido de la palabra, y sobre todo al libro ¿Mató internet el contenido extenso? ¿Mató internet a los libros?

El caso es que últimamente he visto varios casos en los cuales el modo de publicación es controvertido porque se trata de contenidos de un volumen grande, más grande que un post de blog, para entendernos. Primero fue Ulrich Drepper que dudó que opción tomar y tomó la resolución de publicarlo por partes en LWN. Ian Lance Taylor ha publicado un número enorme de post, veinte, muy interesantes (para mi al menos ;) ) sobre enlazadores, pero demuestra claramente que el blog no sirve para crear contenidos amplios y legibles a la vez.

¿Cual es la tendencia? Hemos visto decaer sitios de generación y promoción de contenidos que premiaban calidad y extensión, como k5 o libertonia. Triunfan sitios del tipo digg, reddit o meneame en los que sólo se hace referencia y se extracta brevemente. No se me entienda mal, los sitios me parecen útiles, programming.reddit y tecnologia.meneame los visito y uso. Pero creo que tienden a ser autocontenidos, a quedarse más en si mismos que a servir para lo que probablemente deberían servir: promocionar contenido de calidad. Es la tendencia al minimalismo, tanto en la referencia como en el comentario: estos sistemas premian la brevedad y la concisión, con buenas razones, pero en perjuicio de contenido espeso y en favor del impactante. /. en las dos versiones que uso estaría a medio camino, pero no se acaba de librar de este mal... Es el signo de los tiempos, en los que la sobrecarga informativa va acompañada de atención parcial continuada...

Pues bueno, Charles Petzold, que escribe mucho mejor que yo y que además tiene un buen curriculum de libros espesos publicados reflexiona sobre ello en Hard Work, No Pay: What's the Point?, teniendo en cuenta que lo hace, al menos en parte, desde el punto de vista de un autor. Se pregunta ¿por qué libros y no entradas en blogs? Y responde (citraduzco un poco al vuelo)

Es fácil convencerse de que los pedacitos de prosa representan el nivel óptimo de granularidad de información. Es parte de la visión utópica de la web como una plétora de páginas débilmente enlazadas cuya sinergia genera toda la información que necesitamos. Esta ilusión está afectando a la manera en la que aprendemos y tengo miedo de que no tengamos una visión más amplia y completa que solo un libro puede proporcionar. Un buen autor encontrará una selva poco manejable de información y cortará una senda coherente para pasar a través de ella, a través de una narrativa que enlaza el material.

Respuesta que me ha gustado mucho porque ilustra muy bien el tipo de libros que deberían sobrevivir a la mencionada sobrecarga informativa: aquellos que son capaces de establecer un poco de orden y hacer un poco más comprensible la realidad fragmentada.

¿Está acabando internet con el contenido extenso? en barrapunto

Lo que todo programador debería saber sobre la memoria

Así titula Ulrich Drepper un artículo sobre los posibles cuellos de botella que se generan en las arquitecturas modernas de uso común, explicando el comportamiento de las caches de CPU, el diseño de los controladores de memoria, el DMA... Debería ser útil para esos momentos en los que las abstracciones que usamos empiezan a fallar y debemos conocer lo que hay debajo.

El modo de publicarlo es un poco, bueno, llamémosle arcaico, pero nos conformaremos porque el contenido lo merece, y porque es el deseo del autor, claro... El caso es que se va a publicar por partes en LWN.net y al comienzo serán accesibles solo para suscriptores y posteriormente para el resto. Al final publicarán la versión pdf que probablemente será muy interesante para imprimir. Actualización (22/11/07): Ya está disponible la versión en pdf: "What Every Programmer Should Know About Memory" por Ulrich Drepper

He ido actualizando esta entrada conforme se han liberado las todas las partes del documento, muy interesantes:

• What every programmer should know about memory, Part 1
• Memory part 2: CPU caches
• Memory part 3: Virtual Memory
• Memory part 4: NUMA support
• Memory part 5: What programmers can do
• Memory part 6: More things programmers can do
• Memory part 7: Memory performance tools
• Memory part 8: Future technologies
• Memory part 9: Appendices and bibliographys

Bonus Track: Como creo que pega en esta entrada, pongo el link a unas charlas con diapositivas de Herb Sutter sobre temas similares: Machine Architecture: Things Your Programming Language Never Told You (jejeje, Sutter y Drepper ¿lo mejor de los los dos mundos?)

Lo que todo programador debería saber sobre la memoria en barrapunto

Paul Graham Facts

Paul Graham Facts. Sólo apto para quien sepa quien es Paul Graham (bueno, y aún así...) Ejemplo: Paul Graham is so good, he always tips using $2.56 cheques made out by Donald Knuth

Actualización: por si alguien es tan masoquista de quedarse con ganas de más: Bruce Schneier Facts. Espero que me sepan perdonar :)

Paul Graham Facts en barrapunto

Intel anuncia un compilador con memoria transaccional

Intel está trabajando en un compilador que gestiona memoria transaccional y que está ya en estado de prototipo. Al parecer se puede descargar y usar y para hacernos una idea ponen un miniejemplo de uso. Parece que esta tecnología está saltando de la investigación académica a la industria, habrá que ir viendo lo que da de si, porque, como ya comenté por aquí, hay gente que no acaba de verlo claro.

Intel anuncia un compilador con memoria transaccional en barrapunto

¿Necesitan una reescritura las bases de datos relacionales?

Hoy en High Scalability enlazan a un artículo que 'denuncia' la obsolescencia del diseño e implementación de las actuales bases de datos relacionales: The End of an Architectural Era (It’s Time for a Complete Rewrite). Con una implementación que tiene en cuenta las arquitecturas actuales con sus cuellos de botella en cuanto a CPU, memoria y recursos de red, como ajustar el tamaño de los árboles-B al tamaño de la caché L2 o hacer los procesos de consulta en cada nodo con un solo hilo han conseguido rebajar hasta en dos órdenes de magnitud en el test TPC-C.

Este artículo forma una serie con “One Size Fits All”: An Idea Whose Time Has Come and Gone y One Size Fits All? – Part 2: Benchmarking Results en los que resalta no solo que el diseño y la implementación de los RDBMS son algo obsoleto sino que no son lo más adecuado para todos los escenarios (como ya se han dado cuenta los que se han encontrado con el problema)

Y ya un poco offtopic en este tema me gustaría resaltar una frase:

In the programming language community, there has been an explosion of “little languages” such as Python, Perl, Ruby and PHP. The idea is that one should use the best language available for any particular task at hand. Also little languages are attractive because they are easier to learn than general purpose languages. From afar, this phenomenon apears to be the death of “one size fits all” in the programming language world

O sea que en el futuro se llevará el programador políglota (bueno, o no, depende de quien mande...)

¿Necesitan una reescritura las bases de datos relacionales? en barrapunto

Sam Ruby y Erlang

Asisto con una mezcla de envidia y escepticismo a la conversión a Erlang de Sam Ruby. Sam Ruby es un típico goleor tecnológico ™ Siempre está a la última en cuanto a estándares y lenguajes sobre la web. De hecho, algunos los hace él :) Como buen experimentador de tecnología, como buen gurú, hace sus apuestas de futuro. La última apuesta de Ruby, muy interesante, es a varias bandas: REST, Hadoop, Erlang/OTP y los Microformatos.

Asisto con envidia sobre todo por la fase de enamoramiento compulsivo por la que está pasando (muy interesante para los demás, por cierto) con Erlang, aunque resulta extraña en alguien con tanta experiencia como él. Sino no se puede explicar que diga, en su última entrada, algo tan bonito como:

Con muchos frameworks y lenguajes, tengo la sensación de que estoy trabajando con un armario de metal con capas de pintura para barcos; cuando se le hace un rasguño salen a relucir los bordes afilados. Con Erlang tengo la sensación de un armario victoriano de caoba; cuando uno raya en la madera simplemente sale a relucir más valiosa madera.

Pero este enamoramiento nos está dando a los demás la posibilidad de seguir sus pasos y disfrutar de su código, que no está nada mal... El último paso ha sido un conversor de Atom a JSON, pero anteriormente ha hecho alguna cosita más, como envíar XHTML-IM sobre TLS con Erlang y una pequeña entrada sobre Comunicación entre procesos en Erlang. A ver si dura :)

Sam Ruby y Erlang en barrapunto

La humildad como virtud del programador

Y no me refiero a modestia frente a los otros (que también puede ser una buena cualidad) sino humildad con uno mismo y con lo difícil de hacer realmente bien este trabajo. En este sentido, sin más, le cedo la palabra a Jonathan Edwards, quien en Beautiful Code dice:

Una lección que he aprendido por la vía difícil es que no somos lo suficientemente listos. Incluso los programadores más brillantes cometen errores estúpidos con frecuencia. No solo errores de tecleo (typos) sino errores básicos de diseño que ponen en una situación difícil al código, y que a posteriori deberían haber sido obvios. La mente humana no es capaz de comprender en su conjunto la complejidad de un programa de tamaño moderado, mucho menos los sistemas monstruosos que construimos hoy en día. Esta es la amarga pastilla que nos tenemos que tragar, porque programar atrae y recompensa al inteligente, y su cultura fomenta la arrogancia intelectual. Me ha ha sido de inmensa ayuda trabajar con el supuesto de que soy demasiado estúpido para hacer las cosas correctamente. Esto me hacer usar de modo conservador aquello que ha funcionado, testear cautelosamente las nuevas ideas antes de confiar en ellas y por encima de todo, apreciar la simplicidad.

Curiosamente habla de un libro que me gustaría mucho adquirir y cuya existencia comenté por aquí.

Sobre el mismo tema, me gustaría recordar una famosísima cita de Brian Kernighan:

Depurar es el doble de difícil que escribir el código por primera vez. Entonces, si escribes código tan inteligentemente como te sea posible, no vas a ser, por definición, suficientemente listo para depurarlo.

Actualización: Creo que no ha quedado claro (he escrito la entrada demasiado rápido), pero lo que me parece curioso del comentario de Jonathan Edwards, es que es una justificación de porqué no escribió en Beautiful Code a pesar de estar invitado para ello, con una explicación tan inspirada que irónicamente merecería estar en el libro... :)

La humildad como virtud del programador en barrapunto

Varios sobre concurrencia: JVM, clasificaciones y consejos

Una ración de enlaces relacionados con la programación concurrente:

• El título lo dice todo: Where the metal meets JVM (An interview with Cliff Click) (Encontrado vía Pensamientos ágiles) Interesantísimo repaso a la implementación de la concurrencia en la máquina virtual de Java y de su relación con el hardware subyacente, con sutilezas en cuanto al modelo de memoria de cada arquitectura. Una buena conclusión, después de leerlos sería: no te fíes de que funcione, estudia bien las especificaciones, no vaya a ser que te lleves sorpresas con el run anyware ;)
• Gracias a sammael, dos artículos sobre también sobre el mismo tema: Introduction to nonblocking algorithms y Synchronization optimizations in Mustang, ambos de Brian Goetz. Un vistazo a java.util.concurrent y algunos detalles sobre el presente y futuro de la concurrencia en java. Complementarios al anterior.
• Herb Sutter en "How Much Scalability Do You Have or Need?" vuelve a clasificar las soluciones para aprovechar la concurrencia del hardware; en este caso se clasifica mediante la escalabilidad que se necesita, desde usar un solo core hasta la explotación de todos los recursos disponibles.
• "10 Ways to Reduce Lock Contention in Threaded Programs" de Michael Suess, que también cita a Goetz. Tanto el primer enlace como éste subrayan la dificultad de pasarse de listo y tratar de programar sin bloqueos. Aquí se califica de optimización prematura y se proponen alternativas muy interesantes como granularizar los bloqueos (y evitar el big lock que seguramente debería ser la primera implementación...) o usar bloqueos de lectura o de escritura (si están disponibles y es posible). Se trataría del primer paso (los primeros diez pasos) en la optimización

Varios sobre concurrencia: JVM, clasificaciones y consejos en barrapunto

Un vistazo a Threading Building Blocks

Según se puede leer en Ars technica: Intel open sources multicore programming tool Intel libera Threading Building Blocks, una herramienta hasta ahora propietaria que ayuda a la programación concurrente. La noticia ha salido en muchos sitios con comentarios interesantes (Slashdot, OSNews o en barrapunto)

Había oído hablar de esta herramienta en la entrevista a Sanjiv Shah de OpenMP en thinking parallel, pero como él trabaja en Intel siempre parece más sospechoso tratándose de un producto comercial. Ahora que lo han liberado he estado echándole un vistazo y bueno, creo que tiene su ámbito de aplicación y que puede ser muy interesante para facilitar algunas tareas sin reinventar alguna rueda.

Por analizar un poco la librería, consta como de cuatro partes:

• Algortimos para bucles paralelos: parallel_for, parallel_reduce, parallel_while. Me ha parecido de lo más interesante de la librería porque es muy fácil de implementar y te ahorra mucha gestión. Al algoritmo se le pasa un contenedor sobre el que operar y un functor y el lo procesa en paralelo automágicamente, aunque parece ser algo parametrizable.
• Contenedores seguros a accesos concurrentes: concurrent_hash_map, concurrent_vector, concurrent_queue. Usan internamente los bloqueos de grano fino y estructuras de datos sin bloqueos. Que bien que no haya que hacerlo por uno mismo, tiene pinta de ser complicadillo y muy fácil hacerlo mal
• Utilidades para gestión de la concurrencia: mutexes de diverso tipo (si, recursivos también), locks, operaciones atómicas
• Un gestor de tareas: una ayuda para programar orientado a tareas, threads más ligeros que los del sistema.

Desde que lo han hecho opensource le han asignado un domino propio, http://www.threadingbuildingblocks.org/ en el que hay bastante información. En particular el tutorial al que le he echado un vistazo es Intel® Threading Building Blocks: Tutorial

Por dar alguna nota no positiva... bueno, de momento solo soporta plataformas desde Intel Pentium 4, porteriores y compatibles, aunque en una de las FAQ del proyecto dicen que soportar todos los procesadores, sistemas operativos y compiladores es una las piedras angulares del proyecto. Veremos.

También me ha llamado la atención que dijesen (extraído del artículo de ars technica):

Java and .NET versions of TBB are currently being evaluated by Intel, and may eventually be announced. But Intel maintains that C++ is the company's priority, and it's where they'll be focusing the engineering resources that they're adding to the project.

Puede ayudar a hacer un poco más multiplataforma el código paralelizado en C++, aunque ya existen muchas librerías que lo hacen, como Boost.Thread. Supongo que estará bien usarlo cuando se necesita mucho rendimiento, una aproximación más sencilla no vale y paralelizarlo de este modo sale rápido y óptimo.

Un vistazo a Threading Building Blocks en barrapunto