El artículo reflexiona sobre la representación de los datos en los lenguajes de programación y sostiene que la elección de una notación determina en gran medida la productividad del programador. Partiendo de un ejemplo en Rust, donde el código que crea una estructura, su modelo mental en memoria y la representación impresa son tres notaciones distintas, el autor contrasta esta situación con Clojure, cuyo Extensible Data Notation (edn) reutiliza la misma sintaxis para escribir, imprimir y leer los datos, igual que ocurre con JSON respecto a JavaScript en el terreno del intercambio. La convergencia entre la forma textual y la forma en memoria reduce la carga cognitiva y permite usar la notación como herramienta directa de pensamiento, del mismo modo que un matemático manipuja expresiones algebraicas en lugar de valores concretos.
A continuación, el texto repasa dónde aparecen estas notaciones a lo largo del ciclo de vida del dato: en bases de datos relacionales, en la salida hacia JSON, en depuradores como gdb, en archivos de configuración como TOML y hasta en la pizarra. Cuando todas estas capas obligan a traducir entre representaciones diferentes, se desperdicia capacidad mental. El autor vincula la popularidad de las bases de datos documentales de pares clave-valor con la posibilidad de mantener el mismo modelo dentro y fuera del programa.
Otro eje del ensayo es la propiedad de ida y vuelta entre la representación textual y la memoria, posible gracias a la función de lectura frente a la de evaluación, lo que permite compartir datos con sistemas no fiables sin riesgos de ejecución. Por último, se describen los cuatro niveles de modelo de datos que conviven en un programa Rust habitual: máquina, lenguaje inseguro, lenguaje seguro y aplicación, y se anuncia que las entregas siguientes explorarán cómo conviven estas capas con un sistema de tipos gradual.