Pienso que Smalltalk es una tecnología maravillosa que ha influenciado la programación durante las pasadas décadas. Pero no directamente: su influencia mayor no ha sido a través de uso o de aparición de “killer apps” sobre Smalltalk. Lo que veo que ha pasado es que Smalltalk influenció a programadores. La marca de las ideas de Smalltalk se pueden rastrear en las decisiones de diseño de lenguajes como Python y Ruby. Y muchos programadores se han visto atraídos por las ideas de Smalltalk, trantándolas de aplicar a otros ámbitos. Pero Smalltalk, como tecnología, no ha tomando al mundo. Podemos discutir las razones: una temprana “balcanización” de los proveedores, la falta de una temprana implementación de código abierto. Mi postura: está muy ligado a su propia “GUI IDE”, y es un poco demasiado (tiene demasiadas piezas).
Pienso que es tiempo de explorar caminos alternativos. Durante años, visité tecnologías, lenguajes, y en la pasada década y media (más o menos), tomé de nuevo a Smalltalk, intentando encontrar uno de esos caminos alternativos.
Pienso que un camino a explorar es intentar armar un Smalltalk más simple. Un Smalltalk no tanto ligado a una GUI ID, no ligado a miles de clases. Me imagino una implementación simple que pueda acceder al resto de los avances de programación (como el ecosistema de Node.js).
Para poner manos en la masa, estuve armando tres implementaciones: Smalltalk sobre .NET, en Java y en los últimos tres años en JavaScript/Node.js:
https://github.com/ajlopez/AjTalk
https://github.com/ajlopez/AjTalkJava
https://github.com/ajlopez/AjTalkJs
Más información en posts en http://ajlopez.wordpress.com/category/smalltalk/ y en http://msmvps.com/blogs/lopez/archive/tags/Smalltalk/default.aspx
Pero este post no es para repasar esas implementaciones. Lo que quisiera es pasar en limpio, escribir sobre algunas ideas sobre cómo crear un Smalltalk, sin tener que pasar por el achicamiento de imágenes de uno ya existente.
El Núcleo
Pienso que se puede armar un nuevo Smalltalk, desde un núcleo mínimo. Para eso, podemos partir de un Smalltalk que ejecute albergado por otra tecnología, como puede ser .NET, Java, o JavaScript, o cualquier otra. Pero es hora te dener un Smalltalk que no sea tan aislado, que converse con un ecosistema: tiene que apalancar lo logrado en otros ámbitos. Por ejemplo, un Smalltalk ejecutando sobre JavaScript puede acceder a todo el ecosistema de ese lenguaje, o al ecosistema de Node.js si estamos trabajando en el servidor.
El núcleo de Smalltalk debería implementar:
Object: el objeto y clase base, con algunos métodos iniciales como #subclass:.
Array: para arreglos con acceso por índice numérico, comenzando desde 1 para no romper con la tradición Smalltalk.
Dictionary: para mapear claves (nombres) a valores.
Tipos Primitivos: para acceder a la tecnología albergadora (.NET, Java, JavaScript), a sus tipos primitivos.
Aceso a tipos y objetos nativos: para crearlos, llamar sus métodos de tipo y de instancia.
La Librería
Primero, una implementación mínima de algunas clases, que pueden ser empaquetadas en una implementación inicial.
Pero luego, viene algo importante: tratar de vivir en un ecosistema de paquetes. En vez de tener centenares o miles de clases, que cada aplicación pueda referenciar y obtener los paquetes de un ecosistema. En mis implementaciones, he tomado el camino de usar NPM (Node Package Manager) para publicar y consumir paquetes, para instalarlos por aplicación, aún usando las versiones específicas que necesite cada aplicación y paquete.
Algunos candidatos a paquetes, como ejemplo:
– Una librería de tests (con un método assert)
– Un servidor HTTP
– Un framework MVC (tengo un ejemplo en Smalltalk sobre JavaScript/Node.js usando Express)
– Mensajes distribuidos (tengo una implementación en C#, el objetivo de este año es tener algo similar en JavaScript/Node.js)
– etc.
De esta manera, la adopción de un paquete será más fácil: no se necesita portar un paquete a otro dialecto, sólo consumirlo, teniendo las dependencias en su lugar. Para eso, cada paquete describe las dependencias que necesita.
Items Adicionales
Quiero implementar ambientes/environments: cada clase o paquete puede cargar otras clases pero para uso interno, sin interferir con el ambiente Smalltalk global, previniendo colisión de clases y versiones.
Otra cosa que quiero es poder ejecutar más de una imagen al mismo tiempo. Y que una imagen ayude a otra. Por ejemplo, que una imagen chica pueda ir agregando métodos a sus clases, pero los métodos de compilación los encuentre en otra imagen. De esta forma, una imagen puede comenzar chica, de poco tamaño, siendo ayudada por otra para ir creciendo e implementando los casos de uso que necesita. De esta forma, nos evitamos tener que partir de una imagen grande, e ir reduciédola. Tengo una implementación de estas ideas en mi versión de Smalltalk en C#.
En algunas implementaciones, quiero una imagen (para leer y grabar). Pero primero puedo explorar hasta donde llegar sin tener la necesidad de persistir una imagen.
Cualquier GUI debería ser creada fuera del núcleo, tal vez usando el ambiente albergador. Por ejemplo, usar Windows.Form si estamos sobre .NET o Mono, o Swing o SWT si estamos en Java, o el notable Canvas en caso de HTML5/JavaScript. Pero la idea es que el manejo de la GUI tiene que estar claramente separado de la implementación núcleo. Los Smalltalk populares actuales están muy ligados a la GUI que contienen en toda imagen. Veamos otras tecnologías: Python, Ruby, Node.js, Go, etc… Hay multitud de ellas que avanzaron sin estar ligadas a una GUI y a una IDE. Y sus programadores siguien creando aplicaciones útiles.
Como siempre digo: hay que explorar. Ese es el verbo a usar. Tenemos que explorar caminos alternativos, aún cuando no queden en claro la ganancia a obtener. Si hubiera visto, a esta altura, alguna “killer app” en Smalltalk, o el uso de Smalltalk para la creación de aplicaciones (como pasa en Python, Ruby, Java, JavaScript, Node.js, .NET, y otros), yo no pensaría de esa forma. Pero por alguna razón, Smalltalk no llegó a ese estadío. Veo entonces que hay alternativas, flotando alrededor nuestro, listas para ser exploradas.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
