Angel "Java" Lopez : Smalltalk

Smalltalks 2009 en Buenos Aires: Una conferencia pensada para vos

lopez — Thu, 12 Nov 2009 11:02:43 GMT

Ya había publicado el anuncio de este evento en:

Smalltalks 2009 en Buenos Aires

Puede ver más detalle en el sitio del evento:

Smalltalks 2009

Y en mi post, encontrarán enlaces y detalles de algunos de los participantes de esta tercera edición de estas conferencias y reuniones, armadas por la comunidad smalltalkera de Argentina.

Me pareció interesante publicar este email que recibí en una lista, donde la gente organizadora explica más en detalle los eventos, y el interés que tienen para los desarrolladores de software, sean o no del ambiente Smalltalk:

¿Querés conocer cómo se gestó la programación orientada a Objetos? ¿Te gustaría conocer en persona a uno de aquellos locos que revolucionaron la computación en la década del 70 en Xerox Parc junto al Turing Award Alan Kay?, entonces tenés que venir a Smalltalks 2009 a ver la charla de Dan Ingalls sobre "40 Years of Fun with Computers" y la sesión de preguntas y respuestas denominada "A fireside chat with Dan Ingalls"

¿Querés conocer qué es lo último que se está haciendo de investigación en objetos, realmente distinto y novedoso?, entonces tenés que venir a Smalltalks 2009 y ver la presentación de Stephane Ducasse "I have a dream... let's make it came true" y la presentación de Alex Warth "Implementing programming languages for fun and profit with OMeta"

¿Estas interesado en entender un poco más que es la meta-programación y para que sirve? ¿Querés entender qué significa que un ambiente sea Meta-Circular? ¿No te cierra la herencia múltiple, te parece que las interfaces de Java o .Net se quedan cortas, tenés dudas sobre los mix-ins y sentís que debe haber una mejor manera para compartir código?, entonces tenés que venir a Smalltalks 2009 y ver las charlas de "Glamour" y "Helvetia" de Jorge Ressia, "Mejorando las herramientas de desarrollo de Smalltalk" de Diego Geffner y "Traits at Work" de Stephane Ducasse.

¿Alguna vez te preguntaste cómo funciona una base de objetos, qué diferencias tienen con una base de datos relacional, son más rápidas, son más lentas?... no quiero sonar repetitivo pero no puedo evitarlo, ¡¡¡tenés que venir a Smalltalks 2009!!! hay una charla dada por James Foster denominada "Introduction to GemStone" y un tutorial de un día enteramente dedicado a este tópico, ¡no te lo podés perder!

¿Alguna vez te preguntaste si es posible manejar hardware en tiempo real con objetos y con un lenguaje dinámico? ... hmmm... entonces no te queda otra que venir a Smalltalks 2009 y ver la charla de Gonzalo Zabala sobre "Physical EToys" y la de Andrés Otaduy sobre "Sistema Rul@"

¿Tenés dudas sobre si es posible diseñar y escribir con objetos buenos algoritmos genéticos o modelos matemáticos?, si lo tuyo va por ese lado, entonces tenés que venir a Smalltalks 2009 y ver la chala de Maximiliano Tabacman sobre "Genetic Algorithm Framework" y la de Leandro Caniglia sobre "Homological Algebra in Smalltalks"

¿Estás interesado en conocer los detalles de implementación de una Virtual Machine de objetos o saber qué tan seguras o inseguras son? jeje, ¡¡también tenemos dos charlas para vos!!. "Virtual Machine, Invisible Machine" de Andrés Valloud (programador de la VM más rápida de Smalltalk) y "Security on JIT VMs" de Gerardo Richarte (un experto en seguridad... ¿o inseguridad?)

¿Lo tuyo va por asegurar la calidad de los sistemas? ¿Te pega todo lo ágil, TDD, etc?... no quiero sonar repetitivo pero me es imposible... ¡tenés que venir a Smalltalks 2009! y ver las charlas de Tim Mackinnon sobre "Agile Planning" y "Expressive Testing" y la de Nicolas Chillo y Gabriel Burnstein sobre "Mutation Testing".

¿Estás cansado de tener que subir y bajar el server cada vez que modificas tu aplicación web, pensás que deben haber maneras más sencillas de hacerlo? ¿Estás cansado de recompilar tu aplicación Java u ObjectiveC para poder ver un pequeño cambio que hiciste en tu aplicación de iPhone?, no queda otra que vengas a Smalltalks 2009 y veas las charlas de Germán Arduino sobre "SWT", la de Santiago Robles y Lautaro Fernandez sobre "Meteorid: Un MVC real para la Web" y la de Esteban Lorenzano sobre "Smalltalk in the pocket: Building applications for the iPhone"

O por el contrario, ¿no te gustan la charlas, te aburre esto de escuchar hablar gente todo el día, lo tuyo va por la acción, por construir cosas en serio que aporten a la comunidad, por codear, y no me refiero a pegar codazos :-)? o por ahí siempre escuchaste de Smalltalk pero nunca tuviste el tiempo o la ayuda para meter las manos en la masa? hmm, que se yo, podés darte una vuelta el sábado por Smalltalks 2009 y participar del Pharo Sprint!, una sesión de programación de todo un día que sirve para mejorar y ampliar Pharo, un Smalltalk open-source.

¿Siempre escuchaste o creíste que los lenguajes dinámicos no sirven para desarrollar aplicaciones grandes, o que Smalltalk sólo se usa en la universidad para enseñar? Entonces te conviene venir a Smalltalks 2009 y ver "XTrade - Risk and Yield Analisis" de Maximiliano Tabacman, "Expecco" de Felix Madrir e "iBizLog" de Jose Bretti.

¿Tu especialidad es el User Interface, gráficos 3D, etc.?... también tenemos algo para vos como "Un ambiente visual para desarrollar software" de Adian Soma, "Cuis and Morphic 3" de Juan Vuletich, "Desarrollo de un engine 3D: Experiencias de un neófito" de Andrés Fortier y "#{Open.Source.Graphics} bindTo: {Cincom.Smalltalk}" de Travis Griggs

¿Te hace falta un iPod? ¿Querés regalarle una cámara digital a tu novia/o, o a tu vieja?... es fácil, anotate en el concurso de programación de Smalltalks, te vas a divertir haciéndolo... y si no lograste ganar nada, no llegaste a hacerlo, podés escuchar a Carlos Ferro, creador del concurso explicando cómo fue desarrollado el mismo en la charla de "Smalltalks 2009 Coding Contest"

Y si sos profesor de programación orientada a objetos y querés obtener información, material de enseñanza y compartir tu dudas y experiencias con otros profesores, tenés que venir a Smalltalks 2009 y ver la charla "Enseñanza de programación orientada a objetos con Smalltalk y prácticas ágiles" de Nicolás Paez o pasar unos minutos con Stephane Ducasse quién compartirá con nosotros todo el material que usan en Suiza y Francia para enseñar objetos.

¿Te cansaste de leer este mail tan largo? ¿te divertiste leyéndolo? ¿querés formar parte de un congreso hecho por programadores para programadores que ya lleva más de 300 inscriptos, divirtiéndote y aprendiendo en el camino? jeje, ¡¡tenés que venir a Smalltalks 2009!!

No dejes de anotarte gratis en www.fast.org.ar

Es del jueves 19 al sábado 21 de Noviembre de este año. Podes ver el detalle de las charlas en la sección "Charlas" o "Talks" de la página web, seguro la vas a pasar bien.

Comite Organizador de Smalltalks 2009

Cualquier duda manda un mail a info@fast.org.ar

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Smalltalks 2009 en Buenos Aires

lopez — Sun, 01 Nov 2009 14:41:03 GMT

La comunidad Smalltalk de Argentina ha vuelto a tener actividad en estos últimos años. Ejemplo reciente fue su activa participación en el ESUG: 2009 International Smalltalk Conference. Y como prueba están las dos ediciones de las conferencias Smalltalks. Se viene la tercera edición:

Smalltalks 2009

Se realizará del jueves 19 al sábado 21 de Noviembre, en la Facultad de Ciencias Exactas y Naturales de la Universidad de Buenos Aires. Tienen que visitar el enlace e inscribirse. Hay invitados especiales, a destacar (copiado “sin vergüenza” :-) desde esa página):

Dan Ingalls

Is a pioneer of object-oriented computer programming and the principal architect, designer and implementor of five generations of Smalltalk environments. He designed the bytecoded virtual machine that made Smalltalk practical in 1976. He also invented Bit blit, the general-purpose graphical operation that underlies most bitmap graphics systems today, and pop-up menus. He designed the generalizations of BitBlt to arbitrary color depth, with built-in scaling, rotation, and anti-aliasing. His major contributions to the Squeak system include the original concept of a Smalltalk written in itself and made portable and efficient by a Smalltalk-to-C translator. Read more

¿Qué podría agregar a Dan Ingalls? Vean su trabajo de investigación reciente en Sun, por ejemplo, el Web Browser as an Application Platform: The Lively Kernel Experience. Pueden seguirlo en Twitter como @daningalls pero no escribe mucho. Aunque no relacionado tanto con Smalltalks, no puedo dejar pasar el video sobre Lively Kernel:

(Please visit the site to view this media)

Stephane Ducasse

Since September 2007, He is research director at INRIA Lille leading the RMoD Team. He was the leader of the RECAST Project. He was co-responsible of the version 3.9 of Squeak the open-source Smalltalk developed by the team of A. Kay (Turing award 2003). He is the president of ESUG. He is developing Moose an open-source reengineering platform. He is co-responsible of Pharo an open-source Smalltalk.

Read more

Alex Warth

Alessandro Warth is a computer scientist at the Viewpoints Research Institute, where he is working on the "Steps Toward the Reinvention of Programming" project. His current research interests include tools for rapid language prototyping, and improving the modularity of dynamic languages.

Pueden visitar la página del bueno de Alessandro y seguirlo en Twitter como @alexwarth.

Tim Mackinnon

Tim has been programming with objects for 15 years, however it was when he heard Kent Beck describe Extreme Programming at OOPSLA 98 and again at OT99 that he found a process that balances quality, delivery and happiness. Tim was a member of the team that created UML Modeler for VisualAge Smalltalk, he has also worked at Dashboards Software where he pioneered their use of Extreme Programming. He then built up the XP team at Connextra and was responsible for techniques such as Mock Objects and Heartbeat retrospectives. He is now a senior developer at ThoughtWorks where he is mentoring teams on XP and Retrospectives.

No escribe mucho, pero puede leer su blog Pintside Thoughts.

James Foster

As a junior-high student in 1971, James discovered the local university's computer lab and learned Basic, Fortran, and assembly. After trying other careers (commercial aviation and law), he returned to computer programming and was introduced to OOP on the Macintosh in the 1980s. Since then James has worked on large systems (primarily in healthcare) and introduced agile practices to the teams he has lead. James Foster is on the Smalltalk Engineering Team at GemStone Systems, Inc. and is an evangelist for the Seaside web framework.

Pueden seguir su blog Programming Gems (on Gem Stone) James’s comments on programming GemStone/S, Seaside and Smalltalk.

Y por supuesto, gran parte de los smalltalkers de Argentina (algunos esparcidos por el mundo, otros trabajando en empresas locales, otros en emprendimientos personales) asistirán al evento. Hace dos años escribí sobre la actividad de desarrollo y empresas: Creando con Smalltalk en Argentina.

Más información sobre el evento en Smalltalks 2009 Squeak News

Para los interesados en la actividad Smalltalk en español, y en especial en Argentina, ver:

Fundación Argentina de Smalltalk (Sitio soportado por plataforma GLASS (Gemstone/Linux/Apache/Squeak/Seaside)).
Club Smalltalk (vean ahí la participación argentina en la ESUG 2009)

y participen de la lista:

http://groups.google.com/group/clubsmalltalk

Mi colección de enlaces:

http://delicious.com/ajlopez/smalltalk
http://delicious.com/ajlopez/squeak
http://delicious.com/ajlopez/seaside

Me hubiera gustado participar (por ejemplo, presentando lo que estoy haciendo como máquina virtual en .NET, o revivir algo de lo que hice tratando de emular a Piumarta), pero en estos días estoy bastante concentrado, en muchos cursos, poca programación, luchando con el “Efecto Coto” (si ni siquiera tendré Semana Sabática este semestre… snif… :-).

(Nota adicional: el por qué de tantos enlaces en cada post mío ;-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Explorando objetos con Smalltalk

lopez — Thu, 24 Sep 2009 09:33:50 GMT

Estoy siguiendo a @jarober (James A. Robertson) en Twitter. El es el Cincom Smalltalk Product Evangelist. Postea enlaces, recursos y novedades sobre Smalltalk, en particular sobre los productos Cincom. Escribe un blog:

http://www.cincomsmalltalk.com/blog/View.ssp

que corre sobre Smalltalk. Si visitan ese blog, encontrarán varios posts con videas sobre Smalltalk. Hace poco, Robertson publicó:

Smalltalk Daily: Exploring Objects

Este es el video:

(Please visit the site to view this media)

Robertson escribe:

Many times, you want to do something, know that it can be done - but just aren't sure how to construct the code to do it. If you have an object, you can usually solve that problem by drilling into it with the inspector and looking at it. Today we learn how to programmatically change workspace page text by drilling into a workspace.

Es refrescante ver este tipo de interacción con objetos, tan “a la Smalltalk”.

Debo reanudar mi trabajo en mi Smalltalk VM (intérprete) AjTalk, pueden leer

AjTalk, un intérprete tipo Smalltalk

Le tendría que agregar soporte visual. Mi idea, como en otros intérpretes que estoy escribiendo, es interactuar con el framework de base, en este caso, .NET con su CLR. De esta forma, puedo sacar provecho de todo lo que está armado en ese framework. En estos días, todo lenguaje debería tomar ventaja de un framework de clases ya armado: .NET y Java son las opciones obvias a tomar (ver Clojure como un ejemplo “moderno” de esta estrategia) (o AjSharp… :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Popularidad de Lenguajes de Programación

lopez — Wed, 08 Jul 2009 09:50:06 GMT

Me temo que AjLisp y AjBasic lo usamos yo y nadie más… snif… :-). Pero hay lenguajes más populares que esos. Ya es clásica la lista de TIOBE Software:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

donde aparece Java como el lenguaje más popular, lo que no me asombra. Pero sí me llama la atención la popularidad de C y C++, que deben tener su gran uso en el ambiente Unix, Linux, y otros. Como cuarto, encuentro hoy, Julio de 2009, a PHP, que lo entiendo: la mayor parte del código de sitios dinámicos está en PHP, lejos quedaron los años del predominio del venerable Perl. Y recién en sexto y séptimo lugar, está Visual Basic (parece que agrupan el de .NET y el clásico), y C#. Vean que al final de la lista, aparecen lenguajes con mínimos porcentajes, pero aparecen: RPG, Pascal, Abap, Lisp/Scheme. Más abajo, en la misma página encontraran la lista de posición 21 a 50, donde aparecen COBOL, Objective-C, Fortran, Logo, Prolog, Ada (todavía anda por ahí? :-), Scala, Erlang…. y esta es la lista de 51 a 100:

ABC, AD, Algol, Alpha, Applescript, Beta, Boo, C shell, cg, Clean, Cobra, cT, Curl, Dylan, Eiffel, Euphoria, Factor, Fan, Icon, IDL, Inform, Io, Lingo, MAD, Magic, Maple, Mathematica, MAX/MSP, MOO, MUMPS, Natural, Oberon, Occam, Oz, PL/I, Postscript, PowerBuilder, Progress, Q, R, Revolution, REXX, S-lang, SIGNAL, SPSS, SuperCollider, VBScript, Verilog, VHDL, XSLT

Notable lista, recomendaría tantos lenguajes de esa lista, simplemente para aprender nuevas formas de programar (notable que aparezca todavía MUMPS, REXX, tendría que ver con más detalle a Io). Esta lista de popularidad se basa en el examen de búsquedas en Google, hace un tiempo pasaron a agregar MSN y Yahoo.

Pero en estos días, encontré otra página:

http://langpop.com/

con información de ranking de popularidad, pero con agrupadas con distintas fuentes, como Yahoo Search, search en Google Code, Freshmeat, Craiglist, Amazon.

En lo que veo hoy ahí, julio de 2009, según Yahoo Search C es más popular que Java. Pero para Craiglist, primero PHP, segundo SQL (!!!), en Amazon ganan C, C++ y C#, por encima de Java. Y así, noto dispersión de los resultados, dependiendo de la fuente.

La popularidad de un lenguaje importa. No tanto para entender el lenguaje (muchos lenguajes “boutique” tienen interesantes conceptos, a estudiar con detalle), sino para tener una idea de qué tecnología ha sido adoptada por la comunidad, pero habría que ver más allá: por qué la eligieron, y en qué tipo de proyectos. Dudo que haya muchas aplicaciones desktop, en PHP.

Resumen: gran cantidad de lenguajes, hay lenguajes viejos, desde COBOL y Smalltalk, y más “nuevos” como Boo, Ruby, Python. Y `cuatros grandes grupos: Java, C/C++, lenguajes .NET (VB.NET, C#), PHP, como claros grupos líderes.

Pienso que, como desarrolladores de software, debemos tener contacto con esos cuatro grupos, y además, con alguno de los “otros”, para aprender otras ideas y formas de programar.

No me enojo si intentan ver AjLisp o AjBasic… :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Presentando AjSoda

lopez — Mon, 26 Jan 2009 08:46:29 GMT

Hace un año, escribí un post, comentando el trabajo de Ian Piumarta work:

Self-sustaining sysmtes, Cola, Pepsi y Mate

Proponía que una implementación de las ideas Ian Piumarta y Warth, era posible en .NET o en Java. En vez de usar C como lenguaje base, se podría implementar todo sobre un lenguaje con máquina virtual, con un framework rico de clases de base, y con un garbage collector automático. Para mí, era una interesante idea, que merecía algo de atención.

Para entender las ideas ideas de Piumarta y Warth, lean lo que describieron sobre una implementación mínima en:

http://piumarta.com/pepsi/objmodel2.pdf
http://piumarta.com/pepsi/objmodel.pdf

Encontrarán el código de una implementación en C, en esos papers. Un diagrama aclaratorio:

(tomado deOpen Extensible Dynamic Programming Systems Dls )

Esta semana pasada, puse manos a la obra, y estuve trabajando en una implementación en C# de esas ideas. Publiqué mi código en my Proyecto Google Code AjCodeKatas, dentro de:

http://code.google.com/p/ajcodekatas/source/browse#svn/trunk/AjSoda

La solución tiene cuatro proyectos (dos librerías de clases, y otros dos que son sus respectivos tests). El proyecto principal es el AjSoda:

Un diagrama de las interfaces principales:

IObject es la interfaz que escribí para representar un objeto genérico. Tiene un "payload", que es un arreglo de referencias a objectos .NET arbitrarios.

Una alternativa que consideré, era apuntar solamente a IObjects. Pero quiero tener la capacidad de apuntar y manipular directamente objetos .NET (u objetos Java, si lo reimplemento en ese lenguaje). La alternativa hubiera sido apuntar solo a IObjects, e implementar un digamos DotNetWrapper : IObject que encapsulara los accesos a un objeto .NET (algo así está armado en el AjBasic).

El método más importante en IObject es Send. Usando este método, podemos enviar un mensaje (selector y argumentos) a cualquier instancia de IObject.

IBehavior es mi implementación de lo que Piumarta y Warth llaman una vtable (me recuerda a las tablas de métodos en viejas implementaciones de C++). Es un objeto que contiene una lista por nombre de métodos que pueden atender los mensajes que se envía a un IObject.

Cada IObject tiene una propiedad Behavior que apunta a un IObject. Podría haber elegido apuntar a un IBehavior, pero de esta manera, el Behavior de un objeto puede ser reemplazado por cualquier otro objeto que entienda un mensaje con selector #lookup:.

No necesité hasta ahora, implementar el concepto de Closure, como lo describen Piumarta y Warth en su paper. Usando closures, ellos implementan slots a la Javascript o Self. Pero en los experimentos que hice, no necesité aún implementar eso.

Las clases principales de implementación son:

Cada BaseObject implementa un IObject, manteniendo un arreglo interno de objetos como "payload" del objeto:

    public class BaseObject : IObject
    {
        private object[] values;

        public BaseObject()
        {
        }

        public BaseObject(int size)
        {
            this.values = new object[size];
        }

        public int Size
        {
            get
            {
                if (this.values == null)
                {
                    return 0;
                }

                return this.values.Length;
            }
        }

        public IObject Behavior { get; set; }

(Noten que la propiedad Behavior es un IObject, por las razones que expliqué antes).

El método más interesante es el Send:

        public virtual object Send(string selector, params object[] arguments)
        {
            if (selector == null)
            {
                throw new ArgumentNullException("selector");
            }

            if (this.Behavior == null)
            {
                throw new InvalidOperationException("No behavior in object");
            }

            IMethod method = (IMethod) this.Behavior.Send("lookup:", selector);

            if (method == null)
            {
                throw new InvalidOperationException(string.Format(CultureInfo.InvariantCulture, "Unknown message '{0}'", selector));
            }

            return method.Execute(this, arguments);
        }

No uso directamente this.Behavior.Lookup para obtener el IMethod asociado a un selector. En cambio, uso directamente el método Send para enviar un mensaje al object apuntado por Behavior. De esta forma, obj.Behavior puede ser dirigido a cualquier objeto IObject que quiera implementar la lógica de lookup de un método por selector. Esta decisión tiene impacto en el rendimiento, pero permite explorar nuevas estrategias de obtención de métodos. Pueden leer en los papers mencionados, cómo implementan herencia múltiple y Traits, usando esta capacidad de redefición de lookup.

AjPepsi

En el código encontraran un proyecto adicional, AjPepsi, donde implementé un parser, y intérprete de bytecodes, de un lenguaje parecido al que usaron language Piumarta/Warth como prueba de concepto en sus escritos. Acepta código como:


Object new [^self class basicNew initialize]
Object initialize []

List : Object(head tail)

List head [^head]
List tail [^tail]
List head: newHead [head := newHead]
List tail: newTail [tail := newTail]

list1 := [^List new]
list2 := [^List new]

[list1 head: 'Hello']
[list2 head: 'World']
[list1 tail: list2]

Object y List son prototipos. Dejaré una explicación más detallada de este lenguaje y su implementación para un futuro post. AjPepsi aún está en desarrollo; probablemente, refactorearé gran parte del núcleo de la implementación. Tomé el código de AjTalk como base, pero no estoy seguro de haber tomado la decisión correcta: AjPepsi es muy orientado a prototipos, y basado en AjSoda, así que tuve que trabajar bastante para llevarlo a estas ideas.

Una gran "feature" pendiente: generar código C# a partir del estado de la máquina virtual (clases, métodos e instancias). Vean en el sitio de Piumarta cómo implementó un compilador de su propio lenguaje en C, y que genera en ese lenguaje el código de su propio intérprete. De ahí la idea de "lenguajes auto sustentables".

Los tests están en verde:

El "code coverage" es bueno:

Hay algún "code smell" para refactorear. Un ejemplo clásico: el gran switch con toneladas de código en el intérprete de byte code. Pero la mayoría de ese código oloroso está en el proyecto AjPepsi. AjSoda está tomando forma, yendo hacia una versión estable. Me tomó sólo 4 horas escribir el código de AjSoda, pero estoy gastando muchas horas escribiendo AjPepsi (10 horas hasta ahora).

Como de costumbre, ¡me divertí escribiendo este código!

Más enlaces sobre las ideas de Piumarta/Warth:

http://lambda-the-ultimate.org/node/2483
http://piumarta.com/
http://piumarta.com/pepsi/pepsi.html
http://piumarta.com/software/cola/

Comentarios, sugerencias, bienvenidos.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Superando los límites de la Orientación a Objetos (Parte 9)

lopez — Sat, 27 Dec 2008 17:23:00 GMT

Esta es la última entrega de la charla de la charla de Alejandro Reimondo de Smalltalking, dictada hace unas semanas en la Universidad Tecnológica Nacional, sede Buenos Aires. Como antes, transcribo no textualmente las palabras de Alejandro en cursiva.

En Smalltalking, promovemos la idea de ambiente de objetos. Un ambiente no es su contenido, sino que es una trayectoria en el tiempo, de algo que vemos cambiar, y somos parte de ese cambio, pero ningún elemento que está dentro del sistema, tiene por qué subsistir en el tiempo. Lo que está fijo aca es la identidad del sistema, aunque cambien todas sus partes.

Es parte del sistemismo. Tenemos como ejemplo una persona, aunque cambien sus células, la seguimos considerando la misma persona. Como mencioné en otro post, es parte del problema de la identidad, planteado desde Leibniz, pero aclarado en gran parte con el sistemismo.

¿Que es Smalltalk en esa definición? Es algo en trayectoria en el tiempo, y cada persona tiene su Smalltalk, no hay un Smalltalk, hay un Smalltalk por cada persona. Y Smalltalk bajó esa idea de ambiente, es el de cada uno. El contenido no lo ves. Cada Smalltalk es un objeto.

En Smalltalking, no hablamos del lenguaje, o del contenido, o de la IDE, aunque hay smalltalkers que dicen que es eso. Cada uno tiene su trayectoria, y va cambiando lo que es ST para sí mismo.

No es algo que termina en una propuesta de arquitectura, esto es algo que está aceptado que todo cambie, y lo que se preserva es la identidad, mientras uno lo esté usando. Cuando falte uno mismo, para nosotros no es un ambiente.

El ambiente es la trayectoria de ese sistema abierto. Es abierto, por sus contenidos, porque puede tener nuevos contenidos, y abierto en el tiempo.

En la práctica, los contenidos de otras alternativas, son más fijos. Ruby, Python, son alternativas que están ancladas en esa caracteristica de Smalltalk, y promovidas para tener difusión.

Yo veo que hay algo más en esos lenguajes y otras tecnologías. Hay una comunidad. Eso es lo que hace que una tecnología o lenguaje tenga más sinergia. No es sólo uno el que programa o diseña. Igual hay que meditar sobre otras propuestas, y no tomar todo lo que es aceptado por una comunidad como verdad absoluta.

Es entender que Smalltak es un soporte para un cambio reiterado, pero es en sí, una trayectoria, no es una definición de un lenguaje o contenido, no son las clases o los frameworks lo que hacen al Smalltalk, sino que pueden cambiar, no es la maquina virtual, que tambien puede cambiar.

Yo veo que el soporte del cambio somos nosotros mismos y la comunidad. Tal vez por eso, no me impresiona esta visión del cambio que plante Alejandro. Lo importante es hacer, y también pensar y meditar sobre lo que hacemos, las herramientas que usamos y cómo las usamos.

Nosotros en Smalltalking, sólo se nos ha acercado smalltalkers.

Y yo diría que sólo algunos.

Se plantea: definímelo bien lo de ambiente. Y lo mejor, es no definirlo, sino uno entra dentro del método, lo estamos definiendo, y lo estamos cerrando.

No veo que una definición tenga que ser algo cerrado. Justamente, la definición lo que aclara es el camino para la comprensión, dentro de un diálogo. Ese miedo o rechazo a la definición, no lo veo justificado. Se confunde definición con definición cerrada. Ninguna definición en matemáticas congeló a las matemáticas. Un ejemplo en filosofía en

Sócrates y los nombres

Lo que es interesante, es lo que pasa. Cada vez que uno plantea esto, se pregunta, ¿qué estas planteando?

Hay otras formas de plantear lo mismo, como un soporte para un espíritu creativo, como una herramienta para inventar el futuro, como Alice, Squeak, en donde la propuesta es la mejor manera de predecir el futuro es inventándolo.

Muy emocionante plantearlo de esa manera, pero es una manera de garantizarnos un solo futuro. Y todos convergemos a esa idea.

Cada persona tiene distintos caminos, son divergentes, y las realidades son divergentes.

Hoy hay avances concretos en hacer desaparecer la maquina virtual; no ha ocurrido propuestas donde todo está descripto en objetos. En una maquina virtual, no podemos cambiar la maquina virtual mientras está corriendo. Pero en realidad, todo deberia cambiar. Es lo que se llama hoy sistemas sustentables, hoy tiene ese nombre, ST siempre fue asi, sustentabilidad de sistemas, S3.

Algo más sobre eso en mi post

Self-sustaining Systems, Cola, Pepsi, Coke y Mate - Angel Java Lopez

Les recomiendo el workshop de Postdam en alemania, es muy curioso las cosas que se plantean, tienen que ver con eso, que todo son objetos y todo puede cambiarse, la máquina virtual y su semántica no es el ambiente, esa idea no es necesaria, todo puede cambiar.

Alejandro menciona la reunión de

Self-sustaining Systems 2008 (HPI)

La idea es que los propios lenguajes puedan tener la suficiente expresión para cambiar su propia semática.

Es muy comun, preguntar, ¿cuál es el mejor Smalltalk? El mío. Se refieren al dialecto que usan. En realidad, es el mío, el que uso.

La comunidad es una formulación, como la de cardumen, y pone o seduce, de que es algo que es positivo, que cuando más instancias de uso de la herramienta hay, es mejor para la herramienta. Hay casos en que no es así, como el caso de Smalltalk que lo usan pocos, pero pervive.

No estoy negando el valor de idea de comunidad, lo que digo, es que para cosas de propagación vertical (padre a hijo) de Smalltalk, no sé si tiene valor.

Cualquiera puede aprender a programar en el "lenguaje" Smalltalk.

Leonardo, un asistente, pregunta: me gustaria que aclares cuando se considera programar en ST.

Donde esta definido una formula, una arquitectura, uno puede plantear un tiempo para aprenderla. Cuando todo puede cambiar, no. Hasta uno cambia y produce cambios en el camino.

Smalltalk como trayectoria, nos hace poner el foco en la actividad en lo que hacemos, mas que en el producto.

Aca tenemos oportunidades, por lo cerca de estamos con las catástrofes, en personas de otras latitudes no es tan común entender lo que hablamos.

Por acá tampoco. Acá se acabó el tiempo. Fue una lástima, porque quedaron temas para tratar. Pueden ver alguna información más en el sitio de Smalltalking. Pero sería interesante que Alejandro pasara en limpio las ideas finales a las que quería llegar. El piensa, por lo que entiendo, que el tema de lenguajes sustentables es importante, y que podemos hacer algo desde Argentina. Veremos cómo se desarrollan esas ideas, en los próximos años de Smalltalking.

Post relacionados

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Superando los límites de la Orientación a Objetos (Parte 8)

lopez — Sun, 21 Dec 2008 19:13:59 GMT

Sigo en esta entrega, transcribiendo y comentando la charla de Alejandro Reimondo de Smalltalking, dictada hace unas semanas en la Universidad Tecnológica Nacional, sede Buenos Aires. Pongo la transcripción, no textual, en cursiva.

Una cosa es decir "soy observador, y no me quiero comprometer, soy un orientado". Eso paso con la orientación a objetos.

Hay una POO, DOO, LOO, y hay con objetos. No hay libros donde se hable de eso. Todos tienen la O en el medio, de "Orientado", no se habla de "Programación con Objetos", sino de "Programación Orientada a Objeto".

Abundan la gente que habla de lo que funciona, pero no te dicen lo que no funciona.

En cambio reiterado, también se puede usar Smalltalk, y ahí se ve a Smalltalk como plataforma, como un buen IDE, ese cambio reiterado en un lugar donde todo se puede cambiar, el todo es un objeto me permite seguir proyectando y hacerlo crecer. Y genera en muchos smalltalkers una actitud de fanatismo. El fanático es el que ve distintas alternativas, elige una, y esa la defiende a muerte. Es una etapa común en los smalltalkers, una etapa de fanatismo. Y a veces, en los demás, es percibido como no entendible.

Y lo digo así, porque yo he pasado esa etapa, y ya no soy fanático, ¿por qué? Porque no veo alternativas ... ;-) ... no hay herramientas comerciales que permitan trabajar de esta manera.

Se refiere a programar con objetos.

¿Y por qué? ¿Me pongo a escribir otra cosa? Uno ve que tratan de salir otras cosas, que se parecen a Smalltalk, y luego no lo son, ¿por qué? No entiendo. Hay muchos orientados a objetos, hay pocos ambientes de objetos, y uno es Smalltalk, ¿por qué va a haber otro? Porque siempre lo podemos cambiar.

Lo que quiere decir, es que Smalltalk es cambiable, y de ahí, que no hace falta otra tecnología, en principio.

Ha habido otras cositas tan seductoras como Smalltalk pero no han logrado instalarse.

Algunos usan Smalltalk como sistema cerrado, y valoran Smalltalk con el concepto de imagen. Dicen entonces que Smalltalk es una caja que contiene objetos.

Acá Alejandro mostró un programa en 3 dimensiones, con un pez en una pecera, programado para nadar y reaccionar de forma simple.

No hablamos entre diferencia entre clase y especie. Este pez tiene una colección de pensamientos que puede tener basado en su especie. Este pez es muy estúpido, que sabe ir para hacia adelante, si ve a alguien de su misma especie, va a para ese lado. Cuando esta solo en la pecera, se choca contra todos los bordes. El sistema es pobre, es estúpido.

Si quiero cambiar el sistema, ¿qué puedo hacer? Ir a programar nuevo comportamiento, o puedo agarrar y poner más peces. Pongo diez peces más, y ¿qué pasa? Empiezan a juntarse y se hace un cardumen. El sistema es más eficiente, porque no hay tantas colisiones contra las paredes, los peces aprendieron a no chocarse contra las paredes, y trabajan en grupo. Esto se logra con mas peces. No hubo que cambiar el sistema.

Ese es el punto del ejemplo: no hizo falta cambiar el sistema, sólo agregar objetos. Y el comportamiento que se dió, es emergente: puede o no haber sido previsto por el que colocó la conducta en "pez". Y no hizo falta codificar, pensar, diseñar a "cardumen".

Cuando uno ve esto, piensa en codificar la clase cardumen. Pero vean que curioso, no hubo necesidad. Hay un candidato a objeto que no era necesario hacerlo. Era un objeto que no existía pero era un observable. Hay cosas que observamos que no son objetos. ¿Qué es, entonces, un objeto? Dije que un cardumen no es un objeto. Uds. debian saltar y decir ¿cómo? En las charlas informales de Smalltalking, es un observable, es cardumen. Pero muchos le ponen nombre y lo quieren hacer un objeto.

En cambio, cardumen es una abstraccion. ¿Vamos a poner en el sistema algo que nunca vamos a instaciar?. Estamos haciendo algo que no es del sistema, es algo orientado a objeto. Y en el equipo aparece la evidencia de ese observable, y alguno del equipo lo agarra y lo toma como objeto. Pero no lo es, ¿dónde aparecen los indicadores de que no es un objeto?

Cuando uno tiene un cardumen, y ponemos un vidrio, el cardumen original se divide en dos ¿cuál de los dos es el cardumen? ¿es ésto o es el otro?. O si tenemos dos cardumenes, y se juntan, ¿cuál desaparece?

Se invierte mucha energia en un equipo, para decidir lo que es evidente para todos y no es un objeto. Pero en un ambiente nos damos cuenta.

No queda bien definido a qué se refiere con ambiente, a esta altura de la charla. Venía más adelante una aclaración, pero no alcanzó el tiempo de la charla. Alejandro tiene que comenzar a manejar mejor los tiempos, para lograr transmitir lo que quiere decir. (En un cliente, me hacen practicar dando charlas de 10 minutos... ;-)

Uno de los indicadores es la instanciación, y la identidad. Si no podemos definir la identidad, dudemos de la conveniencia de definirlo como objeto.

Lo interesante es tener un soporte informático para ver un emergente del sistema, al ejecutarlo, antes de que el equipo se de cuenta.

El gran tema acá es la emergencia. Recomendaría para una lectura más amplia, el libro de Mario Bunge "Emergencia y convergencia", y otros, como su filosofía de la biología, para comprender mejor a sistema y emergencia.

En el sistema, van a emerger cosas, independientes de nuestra visión o voluntad de dirigir. Quedarnos con solo nuestra voluntad, nos olvidamos de estos emergentes que van a suceder. El paradigma de objetos se compromete con el tiempo, el sistema incorpora cambios.

En física tenemos sistemas ideales, reales, y naturales. La física trata los ideales, en la práctica, se tunea, para llevar ese modelo ideal a un modelo real, que funcione en máquinas. Y de la naturaleza nadie la trata. Hay un sistema natural, no tiene tratamiento, desde el momento en que uno lo representa.

Lo interesante es Smalltalk como soporte para que las cosas pasen, antes de darnos cuenta de por qué. Nos sirve para definir objetos, y para observar cosas que ocurrían, en cambio de decir de antemano "esto es un objeto, preserva identidad".

Esto de estar dentro y fuera del sistema, hace que las personas entiendan a Smalltalk como un sistema vivo, y en mi opinión, es una expresion usada sin cuidad, esto es lejos de ser un sistema vivo.

Post relacionados

Superando los límites de la Orientación a Objetos (Parte 7)
Superando los límites de la Orientación a Objetos (Parte 6)
Superando los límites de la Orientación a Objetos (Parte 5)
Superando los límites de la Orientación a Objetos (Parte 4)
Superando los límites de la Orientación a Objetos (Parte 3)
Superando los límites de la Orientación a Objetos (Parte 2)
Superando los límites de la Orientación a Objetos (Parte 1)
Mas allá de objetos

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Superando los límites de la Orientación a Objetos (Parte 7)

lopez — Sun, 14 Dec 2008 15:16:17 GMT

Prosigo transcribiendo y comentando brevemente, la charla de Alejandro Reimondo de Smalltalking, dictada hace unas semanas en la Universidad Tecnológica Nacional, sede Buenos Aires.

Transcribo las palabras de Alejandro en cursiva:

Muchas veces se valora el cambio reiterado. Cuando trabajamos formalmente, hacemos un cambio en un sistema, y hacemos en otro sistema, no estan comprometidos uno con el otro. Hicimos un cambio, pero un sistema pudo ser correcto y el otro no. Cuando hay cambio, hay riesgo, entonces minimicemos los cambios.

En base a reconocer este problema, lo que se propone, es hacer iteraciones minúsculas, ciclos iterativos para produccion de software. Y quien tiene éxito trabajando de esta manera, son muchos los que tienen éxito, dicen, "yo trabajo de manera evolutiva", y es entendido entonces que evolución es cambio reiterado de características. Se trata de usar el cambio iterativo, para cambiar para mejorar. Pero estamos siendo inocentes, cambio implica intención, hay una dirección cuando planeamos la iteración.

No veo que la gente diga que trabaja de manera evolutiva, sino iterativa. Como en otros puntos de la charla, no hay una referencia a porqué se afirma algo. Si pongo el contexto de las metodologías ágiles, en un desarrollo iterativo la dirección de cambio puede ir cambiando, porque cada vez tenemos (los que desarrollan, y quienes necesitan el desarrollo) más idea y contexto de lo que necesitamos. Alejandro apunta a otro tipo de cambio, cuando dice evolución, pero (perdón que insista) de nuevo no da ningún ejemplo concreto. Ese es un problema en las presentaciones de Alejandro. Cada uno puede formarse una idea distinta, de un concepto, porque no está completamente definido, y lo "fuzzy" no se despeja, porque no hay ejemplo. Como siempre, el lenguaje humano es limitado, pero gran parte de esta charla, es una adivinanza, una especie de "veo veo", "¿qué ves?" "algo que llamo evolución", y nada más.

Evolución es lo que uno observa sobre algo que ya paso, como pasó, no lo sé! Pero tenemos un sistema que es distinto del que era. Luego, escribimos que hubo evolución, pero no fue planificado.

Asimilándolo a ciencia, esta distinción es parecida a lo que habría entre evolución biológica y diseño inteligente. También podría asimilarlo a historia humana vs ingeniería social, donde en la primera, los sucesos pasan (revoluciones, reordenamientos) sin una intervención humana dirigida.

Eso tambien tiene implicancia en ecología, se hacen cambios iterativos sobre objetos reales, para tratar de hacer evoluciones favorables, pero no tiene que ver con evolución, evolución describe lo que ya pasó, no es la intención dirigida.

Las teorías, cuando las cambiamos, cambian, no evolucionan. Todo cambio usando un lenguaje implica una voluntad definida a priori.

Yo diria que hay evolución, uno cambia algunas partes de forma dirigida, pero hay un nivel donde el ecosistema del software tiene evolución. Un caso que se me ocurren es la emergencia de Ajax, que no fué planeada, fué un emergente ocurrido ante la combinación no esperada de tecnologías que fueron apareciendo, no para llegar a Ajax, sino para solucionar otros problemas inmediatos.

Cambio implica entender antes de hacer. Evolución no. Es algo que pasó.

Ir diciendo como va el mundo, es útil en algunos contextos. En evolución, miramos lo que pasó hacia atrás, y reflexionamos. El cambio es imperativo.

Acá no entendí si esta frase indicaba: "El cambio (dirigido), al contrario de la evolución, es imperativo", o "El cambio (en evolución) es imperativo (siempre pasa)". Así me pasa con varias frases.

Uno no sabe todo, porque esta basado en un metodo reductivo.

Yo veo que no es un tema de método. Es un tema de no saber todo, por incapacidad humana, no por culpa del método reductivo.

En evolución, partimos de qué cambió, y ahora observamos. Todo cambio tiene un valor, es innegable. Ahora decir que por ese cambio genero tal cosa, nos perdemos otras cosas que tal vez genero.

Uno planifica cambios, no planificamos evolucion.

Hay un montón de cosas, que conviene decir lo que otro quiere escuchar. No hay que referirle reuso a alguien que dice reuso de componentes. Ahora, ante alguien que busca espacio en algo alternativo, es importante plantear estas diferencias.

Hoy es muy usado evolución, y no se detienen a pensar. Y dicen que cambios iterativos es evolución. Y deforman la palabra, pero evolución es otra cosa.

Evolución te hace dar cuenta, que por mas cambio que uno planea, hay cosas que pasan.

Insisto, hubiera sido interesante haber planteado un ejemplo de evolución en software. Creo que evolución es un término abusado en varios ámbitos. Se lo plantea como similar a la evolución biológica, y ésta tiene características muy definidas. Y si hablamos, en vez de evolución biológica, de evolución, hay que definir más precisamente a qué se refiere entonces esa palabra en solitario.

Post relacionados

Superando los límites de la Orientación a Objetos (Parte 6)
Superando los límites de la Orientación a Objetos (Parte 5)
Superando los límites de la Orientación a Objetos (Parte 4)
Superando los límites de la Orientación a Objetos (Parte 3)
Superando los límites de la Orientación a Objetos (Parte 2)
Superando los límites de la Orientación a Objetos (Parte 1)
Mas allá de objetos

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Superando los límites de la Orientación a Objetos (Parte 6)

lopez — Tue, 09 Dec 2008 09:59:45 GMT

Sigo transcribiendo (notas no textuales) la charla de Alejandro Reimondo de Smalltalking.

Como antes, transcribo lo de Alejandro en cursiva:

Cuando empieza a popularizarse? Tiene que ver con toda esa historia y el vínculo con la ciencia. Y otra cosa interesante, plantea un camino iterativo de superación. Uno+uno, 2+1, nos alienta a ese inductivismo de hacer objetos hasta que te mueras.

Ahora, Alejandro embate contra la especialización, yo lo veo como recordatorio de no olvidarse del sistemismo.

Hay grandes obras que se han construido de esta manera, en ingeniería, utilización de recursos, las represas, ingeniería nuclear, son obras dignas de todo nuestro respeto, pero no podemos dejar de ver los efectos que todo tiene (peces muertos, una gaviota picoteando), y cuando veo eso, en Atucha 2, los que lo construyeron, ya no están. Cuando los peces empezaron a flotar, ellos ya no estaban. Trataron de llamar a los ingenieros. Pero no, ese no es mi área, no es mi pedazo de la torta. No forma parte de mi óptica, se llama a biólogos, hay un problema que la usina produce tres grados más que van al lago, más temperatura, menos oxígeno, menos peces. ¿Que podemos hacer? Pongamos peces que necesiten menos oxigeno. ;-). Tratamos de emparchar, en vez de ver lo que ya hicimos. No digo que está mal construida la usina, sino que cada vez que se enciende una luz, se proyecta una sombra.

Hay gente que protesta, en el Congreso, cuando ya está hecho, y son los que se dedican al arte, y ninguno entiende mas allá de su torta. Cuando más es su estudio profundo, más huecos tiene, y más temas no son de él.

Aparece un mensaje sobre el "slide" "Smalltalk como plataforma iterativa".

Lo interesante de Smalltalk es hacer cambios y ensayos, es un proceso iterativo. Quien trabaja de esa manera, va a ver a herramientas de Smalltalk, más que un lenguaje. Valora un browser, un inspector. Son muy valorables las herramientas que hay en ST.

La más notable, ver para creer. Quien ve algo, cree en ese algo, nadie cree en algo que no vió. El identificar un objeto, verlo, implica no dudar sobre su existencia, es algo valiosísimos, es algo muy utilizado cuando trabajamos con objetos, ¿por qué? ¿por que es así la realidad? No, porque queremos que otro no dude.

No lo vean que estoy diciendo que esta mal, hay puntos de valor que encontramos con objetos.

Acá hubo una discusión sobre modelo, no la seguí completamente.

Yo no quiero decir dónde tienen que ir los demás, sino que gente de esta región, busque algún ancla en estas críticas, para propugnar un avance. Lo mío no es ataque de la ciencia, sino crítica.

Yo reveria esta postura, estudiaría Bunge y el sistemismo, la ciencia no es como EL metodo que describe Alejandro.

Entonces, se ve a Smalltalk como un completo y robusto de conjunto de componentes "re" usables.

Cuando uno habla de POO, DOO, LOO, esta la palabra, y hacemos orientado a objetos. Esas palabras empiezan con distintas letras (P, D, L) y termina con O de Objetos. Pero nadie se detiene en la O del medio.

Vamos a POO, dice que hay algo que es programación con objetos, pero POO no lo es, sino sólo orientado a objetos. Todos toman que la "orientada" siempre va. Pero se está diciendo que hay algo que es programación con objetos, al que no van a llegar.

En las revistas de Smalltalk, se dibujó un puente entre lo tradicional y objetos. Planteamos una transición, para llegar a objetos. Eso fué hace veinte anios, pero todavía estamos encima del puente, sin ver la O del medio, no hemos abandonado lo de "orientado".

Tenemos una tecnología para trabajar sobre la realidad y no la estamos abordando. No haciendo dibujos sobre la realidad, sino que es el instrumento para llegar a la realidad misma. Si nos quedamos en el ver, pero no vamos al tocar, y realimentar con nuestros sentidos, vamos a estar del lado de lo orientado, y en nuestros problemas de como pensamos al mundo.

Acá de nuevo, hubiera sido interesante mostrar un ejemplo de "tocar" objetos en Smalltalk, contra "ver" diagramas, código y otros artefactos.

El tema de todo esto de "ver", de decir, "esto es", y nos produce una pelota, una caja, y decir que lo que no esta dibujado acá no existe, y esto es una caja negra, nos pone afuera. Eso es el encapsulamiento, tiene un monton de virtudes. Pero, ¿cuales son las limitaciones? ¡Qué mejor que usar cajas negras! ¡Qué mejor que no reinventar la rueda! Nos estamos cortando un camino: los que producir software, queremos producir software, que mejor que hacerlo nosotros, que es nuestro trabajo.

Acá yo tengo una posición: hay distintos tipos de programadores. Hay quienes les gusta hacer la rueda, y otros que quieren una rueda ya hecha, para construir nuevas cosas encima de ella. Alejandro, veo, está muy centrado en pensar que el camino del desarrollo del software es armar algo sustentable por uno mismo o por su grupo de trabajo. Hay evidencia de excelentes programadores, equipos, y proyectos, donde lo que se hace es montarse sobre lo ya hecho por otro, para seguir avanzando y creando cosas nuevas sobre eso.

Entonces, en algun ámbito, se dice que Smalltalk es completo y robusto, que es un conjunto de componentes re-usables.

¿Que es re-uso? Pregunta tonta si la hay.

Alejandro propone una interpretación de reuso, que sólo la encontré en su discurso.

- Poner un componente, y lo usas en un sistema, y en otros sistema. Es no es reuso, es uso.

Acá alguien acotó que un "un objeto es él, y las relaciones con otros". De acuerdo, es una descripción cercana al sistemismo.

No es reuso, es uso. Usabilidad en el software se busca desde los 50, salio ADA, Pascal. La diferencia es que todos hemos cambiado, y las personas, ahora lo toman con naturalidad, entonces no. El planteo de Modula fueron componentes. Hoy los vemos usados. Pero eso da usabilidad. Nos permite usarlos varias veces. Pero no es reuso.

Una instancia de una abstracción, es válida en un contexto. Cuando queremos usarla en otro contexto, es kamikazee. Entonces, esto no nos anda en otro lugar. La abstracción, si es rica, es interesante. Las altas abstracciones son poco valiosas, están desprovistas de información, las que están más abajo, tienen demasiado vínculo con el contexto.

Sería interesante ver un ejemplo concreto de abstración alta, baja, instancia de abstracción y contexto.

Lo valioso a nuestro nivel de desarrolladores, es lo intermedio. Si la abstracción es intermedia, cuando vamos a otro contexto, lo que hacemos es refinarla, porque nuestra intención es instanciarla en con éxito, estamos partiendo de una instancia refinada, que no es lo mismo que usamos en otro sistema. Eso es lo que tiene de valor en nuestras abstracciones, el poder refinarlas para usarla en otro sistema. Ese refinamiento no se puede lograr a nivel de instancia.

Los componentes no son reusables, no es posible su reuso, es posible el uso. Y es inocente, es lo que ocurre en la industria. Los componentes no son importantes. El reuso es aplicable a las abstracciones pero no a los componentes. El reuso implica refinarla. ¿Que conecta una abstracción y una refinación de esa abstraccion? El tiempo, y decimos, "mi sistema evolucionó".

Quien ve reuso en componentes, tiene una vision ingenua.

Las librerías de Modula, no permitían hacer práctico el refinamiento, y ahí sí tuvo un lugar Smalltalk, que sí pudo hacer eso. Y HOY tenemos un conjunto de componentes robusto, pero que es resultado del tiempo.

Quien lo ve desde ese punto, valora su contenido, se fija lo que hay acá, y le sirve para desarrollar sistemas. Qué frameworks de clases hay, y como podemos usarlos.

Acá hay mucho para hablar, y que hacemos frecuentemente en Smalltalking, cada charla todos los meses. Un componente es un instancia, planteado como una caja, y la usamos en distintos contexto, lo valioso es que lo llevo a otro contexto y anda.

Pero puesto en distintos contexto, puede no servir. ¿Que cambiar? ¿La forma? Eso es usarlo. Si cambiamos la idea, es reusarlo. Hay un proceso destructivo de las viejas ideas, y está sostenido en el tiempo. No es un proceso donde esto viejo no me importe, y lo escribo de nuevo para otro mercado.

Smalltalk me da el soporte para cambiar la idea.

¿Qué es lo constante cuando aca decimos tiempo? Lo constante es uno, es la trayectoria de uno como ser humano. Dependiendo de las oportunidades que tengas de usar tus componentes o abstracciones, pero el soporte son las personas. Uno no es el mismo a medida que pasa el pasa el tiempo. Entonces, Smalltalk es un soporte para el cambio de personas.

No tienen valor las cosas, no compres componentes. Sabemos hacer ruedas.

Lamentablemente, todos los libros dicen lo que se conoce hoy, no dudan de eso por la informacion que hay. Cuanto lugar hay para la duda, no existe. No podes pensar de otra manera. Tenemos una punta para desenroscar algo mas, y hacer un aporte. Hay algo que no se ve, que está oculto, y se lo niega.

Vemos analogías en otros lados, fuera de informática, siempre hemos usado la misma forma de disectar el mundo, y lo que no vemos no existe. No digo que no tengamos que hacerlo asi, sino que hay puntos sobre los que podemos trabajar.

Post relacionados

Superando los límites de la Orientación a Objetos (Parte 5)
Superando los límites de la Orientación a Objetos (Parte 4)
Superando los límites de la Orientación a Objetos (Parte 3)
Superando los límites de la Orientación a Objetos (Parte 2)
Superando los límites de la Orientación a Objetos (Parte 1)
Mas allá de objetos

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Superando los límites de la Orientación a Objetos (Parte 5)

lopez — Sat, 06 Dec 2008 10:47:26 GMT

Sigo transcribiendo (notas no textuales) la charla de Alejandro Reimondo de Smalltalking. En el anterior post habíamos llegado a un slide:

Transcribo lo de Alejandro en cursiva:

Los abordajes que hacemos acá, son abordajes de informáticas, que se ve poco, se habla más de computación que de informática, mientras en otras ciencias se ven temas de informática. Y aplican el método. No está mal, es el método. El problema es no reconocer las limitantes.

Hay algo inobjetable que aportó la masificación del concepto de objetos, que es la diferencia fundamental de trabajar con objetos. De la manera que se utilizaba antes, uno se focalizaba en qué tiene que hacer el sistema, uno trabajaba en el hacer. Los objetos aportaron un cambio en la óptica, en con qué se hacen las cosas. Uno con lápiz y papel, podemos hacer factura, pero también puede hacer cartas de amor. Ahí vienen las ventajas, en no focalizarse en que hacer, sino con qué lo hace, para usar las cosas en distintos ambientes. Cuando la gente empezo a entender, compró el tema de objetos, cuando vió que podia usarlo en distintos lugares.

Otra cosa, es que pudo hacer práctico el trabajo y utilizar encapsulamiento. Y con el tiempo empezaron a aparecer usos y construcciones, que empezaron a ser valoradas por la belleza, por otras cosas que no eran sólo la utilidad.

Aparece sobre el "slide" un mensaje "Haciendo software como se hace ciencia".

En el primer abordaje, se hace software como se hace ciencia. La propuesta es hacer software, utilizando EL método, y eso se promovió muchísimo en los ámbitos donde se hacía ciencia, y hay algo que sospechar, que eso nos pasó a todos los que empezamos y veíamos que hacer software no podia ser entendido en algo tan metódico, vamos dijimos en su momento, dijimos que había algo de arte. Eso estaba siendo ocultado, con estos métodos. Esto es lo que hay que hacer, y hay que hacer ciencia.

Como en otras partes de la charla, hubiera sido interesante tener un ejemplo de este caso.

Se puso los lugares donde se enseña informática, cerca de donde se enseña ciencia. Pero en ciencia hubo miles de años de estabilización, pero en software no.

Todos son objetos, todos podemos usar EL método, y hacemos una formalización, pero hay algo que está oculto, y no podemos no verlo.

Aparece en el "slide" un mensaje "Industria del software, Elementos para nuevos negocios".

El abordaje de modular, con Pascal, Modula, Ada, nos proponía una industria de software, que el software tiene que ver con los negocios, y que eso tiene algun vinculo con la informática.

Aparece en el "slide" un mensaje "Software como expresión de arte".

Y el software como expresion de arte, es la formula del pibe que es "cool", que es una óptica distinta, pero no formalizado. Ninguna de las otras dos nos da soporte a ésta.

Aparece en el "slide" un mensaje "Smalltalk como ciencia" cerca del mensaje "Haciendo software como haciendo ciencia".

Vean Smalltalk como lenguaje, para hacer software como ciencia. Se ha utilizado con mucho éxito de esa manera.

Cuando se hace uso de Smalltalk para esta parte, se ve a Smalltalk como un lenguaje, minimalista, elemental, muy práctico, para descomponer y escribir piezas pequeñas. Y eso interesa a quien tiene que trabajar de manera eficiente de esta manera. No digo que no podamos trabajar o que no debamos trabajar. He visto y trabajdo con Smalltalk en esos ámbitos. Si busca trabajan con objetos, Smalltalk es el único ambiente de uso comercial, van a poder trbaajar en esas areas.

Luego, Alejandro pasó a comentar temas, como el origen de la OO, que veremos en un próximo post.

Post relacionados

Superando los límites de la Orientación a Objetos (Parte 4)
Superando los límites de la Orientación a Objetos (Parte 3)
Superando los límites de la Orientación a Objetos (Parte 2)
Superando los límites de la Orientación a Objetos (Parte 1)
Mas allá de objetos

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Superando los límites de la Orientación a Objetos (Parte 4)

lopez — Fri, 05 Dec 2008 09:06:13 GMT

Sigo transcribiendo (notas no textuales) la charla de Alejandro Reimondo de Smalltalking. Mostró un slide con un dibujo de bebé:

Pongo lo que dijo Alejandro (aproximadamente) en cursiva:

Hay un dibujito que se ha usado bastante, mira, mamá, todos son objetos, quedémonos tranquilos. Es algo muy utilizado para vender, si pensamos así, que la inocencia nos valga.

No sé cuántos de los asistentes a la charla vieron algún dibujo así. Hace tiempo que no aparece. El auditorio de esta charla, principalmente estudiantes universitarios, pertenece a una generación que no vió ese tipo de dibujo.

Está bueno decir todos son objetos, pero es muy inocente. ¿No sospecharon cuando les dijeron, "pone objetos"? Es demasiado simple. Muy simple, Y cuando uno lo piensa, todos son objetos, pero cuando uno ve la realidad, a todos nos va yendo mal.

Bueno, yo no diría a todos.

Hay cosas fuera de control, y hay problemas en el software, por ejemplo, en escalabilidad. Si 1+1 funciona, seguimos hasta el infinito, esa proyección inductiva que todos son objetos, nos pone en un camino infinito, y tenemos un mundo para darnos cuenta que cada vez que agregamos más de lo mismo, cada vez complicamos más. Esa complejidad que no vemos cuando empezamos por un sistema simple.

He visto mucha gente capacitada, que dice que todos son objetos.

Pero es interesante, ese dibujo de bebé, nos estan seduciendo a sentirnos que tenemos intercambiar, y tener ese rol.

No entendí esa frase. Pasamos a otro slide, con título Punto de Partida.

No vamos a tratar acá, hay todo un método que sustenta esto, el tratar de abordar a las cosas descomponiéndolas, en el fondo, entendiéndolas. Normalmente, cuando se nos presenta una problemática, lo que se nos sugiere hacer, es decomponerla en partes, seccionarla, y si todo esto era un problema, ahora tenemos tres poblemas mas simples.

Yo recordaría aquí a Descartes. En su método, algo de esto recomienda, pero también recomienda, como cuarto paso, revisar que no nos hayamos olvidado algo.

Cuando atacamos cada problema, vamos seccionándolo. Hay que ser cuidadoso, hay que ver donde seccionar. Hay que saber donde cortar el sistema,para que el problema sea más entendible. Es algo bien enseñado, no tengo que hablar de esto, es diseccionar sistemas, es cuestión de tener un hacha. A medida que tiene más partes, más comienza a ser todo ser inmanejable. No se sabe cual es el vínculo entre las partes. En esa partición estratégica que hicimos, dos partes no tendrían que estar asociadas, pero están.

Lo más curioso, no nos damos cuenta nunca, cuando más partimos, más queda entre medio, más queda entre los intercisios, y lo que entendemos, cada vez es menor, este método genera no solo incertidumbre, cada vez entendemos menos, lo que importa son las partículas, y en el medio lo negamos, es vacío, todos son objetos, son pelotas, es la primera parte del paradigma, entonces, encontramos esas pelotas, marcamos las relaciones, pero en medio hay algo incontrolable, que si lo tocamos, hay cambios en otras partes.

Acá creo que hubiera sido bueno mostrar un ejemplo, para mostrar esa pérdida con un caso concreto.

Es una forma de abordar la realidad, es la única que tenemos. No tratamos de sugerirles que hay otra forma, solamente estamos siendo criticos, de lo que hacemos todos los dias.

Cada vez que arrancamos con algo, empezamos a disectar.

Ese metodo que es lo que produce? ese metodo produce, un sistema, que se entiende como un conjunto de reglas, en donde uno puede chequear, la validez de ese sistema, mientras nada cambia, es un sistema cerrado. Y si una encapsula un conjunto de reglas, lo podrá llamar clases. Y eso está muy bueno para lo que es el estudio y la descripción de lo que es el sistema.

¿Pero qué compromiso tiene con la realidad?

El sistema real no tiene compromiso con cómo lo dibujemos. Cada persona que venga con un hacha nueva, lo parte distinto. Hay un componente importante que está dada por la óptica, y no con la realidad. Queda como uno ve la realidad, más que la realidad.

Cuando un sistema es cerrado, si uno cambia una de las reglas, algo cambia, el sistema resultante es otro sistema, el anterior puede ser correcto, y el siguiente no serlo. Es decir, de ese sistema al sistema modificado, un cambio produce otro sistema, y el primero no tiene relación con el segundo, porque no tiene compromiso con la realidad, es una descripción.

Alejandro hace años que viene afirmando esta postura. Pero creo que le falta algún ejemplo, él ya está tan acostumbrado a transitar este argumento, que le parece claro. Pero el que enfrenta este tema por primera vez, sin saber hacia dónde se quiere llegar, o sin tener una referencia concreta de lo que se está hablando, se puede perder, o entenderlo de otra forma.

Ese método que estamos usando, siempre se compromete, como mucho, a definir la óptica que tenemos con la realidad, pero no está comprometida con la realidad.

Recordemos la experiencia de Alejandro con el sistema de simulación de locomotora. Ahí él armó un sistema, que era el reflejo de la realidad. Hacia ahí apunta el argumento, en parte. Para el que haya usado Smalltalk, también le parecerá algo conocido el camino al que quiere llegar Alejandro: armar el sistema usando el propio ambiente.

No ve a la implementación como una herramienta de percepción. Utiliza la cabeza para hacer los cortes, obtiene un sistema, y como un cambio en ese sistema, resulta en una vuelta atrás, no es utilizado para entender la realidad del sistema.

Cuando obtenemos un modelo, la codificación no es utilizada para entender la realidad que modelo.

Yo veo que gran parte de esta discusión, ya ha sido encarada por los propulsores del diseño dirigido por el modelo, Eric Evans a la cabeza. Aunque ellos no usarían siempre la computadora, sino el lenguaje ubicuo, y otras herramientas de comunicación con el usuario. Pero Alejandro apunta a armar el sistema en el ambiente.

Usamos representaciones, dibujos, pero no usamos la computadora. El sistema virtual que estamos generando, no tenga la posibilidad de utilizar de realimentarnos. es imposible tener experiencia.

Estoy hablando antes de ambiente. Le decimos a la gente, usa la computadora, pero nosotros no las usamos.

Podemos termina ahi, o podemos tratar de ver alternativas, y ver que es una consecuencia del método que estamos tomando. Tratemos de hacer explícita esa limitación.

Se invierte mucha energía en enseñar este método, este método de disectar, pero no queda tiempo para enseñar cuales son los límites del mismo. Mucha gente no tuvo la posibilidad de darse cuenta cuándo ese método no funciona.

No estoy diciendo de desecharlo, de tirar algo que da valor. No. Si yo dijera "tiremos eso, y les doy otra cosa X", estoy cometiendo el mismo error, de darles que en cambio de "todo son objetos", ahora es "todo son X". Quiero motivarlos, para mostrar los límites. Porque sino la gente aplica las cosas rutinariamente, y luego trata de emparcharlas, con la inducción de sigamos siendo lo mismo.

Si hay un problema en lo que hiciste, escribiste mal esto, esto, arréglalo. Yo no me quedo tranquilo en hacer siempre lo mismo. Sin reflexionar sobre la realidad.

Nada mas difícil que un diseño para ver cuando hay una falla. Los intercisios no están escritos en ninguna parte. Son negados con pongamos mas objetos.

Post relacionados

Superando los límites de la Orientación a Objetos (Parte 3)
Superando los límites de la Orientación a Objetos (Parte 2)
Superando los límites de la Orientación a Objetos (Parte 1)
Mas allá de objetos

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Superando los límites de la Orientación a Objetos (Parte 3)

lopez — Sun, 30 Nov 2008 18:31:14 GMT

Sigo con la transcripción no textual de la charla de Alejandro Reimondo de Smalltalking, dada hace unas semanas en la Universidad Tecnológica Nacional, aquí en Buenos Aires, Argentina. Alejandro comentó algunos trabajos en los que participó, desde los noventa:

Participé de un proyecto sobre cine argentino. Fue interesante ayudar durante 2 años, fue interesante ayudar a investigadores de la historia del cine argentino. En esa época, 1995, no había salido Windows 95, no había muchos productos multimedia. Se armó un producto donde todas las fotografías se vinculaban unas a otras, y los personajes y temas relevantes, tenían su ficha. Fue mantenido y creado por un grupo de investigadores coherramientas que fuimos haciendo. Fue la primera cinemateca en el mundo que tuvo un CD ROM de cine de su país.

Pueden encontrar más información sobre el proyecto en

Cine argentino en Cd Roms

Fue creado por la Fundación Cinemateca Argentina, pero no encontré un sitio de esta fundación.

En el 2000, participé del proyecto Halcón de IBM. Es un sistema de tracking de documentación de negocios grandes en Sudamérica. Había sido hecho en Smalltalk y nos tocó hacer una actualización.

Estos proyectos estaban enumerados en el "slide" que presentó en ese momento. No mostró software andando:

No voy a mostrar software. Pero traje algo para que no se aburran escuchandome hablar. En el producto Virtual Fashion, hicimos un enganche de Smalltalk con un engine 3d, de una empresa española, en el 2005, 2006, hicimos el ambiente Smalltalk que se monta en cima del ambiente de 3d de ellos, para diseño de moda virtual. En su tiempo, hubo una competición entre diseñadores, donde los diseñadores usaban virtualmente las telas que se estaban presentando en ese momento.

La empresa para la que se hizo este desarrollo es Reyes Informática:

http://www.reyes-infografica.com/

El producto es Virtual Fashion

http://www.virtual-fashion.com/html/en/

Pueden ver una galería de videos con el producto andando en:

http://virtual-fashion.com/html/en/gallery_video.php

Atlas.TI es de hermeneútica, interpretación de texto. Si uno quiere interpretar párrafos de la Biblia, y los quiere comparar con párrafos del Corán, lo puede manejar por software. Puede enlazar con otros textos, por ejemplo, documentos y contratos. Atlas.TI expandió eso para manejar lo multimedial, y ahora maneja Google Earth. Puede vincular el texto al mapa del mundo de hoy. Esa compañía está trabajando más de quince años, son líderes en el mercado, está escrito en Smalltalk, y me ha tocado darles asistencia desde acá, Argentina, para ese proyecto.

El producto es el

http://www.atlasti.com/

Pueden encontrar información en español en

http://www.atlasti.com/productintro_es.html

donde leemos:

¿Qué es ATLAS.ti?
Durante una década, ATLAS.ti ha sido el líder del mercado en software profesional QDA (para el Análisis Cualitativo de Datos). ATLAS.ti es utilizado en todo el mundo por instituciones e investigadores líderes. Siempre que se precisa de un análisis profesional de texto y datos multimedia, simplemente no existe alternativa a ATLAS.ti.
Compatibilidad con todos los idiomas
ATLAS.ti puede procesar datos prácticamente en cualquier idioma, utilizando todos los juegos de caracteres disponibles, incluidos japonés, chino, árabe, hebreo y muchos más. No obstante, recuerde que la interfaz del programa se mantiene en inglés*, (independientemente del idioma de su material).

Siguió Alejandro con:

Hace dos anios o 3 vengo participando en un esquema de negocios, para el armado de este tipo de productos, fotoalbumes, con cada foto se hacen estos libros. Diseñamos una forma de hacer los libros, mi participación mayor es en hacer este tipo de software. Con PhotoShop se puede hacer, pero lo interesante de nuestro producto, es que el producto final se hace con la dedicación de 2 horas por cada cliente a atender. Entonces, es un software que tiene que ser muchísimo más rápido y eficiente que PhotoShop. Se usan fotos comunes, y hay un metodo de armado. Tenemos un esquema de negocios para Latinoamérica.

La empresa de la que participa Alejandro es

http://www.imaginiasoft.com

Pueden ver algunas características del soft en

ImaginiaSoft, software para fotolibros y regalos con fotos

También mencionó Alejandro otros hitos en la historia de Smalltalk en Argentina:

... hay dos hitos que quiero mencionar, el primero fue la fundación de Sugar (Smalltalk User Group de Argentina), en la que participé hasta 1999/2000. Luego, me he dedicado a Smalltalking, que busca que seamos protagonistas de un avance en tecnología. Si bien tiene vínculo con Smalltalk, no se queda ahí, y estamos intentando ir por más.

Alejandro no llegó a explicar claramente qué era eso de "un avance en tecnología" que espera. Creo que era parte de la charla, pero no le alcanzó el tiempo para volver al tema.

Queremos ser protagonistas de un avance tecnológica de acá a una década, no hemos visto un avance y hay que buscarlo.

....

Con respecto a Smalltalk, me es inevitable no usarlo, porque es lo que he usado durante 20 años. Toda referencia la hago con respecto a Smalltalk, no me va a escuchar hablar de otras alternativas, elijo Smalltalk porque lo puedo sustentar.

No quedó claro a qué se refería con "sustentar". Entiendo que tiene relación con lo que publiqué hace un tiempo sobre

Self-sustaining Systems, Cola, Pepsi, Coke y Mate

Esta falta de terminar de explicitar algunos puntos, va a ser un tema recurrente en la presentación de Alejandro. Habrá que esperar que publique algo explicando esos puntos.

Enlaces relacionados

Superando los límites de la Orientación a Objetos (Parte 1)
Superando los límites de la Orientación a Objetos (Parte 2)
Mas allá de objetos

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Superando los límites de la Orientación a Objetos (Parte 2)

lopez — Wed, 26 Nov 2008 09:16:15 GMT

Sigo transcriendo notas (no textuales) y comentarios, de la charla de Alejandro Reimondo de Smalltalking sobre Superando los límites de Orientación a Objetos. Alejandro comentó sobre sus primeros proyectos con Smalltalk:

"Volcado en años, hay infinidad de cosas hechas ... son proyectos fuera de lo común, no convencionales, y es muy variado el tipo de cosas que he hecho, y hay hitos de los que me siento orgulloso.

(cerca de 1990) El Soler es un sistema que es una simulación de una locomotora, que se utilizó para enseñar a reparar una locomotora. Antes se enseñaba con una locomotora física, eso es costosísimo. En esos tiempos, los japoneses llegaron al país, a hacerse cargo de una empresa de transporte, y nos contrataron para programar un modelo de locomotora, que sirviera para la enseñanza de su reparación.

Es un proyecto que me llevaría tiempo explicar, pero fueron interesantes los resultados. Logramos hacer una locomotora donde están virtualizados los caños, elementos, partes, y lo interesante que eso lo programaron los usuarios. Yo no sabía de locomotoras, el problema real era ¿cómo hago un sistema ne donde quien lo usa, lo programa?. Estamos hablando de 1991, tenía que ser hecho en seis meses el primer modelo, luego estaba planeado modelar más tipos de locomotoras. Empezamos a trabajar en una herramienta de construcción, donde el experto especificaba cada una de las piezas, y las probaba de a una, e iba conectando los subsistemas. Eran como 150 elementos coordinados. Empiezan a trabajar los usuarios a especificarlos, cuando el referente me dice: el problema es grande, no sabemos cómo lo estás resolviendo, ¿qué nos garantiza que todo va a funcionar? ¿cómo vas a resolver las referencias circulares? Eran preguntas de los libros de simulación. Yo sabía la respuesta: nadie te garantiza que todo va a andar. Pero no tuve que dar esa respuesta, seguí construyendo. Un buen día, recibo un llamado: Alejandro, sos un genio, terminamos de armar todo, y anda, ¿cómo sabías que iba a andar? Ahora, la duda ya no es si va a andar, sino, ¿por qué está andando? Acá, este andando es mágico, y ahí entendí la respuesta, que la podía dar en ese momento: anda, porque las locomotoras andan".

Igual acá acotaría que no siempre las simulaciones de ese tipo llegan a buen puerto. El tema no son las referencias circulares, sino la adecuación a lo modelado en la realidad.

"Las locomotoras son dispositivos diseñados estables, están armadas para que no se generen desequilibrios en ese sistema, había toda una ingeniería en esa maquinaria, lo único que no tenía que hacer era programar yo, era permitir al experto que tuviera herramientas para programarlo.

Me di cuenta de eso magico: las cosas funcionan. Lo que tratamos de hacer, es virtualizar eso, para conseguir ese éxito.

Las cosas que andan, si uno lo trabaja con objetos, andan. Me costo unos años, que hay cosas que no andan, y cuando uno trabaja con objetos, tampoco andan."

Me temo que Alejandro no dió un ejemplo de este tipo, de "cosas que no andan". En el tema locomotora, estudiaría sistemas, teoría de sistemas, tendría que recomendar varios títulos de Mario Bunge aquí, como su excelente "Emergencia y Convergencia".

"Lo que tenemos en un modelo de objetos, es algo valioso, pero tiene límites."

En el resto de la charla siguió tratando de mostrar los límites de POO, pero eso seguirá en otros posts.

Enlaces relacionados

Superando los límites de la Orientación a Objetos (Parte 1)
Superando los límites de la Orientación a Objetos (Parte 3)
Mas allá de objetos

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Superando los límites de la Orientación a Objetos (Parte 1)

lopez — Mon, 24 Nov 2008 09:03:36 GMT

El pasado sábado 8 de Noviembre, asistí a una charla de Alejandro Reimondo, de la asociación Smalltalking, dada en la sede de la Universidad Tecnológica Nacional, aquí en Buenos Aires, Argentina. Ya había posteado sobre el anuncio de la charla:

Mas allá de objetos

Tome varias notas, que quisiera ir posteando por acá. La charla duró dos horas y media y un poco más. Hubo interesantes discusiones, y Alejandro trató de explicar a qué limitaciones se refería en el título de la charla. Creo que no llegó a transmitir su mensaje completo, porque se acabó el tiempo. Espero que este primer post y otros que le sigan, sirvan para difundir y entender lo que expuso. Intercalaré comentarios y apreciaciones mías, y algunas aclaraciones. Al principio, Alejandro comentó sobre sus inicios en la programación Smalltalk:

"Arranco siempre explicando un poco algo de historia de objetos en el país, en la región, y de alguna manera ... es innegable que he tenido participación del desarrollo de la tecnologia en nuestro país. Me ha tocado hacer el primer sistema de Smalltalk de uso comercial. En los años 1988-87, me cayó un diskette en las manos, otros dos diskettes fueron uno a la UBA (Universidad de Buenos Aires) y otro a una universidad de Brasil, a una cátegra de inteligencia artificial. No se sabía qué era, y se veía como futuro en la informática".

Yo recuerdo acá que Smalltalk ya lo veía por aquí un poco más temprano, pero no había mucho hardware disponible para ejecutarlo (lo mismo pasaba con Lisp). Recuerdo que en la primera parte de los ochenta, el ingeniero Guido Vasallo ya me había entusiasmado a que estudiara el lenguaje.

"...Me llegó por un conocido, que me dice, fijate qué es esto, Alejandro, en los tiempos que tengas, eran dos diskettes. Quince días más tarde llega un pre-release de Windows 1.2, me lo dan, fijate Alejandro, esto es lo mismo, las dos son herramientas gráficas. Yo en esos tiempos dominaba muy bien el uso de Turbo Pascal".

Recuerdo la primera versión de Windows, la anterior versión 1.0, que no tenía ventanas superpuestas. Habré ido a la sucursal de Bunge y Born, local, a ver la primera versión, corriendo en un monitor VGA, de color, uno de los primeros que habré visto. El Turbo Pascal (y luego el Turbo C) fueron programas que marcaron un rumbo en lo que hoy son las IDEs modernas.

"... Había logrado que me trajeran un mouse de EE.UU. Las herramientas que llegaron eran muy tentadoras, y podía usar el mouse. Windows tenía 3 programas, no había herramientas, no se promocionaba programar en Windows, esa era la política entonces, ya iban a venir las herramientas para desarrollar.

Veo esta otra cosa, el Smalltalk, y empiezo a ver, estaba todo programado ahí, lo puedo tocar, y acepta cambios. Podía modificar su funcionamiento, y eso fue una de las cosas que me motivó para el primer desarrollo de la empresa en la que trabajaba, un sistema de admisión temporaria en el país, de materias primas que entran, y productos que se exportan como terminados.

Como yo manejaba muy bien el Turbo Pascal, lo iba a encarar con ese lenguaje. Me preguntan: Alejandro, ¿cuánto tiempo te toma desarrollarlo? Contesté 3 meses. Yo sabía que en un mes y medio lo hacía en Turbo Pascal, y quería el tiempo adicional para intentar hacerlo en Smalltalk. Me sorprendió que en 15 días, venía gente a ver el sistema, a usarlo con el mouse, mientras lo estaba armando. Para mí fue una experiencia importante, pero yo creía que era un prototipo: los usuarios me hicieron ver que ése era el sistema, y me felicitaron por la velocidad conque lo había hecho. Fue una sorpresa para mí, lo que había pasado.

No había informacion sobre objetos..."

Bueno, en aquellos tiempos, algo había en el ambiente universitario, y también en la literatura que llegaba desde EE.UU., principalmente. Recuerdo haber comenzado a leer sobre Smalltalk en los primeros años ochenta, así como de C++. Pero era escasa la gente con la que compartir experiencias.

"... no había otro que te lo dijera, años en que uno tenía que reflexionar qué es lo que estaba pasando, sin tener el sustento de otros. Fue una experiencia única de alguna manera, hoy existe todo lo contrario, mucha comunicación, muchos contenidos, pero poco tiempo de reflexión para cuando uno aborda una herramienta de de desarrollo de objetos.

En el año 90 dejé de trabajar con Turbo Pascal, y empecé a trabajar sólo con Smalltalk, y todo el desarrollo que he hecho, lo hice con un ambiente de objetos. En los primeros años me tocó promover, ir viendo ver cómo la gente reaccioanaba a eso año a año."

Esto es apenas el comienzo de la charla. Iré publicando el resto en futuros post, y colocando aquí los enlaces. Post publicados:

Superando los límites de la Orientación a Objetos (Parte 2)
Superando los límites de la Orientación a Objetos (Parte 3)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Mas allá de objetos

lopez — Thu, 06 Nov 2008 10:09:02 GMT

La asociación Smalltalking, de la mano de Alejandro Reimondo, presentará una conferencia en al Universidad Tecnología Nacional en Buenos Aires, este sábado 8 de Noviembre, a las 15hs.

La gacetilla de prensa:

Fecha: Sabado 8 de Noviembre, a las 15:00 hs.
Lugar: UTN Medrano, aula a confirmar
Dirección: Medrano 955 - Ciudad de Buenos Aires

En base a los avances en Informática que se estan procurando realizar en nuestra región (*); creemos de interés para los profesionales vinculados a la aplicación y el estudio de la construcción de software; una charla en la que se expondrán los límites del abordaje Orientado a Objetos y se analizará la historia reciente y se expondrán puntos que alientan la superación de las limitantes impuestas por a forma en que hoy se construye y se entiende el software (y la información).

"Superando los limites de la Orientacion a Objetos"
A cargo de : Alejandro Reimondo
Consultor en Tecnología de Objetos
http://www.aleReimondo.com
Presidente Smalltalking
http://www.smalltalking.net
La charla estará centrada en la problemática de producir usando objetos hoy.
Tomaremos como punto de partida, una visión crítica de la POO con la intensión de resaltar sus limitaciones para luego reflexionar sobre la idea de ambiente y los conceptos de uso diario en la producción en Ambiente.
La idea es mover a la audiencia a los puntos de incertidumbre que lleva el diseño con objetos y usar este marco para promover una actitud superadora y alternativa a lo ya conocido (seguir de forma inductiva definiendo mas
objetos).

Puede ocurrir (esto condicionado por la voluntad de la audiencia) que aparezcan en el desarrollo de la charla puntas sobre dónde puede hacerse avances tecnológicos; avances que es muy posible que ocurran en nuestra
región antes que en los países desarrollados; siendo esto un motivante adicional a la ilustración que propone una exposición técnica.

El contenido será de índole práctico (se asume el conocimiento teórico básico sobre OO) y todo el contenido está avalado por experiencias realizadas en su mayoría en nuestro pais.
(*) ver http://www.smalltalking.net

Espero poder asistir y tomar notas, así queda algo publicado para cumplir con los "mindsets":

Lo que no está escrito no existe
Don't be a canuto
Pasando el test: me pisó el 60

;-)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Proyecto Tocatú

lopez — Wed, 22 Oct 2008 10:41:57 GMT

El bueno de Leonardo de Marco y sus compañeros (no tengo los nombres completos acá, ni los encuentro en la página, Gabriel y Marite, y la participación de Alejandro Reimondo) estuvieron trabajando largo tiempo en su tesis y trabajo, de interface multitouch. Ahora pueden ver el resultado en:

http://www.tocatu.com.ar

Explica Leonardo:

El proyecto TocaTú es producto de mas de un año de investigacion y trabajo (esporadicas pero muy divertidas por cierto) en la que junto a Ale, y luego con Gabriel y Marite fuimos avanzando en la construccion de una idea que agrupara las diferentes aplicaciones o casos de uso en que es posible utilizar la tecnologia de vision por computador.
La parte de Software esta totalmente construida en Smalltalk basado en el framework de Ale de OpenCV (http://alereimondo.no-ip.org/OpenCV) y la librería Touchlib (http://www.whitenoiseaudio.com/touchlib/).

Además de haberlo armado y llevado adelante, hoy el proyecto se presenta en INNOVAR 2008!

"El Concurso INNOVAR se proyecta como un espacio permanente de soluciones a los problemas que deben enfrentar y resolver los emprendedores, en el campo del diseño, la tecnología y el comercio, para que sus creaciones lleguen y se difundan en el mercado. Los objetivos de INNOVAR son estimular y difundir los procesos de transferencia de conocimientos y tecnología, aplicados a productos y/o procesos que mejoren la calidad de vida de la sociedad."

Desde acá, felicitaciones y mucha suerte, a Leonardo y sus compañeros.

Más sobre interfaces y multitouchs en:

Posts sobre interfaces

http://delicious.com/ajlopez/interface

Touchless SDK de código abierto (para comenzar a probar multitouch con solo una webcam).

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Reunión de Smalltalking, con Claus Gittinger y Smalltalk/X

lopez — Tue, 16 Sep 2008 10:58:52 GMT

El sábado pasado, 13 de septiembre, asistí a la reunión de Smalltalking. Esta vez, la reunión fue un café cerca del edificion de la Biblioteca Nacional, aquí en Buenos Aires, Argentina. El grupo es pequeño pero entusiasta, y las discusiones fueron muy interesantes.

El primero en llegar fue Leonardo de Marco, que en estos días está cambiando su vida laborar, para dedicarse de tiempo completo al desarrollo de Smalltalk. Alejandro Reimonde, el "jefe" del grupo, llegó un poco más tarde de las 10hs. Otros miembros que asistieron fueron Esteban Lorenzano, Diego Coronel, Matías Castilla y Juan (sólo Juan, no tengo el apellido...).

Alejandro Reimondo es un referente en el campo del desarrollo en Smalltalk, conocido en el mundo, que ha trabajado desde hace décadas con esta tecnología. Es el fundador del grupo Smalltalking, dedicado a la difusión y discusión de desarrollo de software y más, con Ambientes de Objetes Virtuales. Ya había comentado por este blog sobre su actividad en el desarrollo de multitouch (ver Más sobre multitouch screen).

Esteban Lorenzano enseña arquitectura de proyectos IT, en la Universidad Tecnológica Nacional, de Buenos Aires. La página de la cátedra es:

http://apit.wikidot.com/

Es uno de los fundadores de la nueva empresa Smallworks, dedicada al desarrollo de software usando Smalltalk. Los fundadores son ex Snoop, entre ellos, veo a Evagenlista, al que conocí en algún curso mío hace años.

Diego Coronel tiene una compañía, Informagine (no dió el enlace, supongo que es http://www.informagine.com ), con trabajos para el estado argentina, usando Smalltalk, ahora está trabajando mucho con México. Vive en los dos paises. Curiosamente, Diego y Esteban conocían los mismo lugares de México DF, e intercambiaron impresiones sobre cómo es vivir en esa ciudad, y cómo México albergó y recibió a argentinos, tanto en los años difíciles del siglo pasado, como en este siglo, luego de la "debacle" de 2001.

Matías Castillas es estudiante, vino desde la La Plata (unos 70 km de Buenos Aires). Nos faltó otro platense, Elvio Fernandez, que esta vez no pudo asistir a la reunión. El año pasado, el bueno de Elvio fue anfitrión de otra reunión del grupo, donde hubo buenas charlas, discusiones, una raviolada, y algunas botellas de tinto, que muchos de los integrantes actuales estamos extrañando.

En esta reunión, como en otras, hubo varias discusiones, exposiciones, de distintos temas. Las reuniones no se organizan por temas y tiempo, o apenas, así que muchas veces derivan en temas que no se habían propuesto. Pero siguen siendo interesantes. Entre los temas discutidos estuvieron: la sustentabilidad del desarrollo de código abierto, la situación de la educaciónde objetos y conceptos de arquitectura en Argentina, la escasez de gente, en Smalltalk y otras tecnologías, la rotación de los desarrolladores en las compañías, y el alto salario que se ofrece a desarrolladores juniors, debido a la situación global del desarrollo, y el cambio peso/dólar en Argentina, que hace redituable el trabajo para el exterior.

Con respecto a la rotación, yo podría dar referencias de cómo no tener ese tipo de problema. Pero eso será tema de otros posts. En resumen: hay que dar el ambiente y los desafíos adecuados, para que la gente quiera seguir participando en la misma compañía. También, es importante elegir bien a la gente: es más importante tener la gente adecuada, con una actitud proactiva, y de constante aprendizaje y mejora, en vez de buscar "desarrolladores Java que conozcan Struts" o ese tipo de pedidos.

No se mencionó mucho sobre el tema de metodologías ágiles, que me parecen hoy por hoy, fundamentales para encarar el desarrollo con poca gente. He conocido casos de éxito (y también de fracaso) de excelentes desarrollo con poca gente. Incluso los fracasos enseñan qué tipo de proyectos y de gente necesitamos para avanzar, si tenemos una empresa o un grupo interno de desarrollo.

Alejandro comentó su viaje a Postdam, donde asistió a

Workshop on Self-Sustaining Systems (S3) 2008

The Workshop on Self-sustaining Systems (S3) is a forum for discussion of topics relating to computer systems and languages that are able to bootstrap, implement, modify, and maintain themselves. One property of these systems is that their implementation is based on small but powerful abstractions; examples include (amongst others) Squeak/Smalltalk, COLA, Klein/Self, PyPy/Python, Rubinius/Ruby, and Lisp. Such systems are the engines of their own replacement, giving researchers and developers great power to experiment with, and explore future directions from within, their own small language kernels.

Acá había posteado sobre el tema y el trabajo de Piumarta en:

Self-sustaining Systems, Cola, Pepsi, Coke y Mate

Alejandro comentó que le interesó el trabajo de Richard Gabriel, de IBM (su página personal y bio en Richard Gabriel personal page). Pueden ver el trabajo presentado por Gabriel en:

http://www.tele-task.de/page50_lecture3625.html

Esperamos que sea un tema a tratar en una próxima reunión de Smalltalking (con raviolada y pingüinos de tinto en lo de Elvio... ;-)

Pero la estrela de la reunión, fue Claus Gittinger, fundador de Exept Software AG, y creador de Smalltalk/X. Vino de Alemania, el viernes a la noche, por primera vez visita mi país. Pueden leer su perfil en LinkedIn, encontraran todos los trabajos del bueno de Claus, desde los ochentas. Ha trabajado en varias tecnologías y compañías. En 1995, funda Exept Software, que:

provides solutions, advice and consulting services in the Telecom, Automation, Automobile and other technology oriented software areas.
Products include a state of the art OO-development framework and environment (www.smalltalk-x.de) and frameworks for Test- and Qualitymanagement (www.expecco.de)

Claus se dedica a

Architecture, Project Management, Team Building and Leading, Coaching, Teaching, Testing, Test Management, Prototyping,
Programming Language Implementation, VM design & Implementation, Compiler Construction, IDE Design & Implementation, GUI Framework Design & Implementation, OS-Kernel, OO, Smalltalk, ESUG

También dicta cursos en una universidad de su país. Está visitando Argentina, acompañado de Félix Madrid, un desarrollador argentino que trabaja para Except en Alemania. Como escribía arriba, es la primera visita de Claus a la Argentina, espero que disfrute el viaje y la visita.

Smalltalk/X

Claus fue muy gentil, dedicándonos algunas horas a mostrarnos su trabajo, demostrarnos su producto Smalltalk/X (noto en Claus el entusiasmo de alguien que ha creado algo y lo ha llevado hasta el nivel de producto, fundando una empresa alredor de ese primer producto). Su empresa se dedica a otros temas (como el testing a partir de un modelo), estas son características de Smalltalk/X (disculpen que no traduzca):

Smalltalk/X, a product from eXept Software AG, is a complete implementation of the programming language, class library and development environment, providing:

An object-oriented programming language
Graphic development environment with editors, browsers, debuggers, GUI builders, etc.
Incremental compilation, byte code interpreter and dynamic (just in time) compiler
Static compilation and DLL generation, controlled by make-files
Comprehensive class library with ready-to-use modules for applications
Open Smalltalk source code

Implementation of the language and class library complies with the draft ANSI standard and the industry standard.

Claus nos mostró la compilación de archivos .st (con código fuente de Smalltalk) a archivos .stc que contiene código C, que puede compilarse en varias plataformas (en Windows, podemos compilar el sistema completo usando Borland C, o con Microsoft Visual C++). De esta manera, podemos producir programas nativos ejecutables desde nuestro proyecto Smalltalk. Más características de la documentación:

ST/X Smalltalk is a complete implementation of the Smalltalk language. Smalltalk/X is not based on the original ST-80 virtual machine implementation and has been written from scratch. However, the API, class libraries and language semantic is highly compatible to ST-80 based smalltalks, such as VisualWorks, Squeak and others.
Smalltalk/X consists of both an integrated environment for program development AND a standalone smalltalk compiler(1), which generates true machine code, shared code libraries and binary executables without a need for a so called "image". However, traditional image-based development is also supported and typically used for program development.
The programming environment includes editors, browsers, compiler and debugger and a large library of ready to use building blocks for application writers.
The standalone compiler generates true machine code from smalltalk source files - and can be used in a batch environment for production/delivery.
Features

Language syntax and semantic compatible to the industry standard, including arbitrary precision arithmetic and automatic number conversion, exception handling, automatic memory management, threads, contexts, blocks (block closures), metaprogramming and much more.
Additional (mostly backward compatible) extensions to the smalltalk language include: private classes, multiple namespaces, method privacy and end of line comments.
A comprehensive threadsafe library of basic classes, including collection classes, numeric classes, streams, lightweight processes, exception handling and metaclass hierachy.
Many user interface widget classes usable as building blocks for graphical applications. These are fully (non-polling) event driven, multithreaded and support multiple displays, parametrized view styles, wide characters (unicode) and national languages.
Integrated programming environment including browsers with sophisticated refactoring and code generation support, GUI- and Menu builders, monitors and symbolic debugger for efficient program development.
The additional Scripting Engine allows for command-line execution of smalltalk scripts. These script files can be generated by any other editor, or alternatively by saving code from the IDE (file-out from the browser).
Debug once - run everywhere !
complete Source- and Byte-Code compatibility between Unix and Windows versions. Write your application once, run it without change on Win-NT, Linux, Alpha-OSF, Sun-solaris, HPUX, AIX, Silicon-Graphics IRIX(4).
Many demo and 'how-to' example programs
Online HTML documentation and class documentation generator, visualized by the ST/X HTML document viewer.
Well documented classes and methods.
Very liberal licensing conditions

Implementation hilights

Incremental compilation to internal bytecodes for short turn around cycles during development.
Binary files containing bytecode are portable across different machine architectures.
Dynamic (just-in-time) compilation from internal bytecodes to machine code (2).
Except for the faster execution, this is transparent to the program or user.
Batch compilation to real machine code for high performance production code, enabling the creation of binary object modules, class libraries or even shared class libraries.
Since more optimizations and code analysis are performed by this (offline) compiler, the resulting code executes faster - even when compared to dynamic compiled machine code.
Although static compiled machine code leads to bigger executables, the main advantage (beside faster execution) is the deterministic runtime behavior, which cannot always be guaranteed, if bytecodes are compiled dynamically at execution time.
In addition, big applications benefit from static compilation by the sharability of this compiled code among multiple applications, if shared libraries and/or shared text segments are supported by the operating system.
Applications can (and do) use a mix of precompiled machine code classes and interpreted bytecode classes - this is transparent to the program or programmer.
If supported by the operating system (3), machine compiled modules can be dynamically added to and removed from the running system.

Easy creation of standalone executables and applications without graphical user interfaces. This includes self-extracting installation code for windows platforms (null-soft self installing executables).
Easy binding to C-language by allowing inline c code (even inline assembler by using asm statements) or via the ffi-callout mechanism to dynamically loaded shared libraries (dll's).
Sophisticated window interface combining event and process driven techniques.
ST/X supports multiple display devices - you can work with others in the same object environment, or write applications which serve multiple screens.
Your application can even run on a display-less host, serving multiple xTerminals or client applications via TCP connections.
Additional protocol provided in the process, semaphore and processor classes, for better thread synchronization. ST/X's process handling includes additional mechanisms for recovery (semaphore cleanup) in exceptional situations, which is required in technical applications. The ST/X's process scheduler supports timeSlicing and dynamic thread priorities. This allows for better response behavior in multiwindow applications and allows progress of background processes even in case of busy foreground processing.
Modern generational garbage collector, with dynamic adjustable newSpace, adaptive tenuring, both incremental and non-incremental collectors for the oldSpace, both copying and non-copying compressors for the oldSpace.
Object finalization via the WeakArray mechanism; in addition, a number of other collection classes are available with weak references (WeakSet, WeakDictionary etc.)
Both ANSI compliant class based exceptions and (VW-) backward compatible Signal-based exceptions are supported.
In addition, process specific and global default exception handlers are avaliable, to allow for non scoped, global exception handling.
The byteCode interpreter and just-in-time compilers support multiple bytecode sets, for total integration of different languages into a single unified system.
In the current release, this feature is used to support execution of compiled Java code.

Claus también mostró que se puede compilar al vuelo, en el entorno de desarrollo. Uno puede escribir un método, y se traduce a los bytecodes clásicos de una máquina virtual Smalltalk. Pero durante su ejecución, esos bytecodes se compilan a código nativo.

Es aquí donde atiborré de preguntas al paciente de Claus. Su implementación se desvía de una implementación clásica de Smalltalk, no es una implementación como otras. Esto para mí es interesante, así que pregunté en detalle algunos temas.

Smalltalk/X no usa una tabla de objetos, con lo cual cada objeto apunta directamente a otros objetos. Esto facilita algunas cosas, pero complica otras, como el ajuste de los "punteros" durante el proceso del garbage collector (garbage collector), la implementación de become: es prácticamente difícil (no ví todavía si consigue implementarlo Smalltalk/X), y el garbage collector tiene que tomar control en algún momento, para ajustar todos los objetos. El garbage collector es un mark and sweep, con copy de objetos. No usa generaciones de objetos, aunque mantiene un age en la cabecera de cada objeto. (Corrección, el bueno de Claus me comenta en Smalltalking meeting, with Claus Gittinger and Smalltalk/X que lo de mark and sweep, es sólo una de cuatro estrategias, y se aplica solamente a los objetos viejos).

Podemos bajar los binarios del sistema, o podemos bajar el CVS de la compañía (esten preparados para un download con tiempo: son más de 20000 files, >180 megas, a mí me tomó algunas horas de bajada).

Como notan, estuve muy interesado en los detalles de implementación de la VM. Me interesó desde siempre la construcción de ese tipo de sistemas, pueden leer algo de lo que estoy haciendo con mi trabajo en progreso sobre el AjTalk en AjTalk- un intérprete tipo Smalltalk). Algo interesante: como genera código C, en los archivos .st se pueden incluir fragmentos de ese lenguaje, además de llamadas a las clásicas primitivas. Por ejemplo, en el archivo Object.st, que define la conducta de Object, encuentro:

basicAt:index
    "return the indexed instance variable with index, anInteger..."

...

%{  /* NOCONTEXT */

    REGISTER int nbytes, indx;
    OBJ myClass;
    REGISTER char *pFirst;
    REGISTER int n;

...
    if (__isSmallInteger(index)) {
    myClass = __qClass(self);
    indx = __intVal(index) - 1;
    n /* nInstVars */ = __intVal(__ClassInstPtr(myClass)->c_ninstvars);
    n /* nInstBytes */ = OHDR_SIZE + __OBJS2BYTES__(n /* nInstVars */);
    nbytes = __qSize(self) - n /* nInstBytes */;
    pFirst = (char *)(__InstPtr(self)) + n /* nInstBytes */;

...

}%

Despues de pasearlo por temas de implementación, Claus nos siguió mostrando temas del entorno gráfico de desarrollo, con los clásicos workspaces, browsers, implementados directamente en Smalltalk. El producto de Claus maneja directamente distintas implementaciones GUI, sean Windows, Unix, Linux, y demás. Desde un entorno GUI que trae el producto, podemos definir controles, formularios, asociarlos a métodos. También hay soporte de MVC (Model View Controller), donde rápidamente el valor de un control puede modificar el modelo, y su cambio se refleja en otros controles, si queremos. Claus igual comentó que los controles los tienen que diseñar ellos, cuando en el mercado aparece un nuevo tipo de control, por ejemplo, una grilla, ellos no la aprovecha, sino que la implementan en su base de código. Eso permite que ese nuevo control, automáticamente esté disponible en todas las plataformas donde ejecuta Smalltalk/X. Pero imagino que se complica estar al día en el desarrollo de widgets gráficos.

También mostró un servidor HTTP. Con el servidor HTTP funcionando, uno puede definir clases que atiendan pedidos por URL. Implementamos un método que recibe un objeto request, de ese objeto obtenemos un response, y con éste, comenzamos a emitir el contenido del documento, generalmente un HTML. No llegué a ver el soporte que tiene de controles dentro de una página. No llegué a probar eso en mi máquina todavía, y no vi "screenshots" en el sitio de Exept.

Independientemente de Smalltalk/X como producto, si estan interesados en Smalltalk, pueden visitar la página de enlaces y la de documentación (con libros sobre Smalltalk, para bajarse libremente).

Gracias desde acá a Claus Gittinger, por dedicarnos tiempo y compartir su conocimiento con todos. Fue una interesante reunión. Claus es alguien que cumple con el mindset Don't be a canuto.

No estuve hasta el final (tuve que ir a dar mi charla de Microsoft Robotics, en Puerta 18, más datos en Robótica en Puerta 18). Una de las últimas preguntas mías a Claus, fue si usan metodologías ágiles en su empresa. Contestó que sí, pero hubiera sido interesante conversar más en detalle. (Curiosamente, uno de mis contactos en LinkedIn que me unen a Claus, es el bueno de Tobias Mayer, que fue mi entrenador en Scrum).

Espero que tengamos por lo menos una reunión más este año de Smalltalking. Tengo minutas de otras reuniones anteriores, tengo que pasarlas en limpio, ya aparecerán por aquí en formato post. Ya conocen el otro mindset: Lo que no está escrito, no existe. ;-)

Nota adicional: Alejandro, en ánimo turístico, nos comentó sobre el monte del infierno, en las afueras de Berlin. Pueden ver la ciudad desde ese "monte" artificial, armado con los escombros que quedaron al final de la segunda guerra mundial, desde

http://www.panoramio.com/photo/7847858

También comentó sobre Praga, una ciudad que no fue afectada por bombardeos, y no tuvo que ser reconstruida:

http://www.panoramio.com/user/592876/tags/Praga

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com

Nuevo sitio dedicado a Smalltalk: ClubSmalltalk.org

lopez — Sun, 24 Aug 2008 16:01:14 GMT

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/

Smalltalks 2008 en Argentina, Call for Papers

lopez — Fri, 22 Aug 2008 13:56:50 GMT

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

Enlaces y noticias

lopez — Thu, 24 Jul 2008 11:48:44 GMT

Hay varios temas de los que quisiera bloguear más en detalle. Pero vaya hoy una lista de enlaces y comentarios cortos:

Primero de todo, tenemos nuevos Microsoft MVPs por aquí en Argentina, felicitaciones a Rodolfo Finochietti, Pablo Galiano, y al pibe Matías Woloski. El bueno de Finochietti visita de vez en cuando este blog, y deja comentarios, por ejemplo, sobre programación funcional y el lenguaje Cat. Tenemos varios intereses en común, como el estudio de lenguajes, compiladores, y compartimos la afición por la historia de las matemáticas.

Si se interesan en Smalltalk, es interesante The Smalltalk programming language.

Gracias al bueno de Martin Salias, que me avisó de este texto en la web The Early History of Smalltalk de Alan Kay (yo había anunciado una versión en PDF en La historia de Smalltalk). Es un "DEBESERLEIDO" por todo aquel que esté realmente interesado en la programación. Uno debe conocer la historia de las ideas, para realmente entender la situación actual tanto de ideas, como de tecnologías, y para tener un "grasp" de lo que podría venir.

Modu: gracias al twitter de @parancibia, vean este mobile modular. Muy interesante el concepto.

De vez en cuando, Microsoft Directions publica un artículo público. Lean Software Plus Services and Developers. ¿The next big thing?

Dentro del proyecto NHContrib, de herramientas para NHibernate, existe NHibernate.LINQ, que permite usar LINQ sobre NHibernate. Vean ahora lo que se hizo con Silverligh en Silverlight 2 + NHibernate.LINQ == Sweet y el ejemplo de nhibernate con Northwind

Para aprender NHibernate NHibernate - Relational Persistence for Idiomatic .NET. Si quieren contribuir al proyecto hibernate.org - Getting Started with the NHibernate Source Code. Si tienen dudas, ver la lista de NHibernate Hispano.

Siguiendo con LINQ, leo cómo usar un DataContext en memoria, esta vez desde ASP.NET MVC, en ASP.NET MVC Tip #21 – Fake the Data Context

Las aventuras de Scott Hanselman para agregar un OpenSearch en sus páginas: Adding OpenSearch to your website and getting in the Browser's Search Box

Steve Clayton está en Software + Services en Microsoft. Lean su encuentro con Ray Ozzie, no puede decir todo, pero S+S se viene cada vez más. El tiempo dirá qué será eso.

No llegué a tiempo para anunciarla. Diego Jancic realizó una encuesta en línea sobre cómo programamos. Vean los resultados en el blog de Darío Quintana.

El Composite Application Guidance para WPF tiene su nueva página en MSDN.

Jeff Atwood tiene algunas ideas interesantes y discutibles sobre no normalizar base de datos.

.NET Terrarium está de vuelta!

Me interesó el proyecto Jackrabbit, tengo que estudiar más en detalle la especificación Content Repository API de la JSR-170.

Twitter adquiriendo a Summize.

Y hay que visitar y usar 10 herramientas para un tech.

Nuevo Blog de la comunidad MSDN en español. Gracias a Miguel Angel Saez por el aviso.

Si alguien necesita acá está: Implementing Finite State Machines with Physhun and Spring (en Java)

Cada vez más lenguajes dinámicos sobre máquinas virtuales, ver Java 6: Using Python via the new Scripting Engine.

Interesante código y artículo, sobre un tema que se necesita conocer: Single Sign-on in ASP.NET and Other Platforms

Para entender la historia de MVC: The Model-View-Controller, Its past and present

Más sobre Model-View-Controller, Model-View-Presenter, y Presentation-Abstraction-Control en Interactive Application Architecture Patterns.

MVC en ASP.NET en ASP.NET MVC - The Official Microsoft ASP.NET Site

Una interesante comparación de David Hayden ASP.NET MVC Framework Compared To Web Client Software Factory ( WCSF )

¿Necesitan un manejar un proyecto de software? No lo uso, vería el open source Trac Project, via web en Java (gracias a J. Franco, por este enlace). Al parecer, trabaja con Subversion.

¿Necesitan open source en Java? De todo en http://java-source.net/.

Off topic total: mi mejor post hasta ahora del 2008, con gráfica incluida, en Posmopolitan.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
http://friendfeed.com/ajlopez