Entradas archivadas en Libros y Panfletos

The Pragmatic Programmer CoverJusto después de Code Complete me he leído The Pragmatic Programmer, From Journeyman to Master, el primer libro de Dave Thomas, autor del Pickaxe. El libro es bastante cortito (unas 300 paginas) y se lee con facilidad. Si lo comparo con Code Complete es porque se parecen bastante. Este libro se gestó tras cuatro meses de Andy y Dave en un sótano programando un modulo de transacciones en C, y esto tiene bastante influencia, creo, en la forma de ver las cosas de los autores.

A diferencia de Code Complete, en este libro se dan unos consejos de una forma, por llamarlo de algún modo, filosófica. Se dan ejemplos y metáforas bastante buenas sobre comentar el código, programar despacito y bien, etc. pero el enfoque es mas, valga la redundancia, pragmático. No importa que solo tu apliques estos conceptos, siguen siendo validos aun en medio de un proyecto totalmente caótico (aunque quizás, la influencia de uno no sirva para levantarlo). En este libro solo se dan unos cuantos buenos consejos (y su justificación) que puedes seguir o no… pero esto queda en decisión personal tuya, más que en un consenso de todo el equipo.

Code Complete 2edEl primer libro técnico de este año ha sido un tocho (unas 900 páginas) que habia oído recomendar a algunos profesores, Code Complete de Steve McConell. He leído la 2a edición, que es una actualización de la primera, que es uno de los clasicos de la ingeniería del software. En esta, el autor ha substituido los ejemplos de C, Pascal, Basic, Ada, Fortran por ejemplos en lenguajes más actuales como C++, Java o Visual Basic. Quizás solo eche en falta consejos en el ambito del desarrollo de aplicaciones web, que es un aspecto bastante común dentro de la programación de negocios.

El autor ha sido gestor de proyectos en multitud de compañías, lo cual le da una visión bastante completa de las buenas practicas en la construcción de software (como la llama el) y eso es precisamente lo que encontrarás en este libro. Hay cantidad de buenos consejos y información en este libro, pero estas prácticas parecen escritas más para el jefe/gestor del proyecto, que se las debe inculcar a su gente, que no para el individuo/programador. No obstante, un libro interesante si podeís cogerlo en la biblioteca de la universidad o similar, aunque, en mi posición, no lo compraría.

Hace no muchos días Javier Romero hablaba de su proyecto secreto en el cual pensaba usar CLIPS para la parte de inteligencia artificial y repasaba las opciones para Java, PHP y C++. Yo también necesito un sistema de reglas y, visto CLIPS, he decidido descartarlo por completo. Os relato mi viaje mental desde mi intención inicial a la conclusión.

Inicialmente, utilizar CLIPS me parecía una idea no demasiado mala. Nunca es malo aprender algun lenguaje/paradigma nuevo… así que me voy a la web oficial. El primer ostión… los manuales no son grandes, son inmensos. La referencia de CLIPS tiene como 400 páginas y la guía de programación, que va aparte, tiene más de 100. Mi impresión es… esto me va a llevar más tiempo del que había pensado.

Me pongo a mirar a ver si hay algún wrapper facilote para C++… hay una DLL (solo para Windows) sin demasiada documentación, con unos ejemplos para que veas como funciona.

Antes de seguir más se me ocurre hacer un poco de espionaje estudio de glest. Vaya… hacen las reglas a pelo con C++. También me ha gustado mucho la organización de directorios que tienen, aunque no creo que se la copie del todo.

Total, que me parece que voy a utilizar Lua para definir las reglas, exportaré desde C++ una serie de funciones para poder acceder a la base de conocimiento y programaré el núcleo de selección a manita. Después de todo no es mas que una iteración hasta que encuentres una que aplicar. Se puede depurar mucho este algoritmo, pero creo que con una cutrada como la que acabo de describir nos va a sobrar.

Tim Sweeney ha realizado una charla en el certamen POPL (una conferencia sobre lenguajes de programación). Tim Sweeney, además de demostrar que tiene un gusto horrible en cuanto a presentaciones se refiere, presenta la visión que el tiene de como sería el lenguaje de programación de juegos que se utilizará en los próximos años, después de la experiencia como arquitecto técnico del Unreal3 Engine y el impresionante, al menos en las imágenes que se han enseñado, Gears of War.

Podéis consultar las transparencias en el enlace a GameDev para detalles más técnicos (leed también los comentarios que son bastante interesantes), pero la idea general es que el cree que se dejara C++ de lado y se optará por adoptar algún lenguaje de programación funcional (el propone algún derivado de Haskell con algunas variantes para hacerlo más rápido). El motivo de esta afirmación es que las consolas actuales tienen varias CPU y la mejor forma de aprovecharla es tener programas paralelizables. Con programación funcional el paralelismo es, casi, trivial.

Quizás no se llegue a esos extremos pero, por ejemplo, Naughty Dog se programó un compilador de su variante de LISP (que llamaron GOAL) y que han usado para programar los juegos de la saga Jak and Daxter (podeis leer un poco sobre eso en el Postmortem de Jak and Daxter).

Vía GameDev.

Vía el blog de Jare, me entero de la cantidad de problemas del VS2005 (y mas problemas aqui).

Parece ser que los amigos de Redmond, guiados por la consultoría estratégica de un MBA han decidido que era mas importante que la versión 2005 del Visual Studio saliese el día estipulado (por sinergias con el SQL Server, etc.) que entregar un producto de calidad a los desarrolladores. Supongo que esperaran cautivar con bonitos palabros a los minglanillas sin conocimiento técnico para que compren las licencias y serán los programadores que les toque pagar el pato.

Muchas veces he dicho que Visual Studio es un IDE magnifico para programar en C++ sobre Windows, pero le vaticino al 2005 una lenta implantación hasta que aparezca alguna revisión o un Service Pack con los errores corregidos. Me parece discutible, aunque entiendo, que Microsoft se niegue a retrasar la fecha de lanzamiento del Office o, incluso, de Windows o que emplee la tijera de las features™. Pero comprometer el trabajo de los desarrolladores con herramientas de mala calidad… no tiene perdón de $DEITY.