jueves, 11 de diciembre de 2008

Viernes 19/12 , 16:30 hrs: Defensa Tesis de Reingeniería de Jerarquías Polimórficas Utilizando Traits

Nuevamente estoy con poco tiempo para postear... tengo pendiente seguir con los tips que presente en Smalltalks 2008, pero por ahora copio esta invitación a la defensa de tesis de Claudio y Nicolás que además dieron una presentación muy buena en Smalltalks 2008 sobre este tema...
----------------
Invitamos a todos a la defensa de la siguiente tesis de licenciatura, que
se llevará a cabo el Viernes 19 de Diciembre a las 16:30 hrs, aula a
confirmar:

Título: "Reingeniería de Jerarquías Polimórficas Utilizando Traits"

Alumnos: Acciaresi, Claudio y Buttarelli, Nicolás Martín
Director: Hernán Wilkinson
Jurados: Máximo Prieto, Gabriela Arévalo
--------------------------------------------------------------------
Resumen
Los Traits son una nueva herramienta de modelado que permite al
programador compartir comportamiento entre objetos sin utilizar la
subclasificación. Este nuevo concepto fue llevado a Smalltalk en el año
2003 y desde entonces a la actualidad se realizaron varios trabajos
utilizando Traits. Sin embargo, la mayoría de estos aborda el tema desde
un punto de vista más bien práctico realizando refactorizaciones de
jerarquías ya implementadas. Este trabajo en cambio, estudia a los Traits
en un marco teórico donde se considera que programar no es otra cosa que
representar conocimiento.
Para cumplir con este objetivo se reimplementó la jerarquía de Collection
utilizando Traits.  Una vez generado el nuevo modelo se realizó un
análisis del mismo en comparación con la jerarquía implementada en el
ambiente de desarrollo elegido: Squeak. Dicho análisis se basó en la
definición e implementación de métricas de calidad y de performance
tomadas sobre ambos modelos.
Durante el desarrollo se encontraron un conjunto de ventajas y desventajas
en el uso de esta nueva herramienta, pero además, se redefinieron los
Traits como la reificación de características comunes entre objetos. De
esta manera, se separa el concepto de Traits con el de eliminar código
duplicado, y se analiza si el hecho de reificar características comunes
entre los objetos del dominio nos ayuda a crear mejores modelos
computacionales de la realidad.

miércoles, 26 de noviembre de 2008

Mas fotos sobre Smalltalks 2008

Les paso un link a fotos de James Foster sobre el congreso, la cena y la salida al delta:  http://picasaweb.google.com/WeybridgeWay

martes, 25 de noviembre de 2008

Smalltalks 2008 en el diario La Razón

Salió una referencia a la conferencia en el diario La Razón. Se puede ver en http://www.ee.larazon.com/ediciones/2008/11/25/default.asp
Tienen que elegir la sección UAI (donde dice Tapa, arriba a la izquierda) y luego ir a la página 3 de ese suplemento.
Gracias Gonzalo por haber hecho posible esta referencia.

viernes, 21 de noviembre de 2008

martes, 18 de noviembre de 2008

Tip 1: Create an Isomorphism between objects and entities

Este fue el primer tip de la charla de Smalltalks que presenté el viernes pasado. Voy a tratar de repasar todos los tips durante las próximas semanas escribiendo los comentarios que obtuve en el congreso y también esperando que ustedes aporten algún comentario.
Este tip tiene como objetivo "lograr un buen modelo". En realidad, la definición de "buen modelo" que dí está basada en las ideas que Einstein escribe en "Física, la aventura del pensamiento", donde básicamente argumenta que un buen modelo es aquel que soporta todas las observaciones que se realizan de la realidad correctamente. Esta idea combinada con la que Norman ofrece en "The Design of Everyday thing" donde básicamente habla sobre la importancia del "mapping" entre los "entes del modelo mental" que uno se realiza de "la realidad" es que aparece este tip.
La idea es que si logramos mapear correctamente cada ente de la realidad a objetos del modelo computable que estamos haciendo estaremos logrando un buen modelo, puesto que cada observación será mapeada directamente a los objetos existentes, y en caso de no poder ser mapeada es porque aprendimos algo nuevo y por lo tanto hay que crear los objetos correspondiente para soportala. 
Algo que hay que tener en cuenta sobre este tip, que no comenté en la charla, es que este es un objetivo, es lo que se debe buscar puesto que lograr ese isomorfismo es casi imposible (sino imposible) puesto que siempre habrá algo nuevo para aprender de la realidad o una nueva manera de organizar lo que entendimos. 
Otro punto a tener en cuenta es que realmente uno no mapea los objetos con los entes de la realidad sino con el modelo mental que uno realiza de la realidad, es por ello que existen varios modelos del mismo problema que son pensados desde distintos puntos de vista. Es por este motivo que utilizar metáforas para realizar ese modelo mental es fundamental, puesto que guiará nuestra representación e interpretación de la realidad, nos dará una herramienta para entenderla, cuadrarla. El tema de la metáfora es tan importante que hay filósofos post-modernistas que dicen que no pensamos sino a través de metáforas. Representan a estas como "meta-ideas", o sea ideas sobre ideas.
Uno de los comentarios que recibí sobre este tip fue que en el modelo siempre existen objetos que no aparecen en el dominio del problema. En cierta forma es verdad, hay muchos objetos que aparecen en el modelo que no forman parte del dominio de problema funcional, pero muchos de ellos corresponden al hecho de estar haciendo un modelo computable, o sea que son objetos que representan entes de otro dominio de problema, el computable. No tengo manera de probar que siempre estos objetos serán de este dominio pero mi intuición de dice que si.... 
Si no fuese así, debería cambiar el "isomorfismo" por aquella relación utilizada para indicar que todos los elementos del codominio se mapeaban al dominio (no recuerdo la palabra ahora).
Más allá de este detalle (no despreciable por cierto), lo importante es no olvidar la consigna de mantener este mapeo como objetivo y recordar la importancia de tener una metáfora que nos guie en el proceso...

A personal Computer for Children of All Ages

Ese es el paper escrito por Alan Kay en Agosto del 72 donde presenta su idea de la Dynabook. Nunca lo había leído y luego de haberlo hecho no cabe duda de la visión que tuvo en su momento. La parte que más gracia me causo fue la que dice "seguramente una de las primeras aplicaciones que harían sería para evitar que aparezca propaganda..." (palabras más palabras menos, no encuentro exactamente lo que dijo ahora) cuando se refería a la conectividad de la computadora. Vale la pena leer esta paper historico.

lunes, 17 de noviembre de 2008

Adios Smalltalks 2008

Como ustedes sabrán, Smalltalks 2008 ha terminado. La verdad que han sido 3 días maravillosos, de charlas muy interesantes y de reencuentros muy lindos. Mi intención era hacer un resumen de todas las charlas pero no podrá ser. Vi que Andrés Valloud hizo una serie de comentarios sobre las mismas en su blog, así que pueden leer sobre ellas ahí.
Algunas charlas que recuerdo sin ningún orden particular son:
1) Claudio Acciaressi y Nicolás Butarelli que hablaron sobre la reimplementación de Collection para traits. Se notó que prepararon mucho esa presentación y fue muy chistosa
2) Dan Rozenfarb que presentó ExpertCare. Es muy interesante ver como Dan fue cambiando el diseño de la aplicación desde utilizar un árbol de decisión a modelar reglas con algo cercano a lógica de primer orden.
3) Gabriel Cotelli que habló sobre la herramienta reflexiva para generar reportes que usamos en XTrade. Gabriel subió a YouTube una filmación de la charla
4) Monty Williams que dió el keynote y comentó casos de éxito de usar Smalltalk en distintos sistemas. Hay sistemas de misión crítica y con miles de transacciones que ni siquiera sabía que usaban Smalltalk/GemStone, muy impresionante
5) DX Browser Tool de Bruno Buzzi o como implementar herramientas de Smalltalk para administrar web services y archivos XML. Bruno mostró cómo se puede simplificar el uso de herramientas que el hombre hace complejas.
6) Ambiente de Aprendizaje de Objetos de Fernando Olivara y Juan Burella. La presentación fue interesante y llegaron a mostrar el ambiente (en una versión anterior) funcionando en Croquet. Si embargo como se encuentran en medio de una gran refactorización la presentación no se lució tanto como podría haberlo hecho.
7) Glorp, de Alan Knigth. Fue muy intersante como mostró este framework, lástima que no haya presentado temas más relacionados con el diseño que creo que hubiese estado lindo.
8) Los roadmaps de GemStone y Cincom Smalltalk. En de GemStone en particular estuvo muy interesante cuando James mostró una herramienta parecida a WebVelocity pero que corre en GLASS
9) Andrés Valloud nos motró como modelo en coding contest y todas las opciones que tuvo en cuenta para hacerlo, una charla muy interesante para aquellos que trabajamos en el problema
10) Leandro mostró como se puede tener comportamiento por instancia en VisualSmalltalk. El truco es muy interesante y la verdad que la decisión de VisualSmalltalk de que los objetos conozcan un method dictionary en vez de su clase directamente me parece una decisión muy acertada. Como dijo Leandro, es darle más importancia al comportamiento que a la clasificación.
11) La charla de Richie sobre SqueakNos, impresionante. Yo había visto correr SqueakNos antes pero esta vez estuvo muy bien presentado y mucho más estable. En la charla mostro como acceder al boot sector de un disco IDE y todo desde Smalltalk! Ojala podamos hacer crecer este proyecto
12) La mejor charla de todas, por lo menos así fue elegida por la gente, la de Gabriel Honoré que mostró un Emulador de Commodore 64 hecho en VisualWorks! La gente aplaudió como loca con cada chiche que mostraba como el sonido, los juegos, podes controlar la pantalla desde un inspector, etc. Una presentación y trabajo impecable, de exportación!!
También estuvieron las charlas sobre MOOSE, Percolación, SqueakDBX, el trabajo de Tesis de Carlos Ferro, Zafiro y la mia.
Respecto de la mia, creo que generó bastante polvo, por lo menos luego de darla estuvimos hablando sobre varias ideas con Valeria y Richie y las diferencias sobre lo que ellos hacían. También tuvimos unas conversaciones intersantes con Andrés Fortier que me ayudaron a entender como transmitir mejor el mensaje que quería transmitir. Por supuesto, como me ocurre ultimamente, me quedé sin tiempo... es que quiero decir muchas cosas!!! pero fue una lástima porque no pude mostrar ejemplos concretos que hubiesen ayudado a asentar lo que transmitía.
Por supuesto estuvo el coding contest que ganaron Guillermo Amaral y Guido Chari. Lamentablemente yo no le encontré la vuelta aunque conseguí un certificado positivo pero de solo 2 millones contra 26 que consiguieron los ganadores. Creo que hubo varios factores que influyeron en que no lograse encontrar la solución: el cansancio y el hecho de no haber estado trabajando en el modelo por casi dos semanas... pero calavera no chilla! y estoy muy contento de haber participado y programado nuevamente después de unos meses de solo contestar mails, puaj!
Por último, el domingo llevamos a Monty, June, James, Alan y Victor al Tigre. Los llevamos a remar hasta la isla Rufino Elizalde, del Buenos Aires Rowing Club. Estuvo espectacular! creo que lo disfrutaron muchísimo y hasta comimos un asado. Lástima que por la sudestada del sábado el agua había inundado la isla y por lo tanto estaba todo barroso, pero igual creo que fue una experiencia inolvidable para ellos.

Espero que todos hayan disfrutado de esta conferencia tanto como lo hicimos nosotros. Los comentarios que me llegaron así lo dicen... y ya estaremos trabajando para Smalltalks 2009!!!

Nos vemos!

miércoles, 12 de noviembre de 2008

Ya llega!! Ya llega!!

Si señores y señoras, mañana es el día!! mañana empiza la segunda edición del congreso Argentino de Smalltalk!!! Smalltalks 2008. No dejen de ir y participar, les aseguro que estará muy bueno y también se van a divertir mucho!! y habrá muchas sopresas!
Los veo ahí!

PD: Voy a intentar postear un resumen sobre cada charla para mantenerlos al tanto a los que no fueron.

martes, 4 de noviembre de 2008

Smalltalks 2008 - Descripción de Charlas

Me olvide de comentar que en la sección "Charlas" del sitio del congreso hay un link llamado "Ver Propuestas Aceptadas" que lleva a una página con descripciones de las distintas charlas que se darán.

Smalltalks 2008 - Corrección

En el post anterior puse mal la dirección al sitio web del congreso, el mismo es:  http://neuquina.lifia.info.unlp.edu.ar:8001/Smalltalks-2008

lunes, 3 de noviembre de 2008

Smalltalks 2008 - Inscripción y Cronograma

Ya está disponible el cronograma del congreso Smalltalks 2008!!! Creo que quedó muy bueno, hay charlas muy interesantes como el Emulador de Commodore 64 escrito completamente en Smalltalk!! (lo vi funcionando y es una masa!) o SqueakNos, la mía por supuesto :-), los temas de persistencia como SqueakDBX y Glorp, sin olvidar los tutorials (uno sobre la arquitectura de GemStone y otro de Futbol de Robots) y las charlas de gente de afuera como Monty Williams (arquitecto de GemStone), Alan Knight y James Forster nuevamente. (El cronograma lo pueden ver en http://neuquina.lifia.info.unlp.edu.ar:8001/ tab Cronograma)
No dejen de inscribirse puesto que por cuestiones de seguridad vamos a ser más estrictos este año con el ingreso. 

viernes, 17 de octubre de 2008

Un poco de Historia...

La verdad que se me hace complicado mantener el blog con cosas interesantes, no porque no tenga ideas sino porque no tengo tiempo para escribir! 
En fin, hoy leí un post en la lista de squeak que me pareció muy interesante para compartir (y no escribir tanto). Es sobre la historia de Eclipse y VisualAge Smalltalk.
http://talklikeaduck.denhaven2.com/articles/2008/10/15/will-it-go-round-in-circles

jueves, 2 de octubre de 2008

Smalltalks 2008 - Concurso de Programación II

Quería comentar que la reglas del concurso ya están disponibles en castellano. Por un tema de tiempo no llegamos a tenerlas disponibles ayer, pero en el grupo del concurso se encuentra posteada las reglas en castellano.
Espero que esto no haya sido un inconveniente. También les comento que en el grupo del concurso se puede postear en inglés y castellano indistintamente.

miércoles, 1 de octubre de 2008

Smalltalks 2008 - Concurso de programación

Ya está disponible en el sitio del congreso de Smalltalks 2008 las bases para el concurso de programación! No pierdan tiempo! es un trabajo muy interesante y seguro que lo van a disfrutar y aprender!
Además el incentivo es bueno: 1er Premio un iPod Touch, 2do Premio un MP4 y 3er Premio voucher para libros en Yenny! 

Charla de Smalltalk/X - Mis conclusiones

Se hizo esperar, pero finalmente encontré algo de tiempo para escribir mis conclusiones sobre la charla que tuvimos sobre Smalltalk/X:
* La charla fue muy interesante y dinámica. Claus mostró mucho conocimiento y experiencia tanto en Smalltalk como en la implementación de Smalltalk. La primera parte de la charla la dedicó a mostrar la implementación de Smalltalk/X y sobre el final mostró la herramienta de testing que han desarrollado.
Me sorprendió la implementación de Smalltalk/X, no la conocía y me gustó bastante. Es una VM que no tiene nada que envidiarle a otras implementaciones, todo lo contrario, es muy superior a Squeak y VisualAge por ejemplo. Algunas características son:
a) Utiliza IC y PIC para acelerar el method lookup. Solo VW hace eso que yo sepa y por lo tanto sobrepasa en performance por varios cuerpos a Squeak y VisualAge (hagan la prueba sino)
b) Utiliza un GC incremental cuando realiza el mark & sweep del old space (por supuesto, es un GC generacional típico). Esto es muy bueno porque permite limitar el tiempo de gc y por lo tanto asegurar tiempos de respuestas para aplicaciones real time. No conozco otro Smalltalk que tenga esta característica. Por los menos VisualAge y Squeak no la tienen y me parece que VW tampoco
c) El modelo de treading es muy interesante. Primero utiliza threads nativas lo cual permite hacer uso automáticamente de máquinas con más de un procesador, sin embargo no pueden haber dos threads ejecutando concurrentemente. O sea, por un lado es una ventaja por poder distribuir la carga pero no está completamente implementada la posibilidad de ejecutar de manera concurrente. Segundo, cada ventana tiene su propia thread de ejecución, por lo tanto si por darle "evaluate" una ventana se queda haciendo un loop infinito, esto no "cuelga" las otras ventanas, se puede seguir trabajando de manera "normal" (Finalmente alguién que hizo bien esto!)
d) Tiene la opción interesante de generar imágenes muy chicas y empaquetar todo como exes reales. Aunque personalmente no utilizaría esta opción porque la imagen a mi entender sigue siendo algo muy importante, es una opción interesante cuando es necesario hacer aplicaciones para dispositivos con pocos recursos. Hacerlo traería aparejado mayor tiempo de mantenimiento y desarrollo porque habría que asegurarse de que esté todo lo necesario cuando se crea ese "exe" particular, pero es una opción válida para ciertos ambientes.
e) Es interesante la posibilidad de escribir las primitivas en el mismo ambiente, lo cual permite ver con exactitud cómo está implementado cada método. Una lástima no poder debuggear las primitivas, pero tampoco debería ser un requerimiento muy frecuente.
f) Desde el punto de vista de Smalltalk, es una implementación bastante completa. Tiene SUnit, concexión a BD via ODBC, tiene soporte para aplicaciones web (aunque no soporta SeaSide debido a no poder implementar continuations por no poder reificar el stack de ejecución), tiene el refactoring browser migrado y las herramientas típicas de cualquier Smalltalk.
g) Quizá lo único negativo que podría nombrar es la UI. Tiene un estilo un poco "antiguo" y no tan atractivo, pero es algo lógico puesto que hacer UIs "lindas" lleva tiempo y mucha creatividad. Por supuesto que esto para un programador experimientado no debería moverle la aguja, pero para programadores novatos puede ser un stopper (lo que no entra por los ojos...)

En conclusión, una charla muy completa y muy bien dada desde el punto de vista pedagógico. Se nota que Claus tiene experiencia en lo que habla y tiene mucha didáctica por ser profesor también. La verdad que la disfruté mucho y al día siguiente me bajé Smalltalk/X, lo instalé y jugé un poco con él. Un Smalltalk más para tener en cuenta. Es gratis sin ningún tipo de royalties para desarrollar o vender, completamente gratis. No open source, hay algunas temas que no están abiertos. No hay soporte más allá de la misma comunidad a menos que se page por él (no precisó costos). Es una lástima no compartir esta fabulosa implementación de la VM con otros Smalltalks open source como Squeak, o que Smalltalk/X no haga uso de la UI de Dolphin que es más atractiva... un Smalltalk "casi ideal" sería la VM de Smalltalk/X con el modelo de Squeak o VW (o una mezcla de ambos) y el UI de Dolphin... todo open source por supuesto. Una combinación así sería un caño me parece... igual no creo que suceda, por ahora seguimos viendo islas donde cada implementación trata de seguir mejorando lo que tiene. Eliot Miranda mejorando Squeak, Craig Latta haciendo Spoon, VisualAge tratando de soportar SeaSide, Gilad Bracha implementado NewSpeak, etc. No se si sería factible juntar todos los esfuerzos ni tampoco se si sería productivo, pero si se que sería interesante probar.


jueves, 18 de septiembre de 2008

Smalltalks 2008 - Novedades

Por si no se enteraron por otro medio, ya está disponible en el sitio de Smalltalks 2008 la registración para charlas y tutorials! No dejen de presentar sus ideas!.  Ah, la fecha tope se movió al 13 de Octubre, así tienen dos semanas más para pensar.... y no se olviden del concurso... tenemos a varios craniotecas pensando y trabajando en el mismo :-)
Acá está el mail con el anuncio:
-----------------------------
Por medio del presente mail queremos informarles las novedades de la
conferencia:

1. Se encuentra habilitado el envío de propuestas de charlas en
http://neuquina.lifia.info.unlp.edu.ar:8001/Smalltalks-2008 sección
"Charlas". Aquí se podrán presentar distintos tipos de trabajos, ya
sea de industria, investigación o educación. La fecha tope para enviar
es el 13 de Octubre.

2. Se encuentra habilitado el envío de propuestas de tutorials en
http://neuquina.lifia.info.unlp.edu.ar:8001/Smalltalks-2008 sección
"Tutorials". La fecha tope para enviar es el 13 de Octubre.

3. Asimismo les recordamos que el 1ro de Octubre publicaremos el
enunciado del concurso de programación. Para mas información ver la
sección del "Concurso de Programación" en
http://neuquina.lifia.info.unlp.edu.ar:8001/Smalltalks-2008

Esperamos verlos a todos en la conferencia!
Comité Organizador de Smalltalks 2008.

OOPSLA 2008 - 50 años de Lisp

Ya escribí sobre este tema en otro post, pero ya se está formalizando. Miren este mail sino:
Lisp50@OOPSLA
...celebrating the 50th birthday of Lisp at OOPSLA 2008

Monday, October 20, 2008
Nashville, Tennessee, USA
co-located with OOPSLA 2008
participation is free for all OOPSLA participants
registration for at least one conference day at OOPSLA is required

URL: http:www.lisp50.org
Feed: http://lisp50.blogspot.com


Invited Speakers

+ William Clinger, Northeastern University, USA
+ Pascal Costanza, Vrije Universiteit Brussel, Belgium
+ Richard Gabriel, IBM Research, USA
+ Rich Hickey, Independent Consultant, USA
+ Alan Kay, Viewpoints Research Institute, USA
+ Fritz Kunze, USA
+ Ora Lassila, Nokia Research Center, USA
+ John McCarthy, USA
+ Kent Pitman, PTC, USA
+ Guy Steele, Sun Microsystems Laboratories, USA
+ Herbert Stoyan, University of Erlangen, Germany
+ Warren Teitelman, Google Inc., USA
+ JonL White, USA

Titles, abstracts, biographies and schedule will be announced at the
Lisp50 webpage and blog in the coming days and weeks.


Abstract

In October 1958, John McCarthy published one in a series of reports about
his then ongoing effort for designing a new programming language that
would be especially suited for achieving artificial intelligence. That
report was the first one to use the name LISP for this new programming
language. 50 years later, Lisp is still in use. This year we are
celebrating Lisp's 50th birthday. OOPSLA 2008 is an excellent venue for
such a celebration, because object-oriented programming benefited heavily
from Lisp ideas and because OOPSLA 2008 takes place in October, exactly
50 years after the name Lisp has been used publicly for the first time.
We will have talks by John McCarthy himself, and numerous other
influential Lispers from the past five decades. We will also take a look
at the next 50 years of Lisp.


Organizers

+ Pascal Costanza, Vrije Universiteit Brussel, Belgium
+ Richard Gabriel, IBM Research, Hawthorne, NY, USA
+ Robert Hirschfeld, Hasso-Plattner-Institut, Potsdam, Germany
+ Guy Steele, Sun Microsystems Laboratories, Burlington, MA, USA

Sponsored by ACM SIGPLAN

Supported by
+ IBM Research
+ LispWorks Ltd
+ Franz Inc.
+ Clozure Associates

viernes, 12 de septiembre de 2008

Presentación de Tesis Licenciatura - Tema: Refactoring de Traits

Seguramente también se hayan enterado de este evento, pero de la misma manera que con la charla, me parece importante publicarlo acá. La realidad es que estoy muy contento con el avance que estoy teniendo con el grupo de tesistas de la UBA. Estamos haciendo trabajos muy interesante.... bue, en realidad ellos están trabajando mucho, yo solo puse las ideas iniciales y de vez en cuando nos reunimos, pero la verdad que estar trabajando con gente motivada, autónoma y con espíritu de investigación es muy reconfortante. Lástima que tenga tan poco tiempo para dedicarles... si le dedicase más tiempo creo que ni mi perro me reconocería!.
En particular,Alejandro ha hecho un trabajo excepcional con esta investigación y la ha presentado en Smalltalks 2007 cuando aún estaba trabajando en ella. Esta presentación será aún mejor, se los puedo asegurar, si tienen la oportunidad de venir no se van a arrepentir. De vuelta, es un trabajo muy interesante y Alejandro ha trabajado muy bien y con mucha fuerza. Además tendremos un jurado de lujo! Máximo Prieto y Gabriela Arévalo! ¿Qué más se puede pedir?
También me emociona pensar que otros grupos estarán exponiendo para fin de este año si Dios quiere, o principo del que viene, uno también sobre traits y otro sobre ambientes de enseñanza con objetos, así que estén atentos!
Ahora les transcribo el mail que mandé invitando a la presentación de tesis:
-----------------------------
Que tal, 
 el miércoles 17 de Septiembre a las 10 hrs. (aula a determinar), Alejandro Gonzalez presentará su trabajo de Tesis de Licenciatura que trata sobre el estudio e implementación de "Refactorings para Traits".
 El mismo se basó en realizar cambios a jerarquías de clases existentes utilizando un nuevo elemento de representación de conocimiento denominado Trait (o Rasgo en castellano). Al ir realizando estos cambios se tomó nota de aquellos procesos comunes que pudiesen ser creados como Refactorings, para luego implementarlos como tal.
 El trabajo se realizó con Squeak (una implementación open source de Smalltalk) y se amplió la funcionalidad del Refactoring Browser. El mismo se encuentra disponible para ser utilizado en SqueakSource.

 Esta es la primer presentación de un conjunto de tesis que tratan sobre la utilización de Traits en ambientes de objetos que utilizan clasificación como metodología de representación de conocimiento. El resto de los trabajos se irán presentando en los próximos meses.
 El jurado estará compuesto por Máximo Prieto, Gabriela Arévalo 
 Director: Hernán Wilkinson

 A continuación se adjunta un resumen:
---
Traits es un nuevo concepto para estructurar programas orientados a objetos.
Este concepto, permite que el comportamiento total de una clase pueda ser construido
composicionalmente a partir de pequeños rasgos de comportamientos llamados traits.

Traits complementa a la herencia simple y es por esto,
que su inclusión conlleva la necesidad de querer refactorizar nuestros diseños,
ya que con ellos ahora se pueden resolver cuestiones antes no resueltas, o mal resueltas, por la herencia.
En particular, aquellas jerarquías cuestionadas por hacer un fuerte uso de la herencia
como único mecanismo para compartir comportamiento, son las que se convierten en candidatas a ser refactorizadas con traits.
Pero estas refactorizaciones no pueden ser realizadas eficientemente sin la asistencia de una herramienta apropiada.

Muchos ambientes de desarrollo incluyen herramientas para refactorizar código.
Éstas soportan, a menudo, refactorings típicos que pueden realizarse en forma semi-automática,
como por ejemplo Push up method y Rename method.
El problema es que, éstas operan sobre conceptos conocidos del paradigma:
jerarquía de clases, métodos, variables de instancia, etc.
Actualmente, ninguna brinda soporte para la refactorización con este nuevo concepto, traits.

En este trabajo se investigan, tanto desde un punto de vista conceptual como implementativo, nuevos refactorings para traits.
El resultado es un nuevo conjunto de operaciones de refactorings que,
inicialmente surgieron de ideas básicas y operaciones típicas al programar con traits,
pero que luego fueron refinándose a medida que las comenzamos a utilizar para realizar diferentes refactorizaciones.

Estos nuevos refactorings se implementaron en Squeak, un dialecto open-source de Smalltalk,
dado que éste es el único ambiente que incluye una implementación sólida de ambos,
el nuevo concepto de traits y una herramienta de refactorings conocida como refactoring browser.

Charla sobre Smalltalk/X y Model Base Testing

Seguramente ya se entereron de esta charla por las listas de mails de Smalltalk, la facultad, etc. Sin embargo me parecía útil comunicarla acá también. Les transcribo el mail que envié sobre la misma:
--------
Que tal,
 el comité organizador de "Smalltalks 2008" tiene el agrado de anunciar la charla que dará Claus Gittinger, co-fundador de eXept Software AG y creador de Smalltalk/X el viernes 19 de Septiembre, a las 19 hrs. en Ciudad Universitaria (los detalle del aula serán dados más adelante).
 La misma será una exposición técnica sobre la implementación de Smalltalk/X en primera instancia, para luego incursionar en el tema de "Model Base Testing" en donde mostrará un ejemplo real de uso utilizando la herramienta denominada "Expecco", la cual fue desarrollada por eXept justamente con Smalltalk/X

 Para más información sobre eXept y Smalltalk/X pueden visitar: http://www.exept.de/en/home
 Para más información sobre "Model Base Testing" y Expecco, pueden visitar: http://www.exept.de/en/products/expecco
 Para más información sobre "Smalltalks 2008" pueden visitar: http://neuquina.lifia.info.unlp.edu.ar:8001/Smalltalks-2008

 A continuación se detalla el profile de Claus Gittinger:
 Claus Gittinger has a 22-year background as a software architect for object oriented software. He is
the creator of the Smalltalk/X programming system.
 As a co-founder of eXept Software AG he was defining and supervising development and testing
processes with various customers in telecommunication-, factory automization and automotive
projects.
 He is responsible for strategic product planning and the further development of the eXept's expecco
quality management and test automation tool.
 He is part-time teaching computer science at the Hochschule der Medien in Stuttgart.

 Los esperamos!
 Saludos,
 Hernán Wilkinson.

miércoles, 10 de septiembre de 2008

Clojure - On state and Identity

Este paper sobre el lenguaje Clojure me pareció muy interesante. Está muy clara la problemática de los lenguajes actuales (tanto procedurales como funcionales como de objetos) y provee una solución implementativa muy interesante. 
Lo que me parece más intersante de la solución que propone es que es fácilmente ampliable para mantener la historia de los objetos y así no tener más la limitación de que los sistemas reflejen sólo un snapshot de la realidad. 
Hacer que un lenguaje de objetos soporte la historia de los mismos es un lindo tema de tesis que tengo pendiente. Imaginensé si a ese lenguaje le agregamos persistencia automática en una base relacional (puesto que la gente aún se asusta de las bases de objetos), ¿no tendríamos el COBOL del siglo XXI? :-)

V8 - La Virtual Machine de JavaScript de Google

Como todos deben estar al tanto, Google sacó un nuevo Browser llamado Chrone que incluye la VM de JavaScript más rápida hasta ahora (http://code.google.com/p/v8/)
Lo interesante de esta VM es que fue hecha por gente que trabajó en la VM de Self y de Strongtalk, ambas VMs famosas por sus aportes a la materia en cuestión. 
En particular Self aportó mucho sobre como mejorar la performance en el algoritmo de method lookup, implementando algo que se llama PIC (polimorphic inline cache), utilizado actualmente en la VM de VisualWorks por ejemplo. V8 utiliza una versión simplificada de PIC que es IC (inline cache únicamente). La técnica de PIC también fue utlizada por Strontalk, la VM de Smalltalk más rápida hasta ahora (aunque no realiza garbage collection...).
En fin, me parece que desde el punto de vista técnico es muy interesante leer sobre como funciona esta VM, ver cómo está implementada puesto que el código es open source, etc. Y desde el punto de vista de marketing, es muy bueno tener uno de los grander players apostando en un lenguaje dinámico, lástima que sea JavaScript. Sin embargo lo bueno es que en la página de V8 se hace referencia a Self y Smalltalk, lo cual no es poco.

martes, 26 de agosto de 2008

Smalltalk está muerto! Larga vida a Smalltalk! Bienvenido Smalltalks 2008

Transcribo a continuación un artículo que salió publicado en el Journal del Lifia acerca de Smalltalks, espero que lo disfruten!
-------
A mediados de Septiembre de 2007, a cuatro locos se nos ocurrió organizar un congreso de un lenguaje de programación al que la mayoría de la gente lo da por muerto o cree que sólo sirve para enseñar: Smalltalk. ¿A quién se le ocurre utilizar ese lenguaje hoy en día? ¿Hay gente en el mundo o más aún, en Argentina que lo utilice?
Aquellos que conocen Smalltalk y las comunidad que existe alrededor de él, sabrán que sí, que hay gente en el mundo y más aún, en Argentina que usa este lenguaje. Pero además saben que aquellos que formamos parte de esta comunidad tenemos características especiales que compartimos con muchas comunidades de otros lenguajes de programación: amor por desarrollar software de calidad y pasión por el lenguaje que utilizamos, en este caso un lenguaje de programación que tiene ya casi treinta años.
Es por eso que cuando se nos ocurrió hacer este evento (ver http://www.dc.uba.ar/smalltalks2007) nuestras expectativas de convocatoria rondaban las 40, 50 personas como mucho. No pretendíamos hacer una conferencia de más de un día y tampoco pensábamos desplegar una logística complicada. Por ejemplo, los anotados debían enviar un mail a una casilla de correo creado para tal fin, la conferencia no tendría costo, etc. El congreso se realizaría en un aula común de la Facultad de Ciencias Exactas y Naturales de la UBA, a principio de Diciembre; y como se decidió hacerlo muy sobre la fecha, no había mucho tiempo para esperar grandes presentaciones, por lo que el único requisito que se pedía era un abstract de no más de una carilla.
Luego de enviar el mail de convocatoria empezamos a recibir inscripciones a un ritmo inesperado. Imaginamos al principio que el ritmo decaería con el acercamiento de la fecha del congreso, pero sucedió todo lo contrario. Cuando superamos los 40 inscriptos tuvimos que empezar a buscar un aula más grande pero al mes superamos los 100! y luego los 150, y luego los 200! A esa altura sólo quedaba como opción utilizar el Aula Magna del Pabellón I, la cual puede albergar cerca de 450 persona. Teníamos miedo. ¿Qué pasaría si de todos estos inscriptos solo venía la mitad o menos? El congreso era gratis, por lo tanto esto podría suceder. No sería agradable ver el aula Magna con 100 personas, sería verla vacía. Pero nos arriesgamos y decidimos utilizarla, decisión que nos alegra haber tomado porque la cantidad de inscriptos llegó a ser 300!, un número impensable para una congreso técnico en Argentina y menos todavía para un lenguaje que se suponía muerto o en el mejor de los casos fuera de moda!
Pero la sorpresa no terminó en la cantidad de gente anotada, siguió con la cantidad de trabajos presentados. Esperábamos recibir propuestas para presentar 6 u 8 trabajos, pero recibimos 30! Indudablemente un día no alcanzaba para presentar todo. Ni siquiera dos días alcanzaban sin que hubiese superposición de presentaciones. Además de las presentaciones argentinas, GemStone ofreció gracias a la publicidad y gran convocatoria que tuvo el congreso, realizar un Workshop sobre GLASS (http://seaside.gemstone.com), un ambiente de desarrollo web que utiliza Seaside (http://www.seaside.st) como framework web y GemStone (http://www.gemstone.com) como mecanismo de persistencia.
Finalmente el cronograma del congreso pasó de ser de un día con sólo 6 u 8 presentaciones nacionales a tres días, con 30 presentaciones, un workshop de un día entero y gente del exterior participando y presentando. ¡¡Totalmente inesperado!! Este evento superó todas nuestras expectativas, consumió todo nuestro tiempo libre (y no libre :-) ), nos volvió locos, "pero ¡la pucha que vale la pena estar vivo!" y este evento nos dio vida a todos, eso lo puedo asegurar.
Y las sorpresas no terminaron en la "cantidad" sino que también tuvimos sorpresas relacionado a la "calidad", característica que se notó en las presentaciones realizadas. Hubo presentaciones de una calidad técnica inesperada, con una claridad de conceptos e ideas que nos sorprendieron. Esto terminó de mostrarnos lo fuerte e importante que es la comunidad Smalltalk en Argentina. Un ejemplo demostrativo de esta importancia es la participación en los premios que ESUG otorga a los sistemas realizados en Smalltalk, que este año de 22 candidatos 6 son trabajos argentinos, el 25% (y me consta que hay aún más trabajos argentinos que se podrían presentar).
Las presentaciones realizadas abarcaron un espectro de temas muy completo. Las empresas locales presentaron sus sistemas y varias herramientas que usan para poder trabajar mejor, los grupos de investigación nos desasnaron sobre temas actuales y novedosos y hubo también exposiciones de los distintos grupos de enseñanza de objetos de diversas universidades.
En el congreso participó gente que vino de Luján, Mar del Plata, Concepción de Uruguay, Córdoba, Rosario, Rafaela, Resistencia, Formosa y varios lugares más del país. De los inscriptos, el 56% provino de la industria del software y el 44% restante de universidades (un balance muy interesante). De las universidades la que llevó más gente fue la UTN con el 36% (una gran sorpresa para todos nosotros), seguida por la Universidad de la Plata con un 31% y luego la UBA con un 21%. ¡Hasta hubo gente que catalogó el evento como "la conferencia de Smalltalk más importante de los últimos años"! (http://doesnotunderstand.free.fr/?p=459)
Trabajamos muchísimo para realizar esta conferencia y no lo habríamos logrado sin la ayuda desinteresada de varias empresas argentinas (Mercap SRL, InfoOil, Snoop, etc.) e internacionales (CaesarSystems, Cincom, Instantiations, GemStone, etc.), así como otras organizaciones como ESUG, LIFIA, STIC y la UBA, que por medio del Departamento de Computación de la Facultad de Ciencias Exactas, nos dió todo el soporte e infraestructura necesaria para que este evento fuera posible. Gracias a ellos pudimos cubrir cosas como el café y las medias lunas, las tazas y remeras referentes al evento, los cronogramas, DVDs y libros sorteados, así como un descuento del 50% a todos los participantes del congreso para asistir a Smalltalk Solutions 2008 en Reno, Estados Unidos (http://www.stic.st/stic?content=sts2008).
Un hecho interesante del evento fueron los videos que recolectamos de personalidades representativas de la comunidad Smalltalk de distintos lugares del mundo, como aquel de ViewPoint Reasearch Institute (liderado por Alan Kay) o de Dan Ingalls quien declaró sus ganas de venir este año a tomar unas cervezas con nosotros (¿quién dice no?).
En conclusión, fueron todas sorpresas y alegrías muy gratas. Valió la pena invertir el tiempo que se dedicó a este evento y los participantes han quedado más que satisfechos, pidiéndonos repetirlo para este año, lo cual estamos haciendo.
Por supuesto que no va a ser fácil igualar o superar el evento del año pasado. No sabemos si se generará más, menos o igual expectativa, no sabemos si vendrá más o menos gente, pero de algo sí estamos seguros: será un congreso excepcional por varios motivos. Uno de ellos es que como nos propusimos, será realizado en otra universidad, la UAI, quienes con la ayuda de Gonzalo Zabala nos abrieron sus puertas para este evento. Nuestra idea es hacer el congreso en una universidad distinta cada año. También estamos trabajando para que el track de investigación y educación tenga más importancia y podamos imprimir los trabajos presentados. Es nuestro objetivo a corto plazo publicar los trabajos en revistas de investigación de reconocimiento mundial, pero no es sencillo coordinarlo. Se está organizando un "coding contest" muy interesante y al cual están todos invitados. El evento será no sólo para gente de la comunidad Smalltalk sino también para todos aquellos programadores que "amen" su trabajo. Traeremos también personalidades bien conocidas de la comunidad Smalltalk internacional para que nos ofrezcan todo su conocimiento. Por lo tanto, no se olviden de agendar estas fechas: 13, 14 y 15 de Noviembre, y si tienen ganas de participar, tanto realizando una presentación como asistiendo a éstas, no dejen de visitar nuestro sitio para anotarse: http://neuquina.lifia.info.unlp.edu.ar:8001/Smalltalks-2008
Los que usamos Smalltalk somos muy pasionales, no hay porque ocultarlo. Esta actitud tiene su lado positivo pero también su lado negativo, puesto que al ser mal utilizada genera rechazo por parte de otros grupos, algo que ha sucedido en algunos casos. Luego de varios años de maduración y de varías "caídas", el grupo de gente que utiliza Smalltalk ha aprendido a sobrellevar su fanatismo de una manera más "social", menos pedante y más amistosa y estos eventos son el resultado de estos cambios. Es por eso que el evento está abierto a todas aquellas personas a las que les guste desarrollar software cada vez mejor y comparta esa pasión por hacerlo correctamente y con calidad.
Espero haberles transmitido en esta nota las energías, el empuje, el entusiasmo que tuvimos y tenemos para la organización de estos congresos. Tenemos muchas ganas y mucha pasión por hacer algo interesante, educativo, atractivo, con libertad y con calidad. No un congreso más, no un congreso dirigido por temas de modas, no un congreso donde nos digan como tenemos que trabajar, sino un congreso donde podamos compartir cómo nos gusta trabajar y podamos demostrar que es posible hacerlo como queremos.

viernes, 15 de agosto de 2008

Natural Language Programming

A partir de un artículo en la última Communications de la ACM, escrito por Mark Guzdiel llegué a unos papers muy interesantes sobre lo que se denomina "Natural Language Programming" o "Natural Programming". La idea es tener lenguajes de programación que estén hechos para los seres humanos y no para las computadoras.
Una de las observaciones que hacen es que los lenguajes de programación actuales están hechos para ser entendidos por computadoras y que por eso son tan detallados los programas y es tan difícil programar. Lo que proponen es hacer que los lenguajes de programación se asemejen más al lenguaje natural y que se pueda de esa manera entender mejor los programas que se escriben.
Más allá de las limitaciones y dificultades que esto tiene, la idea me parece muy interesante porque cambia completamente el ángulo de importancia. Va de acorde con lo vengo diciendo hace rato y que fue motivo de la charla de la ECI y es lograr que "la computadora haga más y el programador menos".
Una sorpresa que me llevé, que ya a esta altura está empezando a dejar de ser sorpresa, es que es un tema de investigación "antiguo", de hecho los papers fundadores de este movimiento son del '70! La verdad que cada vez más me doy cuenta que hay que ir a buscar en nuestra historia para descubrir los buenos trabajos (será que me estoy volviendo viejo? :-) )
En fin, les paso algunos nombres porque se los pueden bajar de internet sin problema:
* Natural Language programming: Styles, strategies, and contrasts, L.A. Miller (1970)
* Studying the Language ad Structure in Non-Programmers' solutions to programming problems, J. F. Pane et. al
* The influence of the Psychology Of programming on a Language Design: Project Status Report, J.F. Pane et. al.

Espero los disfruten!

jueves, 14 de agosto de 2008

Smalltalks 2008 - Registración y CFP

Ya está habilitado en el sitio web de Smalltalks 2008 la opción para registrarse al evento y la de sumitir papers de investigación (dentro de poco estará la opción de presentaciones de industria y workshops).
¡No dejen de anotarse! ¡Este año tenemos que romper el record del año pasado!

viernes, 8 de agosto de 2008

Los IFs no ofrecen información Meta

Hay un comentario de Gabriel (gaboto) en el post de la conferencia de la ECI donde me pide aclarar un comentario que hice en la presentación relacionado a los IFs. El comentario tenía que ver con el hecho de que los IFs no tienen información "meta". Lo voy a tratar de explicar con el ejemplo de la presentación.
En dicho ejemplo, una de los cambios de diseño que mostré fue reemplazar una serie de IFs por objetos que se encargan de "tipificar" un objeto. Al haberlo hecho hay mucha información que se está poniendo en el código que antes no estaba. Ahora para tipificar un objeto no se utiliza una construcción tan genérica como el IF sino una más concreta que se encarga justamente de "tipificar" objetos. En pocas palabras, a partir de ese momento cuando un programador lee el código se dará cuenta que se está tipificando un objeto simplemente por ver qué objeto (clase en este caso) se está usando.
Algo similar sucede con los patrones; cuando se ve un "state" se entiende para qué está, su función, etc. Si en vez de un "state" hubiese un conjunto de IFs o CASEs, habría que leer lo que está escrito, interpretarlo, etc. para llegar a la conclusión de que se está programando un "state" (a menos que exista un comentario que diga eso, pero así y todo, no se puede deducir información automáticamente de un comentario, solo lo puede interpretar un ser humano).
Un IFs, lo único que indica es que se está tomando una decisión, pero no da indicios sobre qué decisión, por qué, etc., para obtener esa información alguien tiene que "interpretar" el IFs, y solo los seres humanos lo pueden hacer (al menos por ahora... :-) ) De la otra manera no solo le resulta directa la interpretación al ser humano sino que también se puede utilizar esa información de manera automática. Por ejemplo, si se quiere ver todas aquellas clases cuyas instancias son tipificadas, se busca las referencias a la clase que implementa esa responsabilidad y listo. Si se quisiese hacer estadísticas sobre la cantidad de tipos que existen, se puede a partir de estas referencias ver la jerarquía de tipos sobre las que trabajan y obtener todas las subclases de la clase raíz de cada jerarquía y obtendríamos dicha información, etc.
En pocos palabra, no es que el IFs no indique nada sobre lo que se está haciendo, sino que al ser tan genérico se pierde información, información que luego debe ser reconstruida por el programador cada vez que lo lee. De la otra manera, al utilizar un objeto más específico existe información que puede ser interpretada más fácilmente y de manera automática. A esto me refiero con información "meta". Estos objetos que reemplazan al IFs no solo hacen lo que tienen que hacer sino que ofrecen información "más allá de lo que hacen", información sobre el código en el cual están siendo utilizados, o sea, meta-información sobre el programa.
Bueno, espero haber logrado explicar mi idea. Cualquier duda chiflen!

martes, 5 de agosto de 2008

La Imagen de Smalltalk

Muchas veces se discute si es bueno que Smalltalk tenga un imagen, es más, recientemente hubo una discusión al respecto en la lista de Squeak-Dev.
El problema que se le achaca a la imagen es que es difícil de "integrar" con el resto del ambiente. La verdad que si hay algo que no me gustaría perder de Smalltalk es el concepto de imagen y es más, me parece que es una característica que todo lenguaje tendrá que incluir en su evolución.
De la misma manera que hace 10 años la gente discutía sobre si era bueno tener un VM o Garbage Collection hasta que salió Java y empezó a verse sus ventajas, me parece que lo mismo pasará con la imagen. Seguramente salga en algunos años algún lenguaje que tenga una imagen y como será un lenguaje nuevo todos usarán porque estará "copado" y de ahí en más no se discutirá sobre la conveniencia o no de tener una imagen.
De hecho, la "imagen" existe en los ambientes de desarrollo actuales pero en una forma más cavernícola. En Eclipse por ejemplo, la "imagen" está compuesta por todos los archivos .java, las configuraciones, etc. Lo que sucede que esa "imagen" no está compuesta por objetos sino por elementos más antiguos como archivos, texto, etc. y que hacen por lo tanto que el ambiente sea más arcaico y menos manipulable.
Para mí la imagen "siempre existió", pero con otras características y con menos capacidades como aún vemos en varios ambientes de desarrollo. Es por eso que creo que la evolución inevitable de todo "lenguaje" debe ir hacia una "imagen" más estilo Smalltalk.
En conclusión, me parece que antes de que la imagen desaparezca, la imagen aparecerá con más fuerza en algunos años.... veremos si me equivoco.

Visitors en la presentación de la ECI

Hay varios que me preguntaron sobre el test de los visitors que mostré en la presentación de la ECI. En otro post de este blog ya había hablado del tema, el link es: http://objectmodels.blogspot.com/2007/10/cmo-asegurar-la-evolucin-de-un-sistema.html

En si, el código del test es el siguiente:

testVisitorsImplementVisitorProtocol

| acceptingVisitorsRoots visitorProtocols visitorImplementors invalidVisitorImplementors |

acceptingVisitorsRoots := MCPAcceptingVisitorRootFinder allAcceptingVisitorRoots.

visitorProtocols := acceptingVisitorsRoots collect: [ :anAcceptingVisitorRoot |
MCPVisitorProtocol for: anAcceptingVisitorRoot ].

visitorImplementors := visitorProtocols
inject: OrderedCollection new
into: [ :implementors :aVisitorProtocol |
implementors addAll: aVisitorProtocol implementors; yourself ].

invalidVisitorImplementors := visitorImplementors reject: [ :aVisitorImplementor |
aVisitorImplementor isValid ].

self assert: invalidVisitorImplementors isEmpty

Instancias de MCPAcceptingVisitorRootFinder se encargan de buscar la raíz de una jerarquía de clases que acepta visitors. Para ello busca las clases que implementan #accept: y dada un jerarquía devuelve la clase que más arriba se encuentre en la misma.
MCPVisitorProtocol modela el protocolo que debe implementar un visitor. Lo deduce a partir de todos los mensajes que se envían en el método #accept: de una jerarquía de clases. Dado un VisitorProtocol se puede obtener todas las clases que lo implementan. Las implementaciones de un protocolo de visitor está modelado con la clase MCPVisitorImplementor que entre otras responsabilidades sabe responder si es una implementación válida de ese visitor.
Bueno, si desean más detalles de la implementación pregunten!

lunes, 4 de agosto de 2008

Presentación de ECI 2008

El viernes di la presentación de técnicas y herramientas que usamos en Mercap en el marco de la ECI. Creo que salió muy bien, por lo menos me fui contento. Lástima no haber tenido más tiempo y haber cometido un par de equivocaciones con la imagen que había que usar (por estar apurado levanté otra imagen...)
Para aquellos que estén interesados, la presentación está disponible acá: http://www.mercapsoftware.com/ECI2008.pdf

viernes, 18 de julio de 2008

The Story of the Ribbon - La UI de Office 2007

Pocas veces vi presentaciones interesantes de gente de Microsoft, pero tengo que decir que esta vale mil veces verla... no se la pierdan, es sobre el UI de Office 2007. El link es http://blogs.msdn.com/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx

martes, 8 de julio de 2008

Lisp cumple 50 años!

y como me gustaría estar en esta conferencia: http://www.franz.com/services/conferences_seminars/lisp_50th-birthday.lhtml

Alan Kay sobre la enseñanza de computación

Un amigo me pasó este link muy interesante al blog de Mark Guzdial, http://www.amazon.com/gp/blog/post/PLNKVUNBWIDAS9YQ
donde critica un nuevo plan de estudios de Ciencias de la Computación e Ingeniería de Software que propone la ACM. Lo interesante de este blog es que Alan Kay opinó sobre esto y la verdad que no tiene desperdicio todo lo que dice. El blog es largo así que si no tienen tiempo les aconsejo solo leer lo que dice Alan Kay.
Alan hace hincapié nuevamente en la importancia de utilizar el método científico para desarrollarnos como personas y sociedades. También refuerza mucho la necesidad de conocer lo que hicieron en el pasado las personas que trabajan en esta profesión porque sino estamos no reinventando la rueda sino "una rueda pinchada". Comenta que en otras disciplinas como física no pueden darse el lujo de no saber que pensó Newton o Einstein, sin embargo en computación hay gente que no conoce que hizo Engelbart. (A mi me pasa cuando doy clases que los alumnos no conoces a Turing, ni que hablar de Church). Esto hace que estemos en una continua infancia, que nunca crezcamos y seamos adultos. Además comenta que se perdió el espíritu de investigación que existía con ARPA/PARC donde se buscaban nuevas soluciones constantemente, ahora todo está más orientado al "resultado inmediato".
También Mark y Alan hablan de un curso especial que está dando Alan Kay el cual desconozco pero voy a buscar información porque parece interesante.

lunes, 7 de julio de 2008

Charla en la ECI 2008

Este año voy a dar una charla en la ECI (Escuela de Ciencias Informáticas) que organiza el Departamento de Computación de la Facultad de Ciencias Exactas. La descripción de la charla la pueden ver en http://www.dc.uba.ar/events/eci/2008/conferencias/mercap
La misma será una charla técnica en la cual mostraremos las herramientas y técnicas que usamos en Mercap para hacerle la vida más fácil y animada al programador.
Espero verlos!

lunes, 30 de junio de 2008

MagLev o Ruby corriendo en GemStone

La gente de GemStone está encontrando la manera de empezar a hacer más conocido su producto.
Miren esta demo de Avi Bryant sobre MagLev, una implementación de Ruby corriendo en la infraestructura de GemStone.
http://www.vimeo.com/1147409
La verdad que es muy buena y está muy bien dada, creo que dieron en la tecla en la presentación

Más sobre TDD

Siempre me costó encontrar un buen ejemplo para enseñar TDD, pero creo que finalmente he encontrado un problema interesante para resolver mientras se enseña esta técnica.
El problema consiste en modelar un árbol genealógico. Es muy interesante porque se puede empezar por resolver el problema de obtener los padres de una persona y luego los abuelos y luego los tatarabuelos. Haciendo esto se encuentra una recursión que puede ser modelada primero con mensajes y luego con objetos, todo utilizando refactorings!.
Luego se puede continuar con encontrar hermanos, primos, tíos, etc. para luego cuando está todo reificado crear composiciones de búsqueda... un lindo ejercicio, este sábado lo utilice en el postgrado de la UCA con un buen resultado (según me parece).

sábado, 14 de junio de 2008

Como hacer TDD

Hace un par de semanas cuando estaba revisando como iban los trabajos prácticos de POO, vi una confusión sobre lo que significa hacer TDD. Muchos grupos habían escritos varios test pero no habían corrido dichos tests. O sea, seguían trabajando de manera clásica C o Java, donde se escribe todo primero y luego se prueba, en vez de trabajar de manera dinámica, a la Smalltalk, donde se escribe y prueba constantemente.
Es interesante ver que cambiar este hábito es uno de los puntos más costosos e interesantes de este curso. Que los alumnos entiendan que la computadora está para "usarla" y no simplemente para escribir texto es muy difícil de lograrlo y es de esas cosas que hasta que no lo hacen no lo entienden.
En fin, hago este comentario para que todos aquellos que hacen TDD, no se olviden que los pasos son:
1) Escribir UN test
2) Hacer que el test funcione
3) Hacer que todos los test corran
4) Hay que mejorar el diseño?
a) Si hay que mejorarlo, hacerlo, refactorizar, etc. Ir a 3.
b) Si el diseño es aceptable, ir a 1

En estos pasos creo que está claro que luego de escribir UN test hay que hacerlo funcionar, no vale escribir varios test y luego hacerlos funcionar a todos juntos.
De vuelta, es importante darse cuenta que haciendo lo último, estamos manteniendo muchas ideas, soluciones, problemas, etc. en nuestra cabeza en vez de descargarlas a la computadora, y recuerden que los seres humanos cuanto más cosas tenemos en la cabeza más nos equivocamos y olvidamos

viernes, 13 de junio de 2008

Smalltalks 2008

Quería comentarles que ya hicimos el anuncio de Smalltalks 2008. Este año será en otra fecha y otro lugar, pero esperamos tener la misma calidad de presentaciones y cantidad de gente y por qué no, mejorarla.
Estamos trabajando para que venga gente "importante" a dar key notes y lo anunciaremos a su debido tiempo. También estamos trabajando para hacer un "coding contest" y que hayan tutoriales interesantes.
El lugar elegido esta año para hacer el congreso es la Universidad Abierta Interamericana que tiene unas instalaciones muy lindas y nos han abierto sus puertas con muy buena predisposición.
El sitio web del congreso este año será http://neuquina.lifia.info.unlp.edu.ar:8001/Smalltalks-2008
Aún estamos trabajando para hacer la inscripción automática y no por mail, etc. así que hay algunas páginas que están bajo construcción.
Espero verlos a todos en el congreso nuevamente!

martes, 10 de junio de 2008

Por qué escribir de manera inversa?

Estos días de "reposo" que tuve que hacer, los aproveché para ver algunos videos de Abelson y Sussman que son realmente muy recomendables.
Ellos hacen mucho hincapié en los mimos principios que usamos nosotros en POO y DAO, es muy interesante ver como piensan en el MIT y como lo hacían hace más de 20 años atrás!
Sin embargo, viendo uno de los ejemplos que mostraban me di cuenta que no siempre uno cumple lo que dice. Por ejemplo, vean este código:


Más allá de que es un poco difícil de entender la sintaxis porque está escrito en Scheme, lo que quiero remarcar es que para entender lo que hace hay que leer de abajo para arriba. La idea es que esta función sume los primeros n fibonaccies que son impares, y para ello utiliza el patrón
map/filter. Se debe leer, como dije, de abajo para arriba:
1) enum-interval 1 n -> crea un intervalo de 1 a n (a)
2) map fib (a) -> mapea los números del intervalo a su fibonacci correspondiente (b)
3) filter odd (b) -> filtra aquellos fibonacci que son pares, o sea, se queda con los impares (c)
4) accumulate cons '() (c) -> Acumula los resultados en una lista usando un lista vacía como valor inicial
Ahora, si estamos abogando por escribir código entendible, que se pueda leer fácilmente, etc. por qué para leer esta función tengo que hacerlo de abajo para arriba en vez de arriba para abajo que es más natural?
Me parece que sería mejor algo así (ahora en Smalltalk):

interval := 1 to: n.
fibonacciNumbers := interval collect: [ :aNumber | aNumber fibonacci ].
oddFibonacciNumbers := interval select: [ :aNumber | aNumber odd ].
^oddFibonacciNumbers

Al hacerlo así, se puede leer de manera natural, de arriba hacia abajo, de izquierda a derecha como van realizándose el computo.
Tiene una desventaja implementativa respecto de la primera versión y es que guarda todos los fibonacci para luego filtrarlo para quedarse con los impares mientras que la versión Scheme si el fibonacci no es impar, no lo guarda. Se podría lograr lo mismo haciendo:


oddFibonacciNumbers := OrderedCollection new.
fibonacciNumbers := 1 to: n do: [ :aNumber | | fibonacci |
fibonacci := aNumber fibonacci.
fibonacci odd ifTrue: [ oddFibonacciNumbers add: fibonacci] ].
^oddFibonacciNumbers

No es tan claro como la versión anterior, por lo que se podría abstraer en algo así:

(1 to: n)
add: [ :aNumber | aNumber fibonacci ]
into: OrderedCollection new while:
[ :aFibonacciNumber | aFibonacciNumber odd ]

De esta manera queda mejor expresada la idea que se quiere implementar.

lunes, 9 de junio de 2008

Ojo con el ojo

Simplemente quería hacer un comentario de tipo personal. El jueves pasado me realizaron un operación de retina del ojo izquierdo... los Wilkinson tenemos un par de problemas genéticos con los ojos... a mi me tocó algo que no es tan grave que se llama pit de papila que es un agujero en la retina. En fin, entró un poco de líquido por ese lugar, separó la retina del nervio óptico y dejé de ver algunos "pixels".
La operación fue muy interesante, pude ver todo lo que pasaba adentro del ojo porque tenía una fibra óptica que iluminaba todo. Tengo la operación grabada así que si alguien está interesado en verla me avisa!! jaja.
En fin, ahora estoy recuperándome, en una especie de reposo donde solo puedo ver con un ojo puesto que el operado está medio "atontado" por unas gotas que me estoy poniendo para que la retina cicatrice bien.
Es increíble el avance que hay en este tipo de operaciones. Me operaron en menos de una hora y salí caminando como si nada, es más, salí muy interesado en toda la operación, seguramente por el estado de "atontamiento" que tenía por el sedante que me dieron... según mi mujer parecía chico con juguete nuevo jaja.
Voy a ver cuanto puedo escribir con un solo ojo durante una semana!!!

VM de Squeak más rápido que VisualWorks

Parece que Eliot Miranda está trabajando en hacer una VM para Squeak muy rápida, basado en todo su conocimiento de la VM de VisualWorks. Según dice en su blog, su intención es que sea más rápida que la de VisualWorks... veremos si lo logra. Su blog está en http://www.mirandabanda.org/cogblog/

martes, 27 de mayo de 2008

Ejemplos de buena implementación

En la materia de POO, uno de los ejercicios que tienen que hacer es implementar un modelo de medidas y otro un autómata finito determinístico y no determinístico. Son ejercicios muy interesantes y que dan buenos ejemplos de problemas de modelado e implementación.
A continuación transcribo alguna de las cosas que les comenté por mail a los alumnos y que me parecen interesantes en general:

1) En el ejercicio de las medidas, la implementación del mensaje #*, que se puede utilizar para hacer cosas como: "diezMetros * 5" o "diezMetros * dosMetros", no utiliza polimorfismo sino un "if" para solucionar el problema de multiplicar por un número o por una medida. Por ejemplo:

Measure>>* aMeasure

^aMeasure class = self class
ifTrue: [ ... multiplicación de medidas, en muchos casos puesto el código acá directamente en vez de factorizarlo en un mensaje ]
ifFalse: [ ... multiplicación por un número ]

Esta solución adolece de varios problemas:
a) Restringe la solución a multiplicar medidas y cualquier otra cosa, asumiendo siempre que la otra cosa va a ser un número, lo cual está implícito y por lo tanto puede generar errores en la evolución del modelo. Para evitar este problema de evolución, una correcta solución sería:

^aMeasure class = self class
ifTrue: [ ... multiplicación de medidas, en muchos casos puesto el código acá directamente en vez de factorizarlo en un mensaje ]
ifFalse: [ (aMeasure isKindOf: Number)
ifTrue: [ ... multiplicación por un numero ]
ifFalse: [ Exception!!! -> El modelo no está preparado para multiplicar por cualquier otra cosa ]

b) La opción anterior, por supuesto que sigue estando distante de una buena solución, por el motivo que comente en el punto a (que restringe la multiplicación a lo que conocemos ahora que se puede multiplicar), pero también porque queda claro si nos fijamos con cuidado que el colaborador externo aMeasure no es un buen nombre, porque si es una medida, cómo puede ser un Number?. Esto tiene mal olor. Es este caso puede ser interpretado como que falta una abstracción que permita "juntar" el concepto de medida y de número en algo más abstracto, que en el caso de VisualWorks se llama ArithmeticValue. Por lo tanto, Measure debería subclasificar ArithmeticValue (igual que Number) y el colaborado externo se debería llamar "anArithmeticValue" en vez de aMeasure

c) Para no restringir la multiplicación a medidas y números, hay que utilizar la técnica que se denomina "double dispacth". La idea de esta técnica es que las decisiones la tomen los objetos enviándose mensajes en vez de los programadores por medio de un "if". La solución correcta para este caso sería:

Measure>>* anArithmeticValue

^anAritmeticValue multiplyMeasure: self

Measure>>multiplyMeasure: aMeasure

"En este caso estoy seguro que aMeasure es instancia de Measure, puesto que el mensaje lo envió una Measure"
^... (multiplicación de medidas)

Number>>multiplyMeasure: aMeasure

"Soy un número y me piden multplicar aMeasure por mi"
^Measure amount: aMeasure amount * self unit: aMeasure unit (o algo así)

Esta solución erradica el if y está preparada para el día de mañana si alguien observa que se puede multiplicar una medida por algo que no sea ni una medida ni un número... algo quizá medio difícil de ver en primera instancia, pero la puerta queda abierta para esa posibilidad (algún loco le gustaría poder multiplicar por un punto por ejemplo. Para el caso de VisualWorks no parece loco hacerlo puesto que Point subclasifica ArithmeticValue como también lo hace Complex)
Fijense que también el código queda automáticamente factorizado y en el caso de querer multiplicar por algo que no tiene sentido, por ejemplo un punto, automáticamente se genera un doesNotUnderstand y no hay que explícitamente manejar ese caso en el código, los objetos se encargan.

2) Otro ejemplo de código que tiene mal olor es este que pongo a continuación y tiene que ver con la creación de una función no determinística de un atómata finito:

funcionNoDeterministica
| dictionary |
dictionary := Dictionary new.
dictionary
add: (Association key: #(1 'a') value: (Set new add:7;add:6 ));
add: (Association key: #(7 'a') value: (Set new add:3 ));
add: (Association key: #(3 'b') value: (Set new add:5 ));
add: (Association key: #(6 'b') value: (Set new add:2));
add: (Association key: #(6 'a') value: (Set new add:4));
add: (Association key: #(4 'b') value: (Set new add:2; add:5)).

^TransitionFunction dictionary: dictionary.

Si lo analizamos un poco, veremos que:
a) Nombre "dictionary" no agrega valor, no representa su rol en el contexto. En esta caso es difícil pensar un mejor nombre y creo que tiene que ver con el problema de usar un diccionario para representar las transiciones, pero esto es solo una suposición.
b) Se utiliza el mensaje #add: en vez de #at:put:
c) No queda claro qué representa la key ni el value. Por qué se usa como key un Array? y el value? Parecería por el código que se espera que el value sea un Set, pero qué termina siendo?... observen bien el código.... termina siendo un número puesto que el mensaje #add: devuelve el colaborador externo, no el receptor del mensaje. Esto demuestra además que los test realizado no son buenos, no cubren todos los casos.
d) No sería más claro tener algo así:

| transitions |

transitions := OrderedCollection new
add: (Transition from: 1 to: 7 by: $a);
add: (Transition from: 1 to: 6 by: $a);
add: (Transition from: 7 to: 3 by: $a);
....
yourself.

^TransitionFunction with: transitions

jueves, 15 de mayo de 2008

Igualdad de Set

Esta semana hubo una discusión muy interesante en la lista de la materia de la UBA de POO sobre el problema de la igualdad de Set. El problema surgió porque un grupo haciendo un TP compararon Sets y les dió false cuando esperaban que el resultado sea true. Por ejemplo, si evaluamos:

(Set with: 1 with: 2) = (Set with: 1 with: 2)

el resultado es false y no true como se esperaría intuitivamente.
Fácilmente se puede deducir que este comportamiento se debe a que el mensaje #= no está redefinido en Set de tal manera que verifique si su contenido es el mismo, sino que usa la implementación otorgada por Object que define la igualdad como identidad, o sea, dos objetos son iguales si son idénticos, lo que significa que ocupan "la misma posición de memoria".
Hago esta aclaración puesto que la identidad de Smalltalk no es lo mismo que la identidad "filosófica". En Smalltalk pueden existir dos o más objetos que representen el mismo ente de la realidad y que por lo tanto cuando se los compare por identidad devuelvan false, sin embargo en la realidad hay un único ente que posee esa identidad. Por ejemplo:

Date today == Date today

Esta colaboración devuelve false, sin embargo el día de hoy (el ente de la realidad) es único e idéntico a si mismo. Es por este motivo que nunca hay que usar el mensaje #== a menos que explícitamente se necesite verificar si dos objetos ocupan la misma posición de memoria, algo que solo sucede en aquellos modelos relacionados con problema computacionales (por ejemplo frameworks mapeo relacionales, modelos de objetos distribuidos, etc.).
Volviendo al tema de la comparación de conjuntos, luego de varios emails de idas y vueltas en la lista (y un par de errores de mi parte), quedó claro que no se puede fácilmente implementar ese comportamiento y por otro lado tampoco es sencillo darle una semántica clara a esta comparación cuando se están utilizando conjuntos definidos por comprensión (aporte de Daniel Altman que quedó plasmado en la tesis que hizo junto a Hernán Tylin).
Uno de los problemas que surge al implementar el #= en Set es que se debe definir si solo se será true para aquellos casos en que se comparen conjuntos. Algo que yo había pensado es que la comparación debería devolver true si las colecciones comparadas tenían los mismos objetos, más allá de como están implementadas, pero la realidad es que no es sencillo implementarlo así y tampoco tiene sentido semánticamente. Por ejemplo:

(Set with: 1 with: 2) = (OrderedCollection with: 1 with: 1 with: 2)

¿Debería dar true o false?. Cualquier decisión que se tome al respecto es arbitraria. Por lo tanto el #= solo debería devolver true si se comparan conjuntos. Esa es la decisión que tomaron los implementadores de Squeak, donde el #= en Set está definido de la siguiente manera:

= aSet
self == aSet ifTrue: [^ true]. "stop recursion"
(aSet isKindOf: Set) ifFalse: [^ false].
self size = aSet size ifFalse: [^ false].
self do: [:each | (aSet includes: each) ifFalse: [^ false]].
^ true

Fijensé que es necesario que aSet sea instancia de Set o de alguna de sus subclasses. Esto restringe la comparación a que solo devolverá true si se comparan conjuntos. Sin embargo tiene la desventaja de no poder implementar un conjunto fuera de la jerarquía de Set y poder compararlo por igual con un Set puesto que siempre dará falso.
Una vez hecha esta salvedad, surge el problema de cómo implementar el #hash en Set, puesto que al haber implementado el #=, tengo que implementar un algoritmo de hash que cumpla con la condición que dos objetos iguales deben tener el mismo hash. Para la implementación de Object, el hash viene dado utilizando un número que se asigna a cada objeto que se crea y que se almacena en su header (fijensé que no se puede usar la posición de memoria puesto que la misma puede cambiar debido al garbage collector).
La implementación de Squeak es la siguiente:

hash

| hash |

hash := self species hash.
self size <= 10 ifTrue: [self do: [:elem | hash := hash bitXor: elem hash]].
^hash bitXor: self size hash

Podemos observar que se realiza un trade-off entre obtener un buen número y performance. Un buen número estaría dado a partir del hash de los objetos que contiene el conjunto, pero recorrer todo un conjunto puede ser time-consuming y por eso se limita a hacerlo solo en el caso de tener 10 o menos elementos.
Por lo tanto, implementar el #= en Set como uno intuye que debería funcionar no es tan sencillo, tiene sus complicaciones y trade-offs.
Una solución que me propuso Nicolás Kicillof, quién está trabajando en Microsoft en USA, es hacer como hacen ellos en su lenguaje de verificación en donde cada vez que se crea un conjunto, se verifica si el mismo no existe y de existir se devuelve el mismo. O sea, hablando mal y pronto, usan los conjuntos como los símbolos de Smalltalk. Esto implica que los conjuntos son inmutables y por ende tienen que tener un buen algoritmo de búsqueda para asegurarse de no tardar mucho cuando tienen que verificar si ya existe el conjunto (lo cual nos lleva nuevamente al hash...)
Otra solución es la que propone Daniel Altman, la cual crea una nueva manera de ver el problema completamente distinto y que me parece sumamente interesante y acertada. Transcribo lo que Daniel escribió en la lista porque no tiene desperdicio:

"[...] un Set en computación sea distinto del de la matemática, es el dinamismo que hay en el mundo de los objetos, cosa que no ocurre en principio en la matemática.
Es decir, un objeto matemático nunca tiene un estado que cambia.
Basta probar que dos conjuntos tienen los mismos elementos para demostrar que son iguales. Qué pasa en Squeak? Los elementos contenidos en un conjunto cambian a lo largo del tiempo.
Acá entra en juego una consideración bastante importante: es lo mismo hablar de conjuntos como simples “contenedores de elementos” (o sea, básicamente una estructura de datos) que hablar de un conjunto como un ente que tiene una semántica propia?
Para mí, los conjuntos interesantes son los segundos, los que tienen semántica. En ese caso un cambio en el ambiente, o en algún objeto cualquiera, pueden hacer que un elemento pertenezca o deje de pertenecer al conjunto. (por ejemplo, imaginen el conjunto de los objetos que responden true al mensaje #foo).
De ahí se desprende que la manera de comprar la igualdad de conjuntos sería comparar su semántica."

Este comentario quedó a mi entender claramente definido con un ejemplo que escribió más adelante en otro mail:

"Ejemplo: tenes el conjunto de las facturas impagas de una empresa por una
lado, y el conjunto de todas las facturas de la empresa por otro. Esos
conjuntos pueden tener los mismos elementos si nadie pagó ninguna factura,
pero son claramente distintos."

Un concepto muy interesante, ¿no les parece?

jueves, 8 de mayo de 2008

Ventajas del código autodocumentado

Este año hay un grupo muy activo en POO lo cual es muy bueno porque preguntan y hacen cosas más allá de lo que comúnmente sucede en esta materia.
Por ejemplo, el otro día en la lista de POO un alumno preguntó como hacer una búsqueda de algún String particular en los métodos. Pareciera que en VisualWorks no hay manera de hacerlo directamente usando las herramientas de desarrollo que ofrece, pero como esto es Smalltalk no cuesta nada escribir un conjunto de colaboraciones para hacerlo. Así se los propuse y, debido a que es un grupo muy interesante, generaron una solución.
La solución que generaron fue:

| resultado aBuscar bloque |

resultado := OrderedCollection new.
aBuscar := (Dialog request: 'Texto a buscar:' initialAnswer: '' windowLabel: 'Buscar' for: nil).
bloque := [:class :selector :aString | | method |
method := class compiledMethodAt: selector.
( method allLiterals anySatisfy: [:lit | lit isString and: [aString match: lit]])
ifTrue: [ resultado add: method definition]
].
Object allSubclasses do: [:class | class selectors do: [:sel | bloque value: class value: sel value: aBuscar ]].

RefactoringBrowser
openListBrowserOn: resultado
label: 'Resultados de búsqueda'
initialSelection: nil

Me parece interesante analizar los errores que posee dicho fragmento de código y como se puede escribir de otra manera para que sea más simple de entender. Como errores podríamos enumerar:
1) No tiene en cuenta el caso de presionar Cancel cuando se pregunta por el string. En dicho caso buscará el String ''
2) No tiene en cuenta aquellas clases que no tienen superclase que no sea Object
3) No busca el string en Object puesto que hace Object allSubclasses en vez de Object withAllSubclasses

Respecto a como está escrito, los nombre de las variables que usaron no están muy buenos. Dichos nombres deberían ser más explicativos, por ejemplo "resultado" no dice mucho sobre el objeto que referencia.
El objeto "bloque", también es un poco confuso, no solo por el nombre sino por como termina participando en las colaboraciones. Me imagino que la intención fue refactorizar el código puesto que de estar escribiendo esto en una clase ese "bloque" estaría representado por un método. Ahora, de ser así, seguramente ese método no se activaría al enviar el mensaje #bloque, lo que demuestra que "bloque" no es un buen nombre para dicho objeto.
Mi propuesta para resolver este problema es:

| methods stringToLookFor |

methods := OrderedCollection new.
stringToLookFor := Dialog request: 'Texto a buscar:' initialAnswer: '' windowLabel: 'Buscar' for: nil.
stringToLookFor isEmpty ifTrue: [^self].

Class rootsOfTheWorld do: [ :aRootClass |
aRootClass withAllSubclasses do: [ :aClass | | methodContainingStringToLookFor |
methodContainingStringToLookFor := aClass methodDictionary values select: [ :aMethod |
aMethod allLiterals anySatisfy: [ :aLiteral | aLiteral isString and: [ stringToLookFor match: aLiteral ]]].
methods addAll: methodContainingStringToLookFor ]].

RefactoringBrowser
openListBrowserOn: (methods collect: [ :aMethod | aMethod definition ])
label: 'Resultados de búsqueda'
initialSelection: nil

Esta solución resuelve los errores del script anterior. Creo que es un poco más fácil de leer, pero el hecho de tener tantos bloques anidados complica bastante su lectura. Para hacer un poco más entendible el script, utilizo la variable methodContainingStringToLookFor para explicar qué hace el conjunto de colaboraciones "aClass methodDictionary values select: ...". De esta manera no es necesario leer toda las colaboraciones para entender qué resulta al evaluarlas.
Sin embargo, la mejor solución sería modelar esto en una clase (olvidarnos del script...), puesto que al hacerlo se podría refactorizar bastante y hacer que el código quede más "autodocumentado".
De hacerlo, obtendríamos algo así:
...>>methodsContaining: aString

^Class rootsOfTheWorld inject: OrderedCollection new into: [ :methods :aRootClass |
methods addAll: (self methodsContaining: aString inAll: aRootClass withAllSubclasses).
methods]

...>>methodsContaining: aString inAll: aCollectionOfClasses

^aCollectionOfClasses inject: OrderedCollection new into: [:methods :aClass |
methods addAll: (self methodsContaining: aString in: aClass) ]

..>>methodsContaining: aString in: aClass

"Lamentablemente VisualWorks no define le mensaje #methods en Behavior, por eso trabajo con el methodDictionary. Esto rompe el encapsulamiento pero es una solución de compromiso para no modificar Behavior"
^aClass methodDictionary values select: [ :aMethod | self does: aMethod includes: aString ]

...>>does: aMethod includes: aString

^aMethod allLiterals anySatisfy: [ :aLiteral | aLiteral isString and: [ aString match: aLiteral ]].

Creo que así queda mucho más lindo y fácil de entender. Fijensé como desaparece la necesidad de definir la variable methodContainingStringToLookFor debido a que fue reemplazada por el envío de un mensaje, #methodsContaining:inAll: , que a mi gusto además transmite mejor la intención de qué están haciendo los objetos.
Fijensé también que los métodos #methodsContaining:in: y #does:includes: podrían haber sido implementados en Behavior y CompiledCode respectivamente, de tal manera que quedasen como #methodsContainingString: e #includesString:
Me parece interesante este caso como ejemplo de cómo se puede mejorar la legibilidad del código y de cómo así y todo en algo tan sencillo pueden haber varios errores.

miércoles, 7 de mayo de 2008

Programming as a Threory Building

Debido al curso que estoy dando en la UCA, volví a reeler el paper de Peter Naur que se llama "Programming as a Theory Building".

Es interesante que cuando uno relee lecturas, le impresionan partes distintas a las lecturas anteriores. Eso me pasó esta vez, donde lo que más me impresionó fue esta parte donde habla del "status" del programador: (si quieren leer todo el artículo, vayan a http://www.zafar.se/bkz/Articles/NaurProgrammingTheory)

"More generally, much current discussion of programming seems to assume that programming is similar to industrial production, the programmer being regarded as a component of that production, a component that has to be controlled by rules of procedure and which can be replaced easily. Another related view is that human beings perform best if they act like machines, by following rules, with a consequent stress on formal modes of expression, which make it possible to formulate certain arguments in terms of rules of formal manipulation. Such views agree well with the notion, seemingly common among persons working with computers, that the human mind works like a computer. At the level of industrial management these views support treating programmers as workers of fairly low responsibility, and only brief education.

On the Theory Building View the primary result of the programming activity is the theory held by the programmers. Since this theory by its very nature is part of the mental possession of each programmer, it follows that the notion of the programmer as an easily replaceable component in the program production activity has to be abandoned. Instead the programmer must be regarded as a responsible developer and manager of the activity in which the computer is a part. In order to fill this position he or she must be given a permanent position, of a status similar to that of other professionals, such as engineers and lawyers, whose active contributions as employers of enterprises rest on their intellectual proficiency.

The raising of the status of programmers suggested by the Theory Building View will have to be supported by a corresponding reorientation of the programmer education. While skills such as the mastery of notations, data representations, and data processes, remain important, the primary emphasis would have to turn in the direction of furthering the understanding and talent for theory formation. To what extent this can be taught at all must remain an open question. The most hopeful approach would be to have the student work on concrete problems under guidance, in an active and constructive environment."

viernes, 2 de mayo de 2008

Ejercicio de Distancia

El otro día hicimos en la facultad, durante POO, un ejercicio que me ha dado muy buenos resultados. El ejercicio consiste en modelar medidas de distancia, o sea un modelo capaz de expresar cosas como "3 metros", "5 centimetros + 10 metros", etc.
Es increíble como un tema que parece tan sencillo genera tantos modelos distintos, tantas ideas distintas sobre como resolverlo y ofrece una gran cantidad de temas para hablar y discutir.
También es interesante porque es un tema que se puede ampliar a medidas de cualquier tipo, como volumen, velocidad, tiempo, riqueza, etc. y por lo tanto como ejercicio siguiente deben hacerlo.
Lo que implemente este año a diferencia de los anteriores, es que para el modelo de medidas genéricas ellos tienen que escribir los test usando TDD, mientras que en el de distancias nosotros les proveemos los test y ellos solo los tienen que hacer andar.
Aún así, dándole los test, los diseños son distintos.... da para pensar no?

viernes, 18 de abril de 2008

Charla de Patrick Chanezon, Google Developer Advocate

Les paso un dato sobre una charla de un tema bastante "hot" actualmente que se dará en la FCEyN de la UBA (Ciudad Universitaria). Copio el mail que me llegó:

El viernes 2 de mayo a las 19 hs, en el Aula Magna del Pabellón I, Patrick Chanezon, Google Developer Advocate, ofrecerá una perspectiva técnica de OpenSocial, el nuevo estándar abierto de Google para redes sociales.
La charla se titula "OpenSocial, a standard programming model for Social Web" y será en inglés.
Resumen:
OpenSocial define un set de APIs que corren en diversos sitios sociales, entre los que se encuentran MySpace, hi5, LinkedIn, Friendster, Vostu, Sonico, Plaxo, Ning, orkut y Salesforce.com. Con OpenSocial, los desarrolladores solo necesitan aprender una API que luego les permitirá crear aplicaciones sociales para utilizar en cualquiera de aquellos
sitios, así llegando a más de 200 millones de usuarios en todo el mundo.
Como está basada en estándares web como HTML y JavaScript, los desarrolladores no necesitan aprender un lenguaje de programación customizado. OpenSocial es una especificación abierta: cualquier sitio que mantenga una red social puede implementarlo y así convertirse en
OpenSocial container.
En estas charlas, explicaremos OpenSocial, sus beneficios y utilidades; mostraremos ejemplos de aplicaciones y containers OpenSocial; y daremos un panorama de las oportunidades que ofrece.
Patrick Chanezon es API Evangelist de Google desde 2005. Actualmente, sus mayores intereses giran en torno a OpenSocial API y software social, Google APIs, REST, SOAP y Ajax, Java, Groove, JavaScript, PHP, Ruby y Python. Anteriormente, se desempeñó en Sun Microsystems, AOL y Netscape como Software Architect, B2B, Technical Evangelist, Tech Lead y Training
Manager en portales, weblogs, RSS y open source.
Más en su blog en http://wordpress.chanezon.com/

lunes, 14 de abril de 2008

Sigo vivo y videito

Hace rato que no escribo nada, principalmente por falta de inspiración y llenar un blog con pavadas no es mi estilo (bah, en realidad todo lo que escribo son pavadas! :-) ), pero no quería dejar que pase mucho tiempo y siga sin escribir algo. Se me pasaron muchas cosas por la cabeza, pero al no haberlas escrito ya se me olvidaron (me estoy volviendo viejo también).
En fin, un par de cosas que recuerdo que quería comentar es que empezó POO nuevamente este año en la UBA con el grupo de gente más grande de los últimos años, están cursando aproximadamente 35 alumnos lo cual es mucho para el promedio de 15 que veníamos teniendo. Parece que los cambios que estuvimos haciendo están dando resultados, la gente ya no le tiene "miedo" al final de la materia, ven que es "cursable" y siguen aprendiendo bastantes cosas nuevas, lo que me pone muy contento.
Por otro lado seguramente esté dando clases en el postgrado de la UCA también, lo cual es un esfuerzo pero vale la pena. Aunque ya dí cursos de postgrado, siempre es bueno tener contacto con gente de mayor experiencia en el campo que los cursos de grado.
También les comento (aunque seguro que lo leyeron en el blog de Andrés) que estamos trabajando para Smalltalks 2008, de apoco, pero va asomando...

En fin, no mucho sobre objetos este post, así que les dejo un video, que para aquellos no acostumbrados a Smalltalk les puede resultar interesante: http://simberon.com/videos/SmalltalkDemo.html

Saludos.

martes, 4 de marzo de 2008

Kent Beck & McCarthy

El otro día vi unos videos interesantes en InfoQ. El primero de Kent Beck, http://www.infoq.com/interviews/beck-implementation-patterns que habla sobre su nuevo libro para Java que se llama "Implementation Patterns". Como lo dice al principio, es una especie de traducción del libro de "Smalltalk Best Patterns Practices" a Java, lo que nos puede hacer notar lo atrasada que está la comunidad Java (10 años?) respecto de lo que Beck comenta en ese libro. Sin embargo me desilusionó bastante cuando nombra que lo más importante para él es descomponer un método en otros. Por más que es importante entender este punto, pareciera que la única unidad de factorización en la que piensa es el método, se olvida de los objetos!! o sea, parece más que está hablando de programación estructurada que de programación con objetos. También se puede ver su disconformidad con la comunidad de patrones, por como perdió su espíritu inicial.
Si buscan un poco en esa página, también verán una entrevista de John McCarthy (Turing Award, creador de Lisp), que también habló en OOPSLA 2007, en este caso sobre el lenguaje que está implementando "Elephant". Lo que más me sorprendió de la entrevista es el palo que le dió a Dijstra respecto de haber "eliminado el GOTO". Había escuchado últimamente que había varios que cuestionaban la eliminación total del GOTO, pero no sabía que McCarthy estaba entre ellos y menos aún, no me esperaba que lo dijera de la manera que lo dice en esa entrevista... en fin, interesante para ver si tienen tiempo.

jueves, 28 de febrero de 2008

Mindstorms y Loo

Estoy leyendo el libro de Papert, Mindstorms, que trata sobre su idea de usar Logo para enseñar matemática.
La verdad que es un libro muy interesante con ideas muy buenas respecto a la educación. Algo que me dí cuenta leyendo este libro es que lo importante no es aprender Logo sino el proceso de aprendizaje por el que se transita, por lo tanto lo más importante es como los docentes lo enseñan, el ambiente en el cual se aprende.
Lo que veo (por ejemplo con mi hija mayor) es que le están enseñando Logo de la manera clásica, sentada en una computadora sin poder pararse y "jugar a ser tortuga" que según Paper es uno de los puntos más importantes de este aprendizaje. Sin embargo luego de hablar con gente del colegio me quedé un poco más tranquilo porque parece que en el resto de las cosas están haciendo las cosas bien.
El otro día me sente con mi hija menor (recién paso a 2 grado) para ver como reaccionaba ella (no lo vió en el colegio todavía) y la verdad me sorprendí por como llegó a la conclusión de que se necesitaba rotar 360/3 cada vez para hacer un triángulo. Lo bueno es que no tuvo que hacer la cuenta, porque no sabe dividir, pero entendió que alcanzaba con decirle a la tortuga que lo haga...

lunes, 25 de febrero de 2008

Más acerca de Dates, Times, etc.

Estoy leyendo el libro "Developing Time-Oriented Database Applications in SQL" que está disponible para bajarlo en http://www.cs.arizona.edu/people/rts/tdbbook.pdf
Realmente está muy interesante ver como encararon el problema del modelado de calendarios en SQL y tiene muchos comentarios históricos interesantes. Este libro, además de "Calendrical Calculations" nos está ayudando (en realidad a Maxi Taborda) a terminar el trabajo que presentó en Smalltalks 2007
El core del libro trata sobre como modelar aplicaciones temporales, algo similar al problema que encara el paper de Time Travel: A Pattern Language for Values That Change de Kent Beck, sin embargo los primeros capítulos son muy interesantes en lo que respecta al modelado del calendario en SQL. Algunas cosas que recuerdo son:
1) SQL solo modela el calendario gregoriano
2) Ninguna implementación, lo que leyeron, ninguna implementación es complient con el estándar de SQL-92 que es aquél que define como tratar este problema
3) El que más se acerca al estándar es DB/2, el menos similar es Oracle! (El libro fue escrito en 1998)
4) El calendario Gregoriano no tiene el año 0, por que cuando su predecesor, el calendario Juliano, fue creado en occidente todavía no se "conocía" el número 0
5) Hay indicios de que Jesús (de haber existido) nació en el año 4 antes de Cristo, o sea, nació antes de haber existido (otro milagro!! -:) )
6) SQL-92 define abstracciones para Date y DateTime, pero no para Year y DayOfMonth
7) Utilizan una metáfora similar a la nuestra de linea de tiempo, sin embargo no es tan claro en lo que respecta a los puntos de distinta granularidad
8) Posee el concepto de medida de tiempo, aunque lo llama Interval, algo que en Ansi Smalltalk se denomina Duration. Para Chalten un intervalo de tiempo está más relacionado con un intervalo matemático, o sea, algo que posee un inicio y final.
9) El calendario Arabe Hjiri es lunar, con años de 12 meses de 28 días. Por lo tanto un evento puede caer en verano un año y en invierno en otro año. Se sincroniza con el Gregoriano cada 33 años (la edad de Jesús cuando murió... )
10) Entendí por fin que es un segundo bisiesto!!! A partir de la creación del UTC, para mantener correctamente sincronizado los equinoccios y debido a que la traslación y rotación de la tierra no son constantes, se re-acomodan los relojes sumando o restando uno o dos segundos a un minuto particular (generalmente el último minuto de un día). Hasta ahora solo se han agregado segundos. Esto significa que ya no es válido pensar que los minutos tienen 60 segundos puesto que los hay de 61 y 62 segundos. Esta irregularidad agregada al de los "day light savings" (o sea, el cambio de hora para ahorrar energía como sucedió en Argentina esta año) hace que la aritmética de este modelo no sea tan simple. Solamente piense que al sumarle 60 segundos a una hora de un día particular (un DateTime) puede ser que se queden en el mismo día y hora... en pocas palabras, las unidades de minuto y sus derivados no son más intercambiables o derivables de los segundos y sus derivados (como milisegundos)... todo un problema. Todo un problema por tratar de mantener un punto de referencia absoluto...

Espero que hayan tenido tiempo para leer este post! :-)