Quisiera hoy presentar un proyecto de robótica, que se está encarando desde mi país Argentina. Es un proyecto dedicado a crear un robot androide de tamaño aproximado al de una persona. La idea es formar una comunidad de diseño y desarrollo en hardware, software, y para eso, la gente del proyecto invita a los interesados a participar.
La página del proyecto es:
Proyecto Androide
El dibujo que acompaña a este post no es el definitivo, es un dibujo que se irá adaptando a lo que se vaya diseñando en el proyecto. Está en sus inicios. Si no conocen del tema, pueden visitar la página de categorías del wiki, donde encontraran informacion sobre Algoritmos, Biomecánica, Comunicación, Cinemática, Programas, Participantes, Reuniones, entre otros temas.
El proyecto comenzó en marzo de este año, 2008, así que estan dando los primeros pasos. Espero que puedan avanzar con paso firme.
El proyecto está albergado en la página de
Robots - Argentina: Pasión por la robótica
Encontraran ahí varios artículos sobre motores, actuadores, comunicación, procesadores, sensores, energía, circuitos, robots.
Por ejemplo:
La historia de mi primer robot
Baterías para alimentación de robots
Androides de todo el mundo
Se vienen los robots
Ejemplo de un brazo robótico
Lógica de detección de atascos
Visión estereoscópica en tiempo real con una cámara única
Sensores de presión
Sensores de contacto
Piel robótica
Manos robóticas
Músculos de alambre (o alambre muscular)
Músculos neumáticos (o músculos de aire)
Ejemplo de un brazo robótico
y más.
Tienen una lista de Desarrolladores de Robots:
http://ar.groups.yahoo.com/group/robots_desarrolladores/
donde leo:
El grupo Desarrolladores de Robots es un espacio para compartir datos y experiencias sobre proyectos de robótica, ayudarnos en cuestiones técnicas en el desarrollo de nuestro robot, facilitar proyectos en conjunto sobre robots, ayudarnos con información para conocer mejor los componentes y saber cómo obtenerlos, estar informados sobre las actividades relacionadas con nuestra pasión y conocernos y alimentar una amistad que conduzca al crecimiento personal y general en esta disciplina.
Esperamos un nutrido intercambio de mensajes sobre robots, robótica y automatización en general, electrónica, sistemas digitales, microcontroladores, microcomputadores, microprocesadores, memorias, periféricos, comunicación, controles remotos, links de infrarrojo, links de RF, sensores, actuadores, motores, partes mecánicas, inteligencia artificial, programación en todos los lenguajes: Assembler, Basic, C, visual, sin olvidar las complejidades y dificultades de la parte mecánica, que requiere precisión y cuyo logro cuesta tanto trabajo.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
Gracias al Microsoft User Group de Argentina, en especial a Oscar Turquet, Mónica y Sandra, ayer estuve dando un día completo de Scrum, con algo de teoría y varias horas de práctica.
Los asistentes se dividieron en 5 grupos de 5-6 personas, y desarrollamos un ejercicio, un proyecto adoptando Scrum, con tres sprints (Iteraciones) de 3 días simulados de 10 minutos, más un Sprint Planning de 10 minutos, más una presentación al final, una Sprint review. Durante el trabajo fuimos mejorando en algunas prácticas, y al final hicimos una retrospectiva grupal. Estuve usando un ejemplo de Tobias Meyer, que permite tanto aplicar Scrum como pensar sobre el propio proceso.
Es interesante ver cómo los equipos se van autoorganizando, y descubriendo y enfrentando las dificultades que encuentran en el camino. Creo que con la práctica por lo menos de un ejercicio, queda más claro porqué de cada ceremonia de Scrum (que se puede explicar en 1 minuto, si queremos). Ahí con un ejercicio concreto, con grupos formados en el momento, tal vez con gente que no se conoce, es donde se ve cómo funciona Scrum.
Yo veo que Scrum funciona si tenemos la gente adecuada ("the right people") y el ambiente adecuado (al equipo se protege, por ejemplo). Solamente podemos decir que hemos intentado Scrum si lo adoptamos al principio de forma completa. Si sólo tomamos algunas cosas, no es Scrum. Con el tiempo y la experiencia, podemos sentarnos y ver claramente qué modificamos de Scrum para nuestra organización, pero en principio, recomendaría adoptar Scrum para un proyecto, de forma completa.
No hace falta que toda la organización adopte Scrum, pero es necesario que la gerencia, y el cliente, entiendan perfectamente el proceso. Y que el "product owner" sepa armar un backlog de producto saludable, y bien priorizado.
Los enlaces que mencioné, y bibliografía adicional, ya estan incluídos en mi anterior post:
Explicando Scrum
Agrego hoy la lista de desarrollo ágil de latinoamérica:
laasd · Latin America Agile Software Development (mensajes en español)
y el código del sistema que vimos en línea para ingresar backlogs, commitments y llevar métricas:
http://www.codeplex.com/ScrumLite
La presentación actual está en mi Skydrive:
Scrum200802-2003.ppt (formato PowerPoint 2003, 7Megas)
Scrum200802.pptx (7Megas)
Scrum200801.ppt (Presentación original, más liviana, con menos gráficos, 1.2M)
Agradezco a Diego Poza, por haber mejorado y ampliado la presentación original.
Más enlaces sobre estos temas en:
Agiles 2008 en Argentina
Post sobre Scrum en este blog
http://del.icio.us/ajlopez/scrum
http://del.icio.us/ajlopez/agile
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
Por años, la comunidad de desarrolo de software ha luchado contra la complejidad y el cambio. El desarrollo de software es uno de las actividades humanas con más niveles de detalle: debemos captar la imagen completa del sistema, y a la vez, tomar en cuenta cada pequeño detalle. Un desarrollador o un equipo de desarrolladores tienen que manejajar un montón de concptos, estilos de arquitectura, patrones de diseño e implementación, lenguajes, tecnologías, mejores prácticas y aún más: tiene que ejercitar los "soft skills" de comunicación con otros interesados en el proyecto.
Todo esto puede ser una tarea intimidante.
Muchos paradigmas emergieron en las últimas décadas, notablemente el orientado a objeto. Pero toma caminos divergentes: uno fue el purismo académico, con Smalltalkers y otros, que hicieron una gran tarea difundiendo objetos, pero que siguieron trabajando en aplicaciones, digamos, de nicho, no cruzando el abismo para llegar a la corriente principal de desarrollo (supongo que la fragmentación de Smalltalk en diverss dialectos fue una de las razones para el estado actual de la comunidad ST). No me malentiendan: Smalltalk tiene un comunidad fuerte y viva, pero no es uno de las tecnologías con muchas aplicaciones empresariales para mostrar.
C++ fue el primer lenguaje popular que dió "objetos para las masas", pero con la aparición de tecnologías complicadas (¿recuerdan la API desnuda de Windows? ¿O cualquier API de GUI?) y la explosión del mercado de PC, la corriente principal de desarrollo fue tomada por lenguajes derivados de xBase, y Delphi y Visual Basic, este último no tiene soporte de objetos hasta la versión 3, y nunca soporte de herencia. (Visual Basic fue un "matador" de ideas hermosas, como el lenguaje Actor: una extensión orientada a objetos del lenguaje Forth, con soporte nativo de GUI, implementado en Windows). (Sí, también tomemos nota de COBOL: este lenguaje fue y aún es el lenguaje principal en muchos ambientes).
Java hizo su aparición a mediados de los 90, dando aire fresco a la programación (yo nunca programé con VB 6.0: después de encontrar el paraíso Java, quién quería lidiar con Apartment Thread Models y todo el lío COM). Teníamos una librería de clases, verdaderos objetos, pero más: nosotros fuimos bendecidos por un "garbage collector", recolector de basura. Los nuevo "patrones de diseño" podían ser adoptados de forma masiva. Los objetos comienzan a estar en todas partes. Aparecen frameworks.
Pero algo estaba faltando: aunque los frameworks tomaron ventaja del uso de objetos, las implementaciones de negociones de muchas aplicaciones no reflejaban las nuevas capacidades. El elusivo Modelo de Dominio era un "santo grial" que no era fácil de encontrar. El trabajo de Sun con J2EE fué un fracaso parcial para armar modelos de dominio en Java. Cuando .NET nace, Microsoft no repite el error, y en sus primeros ejemplos y escritos de Pattern and Practices, no usan ninguna de los ideas de Modelo de Dominio (supongo que todavía son reluctantes a adoptar un Modelo de Dominio, LINQ to SQL es aún una bestia orientada a datos, la esperanza que tenemos es el Entity Framework).
La comunidad de Java tiene un gran conjunto de herramientas y librerías de código abierto, desde Ant a Maven a Tomcat y más. La simplicidad de la programación POJO (Plain Old Java Objects), junto con soluciones no intrusivas de persistencia (notablemente Hibernate), tomó un nuevo camino para alcanzar una más clara implementación de un modelo de dominio.
.NET entró tarde en el juego: mucha de las herramientas y ejemplos en el mundo .NET eran centradas u orientadas a datos, con datasets, y características de enlace a datos en todas las presentaciones (WinForms y ASP.NET). La comunidad .NET aprendió de la experiencia de la comunidad de Java, y en los últimos años, tenemos las ideas de Modelo de Dominio implementado en ambos mundos.
Eric Evans escribió un libro seminal sobre sus ideas de Domain-Driven Development, donde el Modelo de Dominio no es un artefacto más, sino el corazón del software a desarrollar. El va más allá de Modelo de Dominio, describiendo nuevos patrones y maneras de implementarlo. El libro explica el proceso para crear y descubrir un modelo, usando un lenguaje ubicuo (compartido con los usuarios), y cómo mejorar el modelo a lo largo del proceso de desarrollo.
Implementaciones de modelo de dominio, y DDD, son grandes tópicos a tratar. Quiero comenzar a escribir sobre esos temas, discutiendo varios puntos, y dando ejemplos concretos en Java y .NET. No es una tarea fácil, así que no esperen un post diario: el trabajo tomará tiempo.
Por ahora, pueden visitar mi colección de enlaces sobre DDD en:
http://del.icio.us/ajlopez/ddd
Algunos de mis anteriores posts sobre DDD:
Mini Book Domain Driven Design Quickly
Domain-Driven Design Resources
Enlaces y Recursos Domain-Driven Design
Domain-Driven Design
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
Ayer apareció un rumor en:
Google Chrome, Google’s Browser Project
confirmado, al parecer, por el blog oficial de Google con:
La difusión de sus características e historias, se hizo en formato de cómic, en varios cuadros, el primero es:
Es interesante ver cómo Google sigue lo que predica de "launch early and iterate".
Creo que más allá de algunos temas cosméticos y de lanzamiento, lo principal a destacar es la Virtual Machine de JavaScript V8. Por lo anunciado hasta ahora, tendrá soporte de múltiples threads, tendrá un manejador de tareas. Me imagino que Ajax ya se basará solamente en Javascript, sin necesidad del componente XMLHttpRequest.
Pero si implementan "bien" a Javascript, con la suficiente potencia, seguramente podrá compilarse en Javascript a otros programas escritos en lenguajes, como C#, Smalltalk, Ruby (ya hay implementaciones de esto en Javascript "común"), de una forma más elegante y poderosa. Si consiguen un sandbox seguro para almacenar datos localmente, se abren más posibilidades.
Esto cambiará el mercado de desarrollo SaaS: me imagino aplicaciones Chrome trabajando desconectadas, o conectadas. Pero eso es futurología.
Más concreto es la aparición de un nuevo Javascript. Pero creo que solamente tomará impulso, si Firefox y IE adoptan con el tiempo a esa nueva implementación. Lo que puede ser algo difícil. Es como con Ajax: hasta que no hubo soporte de Javascript y XMLHttpRequest en los mayores browsers, la tecnología no despegó.
Otro camino que se abre, es que se pueda usar ese lenguaje dinámico fuera del browser Chrome, como una VM de aplicaciones Javascript V8, más liviano y multiplataforma (multilenguaje por abajo, es decir, Smalltalk, C#, Ruby.... todos reimplementables en JSV8).
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
La gente de la Asociación de Desarrolladores de Videojuegos Argentina, siempre está trabajando difundiendo la actividad de desarrollo de juegos, desde hace años. Ahora, lanzan un "call for papers" para la exposición que organizan para este año:
http://adva.com.ar/eva/
Pueden ver ahí las presentaciones del año pasado (EVA 07), y de otros años:
http://www.adva.com.ar/eva/biblioteca/
Este es parte del texto de la convocatoria para este año, que me llegó por email:
ADVA (Asociación de Desarrolladores de Videojuegos Argentina - www.adva.com.ar) abre el llamado a presentación de propuestas para disertantes en la 6ta edición de EVA (Exposición de Videojuegos Argentina) a realizarse los días 15 y 16 de Noviembre de 2008 en el Centro Cultural General San Martín, Buenos Aires.
Se recibirán abstracts para charlas y debates hasta el domingo 7 de Septiembre de 2008.
Diferentes áreas aplicables al desarrollo de videojuegos son bienvenidas, pero no limitadas a:
Programación de juegos (gráfica, inteligencia artificial, etc.)
Audio en videojuegos
Diseño de videojuegos
Estética y narrativa de juegos
Arte
Investigaciones académicas sobre juegos
Medios de distribución alternativa
Business (marketing, legales, exportación, etc.)
La profesionalización de la industria de videojuegos en Argentina
Calidad de vida de desarrolladores en Argentina
Internacionalización de Argentina en la industria de videojuegos
Se dará prioridad a aquellas propuestas que apuntan a un público medio-avanzado. Se aceptaran propuestas de charlas para principiantes, pero en menor medida.
Las propuestas deben ser enviadas on-line en la siguiente dirección: http://www.adva.com.ar/eva/openconf/openconf.php
Hay más información en
EVA 08: Llamado a presentación de propuestas
Creo que con la experiencia que tienen, la exposición va a ser un éxito. Pueden visitar el sitio de ADVA para ver la actividad que tiene el desarrollo de juegos en nuestro país, donde hay programadores y diseñadores trabajando para el mundo.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
En algunas empresas, IT es el departamento odiado, o por lo menos, olvidado, despreciado, como una tía loca que uno no quiere mostrar en público. La aparición de series como IT Crowd nos muestra un poco relegados en el ambiente de una empresa. No debería ser así, pero es lo que pasa en varios lugares que he visitado. Tendríamos que conseguir revertir esa impresión. Creo que las metodologías ágiles son un camino. Pero el tema da para más discusión. Por ahora, veamos un video de broma, la guerra IT vs Ventas en una empresa:
Gracias a Jonathan Cisneros, creador del AjGenesis Studio, por el enlace a este video.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
Este texto ha sido "robado" sin vergüenza, del post
A Java Syntax Quirk
de Dan Dyer que a su vez lo robó de otro post de Daniel Futtorovic. Este es un programa compilable Java:
public class Oddity
{
public static void main(String[] args)
{
http://blog.uncommons.org
System.out.println("Why is the URL allowed above?");
}
}
¿Pueden ver por qué compila?
¿Es posible algo así en C#?
Encontré el enlace gracias al twitter de @ekabanov.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
Cualquiera puede reconocer en mí a un entusiasta de la generación automática de código, con un agregado: usar un modelo como el punto de partida del proceso. He adoptado esa idea cada semana, practicando "dog fooding", usando mi propio proyecto de generación de código AjGenesis. Esta semana, estoy leyendo el libro ya clásico "Code Generation in Action" , de Jack Herrington, editado por Manning. Este libro es un "debe ser leído" por cualquiera ineresado en generación de código. Es una muy interesante lectura para desarrolladores: el autor expone un caso a favor del uso de la generación de código, apelando al incremento en calidad y productividad en proyectos de software, incluyendo equipos ágiles.
En el primer capítulo, Herrington lista las reglas "top ten" que quiero comentar en este post. Los párrafos indentados que siguen son extraídos del libro (sección 1.7), seguidos por mis propios comentarios:
De el debido respeto a código generado a mano
Ud debe respetar y rechazar el´código manal. Ud. debe respectarlo porque hay casos especiales en el código que son pasados por alto en una inspección somera. Cuando reemplaza código manual por código generado, necesita estar seguro de haber contemplado esos casos especiales. Ud. debe sentirse disgustado con el código manual porque el tiempo de desarrollo es extremadamente valioso, y gastarlo en tareas repetitiva es casi criminal. El objetivo de su generador de código debe ser siempre optimizar el activo más valioso de su organización: la creatividad y el entusiasmo del equipo de desarrollo.
Cierto, la base de la generación de código es hacer fácil el delegar las tareas repetivivas a la máquina. Nosotros tenemos que usar herramientas que hagan más fácil nuestro trabajo: ésa es la razón por la que usamos compiladores hoy en día, en lugar de estar "seteando" los bits en la memoria (o "seteando" los relés en la vieja Eniac a mano). La razón que sustenta la generación de código no es destruir el código manual: su misión es soportarlo.
Primero escriba a mano
Ud. debe entender completamente su framework antes de generar código. Idealmente, debería escribir a mano una amplia y significativa cantidad de código con el framework, primero, y luego entonces, usarlo como base para los "templates" de su generador.
Absolutamente de acuerdo. A veces, los nuevos usarios de AjGenesis comienzan a usarlo directamente de los ejemplos. Eso es bueno, pero seria mejor generar un ejemplo usando el framework y la tecnología que tengan que encarar. Si Ud. conoce cómo programar usado Struts/Hibernate, entonces puede separar las variaciones técnicas de lo esencial. Llegado a ese punto, podrá comenzar a escribir los artefactos de generación de código que necesite (templates, tareas).
Controle el código fuente
No puedo dejar de enfatizar la importancia de tener un sistema de control de código robusto. Es crítico para el éxito de un proyecto de generación de código. Si su generador trabaja directamente sobre los archivos de implementación que contiene código generado a mano, asegúrese que tiene el sistema de versionado funcionando para que pueda proteger su trabajo.
Otro camino: si Ud. genera código desde el modelo, incluya en el repositorio de código sólo al modelo. El resto de los artifactos vendrán producidos por el proceso de generación. Con la actual tecnología, no se puede generar TODO la aplicación, pero Ud. puede separar, con cuidad, la parte manual de la generada.
Tome con cuidado una decisión sobre el lenguaje de implementación
Las herramientas que use para armar el generador no tienen que ser las mismas que usa para escribir las aplicaciones finales. El problema que el generador está tratando de resolver es completamente diferente del las aplicaciones. Por esa razón, Ud. debe ver al generador como un proyecto independiente y diferente, y elegir sus herramientas de acuerdo a lo que necesita.
Esta es una de las razones por que adopté un nuevo lenguaje (llamado afectuosamente AjBasic) para mi proyecto AjGenesis. Yo quería un lenguaje dinámico que estuviera bajo mi control, para extenderlo en cualquier dirección que el proceso de generación requiera. En uno de mis pruebas iniciales, intenté usar PHP, pero he preferido usar un lenguaje dedicado y pensado para este trabajo, como AjBasic.
Integre el generador en el proceso de desarrollo
El generador es una herramienta para ser usada por ingenieros; entonces, debería encajar claramente en algún punto del proceso de desarrollo. Si es apropiado, puede integrarse en la IDE que use, o en el proceso de build o de check-in en el repositorio de código.
Al haber hecho que el núcleo del AjGenesis sea una librería de clases .NET, pude integrarlo con otras herramientas. Ahora, puedo usarlo desde el NAnt. Una herramienta que se integre a la IDE del Visual Studio o del Eclipse, es una tarea pendiente.
Incluya advertencias
Su generador debe siempre dejar advertencias en el código para qu ela gente no vaya y toque ese código. Si se agrega código agregado a mano y se ejecuta de nuevo el proceso de generación, perderemos las modificaciones. No debe culpar a la gente: el que estén usando su herramienta es un gran paso adelante. En cambio, ponga mayores advertencias, y mejore la documentación del generador. Ud. es el emisario de su herramienta.
En AjGenesis, este problema es atacado por los templates que el usuario escriba. Ud. puede agregar cualquier texto que Ud. quiera, con las advertencias correspondientes: éste es el poder de poder escribir sus propios templates, Ud. tiene la propiedad del código generador, no depende de la herramienta.
Hágalo amigable
Sólo porque el generador es una herramienta para programadores no significa que tenga que ser críptico su uso. El generador debe decir al desarrollador lo que está haciendo, y qué archivos ha alterador o creado, y debe manejar los errores con una razonable cuota de decoro. Puede parecer tonto, pero una herramienta que es difícil de usar o que no es amigable será ignorada y sus esfuerzos por promoverla serán en vano.
El núcleo de AjGenesis es una dll, que puede ser invocada desde una aplicación. Hace años, escribí tareas para invocarlo y ser usado desde el NAnt. Gracias a Jonathan Cisneros, tenemos el AjGenesis Studio, desde el año pasado. He mejorado el código original, y a principios de 2008, agregué el AjGenesis Web Studio, para generar desde una interfaz web. El manejo de errores debe ser mejorado, especialmente para los nuevos usuarios de AjBasic.
Incluya documentación
La buena documentación es un punto a favor de la venta del generador. Su documentación debe ser abarcativa, sin ser intimidante, y cubrir los puntos principales: qué hace el generador, cómo se instala, cómo se ejecuta, y qué archivos afecta.
Actualmente, éste es un punto no bien cubierto por AjGenesis. Pero a cambio, hay varios posts explicando el proceso y los ejemplos (AjGenesis posts) (AjGenesis posts en Español). Usuarios de la herramienta están comenzando a escribir también (ver los posts de Carlos Marcelo Santos). Hay una lista de correo en español donde los usuarios pueden discutir sob ela herramienta y su uso (Code Generation group). Y en la la página del proyecto en Codeplex, hay ejemplo para generar Java, .NET, y PHP, varios usando el mismo modelo (una prueba ácida para un generador).
Recuerde que la generación es un tema cultural
Uducar a sus colegas con documentación, seminarios, y encuentros uno a uno es crítico para instalar y usar su generador. La gente es escéptica a las nuevas cosas, y un buen programador es el doble de escéptico que una persona promedio. Ud. necesita romper con esa resistencia y dudas, y emfatizar que el generador que ha diseñado los beneficiará.
Yo doy de tres a cuatro charlas por año, sólo dedicadas a explicar la herramienta y su potencial. Adicionalmente, la explico en casi cada curso que doy (de Java, .NET, PHP o de software en general). Pero para ser adoptada por una compañía o en un proyecto, un usuario debe tomar el cargo de campeón del producto. No es fácil elevar el nivel de abstracción, escribir el modelo y sus transformaciones, en el medio del trabajo del día a día.
Mantenga el generador
A menos que el generador sea una medida temporaria, necesitará ser mantenido en el largo palzo. Si el generador maneja una cantidad grande de código, trátelo como Ud. trataría a un ingeniero manteniendo ese mismo código. Su presupuesto debe incluir tiempo y dinero dedicado a mantener y actualizar este recurso.
AjGenesis no es parte de las "cosas" a mantener. Estas son los templates y tareas que usará en su trabajo. Si Ud. adopta la herramienta para generar aplicaciones, digamos, .NET, Ud. tiene que cambiar e ir mejorando los templates cuando nuevas tecnologías aparezcan (LINQ, ASP.NET MVC....). Y cuando Ud. gana experiencia, Ud. tiene que mejorar el mismo modelo, si descubre nuevas maneras de representar las líneas de producto en las que su compañía se interesa.
Yo podría agregar algunos puntos más:
- El código generado debe ser de la clase de código que Ud. mismo hubiera producido, y del que se sienta orgulloso. La herramienta no debe dictar la forma y la apariencia de su código. Ud. debe estar a cargo.
- El uso de un modelo eleva el nivel de abstracción que manejamos. Esta estrategia separa la paja del trigo, pone los detalles técnicos en el lugar que merecen: lo importante es el modelo.
Bueno, bastante por ahora. Como pueden darse cuenta, la generación de código es un tema que me apasiona. No es la bala de plata. Pero es un arma que quisiera tener, por si la necesito.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
En estos días, ha sido lanzado un nuevo sitio dedicado a Smalltalk:
http://www.clubsmalltalk.org/
Según el sitio:
ClubSmalltalk.org is a non-profit organization which congregates Smalltalk programmers and enthusiastics. In 2008, we are going a step forward with this new website.
The big idea behind this website is to provide a source of information about Smalltalk in general.
The Smalltalk community has not good sources of information, or they're all over the net, and sometimes it's difficult to find them.
If you want to contribute, you're welcome!
Es un desprendimiento de la actividad de la lista de correo en español:
http://groups.google.com/group/clubSmalltalk
Algunos de los artículos más populares que contiene:
Interview with Luca Bruno, the creator of Smalltalk YX
Argentinian Smalltalk Congress- Smalltalks 2008
Seaside and Ruby on rails
Tiene secciones como:
FAQs:
Smalltalk Frequently Asked Questions
GemStone Frequently Asked Questions
Environments:
Commercial Smalltalk Environments
Free Smalltalk Environments
Abbandon Smalltalk Environments
Frameworks, Platforms & Tools
y más: herramientas, recursos, comunidad. Tiene enlaces a libros sobre Smalltalk como:
Free Books
Thanks to the work of Stéphane Ducasse, we have a huge collection of Free Smalltalk books online.
Download from http://www.iam.unibe.ch/~ducasse/FreeBooks.html
Creative Common Books
Our friend Diego Gomez Deck has written an excellent book in Spanish to start in Smalltalk. You can buy a hardcopy or you can download it under the creative common licence from http://smalltalk.consultar.com/.
If you like it, we recommend to buy it, we are proud of this kind of projects.
El sitio recién comienza, pero espero que con la ayuda de la comunidad Smalltalk, vaya creciendo y se convierta en una referencia para todo interesado en ST.
Está armado con PHP. En mi opinión, es un buen signo: por años, la comunidad Smalltalk estuvo signada por un cierre hacia otras tecnologías o herramientas. En estos días, con la plétora de lenguajes, frameworks y plataformas, debemos abandonar esa tendencia a la aislación, e integrarnos con el resto de la tecnología.
Angel "Java" Lopez
http://www.ajlopez.com/
En mi anterior post sobre F#:
Primeros pasos en F#
había mencionado que no hay variables en el lenguaje, que hay identificadores. ¿cómo es eso? Exploremos el concepto de closure (podría traducirlo cierre, cerramiento, clausura), y cómo se usa en F# (closure es una característica de varios lenguajes).
De acuerdo al artículo de la Wikipedia sobre closures en ciencias de la computación:
a closure is a function that is evaluated in an environment containing one or more bound variables
(una closure es una función que es evaluada en un ambiente que contiene uno o más variables ligadas)
Bueno, ¿qué significa esto? Para entenderlo, asignemos un valor a un identificador, usando el fsi.exe, el intérprete interactivo de F# (podríamos usar Visual Studio también):
MSR F# Interactive, (c) Microsoft Corporation, All Rights Reserved
F# Version 1.9.3.4, compiling for .NET Framework Version v2.0.50727
NOTE:
NOTE: See 'fsi --help' for flags
NOTE:
NOTE: Commands: #r <string>; reference (dynamically load) the given DLL.
NOTE: #I <string>; add the given search path for referenced DLLs.
NOTE: #use <string>; accept input from the given file.
NOTE: #load <string> ...<string>;
NOTE: load the given file(s) as a compilation unit.
NOTE: #time;; toggle timing on/off.
NOTE: #types;; toggle display of types on/off.
NOTE: #quit;; exit.
NOTE:
NOTE: Visit the F# website at http://research.microsoft.com/fsharp.
NOTE: Bug reports to fsbugs@microsoft.com. Enjoy!
> let x = 2;;
val x : int
Ahora, tenemos un identificador x. Podemos mostrar su valor con:
> x;;
val it : int = 2
Un simple y conocido entero. Ahora, no podemos cambiar su valor: este identificador fue escrito en piedra como que es el entero 2. Nada en la historia humana y de F# podría cambiar sy valor. ¿Será así? Definamos una función:
> let dup n = n * x;;
val dup : int -> int
Esta función dup toma un argumento n y lo multiplica por el valor del identificador x. Este identificador es una "variable" libre en la función: no es un identificador local, viene de afuera de ella. Durante la evaluación de la función, x toma su valor del "environment", del ambiente en el que estaba durante la definición de dup. Probemos ahora:
> dup 3;;
val it : int = 6
El resultado fue seis, como esperábamos. Pero ahora, veamos de "cambiar" el valor de x:
> let x = 3;;
val x : int
> x;;
val it : int = 3
En este punto, tenemos que comenzar a hablar de closures: este "x" es OTRO identificador, que oculta el anterior. PERO, para la función dup, el identificador x es TODAVIA el anterior. Veamos de comprobar esto, invocando de nuevo la función:
> dup 3;;
val it : int = 6
¡¡El dup todavía usa el x original!! Aquí está la closure en acción. Si intentamos:
> dup;;
val it : (int -> int) = <fun:clo@0>
Notemos el clo @ 0 : es la firma de la closure que esta función está usando. Apunta al ambiente original donde la función había sido definida.
Esta característica implica que la conducta de una función no cambia luego de su definición. Aún las aparentemente "variables libres" están ligadas en tiempo de definición. Toto esto es parte de los fundamentos sólidos de la programación funcional, en general, y de F#, en particular.
Sobre closures en general y conceptos relacionados, como los lambdas, tenemos para leer a:
The Original 'Lambda Papers' by Guy Steele and Gerald Sussman
Podemos aprender mucho de Lisp, lambdas y closures, viendo:
Implementé algunas lambdas y closures, en mi intérprete Lisp:
AjLisp: a Lisp interpreter in .NET
Más sobre closures y C# en:
What's In A Closure?
Fibonacci Numbers, Caching and Closures
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
El año pasado se realizó la primera conferencia de este tipo en Argentina. Ahora, un grupo de smalltalkers está preparando la versión 2008. En este sitio (basado en Seaside) está el anuncio:
Smalltalks 2008 - 2da Conferencia Argentina de Smalltalk
Este año la conferencia se realizará los días 13, 14 y 15 de Noviembre, en la sede de la Universidad Abierta Interamericana, Av. Montes de Oca 745, Buenos Aires, Argentina. Al igual que el año pasado la inscripción a la conferencia será gratuita.
En esta edición buscamos enriquecer la oferta de actividades. Por ello abrimos los llamados a: Charlas La conferencia va a contar con dos secciones, una de Investigación Científica y otra de Industria del Software. Concurso Este año presentaremos un concurso de programación, en el que se podrá utilizar cualquier dialecto de Smalltalk. Keynotes Conferencias invitadas a cargo de personalidades de renombre. Hands on Sección de tutoriales, a realizarse en laboratorios con máquinas.
Hay una llamada a presentar papers (versión PDF), sobre los temas:
- Aspects, Aspect Languages and Applications.
- Ambient Intelligence, Ubiquitous / Pervasive Computing and Embedded Systems.
- Compilation Technology, Optimization, Virtual Machines.
- Educational Material.
- Language Engineering, Extensions.
- Model Driven Engineering / Development.
- Meta-Modeling.
- Programming in the Large, Design, Architectures and Components.
- Programming Environments, Browsers, User Interfaces, UI Frameworks.
- Reasoning About Code (Analyses, Refactoring, Type Inference, Metrics).
- Reflection and Meta-programming.
- Team management.
- Testing, Extreme Programming / Practices.
- Web Services, Internet Applications, Event-driven Programming.
- Experience Reports.
Es interesante que este año hayan extendido el alcance de los temas para incluir otros lenguajes dinámicos, no solamente Smalltalk. Este es el comité de programa:
- Federico Balaguer (LIFIA, Universidad Nacional de La Plata, Argentina)
- Tulio Ballari (UTN, Buenos Aires, Argentina)
- Alexandre Bergel (INRIA, Lille, France)
- Gilad Bracha (Cadence Design Systems, USA)
- Johan Brichau (Université Catholique de Louvain, Belgium)
- Cecilia Challiol (LIFIA, Universidad Nacional de La Plata, Argentina)
- Marcus Denker (SCG, University of Bern, Switzerland)
- Fernando Dodino (UTN, Buenos Aires, Argentina)
- Stéphane Ducasse (INRIA, Lille, France)
- Alejandra Garrido (LIFIA, Universidad Nacional de La Plata, Argentina)
- Tudor Girba (SCG, University of Bern, Switzerland)
- Orla Greevy (SCG, University of Bern, Switzerland)
- Julián Grigera (LIFIA, Universidad Nacional de La Plata, Argentina)
- Andy Kellens (PROG, Vrije Universiteit Brussels, Belgium)
- Kim Mens (Université Catholique de Louvain, Belgium)
- Guillermo Adrián Molina (ESSI Projects, Spain)
- Damien Pollet (INRIA, Lille, France)
- David Röthlisberger (SCG, University of Bern, Switzerland)
- Daniel Solmirano (UTN, Buenos Aires, Argentina)
- Tom Van Cutsem (PROG, Vrije Universeit Brussels, Belgium)
- Roel Wuyts (IMEC, Belgium)
Smalltalk es una tecnología que, en mi opinion, falló en "cruzar el abismo". A finales de los 80s, y comienzos de los 90s, la comunidad estaba dividida en varios dialectos e implementacion comerciales divergentes. Pero el ímpetu de leales miembros de la comunidad se ha probado el año pasado, aquí, en Argentina, con el éxito de la pasada conferencia del 2007. Espero que Smalltalk pueda integrarse con otras tecnologías, como .NET y Java, para ganar más momento y aceptación. Vean, como ejemplo, la adopción de F# en la comunidad científica: el acceso a un framework popular de clases es una característica clave en el "mainstream" de desarrollo de hoy. Insistir en la actitud de un mundo, un solo lenguaje, no la veo como opción en estos días. Celebro, entonces, la apertura de la llamada de papers a otros lenguajes dinámicos.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
Hoy, en el Microsoft Users Group de Argentina, Patricia Scalzone y Leticia Medela, de Vemn Sistemas, dictan una sesión sobre por qué fallan los proyectos:
Jornada de Soluciones
El temario es:
Escenario: ¿Por qué fallan los proyectos de software?
Solución: Entre las diferentes causas que llevan al fracaso de un proyecto de software, la tecnología no es la determinante. Esta sesión se focalizará en presentar técnicas y herramientas adecuadas para prevenir esa situación, tomando ALM (Application Lifecycle Management) como referencia.
Hay otros temas, como migrando a SOA, mejorar la calidad del software, y la implementación de un portal CMS, usando DotNetNuke.
Pero me gustaría hoy enumerar rápidamente algunas de las causas por las que fallan los proyectos de software. No será una lista original en contenido, y seguramente Uds. podrán aportar otras causas o explicar mejor alguna de las que presente. Sin poner una prioridad, veamos algunas causas:
No se tiene en claro qué hacer: los requerimientos son difusos, se toman mal, y terminamos haciendo algo que el cliente no necesitaba ni quería. No se entiende cuál es el problema a solucionar, el problema de negocio, el valor que nuestro entregable debe aportar al cliente. Se piensa más en detalles técnicos que en lo que realmente importa.
El cliente participa una vez cada seis meses: no se habla con el cliente, se trata de evitarlo. Se lo considera más un "enemigo" que parte del proyecto. Cada vez que entregamos un avance de la solución, nos damos cuenta que lo que entregamos no era lo que el cliente esperaba.
Gente no dedicada al proyecto: se lanza el proyecto, pero la gente que lo lleva adelante se dedica mientras tanto, a otros proyectos sin terminar, soporte de cliente, mesa de ayuda, a mover máquinas de un lado a otro por cualquier causa.
La gente de ventas prometió el oro y el moro: pasa en muchas consultoras. Por un tema de comisiones, o de posicionamiento en el mercado, se ofrece una solución "inflada" que no corresponde con lo que podemos hacer.
No conocer y entender la tecnología: hay que conocerla y ENTENDERLA. No sólo es saberse de memoria los namespaces de .NET, o la configuración de Spring: hay que entender para qué está cada cosa que usamos.
Usar mal la tecnología: hay quienes creen que usando J2EE y patrones todo queda solucionado: seguridad, escalibilidad, etc, sin detenerse a pensar en qué afecta la tecnología y las decisiones de diseño en lo que quieren lograr.
Cualquier problema lo arreglamos con más gente: en vez de encarar el problema de raiz. Agregar más gente a un proyecto con problemas, es como hechar querosene al fuego.
Equipo malfuncional: en el equipo hay gente que no sabe trabajar en grupo, tenemos "prima donna" que hacen lo que quieren, en vez de hacer lo que el proyecto necesita.
Cambios para mañana: viene alguien, de ventas o de gerencia, pidiendo cambios para el viernes, y estamos en la tarde del jueves.
Falta de recursos: se nos pide desarrollar el próximo Youtube + Facebook, con una máquina IBM XT de una diskettera.
Complicar la solución: para comunicar unos datos a otra aplicación, adoptamos un ESB, dos sistemas de cola de mensajería, una base de objetos, dos relacionales de última generación, y cuatro especificaciones de web services, aplicando transformaciones XSLT ante cada paso. Tal vez una simple programa hubiera dado el mismo resultado.
Falta de coordinación y cooperación: en un proyecto grande, hay varios equipos, posiblemente de distintas consultoras, resolviendo distintas partes del proyecto. Lo que un equipo hace, lo necesita otro, pero coordinan mal la entrega y prueba de las partes. Los equipos no se ven como colaboradores: cada uno hace lo suyo, y si otro equipo tiene problemas, consideran que no es problema de ellos. También pasa esto entre personas de un mismo equipo.
Uds. tendrán otros ejemplos a aportar.
Las metodologías ágiles ayudan a mitigar varios de estos problemas, o por lo menos, a ponerlos de manifiesto antes de que sea tarde. Hay problemas que van más allá de la metodología, que se tienen que resolver a nivel de la dirección de la empresa.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
Mi proyecto de generación de código AjGenesis usa un lenguaje interpretado para ejecutar tareas y expandir plantillas. El lenguaje fue bautizado AjBasic. Lo puede ver usado en todos los ejemplos que escribí para AjGenesis (más información en los posts de AjGenesis). Hace unos años, había separado el códgio del intérprete del proyecto madre, pero nunca lo había publicado. Este fin de semana, estuve refactorizando el código, y ahora, el resultado de ese trabajo está publicado en:
http://code.google.com/p/ajbasic/
En mi opinión, Google Code es fácil de manejar. Al contrario de SourceForge y CodePlex, usa Subversion como repositorio de código. Uso el cliente Tortoise SVN para enviar los cambios. La gente de Google es gentil: pude crear varios proyectos, por ahora esta es la lista:
http://code.google.com/p/ajlisp (en buena forma, se pude comenzar a investigar)
http://code.google.com/p/ajtalk (todavía en su infancia)
Más información en:
AjLisp- un intérprete Lisp en .NET
AjTalk- un intérprete tipo Smalltalk
La Solución
La solución AjBasicWithTests se compone de los proyectos:
AjBasic: implementa el compilador y el tokenizador. El tokenizer separa el texto entrante en tokens. El compilador arma árboles abstractos a evaluar, desde esa entrada.
AjInterpreter: Un nuevo proyecto, no presente en el AjGenesis original. Contiene toto el soporte del árbol abstracto, sus nodos, el ambiente (environment) donde se almaceman los valores, y un evaluador de los programas. El manejo de objetos .NET, y de objetos dinámicos, están en este proyecto. Mi intención es continuar usando este proyecto para soportar otros lenguajes interpretados.
AjBasic.Console: Una simple consola para probar el intérprete.
AjBasic.GUI: Un simple (y feo) WinForm para probar el intérprete.
AjBasic.Test: Algunos tests, usando NUnit (hay otra solución AjBasic que no incluye el proyecto de tests)
Todos los proyectos están escritos usando Visual Basic .NET. La solución fue compilada usando Visual Studio 2005. La consola y el proyecto GUI podrían ser usados como base, explican cómo usar el intérprete desde nuestra propia aplicación.
Hay varios puntos para discutir sobre la implemetación: merecerian otros posts. Por ahora, exploremos algunas de las principales características del proyecto, en su estado actual. Luego, escribiré una lista de ideas a explorar en futuras versiones.
Como mencioné, el lenguaje nació para soportar la generación de código desde AjGenesis. Yo lo diseñé para manejar objetos .NET nativos, así como objetos dinámicos. Pero ¿qué es un objeto dinámico? Es un objeto que no tiene clase asociada, pero que puede ser expandido con nuevas propiedades (el ejemplo más cercano que podría mencionar ahora, son los objetos Javascript).
Así, podemos escribir código como:
a.FirstName = "Adam"
a.LastName = "Doe"
a.Age = 800
No tenemos que declarar la variable. Podemos crear el objeto y agregar la propiedad FirstName en un comando (esta creación automática de objeto no está soportada en AjGenesis, aún, pero se puede crear un objeto del tipo DynamicObject con new).
Podemos probar la existencia de una propiedad:
if a.LastName then
' it has a LastName not nothing
else
...
end if
Si la variable a no tiene valor asignado, o si no tiene la propiedad LastName, la condición de arriba es evaluada a falso. Podemos preguntar por algo como foo.bar.anything y no se levanta una exception. El valor del resultado sería Nothing, que es evaluado y tomado por falso en una condición.
Los Tests
La solución no fue desarrollado usando TDD (Test-driven development). Escribí los tests despues del código, solo para estar seguro que la funcionalidad principal estuviera bien implementado, cumpliendo con lo que esperaba de cada método. No usé nombres descriptivos para los tests, pero me fueron muy útiles cuando encaré la refactorización de la solución completa:
Podemos probar el lenguaje desde la consola AjBasic.Console:
y desde el WinForm AjBasic.GUI
Ninguno de los dos es la "qué aplicación, que bruta...", pero funcionan.... ;-)
Próximos Pasos
Hay varias ideas volando cerca de la neurona que me queda, y tengo que poner orden en mi cabeza. Algunos puntos, para que queden escritos:
- Ahora que el núcleo del intérprete está separado del compilador basic, me gustaría escribir AjSharp, un intérprete con sintaxis C#. Entonces, podría ser agregado a AjGenesis, para escribir plantillas y tareas en ese lenguaje, que puede resultar más agradable para los programadores C#.
- Agregar soporte de clases dinámicas y prototipos.
- Refactorizar los tests
- Escribir un manual mínimo, explicando el lenguaje y sus características
- Extender el lenguaje para soportar valores "delayed" y "delayed evaluation" (quizás paralelismo).
- La forma internal del intérprete podrías ser reescrita en Java
- La opción de escribir un AST (Abstract Syntax Tree) que se acople al soporte de DLR (Dynamic Language Runtime) no me atrae, podría llevar mucho trabajo. Pero podría ser interesante para aprender sobre el soporte de DLR en .NET.
- Usar el lenguaje como base para la programación de agentees distribuidos (un punto ambicioso, que merece mayor evaluación).
Como es costumbre, me divertí mucho escribiendo este software.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/en
Se va acercando la primera conferencia latinoamericana de metodologías ágiles:
Primeras jornadas latinoamericanas sobre metodologías ágiles
Entre los referentes internacionales que ya han confirmado su participación en Ágiles 2008 se encuentran Mary y Tom Poppendieck, Matt Gelbwaks y Tobias Mayer.
Ágiles 2008 es un evento sin fines de lucro, el cual es organizado por entusiastas del tema y abierto a cualquiera que tenga ganas de participar.
Si tiene interés en colaborar con la organización de Ágiles 2008, lo invitamos a dejarnos sus datos de contacto aquí
Tobias Mayer es un entrenador de metodologías ágilas, que nos enseñó a muchos de nosotros, acá en Argentina. Una persona de múltiples intereses (como la actividad teatral), muy amable y con grandes habilidades de comunicación, para inspirar a la gente en el método ágil. Podemos considerarlo "el padrino" del movimiento ágil en mi país...:-)
Los organizadores están convocando a enviar "papers", ideas, y propuestas para actividades:
¡Ir a una conferencia a escuchar es demasiado aburrido! Recibimos su idea para participar activamente de Ágiles 2008. En principio tenemos pensadas tres tipos de actividades: Presentaciones (tradicionales, con transparencias, gente sentada escuchando y preguntas al final), Sesiones Interactivas (gente parada haciendo ejercicios tipo teatrales) y Mesas de Discusión (similar a un debate). Pero a no amedrentarse: escuchamos cualquier idea y tratamos de darle un lugar y un momento.
Los bloques serán de 45 minutos, pero es posible tomar más de uno para una misma actividad.
Hay tiempo hasta el 1 de septiembre para presentar una propuesta.
http://www.agiles2008.org/es/call4papers.php
Por años, las metodologías ágiles fueron ganando aceptación en mi país, Argentina, y en Latino América. Y ahora es el tiempo para mostrarlas al resto de la industria, para que vean qué es el movimiento ágil.
A hacerlo! (eso sí, antes escriban un "backlog" ... ;-)
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
Soy un entusiasta de escribir intérpretes, especialmente del tipo Lisp. Mi primer intérprete Lisp fue escrito al principio de los 80, usando el lenguaje assembler de un Intel 808x. Era un trabajo muy "geek". Una de las características más "tricky" de implementar es un recolector de basura (garbage collector). Por suerte, desde mediados de los 90 tenemos Java y su librería de clases como una tecnología ampliamente disponible con un garbage collector decente. En este siglo, .NET es la nueva plataforma de lenguajes con GC..
En el 2005, Martin Salias y yo dimos un TechNight, aquí en Buenos Aires, Argentina, para la oficina local de Microsoft. Trató sobre lenguajes implementados en .NET. Fue la primera vez que presenté F#, así como P# y otros. Despues de esa charla, la misma noche viajé a Mar del Plata, para dar otra charla sobre ASP.NET. Mar del Plata es una bella ciudad, en frente del océano Atlántico, a la que trato de volver cada año. Entonces, era mi primer visita luego de treinta años. En el viaje, "nació" AjLisp.
Esa versión era un intérprete Lisp escrito en Visual Basic .NET. El pasado domingo, lo porté a C# (usando alguna opción de menú de SharpDevelop, ¿alguna otra herramienta que conozcan?). El código original fue usado hace unas semanas en mi post sobre VPL:
Lisp-like interpreter using DSS and VPL
Intérprete tipo Lisp usando DSS y VPL
La nueva versión C# version está publicada en Google Code en:
http://code.google.com/p/ajlisp/
Me gusta Google Code: tiene soporte de SVN, asi que uso mi cliente local TortoiseSVN para enviar los cambios en el proyecto.
La solución
Tiene tres proyectos:
AjLisp: el proyecto núcleo, una librería, que puede ser invocada desde otra aplicación.
AjLisp.Tests: Todos los tests, usando NUnit 2.2.8. Si no tienen NUnit, pueden remover el proyecto de la solución.
AjLisp.Console: un simple programa de consola.
Los tipos
Una interfaz base es IAtom:
public interface IAtom
{
bool IsAtom();
}
Otra es IList:
public interface IList
{
SymbolicExpression First
{
get;
set;
}
SymbolicExpression Rest
{
get;
set;
}
bool IsList();
}
Todos los tipos derivan de una SymbolicExpression:
namespace AjLisp.Types
{
public abstract class SymbolicExpression : IList, IAtom
{
....
Implementé los tipos comunes a usar en un Lisp, como List, Atom, Identifier, Function (para invocar a primitivas y funciones generadas por lambdas), True, Nil...:
Existe una clase Environment para mantener valores asociados a nombres. Cada Environment tiene un Environment padre, para mantener una lista de ambientes con valores.
La clase Interpreter es la principal a manejar: tiene un Environment y define algunos nombres para las primitivas iniciales:
public class Interpreter
{
private Environment environment = new Environment();
public Interpreter()
{
Define("nil", Nil.Value);
Define("t", True.Value);
Define("cons", new SubrCons());
Define("first", new SubrFirst());
Define("car", new SubrFirst());
Define("rest", new SubrRest());
Define("cdr", new SubrRest());
Define("list", new SubrList());
Define("quote", new FSubrQuote());
Define("append", new SubrAppend());
Define("cond", new FSubrCond());
Define("atom", new SubrAtom());
Define("eval", new SubrEval());
Define("null", new SubrNull());
Define("lambda", new FSubrLambda());
Define("progn", new FSubrProgN());
Define("flambda", new FSubrFLambda());
Define("nlambda", new FSubrNLambda());
Define("mlambda", new FSubrMLambda());
Define("numberp", new SubrNumberP());
Define("functionp", new SubrFunctionP());
Define("idp", new SubrIdP());
Define("define", new FSubrDefine());
Define("definef", new FSubrDefineF());
Define("definen", new FSubrDefineN());
Define("definem", new FSubrDefineM());
Define("eq", new SubrEq());
Define("if", new FSubrIf());
Define("let", new FSubrLet());
Define("lets", new FSubrLetS());
Define("set", new SubrSet());
Define("consp", new SubrConsP());
Define("less", new SubrLess());
Define("greater", new SubrGreater());
Define("plus", new SubrPlus());
Define("difference", new SubrDifference());
Define("times", new SubrTimes());
Define("quotient", new SubrQuotient());
Define("remainder", new SubrRemainder());
}
....
Uds. pueden escribir sus propias primitivas y agregarlas a este constructor.
Las primitivas
El intérprete tiene las primitivas usuales:
Hay primitivas, que antes de su invocación, evalúan los argumentos recibidos. Son las que derivan de Subr:
public abstract class Subr : Function
{
public abstract SymbolicExpression Execute(SymbolicExpression args, Environment env);
public override SymbolicExpression Apply(SymbolicExpression form, Environment env)
{
return Execute(form.Rest.Evaluate(env), env);
}
}
form.First es la función, y form.Rest es la lista de argumentos. Para evaluar el form, Function usa un objeto Environment.
Otras primitivas no evalúan sus argumentos, derivan de FSubr:
public abstract class FSubr : Function
{
public abstract SymbolicExpression Execute(SymbolicExpression args, Environment env);
public override SymbolicExpression Apply(SymbolicExpression form, Environment env)
{
return Execute(form.Rest, env);
}
}
Una de las primitivas más interesantes, es la implementación de lambda, llamada FSubrLambda:
public class FSubrLambda : FSubr
{
public override SymbolicExpression Execute(SymbolicExpression args, Environment env)
{
return new SubrClosure(args.First, env, args.Rest);
}
}
Crea un Closure, una manera de recordar el Environment actual para usarlo en una futura invocación de la expresión lambda. Implementé también NLambda, FLambda, MLambda: N es por NonSpread (maneja su lista de argumentos como si fuera un solo argumento), F es cuando no son evaluados los argumentos antes de la invocación, y M es por Macro (tengo que revisar hasta donde implementé esta "feature").
Los tests
Toda la funcionaliad está cubierta por tests. Configuré el proyecto AjLisp.Test para ejecuter NUnit GUI:
La consola
AjLisp.Console es un simple programa de consola. Pueden ingresar una expresión y la evalúa:
Es tan simple, que hay que usar Control-C para salir... ;-).
Próximos pasos
Hay tanto para hacer. Quiero mejorar algunos puntos:
- Reescribir interfaces y clases de base
- Manejar e invocar objetos .NET nativos
- Tratar a Reales y Enteros por separado (hoy a ambos, al operar, los trata como valores double)
- Revisar Macro expansion
- Mejor consola
- Librería de ejemplos
- Un manual mínimo
La idea es llegar a extender este mini lenguaje para ser usado como la base programación de agentes distribuidos. Sería bueno portarlo a Java. Entonces, la conducta de los agentes y su estado puede ser escrito en este lenguaje, y viajar a distintos nodos de la grilla, de forma independiente a la plataforma.
Bueno, son sueños. Ahora, el estado actual: está funcionando, y me divertí escribiéndolo. Disfruten!
(Este artículo es una traducción a Spanish, desde el Anglish (Angel's English) original:
AjLisp- a Lisp interpreter in .NET
)
Angel "Java" Lopez
http://www.ajlopez.com/en