NetLogo Wishlist

Como bien saben todos los que me rodean (o han pasado por la experiencia de recibir clases mías), no oculto mi predilección por NetLogo, a pesar de que se aleja de los circuitos profesionales (ni informáticos ni científicos) en los que se supone que debería moverse un miembro de un departamento de Ciencias de la Computación e Inteligencia Artificial.

Tanto es así, que lo uso de forma habitual para desarrollar asignaturas que normalmente se dan en lenguajes pretendidamente más interesantes (apunto aquí a los Java's y Python's que tantos adeptos han acumulado). Algunas de estas asignaturas han tenido como objetivo mostrar los fundamentos del modelado de sistemas (donde NetLogo se acopla como un guante); otras, enseñar fundamentos de programación a alumnos primerizos; y otras, mostrar los fundamentos de la IA como herramienta para resolver problemas de forma mecánica y lo más general posible (donde NetLogo es bastante menos frecuente). Llevo con orgullo las mofas y miradas raras que me gano por ello, pero por cosas peores podría haberme ganado el mismo resultado...

El famoso Logo (inspiración de algunas cosas de NetLogo) fue de los primeros lenguajes que aprendí, hace muchos años ya, y que me enseñó a diferenciar los lenguajes de batalla (como BASIC) de los lenguajes que ocultaban un diseño sencillo, esmerado, y elegante, así que no dudo acerca de que mi inclinación por NetLogo tenga una gran parte sentimental. Pero esta elección me hace pagar con una cara moneda, porque cada año hago el esfuerzo por justificar delante de los alumnos (tan cargados de prejuicios como el resto de humanos) el uso de un lenguaje que "nadie más usa" y que "no volverán a usar ni les piden en ninguna empresa", y cada año las manzanas maduras demuestran que es solo cuestión de tiempo que al final del curso hayan entendido algunas de las razones más importantes por las que la elección no ha sido tan desacertada ni aleatoria. Y es que, salvo que un año me encuentre con un grupo de alumnos expertos programadores, sería difícil abordar las necesidades de una asignatura como IA con un solo lenguaje sencillo, con un entorno gráfico cómodo, y que además cumple con requisitos de eficiencia que difícilmente se llegan a encontrar en implementaciones similares en otros lenguajes.

A pesar de todo, no soy un fanático (aunque a veces juegue a serlo para medir las reacciones), y cada año hago la prueba de implementar algunas soluciones completas en otros lenguajes para poder comparar las bondades y así decidir si, de una vez por todas, salto o no a un nuevo entorno de programación... hasta ahora, todos fallidos. Y ya van: Python, Julia, Haskell, y Elm (he de mirar en más profundidad Julia, porque avanza rápido, y ahora me está llamando la atención Lua, pero he de conseguir diferenciar bien las librerías que de verdad están en activo). Y no porque sean peores, sino porque deben sumarse ciertas características que permitan mantener las exigencias que actualmente tiene el curso (todos son mejores que NetLogo en alguna, pero después todos pierden estrepitosamente en algunas otras). En general, las características que busco para el curso de IA son:

1. El curso es amplio en contenido, quizás no tanto en profundidad como en anchura, así que no me basta que tenga una buenísima librería para hacer redes neuronales y que usa todo el mundo (aunque no sepan ni cómo funciona). No quiero que esté todo hecho, sino que se pueda hacer en un tiempo razonable con conocimientos básicos.
2. Debe poder implementar soluciones que van desde la clásica búsqueda de estados, hasta el actual aprendizaje automático (el genérico, ni se me ocurre meterme en Deep Learning en un curso de introducción a la IA), pasando por optimización, sistemas multiagente, lógica, planificación, satisfacción de restricciones, métodos de Monte Carlo, ...
3. Apenas podemos dedicar un par de semanas del curso para conocer los entresijos del lenguaje a usar (cada día dedicado a "programación" es un día perdido de IA).
4. Debe proporcionar un entorno de desarrollo rápido, fácil de instalar, y disponible en varios sistemas operativos. Que no ocupe 2 Gb y que sea Open Source.
5. Debe traer muchos ejemplos que sirvan de guía al alumno en caso de necesidad.
6. Debe dar mecanismos para acercarnos a prototipos de soluciones finales, con interfaz gráfica y alejados del típico entorno en el que ejecutamos código como si fuera una clase de algorítmica... porque el curso se evalúa principalmente por medio de la creación de proyectos completos (jugadores automáticos, análisis de datos, optimización de procesos, etc.) en los que visualizar el comportamiento y decisiones es esencial.
7. Debe ser lo suficientemente flexible como para adaptarse a la creación y modificación de nuevos métodos y algoritmos. Quizás por mi culpa, pero cada año se modifican soluciones anteriores y se introducen nuevos algoritmos para proporcionar formas alternativas de solución, así que el curso no está cerrado en contenido, solo en objetivos, y esta tarea muchas veces se hace en tiempo real, según las necesidades e intereses observados en el grupo ese mismo año.
8. Debe dar una aproximación a la programación que permita jugar con aproximaciones funcionales (aunque no se busca que sea purista) y con aproximaciones con agentes, como corresponde a la IA.

Sí, NetLogo permite trabajar con estas restricciones y a la vez dar resultados suficientemente buenos como para que los alumnos aprendan (si quieren, que no siempre es así) los fundamentos, las ideas principales que les permitan implementar este tipo de aproximaciones a futuros proyectos, independientemente del lenguaje elegido y del contexto en el que lo quieran resolver. La idea es abrir una puerta para que sigan profundizando y sean capaces de entender cuáles son algunos de los posibles caminos existentes (a pesar de que es un área en la que los cambios y novedades se producen con mucha más celeridad de la que se observa en otras áreas de conocimiento, sobre todo en los últimos años, y precisamente por ello no son tan importantes las tecnologías como las ideas).

Entonces, ¿porqué cada año hago pruebas en otras direcciones? Primero, porque nunca estoy seguro de si mi visión puede se errónea y otra aproximación sería más beneficiosa para el alumno (todos sabemos que, en realidad, casi cualquier lenguaje puede servir para casi cualquier cosa que hagan otros lenguajes)... y segundo, porque, a pesar de todo, NetLogo tiene algunas carencias (algunas fundamentales, otras no tanto, solo vistas como carencias porque todos queremos la herramienta perfecta) que hacen que cada año se echen de menos soluciones más elegantes, o más sencillas, o simplemente más cómodas.

La lista de deseos

El resto de esta entrada está destinada a destacar aquellas carencias que en más de una situación he echado en falta. Si puedo, iré justificando el porqué considero que sería interesante resolverlas. Es posible que algunas de ellas sean fáciles de incluir en versiones posteriores del lenguaje (sería lo ideal), otras es posible que tuvieran más sentido por medio del sistema de extensiones que tiene el lenguaje, quizás haya muchas que son necesidades para mí pero no para la mayoría de los usuarios de NetLogo, y seguro que hay algunas (espero que las menos) que exijan cambios demasiado profundos como para poder ser acometidos por el equipo de mantenimiento y desarrollo. Quizás algunas de ellas puedan someterse a estudio, aunque sea para una posible versión 7.0 del lenguaje.

Quiero también hacer notar que la existencia de una versión web de NetLogo apenas ha significado una curiosidad en mi contexto, y tampoco mis alumnos de los últimos años han obtenido ningún provecho de ella. Quizás es el momento (en un mundo ideal) en el que el desarrollo de NetLogo se divide en dos ramas claramente diferenciadas: una versión para educación en niveles principiantes, y otro para un público objetivo con mayores necesidades de programación y objetivos más ambiciosos.

En todo caso, sí me parece importante destacar que la siguiente lista de deseos no se vea como un reproche al trabajo realizado por los desarrolladores del lenguaje, porque esta lista surge precisamente del interés de potenciar aún más una plataforma de desarrollo que ha demostrado durante años una innovación y capacidades que superan los iniciales objetivos educativos básicos (la mayoría de las necesidades que marco aparecen en el ámbito de investigación, donde también he usado NetLogo para proyectos de investigación, y otros en el de educación superior, porque lo uso en asignaturas de nivel universitario).

Pido disculpas si algunas cosas son imposibles, o la respuesta sería "¿y porqué no lo haces tú?", algunas cosas las he intentado, pero mis conocimientos de programación no me lo han permitido (parece que siempre me he movido fuera del entorno de Java/Scala), y acabo pensando siempre en cómo hacer un clon de NetLogo en otros lenguajes más cercanos, y me parece un sinsentido terminar haciendo un trabajo que ya existe y mejor de lo que yo pueda crear.

Para intentar agrupar mejor los deseos, he dividido las peticiones en tres bloques, aunque algunas de ellas puedan parecer repetitivas y es verdad que afectarían a más de un bloque:

1. Entorno: aquellas que afectan al entorno de programación que también proporciona NetLogo.
2. Lenguaje: aquellas que afectan a NetLogo como lenguaje de programación.
3. Extensiones: aquellas que pueden afectar a cualquier de los dos bloques anteriores, pero que quizás pueden resolverse por medio de extensiones adecuadas y no modificando el núcleo del lenguaje. Aquí me gustaría notar que quizás se necesitara un sistema de extensiones para manejar el entorno (quizás llamarlos plugins, como alguna vez creo que se comentó en propuestas anteriores), y simplificar la API de creación de extensiones tanto para el lenguaje como para el entorno.

Entorno

1. Remapear algunas teclas del editor, porque no funcionan en portátiles no ingleses (o dar la opción de que el usuario decida cómo se mapean). Por ejemplo, en los portátiles españoles es imposible modificar el zoom de la aplicación por medio del teclado.
2. Cambiar el aspecto gráfico para hacerlo más profesional. La versión actual es cómoda, es práctica, pero arrastra un aspecto visual de más de 20 años que empieza a pesarle y que lo hace poco atractivo en una primera aproximación en entornos universitarios y académicos. Lo ideal sería incluso que fuese fácil personalizar el aspecto visual de la herramienta, tanto a nivel de la aplicación como a nivel de widgets. Se agradece enormemente el esfuerzo hecho recientemente en las mejoras del editor, pero quizás sea el momento de pensar en un entorno de programación basado en otros proyectos abiertos disponibles (como atom, o similares). Quizás con un acceso adecuado a la información de NetLogo Headless se pueden hacer pruebas
3. Crear versiones GUI de modelos sin acceso a código ni a modificación del interfaz. Bastaría una interfaz distribuible que pueda llamar a ficheros .nlogo a la que se le quita toda la parte del editor y que trabaje de fondo con NetLogo.jar. Incluso, quizás se podría pensar en la posibilidad de incluir el compilado intermedio que la herramienta hace previo a la ejecución, y dar opciones de si esta versión cerrada y distribuible lleva acceso al Command Center, ventanas de inspección de agentes, etc...
4. Funciones para crear ventanas desacoplables de widgets. Por ejemplo, de plots. Aunque algo parecido se puede hacer con extensiones orientado hacia las pestañas, sería más interesante y potente si va integrado en la propia herramienta de forma nativa y permite la creación de ventanas independientes. Veremos que hay varias propuestas relacionadas con el sistema de visualización de pestañas/interfaz.
5. Añadir la opción de que el mundo ocupe el 100% del interfaz. Muchas veces, puedes y quieres controlar el modelo completo por medio del teclado y ratón. Quizás se podría añadir la opción de una barra flotante o auto-ocultable para dar acceso a widgets específicos durante la ejecución del modelo.
6. Convertir el Command Center en un widget. De esta forma, se puede decidir si se quiere presente o no.
7. Añadir pestañas de interfaz. Similar a lo que hace ya alguna extensión, pero integrado en la plataforma de forma nativa.
8. Añadir widgets específicos. Uno de texto enriquecido y otro para mostrar información tabular. Quizás bastaría disponer de uno que admitiese Markdown y añadir una extensión con instrucciones para manejar Markdown de forma cómoda (al fin y al cabo, ya va integrado algo parecido por medio de la pestaña Info).
9. Permitir pestaña de código y de interfaz a la vez. Quizás lo mejor sería que las pestañas fueran desacoplables. Algo parecido ya se hace en NetLogo Web. Muchas veces se quiere modificar el programa y ver el resultado en el modelo, y es bastante incómodo ir cambiando de pestaña perdiendo la visualización completa de una de ellas.
10. Hacer que el mundo sea un control más, que se pueda añadir o quitar (ocultar) de la interfaz. Incluso posibilidad de tener más de un mundo (algo parecido ya se hizo con una extensión a nivel de patches). Pensar cómo se decide en qué mundo/s se representa qué información.
11. Manipular completamente el interfaz por código (como hace alguna extensión).
12. Añadir una opción para inspeccionar toda una familia (mostrada como una tabla de individuos con las propiedades en columnas). Ofrecer opciones de interacción por medio de esta tabla, y también formas de ordenarla por los valores de las diversas propiedades. Incluso se podría permitir un pequeño cuadro en el que filtrar los agentes mostrados por medio de una restricción (el comando acepta cualquier cosa que podría evaluarse como un agentset), algo así ya se hace en la inspección de agentes.
13. Añadir shapes de tipo sprite. Hubo una extensión que iba en esta dirección. Lo que implica añadir bitmaps como shapes de agentes. Este tipo de mejoras, junto con otras anteriores, permitiría potenciar NetLogo para una forma distinta de programar juegos, por ejemplo.
14. Potenciar de nuevo la parte OpenGL para 3D. Parece que ha quedado un poco desactualizada y es una opción muy potente.

Lenguaje

1. Función (apply f [x1 ... xn]) = (f x1 ... xn). Con el fin de tener una aproximación mucho más fiel al paradigma funcional, donde ya se está haciendo un buen papel.
2. Hacer que los procedimientos anónimos, al asignarlos a una variable, se conviertan en procedimientos normales, el nombre de la variable pasa a ser el nombre del procedimiento en el espacio de nombres. Esto es algo que se podía hacer en el Logo antiguo y era muy cómodo y natural, y se puede hacer en otros lenguajes que van incluyendo funciones lambda.
3. Arreglar algunas funciones para hacer el sistema más coherente. Por ejemplo: towards debería devolver el ángulo de giro considerando la orientación de la tortuga, no como si siempre mirase al norte (los patches, deberían considerarse con heading fijo hacia el norte); instrucciones como link a b deberían funcionar recibiendo a y b como tortugas, no sus who. Es decir, orientar las instrucciones hacia los agentes, que debería ser la estructura de datos fundamental del lenguaje (junto con las funciones si se consiguen convertir en elementos de 1ª clase).
4. Permitir la creación de propiedades de agentes on-fly. Aunque pueda ser costosa y desconsejable, y solo se use en determinadas ocasiones (por ejemplo, en el setup de un modelo), es muy interesante poder definir propiedades dependiendo de la configuración del modelo. Aunque se puede simular con una propiedad que es una tabla, no es lo mismo.
5. Añadir una estructura de datos de tipo registro. Quizás bastaría añadir un tipo de agente abstracto, que no tenga representación gráfica, con la capacidad de definición de propiedades en tiempo de ejecución, pero quizás fuese más costoso, sobre todo si después se quieren meter varios registros como propiedades de otros agentes.
6. Añadir la notación "." para las propiedades de agentes y tablas/registros: turtle.xcor. La notación [prop] of agentset se dejaría para obtener listas de propiedades (aunque sea de un agente, que entonces daría una lista unitaria).
7. Dar la posibilidad de trabajar en un mundo sin patches (aunque sea acotado).
8. Independizar la ventana de representación del tamaño del mundo. De forma que se pueda ver una sección del mundo y hacer zoom.
9. Añadir otras topologías al mundo. Tanto a nivel de estructura geométrica del patch (hexagonal, triangular), como en las relaciones de vecindad (esférica,...).
10. Introducir el concepto de clase de agentes, de forma que algunos procedimientos sean propios de cada clase. Por ejemplo, todos los agentes derivarían del abstracto, y los links se pueden hacer entre cualesquiera 2 abstractos (o derivados).
11. Introducir reflejos (procedimientos definidos para cada familia que se ejecutan automáticamente en cada paso de la simulación). Hay que pensar de qué forma se ordenan en el tiempo en cada iteración, y cómo funcionarían en modo continuo.
12. Permitir links entre cualesquiera tipos de agentes ... incluidos los patches. Al fin y al cabo, los links reflejan relaciones, así que los links son interesantes para ellos.
13. Permitir más de un link de la misma familia entre dos agentes. Que sea el usuario, si en su modelo hace falta, el que controle si ya hay otro o no.
14. Permitir agentes relacionales de cualquier aridad (2 = link). Pensar en cómo se representarían. Pensar en si el orden afecta.
15. Enriquecer las instrucciones que manipulan el ratón. Controlar el botón del ratón que se presiona, añadir la selección de links (el entorno lo permite, debería permitirlo el lenguaje también).

Extensiones

1. Añadir la importación de librerías nativas (hechas en NetLogo) a diferencia de las extensiones hechas en Java/Scala: import [...] / extensions [...] / include [...]. La diferencia entre una librería y un nls es que la primera encapsula el contenido y solo deja algunas funciones/estructuras visibles (y puede estar precompilada), mientras que el fichero `nls` es solo una reordenación del código.
2. Añadir un widget que permita contener/desplegar otros (tipo contenedor).
3. Añadir una extensión gráfica avanzada (que permita manipular la capa de dibujo con mayor libertad y flexibilidad), al estilo de la que hubo para la v5. Realmente, esto lo metería como parte del núcleo del lenguaje, una mayor capacidad en la capa de dibujo.
4. Conectar NetLogo y Julia. 
5. Conectar NetLogo y Javascript (¿quizás con un entorno electron?)
6. Añadir map, filter, foreach para estructuras como: table, string. En general, si una estructura se puede trabajar de manera funcional, debería tener todo el aparato de funciones para tratarlo. Aunque a veces podría plantearse la necesidad de definir entonces iteradores para foreach, se podría trabajar con el iterador natural.