Gamelab 2018: Jonathan Blow reivindica el derecho a la felicidad del programador

Explicaba Pep hace unos días que Jonathan Blow es «uno de esos genios que trabajan de pie». No era una metáfora: al parecer en algunos de sus vídeos sobre programación se le puede ver tecleando código sin sentarse, en una mesa alta como las de las cafeterías más cosmopolitas, posiblemente porque le va bien para la espalda o la circulación o porque el tipo es tan inteligente que necesita estar involucrado en una constante actividad paralela; quizá mientras programa está cocinando o haciendo Taichí. Quizá mientras programa intenta cultivar su calidad de vida o, al menos, vivir.

Esa necesidad de no caer en el sedentarismo más aplastante es algo que se desprende de su charla del pasado jueves en el Gamelab de Barcelona: antes de arremangarse y ejecutar el compilador en su ordenador portátil (momento en el que inevitablemente perdió la atención de buena parte de los presentes: los que no tenemos ni idea de programación o hemos olvidado lo poco que sabíamos), Blow habló de cosas muy terrenales, de preocupaciones y reflexiones afiladas en su día a día que le llevaron a tomar una decisión tan contundente como crear su propio lenguaje de programación, Jai. Hasta ahora Blow ha tenido siempre fama de tipo extraño y difícil de tratar, y a menudo se ha dicho de él que su obsesión con el trabajo rozaba lo insalubre: en enero de 2016 publicó un misterioso twit (ahora eliminado) con una fotografía en la que mostraba una botella de plástico llena de orina, sugiriendo que estaba meando en botellas para no perder ni un segundo yendo al retrete durante el tramo final del desarrollo de The Witness. Cuatro años antes, en mayo de 2012, The Atlantic publicaba el que quizá sea el mejor artículo para conocer la personalidad algo complicada de Jonathan Blow: «Si quieres sacarle a comer algo, tienes que decirle “salgamos a discutir este tema” o “salgamos a trabajar en nuestros juegos”», explicaba Chris Hecker, su mejor amigo en la industria. «Si le preguntas si quiere simplemente salir te responderá: “¿por qué?”».

Algo debe de haber pasado a lo largo de estos años para que Blow haya empezado a tomarse más en serio otras dimensiones, personales y sociales, de la vida, pero a pesar de que su charla habla de sus frustraciones con los lenguajes actuales, no parece interesado en hablar mucho de sí mismo, de su obra o de sus influencias. Estamos hablando de un tipo que ha dado conferencias de títulos tan pomposos y trascendentalistas como Videojuegos y la condición humana y que a menudo ha sacado a colación la influencia de la obra de Italo Calvino en su trabajo. Da la impresión de que Blow piensa ahora en otras cosas: «Es importante que los programadores mejoremos nuestras calidad de vida: no deberíamos ser infelices como muchos lo somos», confiesa. Su Jai nace de la intención de hacer un lenguaje que aporte fluidez en la elaboración del código, que permita solucionar los problemas y los errores humanos de manera rápida y satisfactoria, que acorte significativamente el tiempo que tarda en compilarse una aplicación para no perder el ritmo de trabajo y que afecte de manera positiva a la productividad y la conciliación familiar. Habla de reducciones actuales en los tiempos de cerca del 15%, pero afirma que la idea es rondar entre el 50 y el 80% en la productividad.

El problema que encuentran los programadores a menudo, según Blow, es que no hay un lenguaje que mantenga el equilibrio entre la sencillez y el control. Cuando más sencillo y accesible es el lenguaje, más sensación tiene el programador de que no está controlando todo lo que sucede y que por tanto se le escapa un margen de libertad de acción; y cuanto más controlable es un lenguaje, más problemas presenta, más lento funciona y más complicado es trajinar con él sin caer en momentos de frustración. «Existe la idea generalizada entre este dualismo es inevitable, pero no es cierto: se puede hacer un lenguaje con todas las ventajas de C# pero que al mismo tiempo permita un control a tan bajo nivel como C», explica, «lo que sucede es que nadie lo ha hecho aún y al no ver ejemplos nos parece incomprensible». Blow sostiene que el mundo de los lenguajes de programación está lleno de ideas preconcebidas como que «se suele pensar que la acumulación de pilas es algo que hace el código más completo y mejor, pero en realidad lo hace peor: acaban por no ser algo bien construido, como un tambaleo que al final acaba por tirarte al suelo», dice. «Lo ideal es ser explicar con claridad cómo es la interacción entre las distintas capas del código, por si tú u otra persona necesita modificar algo», señala. «Este tipo de capas generalmente no encajan entre ellas, son chapuceras y provocan que haya veces en las que no sabes qué demonios está pasando, y eso sucede cuantas más capas añades, haciendo también más lenta la compilación, y todo acaban siendo problemas».

Blow también se queja de una sobreutilización «en el mundo moderno» de software como Visual Studio o Xcode, entornos integrados de desarrollo que «a muchos programadores les parecen imprescindibles porque les dicen qué está pasando y dónde están los archivos, pero que en realidad tiene un valor nulo o directamente negativo porque interfiere entre el programador y la programación activa; es una bestia rara, un Frankenstein sin sentido que al final te impide programar sin usarla», lamenta Blow, «lo realmente importante es el debugger y el editor». El diseñador y programador sostiene que debe ser el propio lenguaje y nuestra manera de trabajar con él lo que nos traslade toda la información detallada sobre qué está haciendo el código y cómo funciona cada cosa. Habla de añadir comentarios de manera exhaustiva, de avisar sobre cuándo se cierra un archivo para que el proceso pueda seguir, de no esconder nunca el funcionamiento de las cosas.

Blow tiene cierta fama de neurótico, y desde luego su Jai puede ir enfocado a cosas que le obsesionan como la eficiencia, el tiempo invertido y el orden y la claridad de las cosas.

Tras décadas tecleando código ha llegado a un conocimiento cristalino sobre lo que ayuda y lo que perjudica la tarea de programar, y también a conclusiones muy sonoras: «La gente que habitualmente diseña lenguajes de programación quiere ayudarte (a veces), pero no escuchan este tipo de quejas y problemas, de modo que es imposible programar de la manera correcta si quien ha hecho el lenguaje no ha abandonado ciertas ideas y tópicos demasiado asimilados». Dice muchos programadores de juegos usan C++ «porque no te impide hacer cosas a muy bajo nivel; hace bien cosas que otros lenguajes hacen mal (…) pero en general C++ es un desastre, es un lenguaje realmente terrible». Dice que C++ permite gestionar muy bien la memoria (uno de los grandes granos en el culo de la programación), pero que el coste a nivel velocidad de ejecución es enorme, que hay muchas veces en que el código del programador está perfectamente pulido pero las instrucciones del lenguaje no son eficientes. Habla de problemas de calado incluso conceptual, de cómo se entiende la memoria o las órdenes que envían a un hardware que tiene sus limitaciones y su comportamiento específico: «Tratar de escalar hacia el cielo no es necesariamente un error, pero es importante mantener un pie en el suelo», advierte. El código es algo abstracto que permite hacer teóricamente cualquier cosa, pero Blow dice que «programamos en el mundo real y las máquinas están en el suelo, por eso es importante mantener el contacto con ese suelo», y echa falta un conocimiento más extendido de los detalles de implementación, de la velocidad a la que corre un ordenador o de su grado de robustez. «Conviene poder subirse a la escalera para hacer cosas abstractas, para expresarse, pero también ser capaces de bajar al nivel del suelo para manipularlas desde la raíz; lo interesante es poder moverse en ambas direcciones».

Finalmente llega la pregunta que, dice Blow, le hace todo el mundo en todas partes: «¿Por qué hacer un nuevo lenguaje de programación? Por Dios, si hay cientos en el mundo, por qué no te quedas con uno de esos» y su respuesta resume el discurso moderadamente contracultural que viene haciendo con respecto a todo su trabajo, tanto en la programación como en el diseño de videojuegos: «Hago Jai porque todos y cada uno de esos lenguajes ya existentes han comprado las creencias incorrectas, todos parten de algunas bases y concepciones que son un error o que no favorecen a la hora de hacer videojuegos».

Blow dice que Jai sigue en desarrollo y que hasta ahora solo lo han utilizado para programar quienes están diseñándolo junto a él, no más de cinco personas, y que para finales de año espera entregar una alpha cerrada a unas cuantas personas. Nos muestra un ejemplo: una versión 3D de Sokoban que compila en tiempo real en su portátil en 1,7 segundos y que, dice, «en mi ordenador de sobremesa ronda un solo segundo», y en la sala no se oye a nadie desmayarse de la impresión o levantarse a aplaudir. Intuyo que lo que ha conseguido Blow no es ninguna cosa revolucionaria, pero por cómo se refiere a Jai parece que tampoco trata de serlo, al menos a corto plazo. Sabe perfectamente que los videojuegos, y especialmente los AAA, trabajan sobre game engines que son auténticos mastodontes carísimos y enormes («la última vez que lo comprobé, el de los Assassin’s Creed rondaba los diez millones de líneas, ahora probablemente habrá crecido mucho más») que no cambiarán de la noche a la mañana, así que su objetivo son los desarrollos doble A y los indies. Dice que está cansado del derrotismo de los programadores cuando dicen que lo que ha sido siempre así difícilmente va a cambiar, pero incluso quienes no sabríamos ni programar un vídeo VHS si aún existieran tenemos claro el potencial de Blow como agitador de la industria y de sus métodos. Muchos situamos el inicio de la gran eclosión de los indies en el momento en que Braid salió a la venta hace casi exactamente diez años, así que de Jonathan Blow se pueden decir muchos cosas y no todas son buenas (en 2011 Kotaku planteó a su comunidad un debate titulado «Cuando amas a un juego pero no a su creador» y lo ilustraron con una captura de pantalla de Braid), pero el error más grave por nuestra parte sería, sin duda, subestirmarle.