Algo similar es lo que quiero capitalizar con Cardumem y luego portar a Grafoscopio, pues, como lo ha mostrado la experiencia con este último, las interfaces en Spec, el toolkit gráfico de Pharo, si bien brindan algunas cosas que las interfaces web no tienen, adolecen del basto ecosistema de ésta última y mantienen los documentos y la computación aisladas dentro de la imagen.

La web, por el contrario, es casi ubicua en términos de las tecnologías ya instaladas y así no se cuente con una conexión a internet en el equipo de cómputo, si este tiene una interfaz gráfica, muy seguramente contará con un naveador web. Y ahora que los sistemas hipermedia, hacen posible programar la web desde cualquier lenguaje (HOWL: Hypermedia On Whatever you Like), se puede aprovechar tanto lo que sabemos de los lenguajes/entornos que nos gustan (Pharo o Lua) como del amplio sistema de la web. Antes de 2023, que se popularizaron los sistemas hipermedia, teníamos que elegir entre lo uno y lo otro. Y yo deselegí activamente la web, debido al adefesio de JavaScript y lo engorroso del CSS. Hoy, las condiciones son bien distintas.

Como he documentado en mi blog, antes de Grafoscopio, mis primeros intentos por crear flujos y herramientas de documentación interactiva a medida fueron en IPython, pero me cansé de lidiar con la complejidad incidental del stack con el que IPython y luego Jupyter estaban hechos, encontrando en Pharo Smalltalk una plataforma más coherente, simple, entendible y adaptable.

Como he explicado en otros apartados, si bien Grafoscopio mezcla herramientas distintas de nuestros flujos de documentación y publicación, ahora Cardumem surge con la idea de crear una interfaz web y una experiencia unificada para las integraciones, con una sintaxis minimalista y sin los requerimientos conceptuales de la programación orientada a objetos.

Grafoscopio incluía los automatismos que permitían exportar un documento/árbol a distintos formatos. Cardumem debería continuar dicha tradición, indicando qué versión y checksum del mismo fue utilizado para la exportación, junto con el algoritmo de selección, traversal y expotación que dieron lugar a un documento exportado en un formato particular. Dicha información debería ser parte del documento fuente, del mismo modo que lo era en Grafoscopio y, eventualmente, del exportado, cuando sea posible. (en Grafoscopio lo colocaba en los anexos.

La idea y el uso de las libretas computacionales es menos generales que la de (Inter) Personal Knowledge Management, como era de esperarse y ha evidenciado nuestras prácticas en la comunidad de Grafoscopio, donde sus libretas interactivas fueron usadas extensivamente y de acuerdo a las necesidades descubiertas con la comunidad en la creación y articulación de flujos documentales a medida. Algo similar se puede decir en las ciencias sociales y humanas, donde también se escribe, pero no simulaciones de sistemas complejos.

En estos contextos comunitarios y de las ciencias amplias y estudios críticos, el hipertexto y la interactividad puede servir, pero más para explorar la memoria propia, imaginar y enactuar otras formas de comunicarla y construirla.

El énfasis actual en Cardumem, en lugar de Grafoscopio, y los posibles vínculos entre ambos reconoce estas otras posibilidades de interacción y computación desde esa memoria interpersonal e interactiva.

Bret Victor, en Media for thinking the unthikable, compara a Leibnitz con Steve Jobs, diciendo que el primero era un gran inventor de interfaces de su época, en la forma de nuevas notaciones.

Cardumem, de hecho, empezó como un ejercicio mental pensando una nueva notación para expresar "álgebras hipertextuales" que pudieran ser embebidas en un motor wiki (al comienzo vía Lua en JavaScript y luego del lado del servidor, con sistemas hipermedia). Y dicha notación fue concebida en la medida en que las herramientas externas para manipular hipertexto, como TiddlyWiki Pharo generaban mucha fricción en los miembros de la comunidad de Grafoscopio, al punto que su uso era marginal. Una nueva herramienta con una nueva notación alentaría usos y personalizaciones compartidas que con herramientas separadas eran muy esporpadicos y más bien solitarios, entre un puñado de personas, a lo sumo.

Dado que las piezas para armar el wiki (Djot y YueScript) ya estaban integradas al ecosistema Lua, y que originalmente se pensaba en integrarlo directamente a TiddlyWiki, del lado del navegador web, en lugar del servidor, Lua este fue elegido en lugar de Pharo para los procesos de prototipo, dando muy buenos resultados iniciales hasta el momento.

Una solución serían los artículos de fuente única y salidas distintas (PDF y Web estática/interactiva) en los que la marginalia puede ser usada para colocar notas extendidas en forma de enlaces abreviados, AprilTags o códigos QR que apunten a las versiones expandidas de esos códigos en los formatos estáticos. Esto haría que esos códigos extendidos se presenten por demanda si la lectora/exploradora los desea, en el medio (impreso, web) donde acceda al artículo.

Afortunadamente, para las ciencias humanas y sociales, esta computación está aún en desuso y se pueden explorar otras dinámicas de escritura en digital mientras las acá criticadas maduran y mientras se trabaja el problema de reproducibilidad desdes otros lugares, como Cardumem

Interesting, as the possibilities are similar to Cardumem's as one of the main notations there is for transclusions, even of its own source code at some particular commit. Also, there Cardumem shares the idea of tailor made software tools, but the difference is that its context is related with interpersonal and community knowledge and memory care, preservation and management and the tech stack is different (Lua based, instead of Common Lisp).

Para Cardumem el enfoque, como he dicho en otros lados es diferente, eligiendo una arquitectura federada, que incluye los servidores ejecutándose localmente y con menores complejidades arquitectónicas.

A menos que cada uno tuviera su propio servidor y los servidores centralizados fueran usados sólo para coordinar comunicaciones, como ocurre con Fossil y ocurrirá con Cardumem. Así, la centralización ofrece conveniencia pero no usa asimetría fundamental de capacidad o poder, como ocurre actualmente y servicios/protocolos de descubrimiento de servidores podrían ser implementados sobre la infraestructura cliente servidor actual, en caso de que algún servidor sea dado de baja.

Acá hay transiciones en los siguientes cuadrantes:

Cardumem toma una ruta alterna y más sencilla para explorar transiciones similares.

1. Inicia por el wiki, como software documental asíncrono.
2. Se conectará con HedgeDoc como software documetal síncrono.
3. Se conectará con Hypothesis como software dialógico asíncrono.
4. Implementará progresivamente funcionalidades síncronas vía sistemas hipermedia en tiempo real.

La idea de local primero ocurrirá debido a que el servidor puede correr de manera local o remota.

Es interesante esta generalidad desde los bloques (objetos, tipos y relaciones, que se juntan en un grafo). Los Dumems en Cardumem son otra forma de generalización desde el hipertexto programable (gracias al scripting en YueScript) y los metadatos personalizables que permiten las tablas de Lua.

Sin embargo, para disminuir la complejidad y aumentar la practicidad, en Cardumem no apuntamos a tecnologías de la llamada web 3.0, sino que usamos las buenas y confliables web 2.0 con algo de retrofuturismo en los sistemas hipermedia.

Con ADD también empezamos con la instancia del objeto que queremos manipular.

Desde que me lo presentaron, siempre me ha desagradado el Test Driven Design (TDD), pues me parecía absurdamente burocrático y contra flujo. Afortunadamente, gracias al podcast de Book Overflow, encontré un autor reconocido, John Ousterhout, creador de Tcl/Tk y "A Philosophy of software design", que comparte mi opinón respecto a escribir los test antes de escribir el código y dice que en el TDD no se hace diseño, sino que se depura el software hasta su existencia.

Mi enfoque, que podría llamarse Argumentative Driven Design o ADD es uno en el que el código se desarrolla para mostrar un argumento en favor de una hipótesis, y las pruebas de código se van creando en la medida en que uno necesita inspeccionar y manipular los objetos que dicho código produce.

En palabras práctica, esto quiere decir que los test y su configuración deberían hacerse cuando uno necesita hacer un "print" (para probar/inspeccionar/manipular un estado/elemento del sistema) y no antes, lo cual aumenta la utilidad, no interrumpe el flujo y responde preguntas similares a las de este apartado, respecto a de dónde provienen las pruebas y qué hacer con los resultados exitosos.

Nuestros wikis interpersonales son pensados para ser utilizados por otras personas. Sin embargo, los identificadores únicos vía NanoID, podrían tener también una jerarquía de contadores arborecentes, similares a los de Luhmann.

Había pensado en esos contadores únicos en cada wiki para TiddlyWiki por si queríamos algún tipo de enlace corto local de ese wiki y el NanoID para los indicadores únicos entre wikis, dadas las bajas probabilidades de colisión. Son ideas que se pueden combinar con otras como el control de versiones.

El carácter dinámico del wiki no tiene por qué sacrificar la trazabilidad histórica y una cierta memoria visual de los enlaces y sus conexiones. Lo clave es que el wiki sea programable con curvas progresivas entre creación de contenido y de funcionalidad, como lo hace TiddlyWiki y lo propone Cardumem

Los blikis (blogs + wikis) son formas de pensar en público y tener modos de lectura y escritura está bien, pues no todos los que se aproximan al wiki lo van a editar y la mayoría de internautas sólo lo va leer.

Además sistemas tipo TiddlyWiki (y en el futuro Cardumem) alientan en buena medida la reedición de unidades de contenido (wiki refactoring). Lo clave es que las unidades sean pequeñas y se puedan usar para organizar otras unidades (es decir usarlos como etiquetas).