Seguramente has oído hablar de Smalltalk. Posiblemente, y puesto que uno de los nichos donde se ha quedado encerrado es el educativo, si has estudiado programación, incluso puede que lo hayas estudiado. Pero no trato de hacer una presentación aséptica, completa y exhaustiva del lenguaje y sus herramientas, sino que voy a dar mis puntos de vista, subjetivos, evidentemente, sobre este asunto. Me gustó su sencillez: en la imagen de arriba tenéis resumida todos los elementos de la sintaxis del lenguaje en una postal.

Cuando me llegó información concreta sobre Smalltalk ya conocía otros lenguajes y programaba con cierta soltura con algunos de ellos, bajo la égida de la POO². En general, la POO me parece una buena abstracción como psicólogo³, aunque para resolver problemas puede haber otros procedimientos tan válidos o, incluso, más eficientes. De hecho, en líneas generales, considero que la POO puede también entorpecer u ofuscar una solución, cuando las clases empiezan a ser más etéreas y menos tangibles. Los conceptos, menos tangibles, o más abstractos si lo prefieres, son más complicados de manejar por la mente humana y, por tanto, de llevar a una estructura virtual, paralela en POO.

Éste enfoque, Smalltalk lo resume en dos aspectos: cosas y acciones, nombrándolas como objetos y llamadas⁴. En este lenguaje todo dato es un objeto, una clase es un objeto, y todo lo que no es un objeto, es una llamada. Por ejemplo, los operadores aritméticos son llamadas definidas en la clase numérica correspondiente, igual que las funciones trigonométricas. Llegando al extremo, de que no hay palabras clave como if, operadores o bucles como for. Pero en la clase Boolean encontrarás llamadas como IfTrue:, IfFalse, or: o and:, por poner algunos ejemplos. La estructura no cambia y se puede resumir, en general como:

objeto llamada [parámetros]

El problema de este enfoque es que necesitarías muchas horas de trabajo para levantar cualquier tipo de entorno que resuelva algún problema sólo con esas premisas y partiendo de cero. Para ello, otra característica de Smalltalk es la cantidad de código que ya nos proporciona hecho, funcionando y probado y, por tanto, podemos encontrarnos dos partes bien diferenciadas de Smalltalk: la máquina virtual (vm) y la imagen⁵. La vm suele coincidir con un ejecutable, que dependerá de cada sistema operativo, pero cuya función es hacer que los objetos contenidos en el código y las librerías dentro de la imagen cobren vida y se envíen mensajes unos a otros para funcionar.

Este modelo es su principal fuerza y su principal desventaja. Por un lado, tenemos que una imagen es una base de datos del estado de los objetos que contine. Cuando guardamos una imagen, guardamos en un archivo de disco estático el estado de todos los objetos que contiene nuestro entorno de trabajo. Por el otro, las imágenes tienen bastante peso y son un inconveniente en el proceso de distribución de nuestra aplicación. Es decir, nos da resuelto el problema de la serialización del contenido, pero a cambio de dificultarnos la distribución.

Cuando está en funcionamiento se convierte en un sistema REPL⁶ con esteroides. Mientras estás programando puedes evaluar cualquier código, no hay nada oculto en librerías, todo está a la vista. Puedes crear clases, dotarlas de nuevos mensajes, modificar el código que ya existe evaluando su adecuación al proyecto sin detener en ningún momento el proceso. Si se produce algún error, aparecerá un mensaje junto con una ventana de depuración, donde podrás modificar el código o escribir nuevo sobre la marcha. Puedes inspeccionar cualquier objeto del sistema e incluso modificarlo mientras se ejecuta. Es el sistema más interactivo y flexible que he utilizado jamás y este fue el principal motivo que me enganchó durante aquellos años.

Éste fue mi primer entorno Smalltalk, aunque no llegué a él buscándolo como herramienta de programación, sino como herramienta educativa. En aquel entonces me dedicaba a dar clases y Squeak fue un juguete muy útil. Por él me metí en el mundo de Smalltalk, aprendí el lenguaje y algunas cosas más sobre programación en general.

Cuando empecé a trastear con él, lo hice por los eToys. En el entorno de Squeak puedes hacer cualquier dibujo a mano alzada (un eToy) y luego programarle comportamientos como que se desplace, que rote, que cambie de color, etc. Puedes ponerle sensores que detecten otros eToys y que interactúen entre sí, etc. Si has trabajado alguna vez con Scratch⁷, ese sistema basó su idea en esta herramienta.

Los menús, herramientas de programación y demás elementos se articulan desde un sistema de ventanas Morphic, basado en Self. Por lo demás, es un Smalltalk completo y como tal todo el sistema se puede visualizar (y modificar) en el Browser. Su principal impulsor fue Alan Kay, uno de los creadores de ST-80, y por tanto mantiene herramientas como el famoso Browser para visualizar el código mediante el árbol de paquetes, clases, protocolos y llamadas.

Cuando yo empecé a trastearlo todavía se utilizaban en el código Smalltalk el símbolo ← para hacer las asignaciones y ↑ para hacer una devolución desde una llamada⁸. La separación del código entre clases (en el archivo .changes) venía delimitado por un carácter de salto de página y de fin de archivo para separar paquetes. Esto hacía complicado la edición en otros editores que no fueran los propios del entorno.

Al poco tiempo apareció GNU Smalltalk como herramienta de scripting y por tanto debía utilizar una codificación ASCII sin caracteres no imprimibles. Squeak también comenzó derivó a utilizar el código más de texto plano.

En resumen: me lo pasé muy bien con Squeak. Mis alumnos aún más. Recuerdo aún algunos ejercicios, el primero consistía en dibujar un eToy similar a un coche y otro similar a una carretera y programar el primero para siguiera el segundo. Recuerdo otro ejercicio donde programábamos una caja de Skinner para ilustrar los distintos tipos de aprendizaje animal, con sus refuerzos positivos y negativos mediante un esquema de palancas, sonidos y luces simuladas con eToys.

Pharo se inició como un fork de Squeak. El objetivo perseguido, y conseguido desde mi punto de vista, era proporcionar un entorno más profesional para programar en Smalltalk. Por tanto, eliminó los eToys y le dio un aspecto más formal en la interface con Morphics.

Su mayor aportación, desde mi punto de vista fue el desarrollo de las herramientas Monticello y Metacello⁹, que se adoptaron también rápidamente en Squeak. Proporcionando un sistema de control de versiones y facilitando el trabajo en equipo.

Por otro lado, al ser Pharo un fork de Squeak su imagen sigue siendo heredera en su kernel más profundo del estándar ST-80 que definió Smalltalk a finales de los años 70. Este kernel lleva funcionando y depurándose muchos años, por lo que se puede confiar en la estabilidad y afinación del sistema.

A la vez que se desarrollaba Pharo, aparecieron entornos web y de servidor como Aidaweb o Seaside. Que permiten desarrollos de aplicaciones concurrentes y accesibles sin necesidad de instalar ninguna infraestructura.

Aunque Squeak siempre será mi favorito, por haber sido el primer entorno Smalltalk libre con el que trasteé. Si estás pensando en un entorno más profesional, Pharo es el más aconsejable. Especialmente por su herramienta pharo-launcher.

Esta herramienta nos permite descargar distintas imágenes y máquinas virtuales. De esta manera, podemos gestionar fácilmente los proyectos aún con versiones de Pharo antiguas.

Smalltalk/X es un entorno Smalltalk completo desarrollado por la empresa alemana eXept software AG y que se distribuye gratuitamente, sólo hay que registrarse como usuario. En su día lo estuve, pero el correo electrónico con que lo hice ya no lo tengo y por tanto he perdido la posibilidad de volver a descargarlo sin volver a registrarme. Podría hacerlo de nuevo, sí, pero a estas alturas no creo que lo utilizara mucho y puede la pereza. Además, cuando me registré eran años en los que la paranoia no estaba tan asentada como ahora 😜.

Pero también he encontrado un fork que se puede descargar libremente desde https://jan.vrany.io/stx/. Así que me puse a probarlo y he comprobado que faltan algunas partes (supongo que las propietarias) y al intentar acceder a ellas lanza un inevitable error.

Lo primero que salta a la vista de esta herramienta es que las ventanas de las herramientas son independientes. En los dos entornos anteriores no era así, porque Squeak nació con pretensiones de sistema operativo para el proyecto Dynabook de Alan Kay. Integraba herramientas de gestión de archivos, sonido, gráficos, presentación, etc. Es decir, todo en una ventana con ánimo hacer de escritorio.

Otro de los puntos interesantes de Smalltalk/X, al menos en su día, era la facilidad para adecuar la interface imitando las ventanas del Sistema Operativo anfitrión y el que detecte el idioma configurado en el mismo para mostrar menús y widgets.

Pero la ventaja principal, por lo menos desde mi punto de vista, cuando lo llegué a utilizar de manera profesional, es que puede generar ejecutables independientes y evita el modelo de vm+imagen de los otros sistemas Smalltalk. Además podías escribir código C directamente en las clases y la integración con C era fácil y fluida. He visto que el fork que enlazo también tiene soporte para Java.

Llegué a Smalltalk/X un poco de rebote. Me apunté, joven yo, a una de esas, ahora llamadas, startups que prometen mucho y pagan poco. La idea inicial era desarrollar una aplicación de escritorio. El jefe prefería éste sistema a Java. La historia es larga y con ramificaciones legales que no vienen al caso. El asunto es que, conseguimos poner en marcha una beta del programa y comenzar con las pruebas en producción con algunas pequeñas empresas cliente. Durante las primeras pruebas se llegó a la conclusión de que se necesitaba un acceso concurrente y aprovechando que teníamos funcionando de manera suficientemente estable el modelo de negocio en Smalltalk/X, lo pasamos fácilmente a Pharo sobre un servidor web Aida. En un par de meses conseguimos hacer el cambio y conseguir otra decena de empresas cliente... todo parecía ir correctamente hasta que el jefe recibió una oferta y vendió la empresa. Los que la compraron ni habían oído hablar de Smalltalk ni les importaba, nos despidieron a todos de un día para otro, y se pusieron con una evolución que creían que podían hacer en tres días con PHP. Y así terminó mi única incursión profesional programando en Smalltalk. A la semana de ser despedidos nos llamaron para que regresáramos a mantener lo que ya teníamos funcionando mientras hacían su aplicación. Yo no regresé, en ese tiempo era un segundo trabajo y no lo necesitaba para pagar la hipoteca. Luego me enteré de que no volvimos nadie del equipo ST, hubo bastantes reclamaciones y tuvieron que pagar varias indemnizaciones y la empresa quebró.

Las cosas han evolucionado bastante desde que abandoné Smalltalk. Por ejemplo, en el aspecto del trabajo en equipo. Cuando lo dejé existía Monticelo y nada más. Ahora veo que estas tres herramientas cuentan con soporte para Git.

Los sistemas se han mostrado bastante ligeros. No puedo asegurar si es por una mejora en la ejecución de Smalltalk o que ahora mi máquina es más capaz, pero la velocidad percibida es bastante más fluida de lo que la recordaba. Pero no debe ser sólo eso: en su día Smalltalk/X era más ágil que Squeak o Pharo, pero esta vez, éstos dos se han mostrado bastante más rápidos, especialmente Squeak.

En estos momentos había pensado darle otro tiento a Pharo, aprender cómo va el tema de gestionar respositorios Git y hacer algún ejercicio sencillo. Ahora mismo supongo que me costará más retomarlo, mis esquemas mentales se han ido orientando más la programación funcional que a la POO, pero supongo que todo es ponerse. Aunque a estas alturas tampoco garantizo que llegaré a nada concreto, lo mismo me empieza a aburrir a los dos días como todos los proyectos que empiezo últimamente.