Está siendo un magnífico verano y aunque nos queda un mes completo todavía, ya el ambiente empieza a oler a Otoño. Y a series. El próximo martes 23 se estrena la tercera temporada de Halt and Catch Fire. Dos días después de que acabe, el 21 de Octubre, empieza BlackMirror. Los astros se alinean para darnos un respiro y que podamos compaginar todo. Qué gustazo. ¡Estamos listos para empezar la temporada!

En la misma línea de Stephenson -pero mucho más ácido y humorístico- Max Barry se pregunta a dónde nos lleva esta sucesión de payasadas, por decirlo en sus palabras.

I was thinking about how unfair it is that reality has evil right-wing corporate overlords named the Koch Brothers while if I wrote that in a novel people would call me shallow and juvenile. I mean, it would be true. But also unfair. You’re supposed to have more creative license in fiction, not less. Then there’s Trump, who does things on a daily basis that no satirical character could get away with. It makes you wonder where there is left to go.

Send it the clowns, Max Barry.

Sugiere, además, que la política del espectáculo nos empuja a una situación donde veremos a dos payasos competir por ser presidente – o a un nuevo Hitler ascendiendo al poder. No sabría decidirme entre si será eso lo que viene o más bien deberíamos prepararnos para un oso azul en 3D como próximo diputado de las cortes, como propuso Charlie Brooker en BlackMirror. Y pienso que ahora que las anteriores temporadas se parecen más a un documental que a ciencia ficción futurista, es un alivio que el estreno de la siguiente sea el 21 Octubre. Necesito otra dosis de la vacuna contra la realidad.

Grammarly

Como parte de mi refuerzo de aprendizaje del inglés, en los últimos meses he estado escribiendo varios textos: formales, informales, críticas, emails, académicos, informes, etc. Mi herramienta favorita actual para esos momentos es Grammarly. Las sugerencias van más allá de la mera corrección ortográfica y son contextuales al estilo de la redacción, te recomienda sinónimos a palabras usadas en exceso, se integra en mi flujo diario de trabajo digital (email, Simplenote, etc) y me envía informes semanales de los errores más habituales que cometo, en el navegador funciona como tesauro al seleccionar una palabra, etc ¿qué más se puede pedir?

Al poco de experimentar la versión gratuita me hice premium; fue un flechazo a primera vista. Aunque no lo he usado todavía me gusta además que, de manera natural, te invite a contactar con un humano para revisar textos que son devueltos en menos de media hora, 3h o un día. Han visto muy bien que la gente con la sensibilidad para usar este tipo de herramientas son presciptores naturales de un servicio de traducción humano.

Como todo buen software, tiene sus peculiaridades que hace que les tengas cariño: por ejemplo, las comas de Oxford han sido un descubrimiento y todavía estoy decidiendo de qué bando estoy. Por el momento, lo único que verdaderamente me molesta es que sólo pueda usarla con los textos de inglés. Me gustaría ver algo así para el español, gallego o portugués. ¿Una especie del famoso dardo en la palabra actualizado al siglo XXI?

En esta charla, Stephenson, introduce la idea de que, como sociedad, nos hemos olvidado de cómo llevar a cabo grandes empresas, esas que se consideran imposible. Hasta que se consiguen. Considera que en la raíz de esto está la pérdida de apoyo a lo cientifíco, que se evidencia en detalles diarios como padres que no quieren vacunar a sus hijos, etc. Pero también que no tenemos la mentalidad adecuada para embarcarnos y asumir el coste de una aventura con riesgo.

Si el mismo tema os resulta interesante, os recomiendo una de las mejores películas de la década: Interstellar. Porque los dioses somos nosotros.

Programación de interfaces basada en componentes

En mi travesía por aprender cómo mejorar lo que hice en mi último proyecto, estoy empezando a apreciar el encaje que tienen ideas como el immediate mode, las funciones puras y la inmutabilidad. Conceptos que transcienden modas y que, al entender su utilidad y trade-offs, se introducen en el conjunto de herramientas que tenemos a nuestra disposición, sea cual sea el contexto en que programamos.

Hay otro concepto al que recientemente le estoy prestando atención: programación de interfaces basada en componentes.

¿En qué consiste?

En la creación de elementos reutilizables que sean autosuficientes. Es decir, estables por sí mismos y que no dependan de estado global.

components_before components_after
Lo que hacemos ahora Lo que necesitamos hacer

Es muy interesante comparar cómo diversas herramientas proponen la creación (o no) de componentes. La selección tecnológica es, en sí mismo, un tema con muchos matices y tonalidades y existen diversas aproximaciones para comparar toolkits de programación. Algunas aportan algo, otras no y otras depende.

Por ejemplo, a la hora de comparar dos toolkits líderes de sus respectivos sectores como Wicket y React podríamos hacerlo de la siguientes maneras:

Sin embargo, si los comparamos en términos de cómo componen la interfaz, vemos que su aproximación es similar: proponen crear componentes que encapsulen conjuntamente HTML, CSS y JavaScript. ¿Cómo lo hacen? Tanto Wicket como React crean los componentes mediante un lenguaje de programación (Java/JavaScript) y no mediante un lenguaje de marcado (HTML).

  • Componente en Wicket. En Wicket, la unidad mínima de reutilización es el Panel, que consiste en varios archivos: panel.java, panel.html y opcionalmente otros de localización como panel.properties.
  • Componente en React. En React, el componente es un archivo JavaScript que devuelve código HTML. JSX es únicamente azúcar sintáctico que ayuda a que el código JavaScript sea más expresivo.

Esta aproximación los diferencia de otros toolkits como Angular, Polymer, JSP o Mako, que serían ejemplos de lo contrario: la composición de la interfaz se hace mediante un lenguaje de marcado -HTML- o derivativos que compilan a él.

¿Esto supone una mejora?

La respuesta rápida: sí, porque en un lenguaje de programación tienes a tu disposición 50 años de investigación en computer science, destilados con más o menos suerte. Hombros de gigantes sobre los que mirar más lejos.

La respuesta más elaborada: las interfaces son sistemas complejos, necesitamos subcomponentes para simplificar su creación y mantenimiento. Hay dos áreas donde un lenguaje de programación supera al de marcado para crear subcomponentes: encapsulación y expresividad.

Encapsulación

La encapsulación consiste en la creación de elementos que podamos (re)usar sin la obligación de entender sus propiedades internas, ni de empezar todo desde cero cada vez. En un lenguaje de programación tenemos herramientas para encapsular elementos y funcionalidades como paquetes, módulos, clases, funciones, herencia, mixins, patrones de diseño, etc. Por el contrario, en un lenguaje de marcado como HTML, las opciones son inexistentes.

Iniciativas como WebComponents se han creado 20 años después del propio HTML. Son bienvenidas, pero no podemos obviar el elefante en la habitación: sólo nos ofrece la creación de paquetes, no todo lo demás. En Wicket y React los componentes son elementos que están programados en Java/JavaScript y, por lo tanto, podemos hacer con ellos lo que normalmente haríamos con cualquier otro trozo de código: herencia, composición, aplicar patrones de diseño, etc.

Expresividad

La expresividad consiste en la capacidad de programar los distintos matices que deseamos. En un lenguaje de programación tenemos a nuestra disposición mecanismos como tipos de datos, control de flujo, inversión de flujo, bucles, paso de mensajes, etc. HTML no tiene nada de esto.

Los toolkits que pretenden componer mediante un lenguaje de marcado -JSP en Java, Mako en python, etc- no poseen esa expresividad. Para solventarlo, tratan de integrar parte de ella en un lenguaje propio que compila a HTML: un sistema de plantillas. Un ejemplo típico que casi todos los sistemas de plantillas poseen son algunas construcciones para controles de flujo y bucles. Por ejemplo, en JSP:

<c:when test="${isThisVariableTrue}">
 <h1><fmt:message key="Title" /></h1>
 <c:if test="${isThisOtherVariableTrue}">
   <fmt:message key="showMessage" />
   <c:out value="${value}" />
 </c:if>
 <c:if test="${isThisOtherSecondVariableTrue}">
   <fmt:message key="aDifferentMessage" />
   <c:out value="${aDifferentValue}" />
 </c:if>
</c:when>

También necesitan crear mecanismos para pasar información del código a la plantilla y suelen ofrecer nuevos tags HTML para realizar acciones que HTML no permite. Interacciones que cualquier lenguaje de programación incluye por defecto pero que un sistema de plantillas integra con esfuerzo, limitaciones y a costa de aprender una nueva sintaxis no reutilizable en otros contextos. Para controlar la complejidad necesitamos más expresividad que la que nos aportan bucles y condicionales. Si lo único que puedes utilizar es un martillo, todos los problemas te parecerán clavos.

Conclusión

Sería simplista decir que Wicket y React se han convertido en líderes de sus respectivos sectores únicamente por la propuesta de creación de interfaces mediante componentes. Es, sin embargo, un fundamento que comparten y plausible para explicar por qué React tiene éxito y Polymer no: como la productividad aumenta al usar esta aproximación, se acaba extendiendo por microdecisiones de agentes interrelacionados que buscan su propio beneficio.

Al pivotar la construcción de componentes sobre un lenguaje de programación y no sobre un lenguaje de marcado tenemos a nuestra disposición todas las herramientas de encapsulación y expresividad disponibles en el lenguaje, lo que facilita domar la complejidad inherente a la creación de interfaces. El aumento de productividad es de órdenes de magnitud.

Para entender en toda su complejidad los efectos del cambio, conviene releer parábola de los relojeros.

En la evolución de cómo se hacen aplicaciones web, la mutación principal del ciclo anterior habría sido la separación API/interfaz. En el actual, apostaría que lo fundamental se deriva de que el ecosistema JavaScript (tanto el lenguaje como las librerías a su alrededor) ha interiorizado dos ideas del mundo de la programación funcional: las funciones puras y la inmutabilidad. Esta hipótesis serviría para explicar, por ejemplo, la popularidad de React y Redux que no son más que la aplicación de estos conceptos a la creación de interfaces y la gestión del estado.

Herbert_simon

La arquitectura de la complejidad

Herbert A. Simon dedicó su vida al estudio de sistemas: organizaciones, economía o inteligencia artificial. En 1962, publicó un paper titulado «The architecture of complexity» donde presenta cómo el estudio general de sistemas significa entender la formación de jerarquías.

Sistemas complejos y jerarquías

Simon aproxima un sistema complejo como aquél que está compuesto por un número grande de componentes que interactúan de manera no trivial. Un sistema jerárquico sería aquél que se puede descomponer en subcomponentes interrelacionados, que no necesariamente tienen que estar subordinados en una relación de autoridad maestro-esclavo.

La razón por la que es más habitual encontrar jerarquías de cualquier tipo en los sistemas complejos es porque forman estructuras estables de manera más rápida. Para defender esta tesis repasa ciertos ejemplos de la naturaleza y sociales, pero baste cita la famosa parábola de los dos relojeros para entender lo que quiere decir:

There once were two watchmakers, named Hora and Tempus, who manufactured very fine watches. Both of them were highly regarded, and the phones in their workshops rang frequently – new customers were constantly calling them. However, Hora prospered while Tempus became poorer and poorer and finally lost his shop. What was the reason?

The watches the men made consisted of about 1.000 parts each. Tempus had so constructed his that if he had one party assembled and had to put it down -to answer the phone, say- it immediately fell into pieces and had to be reassembled from the elements. The better the customers liked his watches, the more they phone him, the more difficult it became for him to find enough uninterrupted time to finish a watch.

The watches that Hora made were no less  complex than those of Tempus. But he had designed them so that he could put together subassemblies of about ten elements each. Ten of these subassemblies, again, could be put together into a larger subassembly; and a system of ten of the latter subassemblies constituted the whole watch. Hence, when Hora had to put down a partly assembled watch in order to answer the phone, he lost only a small part of his work, and he assembled his watches in only a fraction of the man-hours it took Tempus.

Es decir, la organización en subsistemas, facilitaría la estabilidad de la estructura global.

Sistemas casi-descomponibles

Para entender las jerarquías, Simon propone dos aspectos fundamentales:

  • el número de componentes en que se particiona el sistema: o el span. En los límites, un sistema jerárquico con span = 1 sería una cadena de componentes; un sistema jerárquico se consideraría como plano si su span es alto.
  • cómo se agrupan sus componentes: aunque los sistemas físicos y químicos se suelen agrupar por las propiedades espaciales y los sociales por la interacción entre componentes, Simon argumenta que esta es una falsa dicotomía. Él propone que los componentes de un sistema se agrupan por la “intensidad de la interacción” entre ellos y que la cercanía espacial es un subproducto de ciertas estructuras físicas que necesitan cercanía para intercambiar información.

Es precisamente la interacción –entre subsistemas y dentro del subsistema- lo que Herbert usa para estudiar las jerarquías. Su tesis es que podemos entenderlas como sistemas casi-descomponibles: es decir, que las interacciones dentro de un subsistema son muy intensas mientras que las interacciones entre subsistemas son más débiles aunque no despreciables. En parábola:

Consider a building whose outside walls provide perfect thermal insulation from the environment. We shall take these walls as the boundary of our system. The building is divided into a large number of rooms, the walls between them being good, but not perfect, insulators. The walls between rooms are the boundaries of our major subsystems. Each room is divided by partitions into a number of cubicles, but the partitions are poor insulators.

A thermometer hangs in each cubicle. Suppose that at the time of our first observation of the system there is a wide variation in temperature from cubible to cubicle and from room to room – the various cubicles within the building are in a state of thermal disequilibrium. When we take new temperature readings several hours later, waht shall we find? There will be very little variation in temperature among the cubicles within each single room, but there may still be large temperature variations among rooms. When we take readings again several days later, we find an almost uniform temperature throughout the building; the temperature differences among rooms have virtually disappeared.

Es decir, a  corto plazo, se podría entender el comportamiento de un subsistema de manera individual; sin embargo, a largo plazo, necesitaríamos incluir en la ecuación el resto de componentes de manera agregada para tener en cuenta los efectos de esas interacciones.

La descripción de la complejidad

El hecho de que muchos sistemas complejos tengan una estructura jerárquica casi-descomponible, facilita nuestra comprensión de ellos. O quizás nuestra comprensión de otro tipo de sistemas está limitada por nuestra capacidad de procesamiento. En cualquier caso, según Simon, cualquier actividad humana que suponga problem-solving se puede asimilar a un sistema de este tipo: el progreso hasta llegar al objetivo se produciría por un proceso de prueba/error selectivo; nos apoyaríamos en resultados intermedios que tendrían la misma función que los subsistemas biológicos (estabilizar la estructura) y nos señalizarían el camino hacia el objetivo.

¿Cómo, pues, podemos usar en nuestro beneficio las jerarquías para entender y construir sistemas complejos?

  • La jerarquía es, al fin y al cabo, una manera de encapsular la redundancia del sistema y hacerlo más económico en términos de esfuerzo.
  • Aunque no conocemos reglas generales que describan cómo encapsular esa redundancia para cualquier sistema, tenemos a nuestra disposición dos tipos de representaciones útiles: describir su estado y describir el proceso.

Usando la descripción de estado, podríamos definir un círculo como “el lugar de los puntos equidistantes de un punto dado“. La definición del proceso podría ser algo como “pinchar el compás en un punto del plano y rotar el otro brazo hasta que dé una vuelta completa“.

Coda

La arquitectura de la complejidad, de Herbert A. Simon aborda una tarea difícil y consigue reducirla a algo manejable: propone que el estudio de sistemas complejos es fundamentalmente el estudio de su jerarquía, encontrar la redundancia que nos permita representar su estructura de manera comprensible, para lo que tenemos a nuestra disposición dos herramientas fundamentales, estado y proceso.

Una teoría de sistemas aplicable a multitud de entornos (biología, sociales, etc) es necesariamente generalista. Como programador, sin embargo, hay lecciones en este paper que se pueden extrapolar a nuestro día a día.

code-hierarchy

La teoría de la casi-descomponibilidad es atractiva. Explica, por ejemplo, por qué los tests unitarios en subsistemas son posibles pero no suficientes para modelar el comportamiento del sistema. Explica también que para una mayor eficiencia en nuestro trabajo deberíamos enfocarnos en la búsqueda de submódulos estables. No menos importante: apunta que para agregar código en componentes (funciones, clases, módulos, etc) deberíamos primar agregaciones con gran interacción interna pero con interacción externa baja – es decir, loose coupling y high cohesion.

Por otro lado, alguna vez he bromeado con que el título que mejor me representa es el de físico-químico de sistemas de control interactivos. Tras la boutade se esconde una pequeña píldora de verdad: en el fondo, el día a día de todo programador consiste en eliminar la redundancia de un sistema. Me paso el día codificando esa redundancia con 2 herramientas principales: estado y proceso, datos y algoritmos.