Donde "reimplementar" quiere decir, entre otras cosas, "crear un monton de cosas que en 32 bits no existen" :).
2010/10/7 Angel Java Lopez <[email protected]>: > Hola gente! > > Guillermo, son decisiones personales. Hace varios anios vi la maquina > virtual de Squeak, e implementar cada cosa que se me ocurria, por lo menos a > mi, me tomaba mas tiempo que armar una maquina virtual mia, directamente. Al > llegar a una maquina virtual ya armada, es como ya tomaron decisiones, que > quien sabe si los voy a encontrar alineadas con lo que quiero. > > Vean que hasta a la gente de Valloud se les complican algunas cosas, como > pasar de 32 a 64 bits, reimplementando la VM que ellos mismos armaron. > > Lo mio es mas artesanal. Un subproducto interesante, por lo menos para mi, > es el gran trabajo de TDD que he aprendido a hacer. > > Igual, ahora, el enfasis mio esta puesto en practicar armar VM, no en > aprender como implementarlo en Smalltalk o Squeak una feature. Por eso, > durante varios meses, apenas mencione este tema en la lista, porque veia que > aca era mas orientado a Smalltalk. Solo comence a mencionarlo, cuando se > planteo el tema de la nueva VM que comento Leo di Marco hace un par de > meses, y ahora, que se planteo que es objeto, y Valloud comento lo de enviar > un mensaje y quedarse esperando. > > Y al armar la VM artesanalmente, es como que uno va viendo crecer el bebito > de chiquito, y no lo encuentra ya grandulon y fumando con barba ;-) > > Podria decirse que es un balanceador de carga. La idea es que: > > - Puedo tener trabajo para hacer, en una aplicacion o varias, corriendo en > una maquina > - Si aparecen maquinas por ahi, que las aplicaciones que esten corriendo > puedan derivar trabajo a esas otras maquinas > - Que el programador (pobre como yo .. ;-) que tiene una sola maquina, igual > pueda correr la aplicacion apenas cambiandola > - Que el programador, cuando sepa que hay mas maquinas o que pueden aparecer > dinamicamente, pueda, apenas cambiando algo, aprovecharse de esos nuevos > recursos > - Una maquina nueva, no sabe de antemano que elementos (clases, objetos, > metodos con codigo o compilados, lo que sea) necesita, se lo debe poder > enviar en el momento > > Tengo mis dudas de llamarlo balanceador de carga. Pero si, se aproxima por > lo menos. > > Nos leemos! > > Angel "Java" Lopez > http://www.ajlopez.com > http://twitter.com/ajlopez > > > 2010/10/7 Guillermo Schwarz <[email protected]> >> >> Bueno sería "kiego divegtigme" o "quiero divertirme", lo otro no sé qué >> sería... ;-) >> Supongo que lo que estás haciendo es un balanceador de carga, de otra >> manera no se entiende porque el nodo M1 no tiene el código ya alojado y >> simplemente recibe una petición en texto mediante un socket. >> Entonces si estás haciendo un balanceador de carga en el que te das cuenta >> que una operación tomará mucho tiempo y muchos recursos, creas el objeto en >> otro nodo y lo hechas a correr. >> Lo mismo podría pasar si tienes 5 porcesos que piensas que se van a >> demorar 1 segundo cada uno y lleva 1 minuto cada uno y no termina, si tienes >> 4 CPUs desocupadas los puedes mandar a terminar allá y quedarte solo con >> uno. >> Lo que yo haría sería hacerlo más rápido con Proxy y cunado esté listo ver >> si lo implemento en la VM sale más rápido. Debería, para que valga la pena >> implementarlo a nivel de VM, pero sospecho que no.¿Porqué? Porque alguna vez >> corrí Squeak dentro de Squeak. La VM de Squeak está escrita en Squeak. No sé >> si eso te dice algo. Si se te ocurre una optimización, es mucho más fácil >> escribirla en Squeak que en C o assembly language. Luego pasarla a la VM >> debiera ser trivial. >> A nivel de la CPU todos los objetos son bytes, casi no hay abstracción. A >> nadie se le ocurriría impementar un webserver en assembly language. ¿Cuál >> sería el objetivo de aprender a interactuar con elementos de tan bajo nivel >> si en la práctica todo eso puede ser reescrito en Squeak en 16 semanas? >> "By following this plan, facilities became available just as they were >> needed. For example, the interpreter and object memory were debugged using a >> temporary memory allocator that had no way to reclaim garbage. However, >> since the system only executed a few byte codes, it never got far enough to >> run out of memory. Likewise, while the translator was being prepared, most >> of the bugs in the interpreter and object memory were found and fixed by >> running them in Smalltalk. >> It was easy to stay motivated, because the virtual machine, running inside >> Apple Smalltalk, was actually simulating the byte codes of the transformed >> image just five weeks into the project. A week later, we could type "3 + 4" >> on the screen, compile it, and print the result, and the week after that the >> entire user interface was working, albeit in slow motion. We were writing >> the C translator in parallel on a commercial Smalltalk, and by the eighth >> week, the first translated interpreter displayed a window on the screen. Ten >> weeks into the project, we "crossed the bridge" and were able to use Squeak >> to evolve itself, no longer needing to port images forward from Apple >> Smalltalk. About six weeks later, Squeak's performance had improved to the >> point that it could simulate its own interpreter and run the C translator, >> and Squeak became entirely self-supporting." >> >> Fuente: http://www.cosc.canterbury.ac.nz/wolfgang.kreutzer/cosc205/squeak.html >> Saludos, >> Guillermo. >> >> 2010/10/7 Angel Java Lopez <[email protected]> >>> >>> Hola gente! >>> >>> Si, con respecto a los numeros y strings. >>> >>> Igual, todavia no llego un caso de uso que necesite que un objeto se cree >>> aca en N, y luego viaje a M. Mis casos de uso son: la clase X esta en N, y >>> necesito crear un objeto/agente que trabaje en nodo M1 (y quizas otro en M2 >>> y asi), aun cuando esos nodos no conozcan la clase X. >>> >>> E insisto, quiero hacerlo en la VM! Quiero divegtigme con eso! ;-)... >>> >>> Y en otros casos donde lo hice (el tema de levantar objetos remotos, en >>> otros nodos, en el caso de AjSharp), todavia no tuve los problemas que >>> mencionas. Mi approach no genera codigo, solamente uso dos o tres clases >>> escritas en la vm base (en este caso la VM .NET) que implementan las >>> primitivas necesarias para eso, y voila. Si alguna vez veo que esas clases >>> las puedo remover (luego de haberlas usado como apoyo de scaffolding), y >>> pasar a implementar esa funcionalidad en el lenguaje de "arriba" (AjTalk en >>> este caso) lo hare. Mientras, este approach me permite seguir jugando, >>> rapidamente. >>> >>> Nos leemos! >>> >>> Angel "Java" Lopez >>> http://www.ajlopez.com >>> http://twitter.com/ajlopez >>> >>> >>> 2010/10/7 Guillermo Schwarz <[email protected]> >>>> >>>> Pero de alguna manera hay que decirle que los números y los strings no >>>> los "remotee". >>>> Como son más los objetos locales que los remotos y deseas usar los >>>> objetos remotos como si fueran locales, proxy está pintado para eso. No >>>> creo >>>> que sea necesario intervenir la VM. >>>> De hecho la experiencia en Java en ese caso ha sido desastrosa: Usar >>>> generación de código que interviene las llamadas para hacerlas remotas, con >>>> todos sus stubs y todas esas payasadas, resutla ser muy pesado, mucho >>>> código >>>> generado (CORBA) y cuando hay algún tipo de error por que el generador de >>>> código que interviene las llamadas para "remotearlas" ha fallado o generado >>>> código incompatible con "algo", put your head between your legs and kiss >>>> your but goodbye ;-) >>>> En el caso de usar proxy es trivial y liviano y si el mecanismo funciona >>>> para uno, funciona para todos. >>>> Saludos, >>>> Guillermo. >>>> >>>> 2010/10/6 Angel Java Lopez <[email protected]> >>>>> >>>>> Hola gente! >>>>> >>>>> Si, lo he visto, no solo en Smalltalk. >>>>> >>>>> La idea es hacerlo transparente, ponerlo a nivel de VM, sin necesidad >>>>> de eso, y explorar que se puede hacer de interesante con eso. Por ejemplo, >>>>> una VM con esa capacidad, puedo implementar otro lenguaje encima de esa >>>>> VM, >>>>> no necesariamente Smalltalk. >>>>> >>>>> Y no quiero enviar todos los objetos relacionados. Solo los que >>>>> necesito poner en otra maquina. >>>>> >>>>> Nos leemos! >>>>> >>>>> Angel "Java" Lopez >>>>> http://www.ajlopez.com >>>>> http://twitter.com/ajlopez >>>>> >>>>> 2010/10/6 Guillermo Schwarz <[email protected]> >>>>>> >>>>>> En Smalltalk lo que dices de migrar un objeto de una máquina a otra es >>>>>> (o debería ser) trivial. >>>>>> 1. Se serializa la clase en la máquina 1 (representación en texto). >>>>>> Hay bibliotecas para hacer eso que recojen incluso todos los objetos >>>>>> relacionados. Se debe incluir el método y la línea que estaba ejecutando, >>>>>> eso es trivial con thisContext. >>>>>> 2. Se envía a la máquina remota, se deserializa y se le indica al >>>>>> "thisContext" que continúe ejecutando. >>>>>> No lo he probado, pero debería funcionar. ;-) >>>>>> Lo que sí he probado es tener objetos remotos persistentes. Es muy >>>>>> parecido. >>>>>> 1. Creo una clase PersistentRemoteDictionary que serialice los objetos >>>>>> y lso envíe a través de un socket a un servidor ejecutando C++ o Java. >>>>>> 2. En el servidor coloco GDBM o JDBM e implemento put y get. (#at:put: >>>>>> y #at: sería el equivalente en Smalltalk). >>>>>> Listo. ;-) >>>>>> Ahora cualquier Dictionary se puede reemplazar >>>>>> por PersistentRemoteDictionary y puedo tener todos los clientes Smalltalk >>>>>> que quiera compartiendo los objetos a través de un servidor, como un >>>>>> PoorManObjectDatabase y el desempeño es como correr local, porque los >>>>>> sockets son super eficientes y JDBM también. >>>>>> Saludos, >>>>>> Guillermo. >>>>>> >>>>>> 2010/10/6 Angel Java Lopez <[email protected]> >>>>>>> >>>>>>> Hola gente! >>>>>>> >>>>>>> Guillermo, no, todavia no lo he intentado, lo de los objetos remotos. >>>>>>> >>>>>>> Con respecto a los threads del sistema operativo, no habria problema >>>>>>> en reimplementar el dispatching de los mensajes a los agentes de esta >>>>>>> forma: >>>>>>> >>>>>>> - En vez de tener una cola por agente, hay una sola cola con >>>>>>> <mensaje>, con <mensaje, receptor> >>>>>>> - N threads consumiendo esa cola, y enviando el mensaje al agente >>>>>>> correspondiente. >>>>>>> >>>>>>> De nuevo, es un cambio en la VM, nada de lo escrito en AjTalk con >>>>>>> agentes deberia cambiar, tengo los tests de TDD para asegurarme que eso >>>>>>> se >>>>>>> cumpla (espero ... :-). >>>>>>> >>>>>>> No estoy tan seguro que los threads del sistema operativo sean los >>>>>>> mismos que la VM: una VM tiene un concepto de thread mas logico aun. >>>>>>> Solo un >>>>>>> thread de la VM activo necesitaria un thread del sistema operativo. Por >>>>>>> lo >>>>>>> menos, en .NET, hay una propiedad del thread llamada ManagedId, que >>>>>>> recuerde, que no parece tener una aplicacion directa a tal thread del >>>>>>> sistema operativo. >>>>>>> >>>>>>> Lo de objetos remotos, lo tengo en AjShap, todavia me falta ponerlo >>>>>>> en AjTalk. >>>>>>> >>>>>>> Me gustaria: >>>>>>> >>>>>>> - Definir una clase en la maquina M, poder instanciar un nuevo objeto >>>>>>> en la maquina N (viajando de alguna forma la definicion de la clase >>>>>>> definida). >>>>>>> - Definir una clase en la maquina M, crear una instancia en esa >>>>>>> maquina, y hacerla viajar a la maquina N (mas dificil: si la instancia >>>>>>> tiene >>>>>>> referencias a otros objetos, que objetos hacemos viajar a N y cuales >>>>>>> permanecen como una referencia remota en N al objeto en M?). >>>>>>> >>>>>>> Si traslado lo de AjSharp, podria ponerlo en AjTalk como en el nodo M >>>>>>> >>>>>>> MiClase at: <objetoquedescribeelnodoremotoN> new: .... >>>>>>> >>>>>>> Me quedaria en M un objeto cuyos mensajes son reenviados a la >>>>>>> instancia recien creada del nodo N. >>>>>>> >>>>>>> Nos leemos! >>>>>>> >>>>>>> Angel "Java" Lopez >>>>>>> http://www.ajlopez.com >>>>>>> http://twitter.com/ajlopez >>>>>>> >>>>>>> >>>>>>> Nos leemos! >>>>>>> >>>>>>> Angel "Java" Lopez >>>>>>> http://www.ajlopez.com >>>>>>> http://twitter.com/ajlopez >>>>>>> >>>>>>> >>>>>>> 2010/10/6 Guillermo Schwarz <[email protected]> >>>>>>>> >>>>>>>> Tengo entendido que la mayor parte de los sistemas operativos tienen >>>>>>>> un limite de entre 256 y 1024 threads, e incluso algunas versiones de >>>>>>>> linux >>>>>>>> soportan 8192 threads y no tienen problemas de desempeño. >>>>>>>> Pero una vm de smalltalk debe tener unos 5000 objetos activos (no lo >>>>>>>> he revisado pero no creo que pueda tener menos), y un seaside con 10 >>>>>>>> mil >>>>>>>> conexiones activas se iría de espaldas rapidamente usando tu diseño. >>>>>>>> Si queremos tener arquitecturas escalables, debemos limitar el uso >>>>>>>> de recursos que a nivel del sistema operativo son limitados. >>>>>>>> A todo esto, tu diseño parece que podría de manera trivial publicar >>>>>>>> objetos para ser llamados de manera remota. ?lo haz intentado? >>>>>>>> >>>>>>>> Saludos, >>>>>>>> Guillermo Schwarz. >>>>>>>> El 06-10-2010, a las 11:18, Angel Java Lopez <[email protected]> >>>>>>>> escribió: >>>>>>>> >>>>>>>> Hola gente! >>>>>>>> >>>>>>>> Guillermo, me parece interesante ponerlo ya a nivel de la >>>>>>>> expresividad de un lenguaje, que esa conducta "envio mensaje y sigo >>>>>>>> con mis >>>>>>>> cosas" se vea como natural, ya puesto en el mensaje. Podria >>>>>>>> implementar eso >>>>>>>> directamente en el proceso de mensaje de agente1, para que sea >>>>>>>> transparente >>>>>>>> para el llamador, pero me parecio interesante (me tomo menos de una >>>>>>>> hora, >>>>>>>> usando TDD) directamente ponerlo en la VM. >>>>>>>> >>>>>>>> Los threads en .NET son, digamos, logicos. Lo mismo, que recuerde, >>>>>>>> en Java. Las VM luego mapearan los threads a lo que haya disponible en >>>>>>>> los >>>>>>>> sistemas operativos, hardware, y demas que se encuentren hoy o el dia >>>>>>>> de >>>>>>>> maniana. Bloquear un thread, no lo deja "ocupado". Y aun los threads >>>>>>>> de un >>>>>>>> sistema operativo, son, digamos, virtuales. Lo real es la asignacion >>>>>>>> de un >>>>>>>> thread a un procesador. Lo que si consume un thread es memoria en algun >>>>>>>> lado, para mantener su estado, aun cuando este suspendido. Pero >>>>>>>> imagino que >>>>>>>> la parte del leon, en eso, se la lleva el proceso, mas que el thread. >>>>>>>> >>>>>>>> Puedo copiar objetos, pero la idea es: si copio objetos y los coloco >>>>>>>> en la misma maquina, puedo mejorar algo el rendimiento de la >>>>>>>> aplicacion. >>>>>>>> Pero mas interesante de explorar, es copiar los objetos en OTRAS >>>>>>>> maquinas, >>>>>>>> de forma que sea transparente >>>>>>>> >>>>>>>> agente1 doSomething: param1 with: .... >>>>>>>> >>>>>>>> que agente1 este local o remoto. Por supuesto, el programador de la >>>>>>>> aplicacion debera ver que esa llamada tiene un costo. Pero mi idea, es >>>>>>>> que >>>>>>>> si el agente1 es local o remoto, sea algo que se decida en otro lado >>>>>>>> del >>>>>>>> codigo (o configuracion), sin tener que cambiar el codigo de la >>>>>>>> aplicacion. >>>>>>>> De esta forma, puedo probar un algoritmo, aplicacion, de forma local, y >>>>>>>> luego, comenzar a distribuirla y hacer escalamiento horizontal. El >>>>>>>> ejemplo >>>>>>>> que uso es un Web Crawler. Ahi en las referencias que envia, habia >>>>>>>> algunas >>>>>>>> implementaciones. >>>>>>>> >>>>>>>> Tambien, la idea (tengo algo en AjSharp implementado) es que agente1 >>>>>>>> en realidad, sea local, y haga una especie de load balancing con varios >>>>>>>> objetos remotos. Por ejemplo, en un web crawler, podria enviar >>>>>>>> >>>>>>>> downloader downloadUrl: ´http://mycompany.com´ >>>>>>>> >>>>>>>> y downloader por abajo, envia ese trabajo (bajar tal pagina) a si >>>>>>>> mismo, o enviarlo a cualquiera de los 400 downloaders que tendria en mi >>>>>>>> laboratorio... mmmbuajjajaja... :-) >>>>>>>> >>>>>>>> Tanto AjSharp como AjTalk (y otros Aj ... :-)... como AjBasic, >>>>>>>> AjGenesis, AjLisp, AjProlog....), se pueden reimplementar en Java: >>>>>>>> practicamente no estoy usando nada especial de .NET, por ahora. Por >>>>>>>> ejemplo, >>>>>>>> cuando comence a escribir algunos de esos, en .NET tenia Generics y en >>>>>>>> Java >>>>>>>> todavia no: y no use generics, recien ahora lo estoy usando >>>>>>>> minimamente. En >>>>>>>> el caso de objetos distribuidos, si, hay algo que uso para hacerlo >>>>>>>> rapido: >>>>>>>> Remoting binario en .NET, tendria que investigar el estado del arte de >>>>>>>> la >>>>>>>> serializacion en Java. >>>>>>>> >>>>>>>> Nos leemos! >>>>>>>> >>>>>>>> Angel "Java" Lopez >>>>>>>> http://www.ajlopez.com >>>>>>>> http://twitter.com/ajlopez >>>>>>>> >>>>>>>> 2010/10/6 Guillermo Schwarz <[email protected]> >>>>>>>>> >>>>>>>>> Autopoyesis es copia, no autoorganización. Que conduzca a la >>>>>>>>> autoorganización es otra cosa. >>>>>>>>> ¿Como es eso de que te llamas Angel Java Lopez e implementas un >>>>>>>>> Smalltalk asíncrono en C#? ;-) >>>>>>>>> ¿Porqué no usas colas de mensajes y un colocas los objetos sobre un >>>>>>>>> thread en la medida que lo van necesitando? Sí, lo de lo mensajes lo >>>>>>>>> hiciste, y lo del watermark (que se queden pegados los enviadores >>>>>>>>> cuando se >>>>>>>>> llena la cola también), lo interesente es que los objetos enviadores >>>>>>>>> se >>>>>>>>> queden bloqueados pero los threads no, para reutilizar los threads >>>>>>>>> con otros >>>>>>>>> objetos. >>>>>>>>> (Eventualemtne sospecho que los sistemas operativos harán esto, >>>>>>>>> pero en el intertanto...) >>>>>>>>> Podrías además crear copias de los objetos que reciben los mensajes >>>>>>>>> para que operen más rápido. Claro que todo esto serían un overkill si >>>>>>>>> no lo >>>>>>>>> aplicas en algo que lo necesite, como por ejemplo pdoría ser en >>>>>>>>> slashdot. >>>>>>>>> Saludos, >>>>>>>>> Guillermo. >>>>>>>>> >>>>>>>>> 2010/10/6 Angel Java Lopez <[email protected]> >>>>>>>>>> >>>>>>>>>> Hola gente! >>>>>>>>>> >>>>>>>>>> El termino autopoyesis me parece innecesario, ya estaba el termino >>>>>>>>>> autoorganizacion. Con eso basta. Hmmm... supongo que el clasico a >>>>>>>>>> leer sobre >>>>>>>>>> la vida, es el clasico de Monod, Azar y Necesidad. Supongo que un >>>>>>>>>> tema >>>>>>>>>> relacionado a intencionalidad en organismos y evolucion biologica, >>>>>>>>>> seria >>>>>>>>>> teleologia. Leeria ahi a Ernst Mayr, que distingue varias acepciones >>>>>>>>>> de esa >>>>>>>>>> palabra. >>>>>>>>>> >>>>>>>>>> Con respecto a los mensajes y su envio, en este thread Valloud >>>>>>>>>> habia mencionado algo como "un objeto envia un mensaje a otro, y se >>>>>>>>>> queda >>>>>>>>>> esperando la respuesta". Siempre me parecio interesante ir a >>>>>>>>>> explorar otro >>>>>>>>>> camino "un objeto envia un mensaje a otro" y ya esta. Es asi como >>>>>>>>>> funcionan >>>>>>>>>> las partes de los sistemas vivos. >>>>>>>>>> >>>>>>>>>> En mi caso, lo estoy implementando en mi VM pet project, AjTalk >>>>>>>>>> [1]. Tengo algo como >>>>>>>>>> >>>>>>>>>> Object agent:.... >>>>>>>>>> en lugar >>>>>>>>>> Object subclass:.... >>>>>>>>>> >>>>>>>>>> Lo llame agent como podria llamarlo de otra forma. Entonces, los >>>>>>>>>> objetos de esa clase que se define, tienen metodos, todo igual, pero >>>>>>>>>> cuando >>>>>>>>>> uno envia un mensaje tipo >>>>>>>>>> >>>>>>>>>> agente1 msg: par1 with: ... "o lo que sea" >>>>>>>>>> >>>>>>>>>> el enviador del mensaje no se queda esperando la devolución. Y el >>>>>>>>>> objeto agente va atendiendo los mensajes que le llegan de a uno >>>>>>>>>> (actualmente, en un thread aparte, para cada agente, pero podria >>>>>>>>>> cambiar la >>>>>>>>>> implementacion). También implementé que la cola de mensajes del >>>>>>>>>> agente, >>>>>>>>>> tenga un tamaño limitado, asi si hay varios que producen mensajes >>>>>>>>>> para ese >>>>>>>>>> agente, y la cola de mensajes se llena, automaticamente se van >>>>>>>>>> suspendiendo >>>>>>>>>> a los threads/procesos del objetos enviadores, reanundando su >>>>>>>>>> actividad ni >>>>>>>>>> bien tienen lugar en para dejar su mensaje en la cola de mensajes del >>>>>>>>>> agente. Espero producir asi una auto-regulacion de las velocidades de >>>>>>>>>> produccion y atencion de los mensajes. >>>>>>>>>> >>>>>>>>>> La idea, es conseguir tambien objetos y agentes distribuidos, como >>>>>>>>>> en AjSharp [2], en varias maquinas. Pero para eso me falta un >>>>>>>>>> poco... :-) >>>>>>>>>> >>>>>>>>>> [1] http://code.google.com/p/ajtalk >>>>>>>>>> [2] http://ajlopez.wordpress.com/category/ajsharp/ >>>>>>>>>> >>>>>>>>>> Nos leemos! >>>>>>>>>> >>>>>>>>>> Angel "Java" Lopez >>>>>>>>>> http://www.ajlopez.com >>>>>>>>>> http://twitter.com/ajlopez >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2010/10/6 Guillermo Schwarz <[email protected]> >>>>>>>>>>> >>>>>>>>>>> Suena a que tiraste la toalla. >>>>>>>>>>> Lo de la intencionalidad está bien para los seres humanos, pero >>>>>>>>>>> en el caso de la naturaleza en vez de intencionalidad hay >>>>>>>>>>> oportunidad >>>>>>>>>>> (nichos ecológicos) que son llenados por elementos con >>>>>>>>>>> autopoyesis http://culturitalia.uibk.ac.at/hispanoteca/lexikon%20der%20linguistik/ao/AUTOPOIESIS%20Autopoyesis.htm >>>>>>>>>>> Esto es interesante para el punto en discusión porque al ser Alan >>>>>>>>>>> Kay un biólogo molecular y al tratar de modelar los objetos como si >>>>>>>>>>> fueran >>>>>>>>>>> células que responden a mensajes, la idea era que el comportamiento >>>>>>>>>>> "emergiera". Esto es también uno de los objetivos de eXtreme >>>>>>>>>>> Programming, >>>>>>>>>>> que emerja la auto-organización del programa, por más extraño que >>>>>>>>>>> resulte >>>>>>>>>>> para una visión donde todo tiene intencionalidad. >>>>>>>>>>> Un ejemplo de la vida real en el mundo del software son los >>>>>>>>>>> proyectos open source. No existe una autoridad central que los >>>>>>>>>>> organice y >>>>>>>>>>> sólo en la medida que van teniendo éxito (más gente los usa) van >>>>>>>>>>> mejorando. >>>>>>>>>>> Desde el punto de vista de la "intencionalidad" eso no podría >>>>>>>>>>> funcionar >>>>>>>>>>> nunca, ni los wikis, etc. >>>>>>>>>>> Saludos, >>>>>>>>>>> Guillermo. >>>>>>>>>>> On Tue, Oct 5, 2010 at 11:14 PM, Andres Valloud >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> > Si todas las cosas dependen de las intenciones, ¿dónde dejas >>>>>>>>>>>> > la ley de >>>>>>>>>>>> > las consecuencias indeseadas (unintended consequences)? >>>>>>>>>>>> >>>>>>>>>>>> No por querer volar logro despegar el chancho. >>>>>>>>>>>> >>>>>>>>>>>> Andres. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>> [email protected] >>>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>>> [email protected] >>>>>>>>>>>> >>>>>>>>>>>> http://www.clubSmalltalk.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Saludos cordiales, >>>>>>>>>>> >>>>>>>>>>> Guillermo Schwarz >>>>>>>>>>> Sun Certified Enterprise Architect >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> To post to this group, send email to >>>>>>>>>>> [email protected] >>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>> [email protected] >>>>>>>>>>> >>>>>>>>>>> http://www.clubSmalltalk.org >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> To post to this group, send email to >>>>>>>>>> [email protected] >>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>> [email protected] >>>>>>>>>> >>>>>>>>>> http://www.clubSmalltalk.org >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Saludos cordiales, >>>>>>>>> >>>>>>>>> Guillermo Schwarz >>>>>>>>> Sun Certified Enterprise Architect >>>>>>>>> >>>>>>>>> -- >>>>>>>>> To post to this group, send email to [email protected] >>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>> [email protected] >>>>>>>>> >>>>>>>>> http://www.clubSmalltalk.org >>>>>>>> >>>>>>>> -- >>>>>>>> To post to this group, send email to [email protected] >>>>>>>> To unsubscribe from this group, send email to >>>>>>>> [email protected] >>>>>>>> >>>>>>>> http://www.clubSmalltalk.org >>>>>>>> >>>>>>>> -- >>>>>>>> To post to this group, send email to [email protected] >>>>>>>> To unsubscribe from this group, send email to >>>>>>>> [email protected] >>>>>>>> >>>>>>>> http://www.clubSmalltalk.org >>>>>>> >>>>>>> -- >>>>>>> To post to this group, send email to [email protected] >>>>>>> To unsubscribe from this group, send email to >>>>>>> [email protected] >>>>>>> >>>>>>> http://www.clubSmalltalk.org >>>>>> >>>>>> >>>>>> -- >>>>>> Saludos cordiales, >>>>>> >>>>>> Guillermo Schwarz >>>>>> Sun Certified Enterprise Architect >>>>>> >>>>>> -- >>>>>> To post to this group, send email to [email protected] >>>>>> To unsubscribe from this group, send email to >>>>>> [email protected] >>>>>> >>>>>> http://www.clubSmalltalk.org >>>>> >>>>> -- >>>>> To post to this group, send email to [email protected] >>>>> To unsubscribe from this group, send email to >>>>> [email protected] >>>>> >>>>> http://www.clubSmalltalk.org >>>> >>>> >>>> -- >>>> Saludos cordiales, >>>> >>>> Guillermo Schwarz >>>> Sun Certified Enterprise Architect >>>> >>>> -- >>>> To post to this group, send email to [email protected] >>>> To unsubscribe from this group, send email to >>>> [email protected] >>>> >>>> http://www.clubSmalltalk.org >>> >>> -- >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> >>> http://www.clubSmalltalk.org >> >> >> -- >> Saludos cordiales, >> >> Guillermo Schwarz >> Sun Certified Enterprise Architect >> >> -- >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> >> http://www.clubSmalltalk.org > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
