El Problema de Processing 4

¿Qué está pasando con Processing? Y no lo digo como alarma ni nada, lo digo como reflexión de parte de un desarrollador, por ser una de las herramientas más importantes de los últimos años, pero que últimamente no se entiende bien a donde quieren llegar. Processing nace como la búsqueda de generar una herramienta que permita programar gráficos interactivos a personas del ambiente del arte / diseño que no sean, necesariamente, programadores. Así se consolida como una suerte de Framework de Java, con un lenguaje de programación propio de sencillo aprendizaje. Pero la historia de Processing prefiero contarla a través de mi propia experiencia. Será un articulo largo en nuestro blog y de algo a lo que estamos acostumbrados. Pero lo sentí necesario.

¿Qué es y que hizo grande a Processing?

Mi historia con Processing es larga, la conocí como herramienta en el año 2010 mientras estudiaba en la universidad. Como alguien que había metido mano solamente a JavaScript, la existencia de un lenguaje / IDE como Processing (que permitía agregar interactividad en pocas líneas de código) me enamoró totalmente. Pero claro, la tecnología es todo menos estática, por esos años (Processing versión 1.2) aún era común exportar un Applet de Java para embeberlo en un Website (hace años no escribía la palabra "applet"). La herramienta ganaba puntos porque la competencia era leve, no necesariamente porque fuese la mejor opción posible. Yo creo que, pese a todo, era la mejor opción, pero solo si se sabía lo que se buscaba. Processing entra, entonces, en permitir exportar los compilados de Java en una App para Android. Aquella versión (1.5) iba a ser un punto de inflexión en Processing, ya que sería una de las features más utilizadas versiones posteriores: los Modos (Java, Android, JavaScript, Python, etc). En esos años (entre 2011 y 2012) con mi colega Jaime Pérez Marín escribimos lo que fue el primer manual en español de Processing (Processing: Un lenguaje al alcance de todos), y al año siguiente aparece la primer versión "estable" de Processing 2. Haciendo un poco de revisionismo histórico, Processing estuvo en Alpha/Beta desde 2001 hasta 2008 que sale la primer versión de Processing. En 2013 sale la versión 2.0 y, poco más de dos años despues, en 2015, sale la versión 3.0. Parecería que Processing decide sumarse al ritmo vertiginoso de versiones que empiezan a aparecer en muchos software producto del "efecto Chrome", con esto de sacar muchas versiones mayores por año. ¿Es algo deseable para un software como Processing? Para mi no, pero tampoco me molesta tanto. Processing 3 buscó re-encontrarse con los desarrolladores, que pedíamos herramientas más robustas para programar, en lugar de hacer algo exclusivo para diseñadores y artistas. De esa manera incluye cosas interesantísimas como un inspector de variables, un modo de edición en vivo, un debugger, etc. Fue una gran versión, y desde hace 4 años que seguimos parados en dicha versión.

Desde entonces han aparecido otros agentes a "competir" directa o indirectamente con el framework. La web mejoró mucho en pocos años y JavaScript ya contaba con un manejo de gráficos mucho más profundo, con lo cual se desarrolla el proyecto P5JS. Un proyecto que lleva, finalmente, una versión nativa de Processing a la web. Muchos comenzamos a usarlo para experimentar (como en su momento existió el ProcessingJS), pero poco a poco se volvió muy interesante. Básicamente el lenguaje es el mismo (al menos es sumamente similar), permite hacer muchas cosas que antes se encontraban limitadas en la web (como acceder a la cámara, microfono, leap motion, etc) y al estar en formato web se ve beneficiado de todo lo que trae consigo JavaScript. De esta manera, si se quiere tener una App de escritorio existe Electron; si se quiere una App mobile existe Apache Cordova; si se quiere tenerlo online existe NodeJS; se integra 100% con los elementos del DOM y con otros frameworks de éxito (Angular, React). ¿Qué beneficios trae entonces utilizar el IDE de Processing con Java? A comparación muy pocos, más aún si vemos que los esfuerzos parecen dedicarse a documentar y agregar más modos. Y no me malinterpreten, documentar es importantísimo y es una de las cartas fuertes de Processing; y los modos son una de las grandes diferencias que tiene Processing con otros frameworks, el modo Android es excelente y está documentado de manera impecable. Pero, ¿el modo Python? solamente te permite programar con la sitaxis de Python (que no es ninguna maravilla), ya que en el fondo sigue compilando en Java. Parece más un capricho de querer tenerlo. Siempre tener más opciones es mejor, pero me gustaría saber cuantas personas utilizan el modo Python por sobre el tradicional de Java. En estos 4 años las novedades referentes a Processing no han salido de ahí. De las veredas de en frente se presenta una web poderosa, un framework como Angular que en 2 años creció a niveles increibles, el P5JS que cada vez es más usado, e incluso OpenFrameworks que por mantenerse fiel a su objetivo inicial está logrando ser una gran herramienta para gráficos interactivos de alto rendimiento.

Processing 4

¿Processing 4? Cualquiera diría que ya está por salir, pero no. Hace poco tiempo la gente de Processing compartió un articulo en su Wiki en el que hablan de que les gustaría incluir en una futura versión, pero afirman reiteradas veces que no tienen ni tiempo ni suficiente ayuda de la comunidad. Hasta acá parece el problema típico de un proyecto OpenSource. Sin embargo, cuando listan los cambios que quieren traer a Processing 4 no hay nada ni remotamente interesante. Escriben lo esperable, sobre migrar a Java 11 (cosa lógica que siempre hicieron, usar la versión actualizada de Java), de quitarle el soporte a la versión de 32 bits (también algo lógico, aunque molestaría un poco a los usuarios de Raspberry Pi), cambios en el core / motor gráfico producto de cambios en Java, y mejoras generales. Lo más interesante es una nueva API donde se agregaría mucho soporte a eventos Touch. Esto sería genial, de no ser porque se lo siente (en mi opinión) un poco fuera de tiempo. Con la cantidad de recursos que hay hoy en día para acceder facilmente a los eventos touch, que Processing lo esté considerando recién en una versión sin fecha de salida resulta extraño. Pero vamos a hacer la vista gorda por tratarse de Processing, y porque me consta que el grupo de desarrollo no es tan grande hoy. Hay una lista enorme casi al final del artículo donde listan cosas que quieren agregar, pero que ni siquiera están seguros de poder agregarlo en una versión futura por la cantidad de trabajo que lleva. Son puntos interesantes, como sincronizar sketchs con Dropbox, una versión paga de Processing en los stores (de esa manera podrían financiarse un poco mejor) y el cambio del IDE para que no use como base Java y emplee mejor HTML/CSS (algo que, en mi opinión, debió hacerse como prioridad hace años). Son cosas interesantes, pero tampoco justifican una versión mayor si no van a llegar todas juntas. Me preocupa, como desarrollador, no tanto la falta de tiempo o la ausencia de una versión mayor en 4 años (al menos una alpha), sino la carencia de metas claras.

Especialmente en relación al último punto donde aventuran un "Adios Java?". Processing no quiere utilizar más a Java como Core de su plataforma, a raiz del poco soporte que está dando Java a Desktop (se concentran en móviles, donde hay más mercado) y lo poco óptimo que suele ser para proyectos de alta complejidad. Sugieren tres plataformas para migrar: Swift, Python o Javascript. Vamos por partes. Swift, la plataforma de Apple para hacer Apps, un sistema sumamente cerrado, solo para usuarios de Apple, creo que no debería ni entrar en la discusión. ¿Python? Si se consigue compilar algo en C puede ser muy atractivo, pero ¿qué van a hacer con el lenguaje? Después de tantos años Processing ya es un lenguaje en sí mismo y portabilizarlo a Python sería algo complejo para la comunidad, sin contar el problema de manejar un motor gráfico. JavaScript es una opción interesante, no hay que hacer grandes cambios en el lenguaje (por no decir que ninguno) y tendríamos todos los beneficios que hoy tiene P5JS, pero sin ser P5JS. Processing lo descarta ya que Java puede manejar grandes datos de ciertas formas en las cuales JavaScript no puede. No lo discuto pero, al menos con JavaScript sería empezar con algo. Nuestra sugerencia es distinta. OpenFrameworks nunca fue una competencia directa de Processing, pero convendría tenerlo como referencia ya que el Core de OpenFrameworks es un conjunto de librerías en C que lograron implementar un motor gráfico muy bueno y completamente optimizado. Quien escribe este articulo hizo un traductor de código de Processing a OpenFrameworks que, con sus limitaciones, funciona bastante bien. Y hablamos de un proyecto en solitario sin recursos. Sería un esfuerzo inicial bastante grandes, si, pero los beneficios a largo plazo son incalculables. Es una discusión interesante pero, ¿por qué ahora y no hace años? Todo mundo sabía que Java iba a terminar siendo limitado para Processing, y abordar la discusión hoy por hoy se hace complicado cuando comunidades como la Online o la de OpenFrameworks se hacen fuertes. Está lejos de ser el final de Processing, sigue siendo fuerte, pero espero esto no es convierta en el principio del fin. Sería un final muy injusto para un framework fantástico y que ha enseñado a tanta gente a programar.

Como dije al principio, no podía dejar de compartir esta breve reflexión, por historia y por respeto. Desde ya el proyecto Rosetta (pese a sus limitaciones) está a disposición de la gente de Processing para lo que deseen.