^[:Il | Messaggero := non: 'è importante']

A raíz de mi anterior entrada, un tal Pablo se puso en contacto conmigo, interesado en obtener más información sobre GST.

Intentaré explicar un poco mejor lo que ya dije.

GNU Smalltalk, es una implementación de Smalltalk concebida para funcionar en modo scripting.

Cuando ejecutamos ‘gst’, carga en memoria una imágen base sobre la que trabajar con los Objetos básicos para poder comenzar a hacer algo, y nos ofrece una shell interactiva, como la que puede ofrecernos Python, o Ruby, etc….

A partir de aquí, podemos, desde esta shell, crear nuevas clases, instanciarlas etc.. Digamos, que sería un workspace en linea de comandos y sin nada más.

Ahora, que esté concebido como scripting, no implica que sólo funcione así. Este concepto se escapa un poco de la filosofía Smalltalk, ya que éste es más que sólo un lenguaje de programación. Una de las cosas más importantes de Smalltalk, es su entorno. En el mundo smalltalk, entendemos como entorno, un “mundo” donde los objetos conviven y se envían mensajes los unos a los otros. Este “mundo”, también es un objeto, como todo en Smalltalk.

En el caso de Squeak, cuando lo iniciamos, éste, levanta todo el sistema de Objetos, incluido su sistema visual. Desde ese entorno, es desde donde accedemos a las poderosas herramientas que Smalltalk nos provee, como los distintos Browsers para poder navegar por los objetos del sistema, los inspectores, el catálogo online de paquetes Squeakmap o Universes, el poderoso depurador integrado, la interfaz para SUnit, y un largo etcétera que hace el desarrollo de Smalltalk, distinto a todo lo demás.

¿Pero entonces, en qué se distingue GST de Squeak?
Como ya he dicho, la concepción de GST, fué proveer de un smalltalk de scripting. Un smalltalk al que le pasamos código incrustado en un archivo, y éste lo evalúa como pueda hacer Python, pero realmente, no hace las cosas muy distintas a como las hace Squeak.

En Squeak, cuando abrimos la imágen, en ésta, ya está por defecto todas las herramientas “visuales” a nuestro alcance, puesto como ya he dicho, sin ellas, Smalltalk no es más que un simple lenguaje de programación y no tiene nada especial. En GST, la imágen base, sólo levanta los objetos básicos y el sistema que permite que puedan enviarse mensajes los unos a los otros, y no levanta por defecto ningún subsistema visual, ya que éste, es un paquete aparte. En cambio, con un script, podríamos cargar Blox (la parte visual de GST), Swazzo, Seaside y dependencias, y grabar ese estado de la memoria en un archivo de imágen, para que al volver a ejecutar, todo estuviese cargado de igual manera que hace Squeak.

De hecho, el script Browser.st, lo único que hace es lo siguiente.

Siento que el código no esté indentado ni coloreado, pero estoy teniendo problemas con el plugin de wordpress que hace ésto

(Smalltalk includesKey: #BLOX) ifFalse: [
PackageLoader fileInPackage: 'Browser'.
ObjectMemory snapshot
]!

(Smalltalk includesKey: #BLOX)
ifFalse: [
stdout nextPutAll: 'BLOX not loaded, is Tcl/Tk installed?'; nl
]
ifTrue: [
stdout nextPutAll: 'Starting window environment...'; nl.
BLOX.BLOXBrowser.BrowserMain new initialize
]!

ObjectMemory quit!

Si miráis las primeras líneas, comprueba si Blox ya está cargado, y si no, carga el paquete Browser para que levante el sistema, y lo graba como imágen. Si ya existe, entonces carga el Browser principal. Es decir, la parte visual de GST existe, y si ésto lo grabásemos no habría diferencia con Squeak (menuda herejía acabo de soltar), salvo la más importante de todas.

Repidiéndome hasta la saciedad, lo más importante de un sistema Smalltalk es su entorno. Y el problema de GST, es que su entorno está muy muy verde. Apenas contiene un par de Browsers, éstos no funcionan al 100% como deberían, y encima en TCL/TK. Faltan muchas herramientas como interfaz para SUnit, o más importante aún, como dice mi querido amigo Notxor, mejorar el debugger, que es una de las herramientas más importantes en Smalltalk. Ésto obliga a que practicamente, tengas que desarrollar apoyado en un simple editor de texto (y los que conozcan smalltalk, por muy potente que sea un editor, saben porqué digo “simple”), y trabajar “a pelo”, y de ésta manera, pierdes toda la potencia que Smalltalk puede ofrecer, pero Roma, no se construyó en un día.

Si es cierto que como dije, existen muchos paquetes de acceso a Datos, para trabajar a través de la red, está portado el servidor web Swazzo y el framework web Seaside, pero repito, volviendo a lo dicho, sin las herramientas básicas “smalltalkrianas”, todo ésto, en mi humilde opinión, no sirve para nada.

No quiero decir con ésto que GST no sirva para nada, todo lo contrario. De los pocos días que llevo mirando GST, basta que se terminase y mejorase un poco el Browser, para que ya se pudiese trabajar directamente sobre él sin depender de un editor, y a partir de ahí, hacer y mejorar todo lo demás, sería “coser y cantar”. Pero se necesita ayuda (ya dije ésto antes no? :D )

Paolo, además, comentó que se podría portar Morphic sobre SDL para usarlo como base en la parte visual de GST, pero como ya comenté en mi anterior entrada, para esto, hace falta gente que colabore en el proyecto (esto también lo dije no? :D )

Entradas relacionados:

1. Regreso al futuro de Smalltalk
2. Respecto a las últimas entradas
3. Smalltalk, OOP Quotes
4. ¿Y que pasa con los proyectos…?
5. Blog en 16 minutos en Aida/Web