Finalmente después de un mes de trabajo voy a intentar explicar sintéticamente en que consiste el proyecto en el qué me encuentro trabajando. Pero dado que para entender lo que estamos intentando hacer es necesario cierto conocimiento de Smalltalk, he decidido dividir esta explicación en 2 partes. En esta primera parte voy a explicar algunas cosas básicas (o mejor dicho históricas) de Smalltalk. En la segunda parte voy a ahondar en la problemática de nuestro proyecto y en  los distintos enfoques que analizamos.

Smalltalk a diferencia de la mayoría de los lenguajes actuales, ofrece un desarrollo basado en una imagen. Esto es: al programar uno no manipula archivos de texto con código fuente, sino que el código es manipulado en el contexto de una imagen de memoria que contiene toda la definición del sistema, o sea sus clases y sus correspondientes instancias. Esta imagen es ejecutada por una máquina virtual, y en este punto sí es como Java, C# y algunos otros lenguajes actuales.

Si bien existen distintas implementaciones de Smalltalk (Gnu Smalltalk, VisualWorks, Squeak, Dolphin, Pharo, etc), todas ellas están basadas en la especificación del Blue Book, publicado a comienzo de los años ’80.

Todo sistema Smalltalk consta de dos componentes, una máquina virtual y una imagen. Una máquina virtual puede interpretar un formato específico de imagen. En el caso particular de Pharo, el formato de imagen es compatible con el formato de Squeak, porque en cierto modo Pharo surge inicialmente como un «branch» de Squeak.

La evolución de Smalltalk y en particular de Squeak/Pharo a lo largo de más de 20 años ha consistido en modificaciones «relativamente menores» en la máquina virtual y en la imagen. Y quiero que nos detengamos en algo, la imagen de Squeak se generó UNA vez, hace unos cuantos años escribiendo byte a byte según lo que esperaba la máquina virtual, de ahí en más la evolución ha consistido en modificaciones de esa primera imagen a partir de agregar/quitar/modificar clases, métodos e instancias. Si tenemos en cuenta que la imagen original data de una época en que la orientación a objetos recién daba sus primeros pasos, no es raro que al examinar el kernel de la imagen (clases Behavior, Class, Object, etc) nos encontremos con algunas cosas sospechosas desde el punto de vista de la orientación a objetos y la separación de incumbencias (dependencias poco felices, muuuuchos métodos dentro de una misma clase, métodos deprecados, etc, etc ).

Hasta aquí los conceptos, en la segunda parte entraré en cuestiones concretas del proyecto.