Leer: Manual de GemStone/S, capitulo Replicates y Forwaders. Saludos, Bruno
----Mensaje original---- De: [email protected] Fecha: 13/10/2010 19:45 Para: Asunto: Re: [clubSmalltalk] Blog Sí, que bueno que lo mencionas. El problema está ampliamente resuelto en las bases de datos. En el caso de los "objetos" estamos tratando de reinventar la rueda, no sé para qué. Supongo que el olorcillo a que es un ejercicio intelectual que se puede resolver bien con algo de esfuerzo los motiva, cuando en realidad si partes de un diseño mal concebido no puedes tener una buena implementación aunque lo debuggees por años. Ejemplos de cómo no se debe hacer hay muchos. Partamos por el ejemplo que mencionaba Angel donde algunos objetos son threads, ¿qué haces con los objetos apuntados por el thread? Supongamos que decides serializarlos para enviarlos a la máquina remota, ¿tendrás 2 copias de cada objeto? ¿cómo te aseguras que sean coherentes? Porque recordemos que en Smalltalk los objetos tienen estado, si cambias uno, ¿el otro cómo se entera? ¿Vas a hacer que uno sea el proxy del otro? ¿Cómo decides cuándo crear un nuevo proxy y cuando reutilizarlo? ¿Cómo evitas que el protocolo se vuelva "chatty"? ¿Las transaccioens serán también distribuidas? Alguien también mencionó que los objetos tienen identidad. ¿En qué parte dice eso? Una vez vino a la universidad un Uruguayo o Argentino de apellido Tichy que venía fascinado con Smalltalk y venía con las idea de que todos los objetos deben tener identidad. ¿Porqué? ¿Porqué las bases de datos no lo hacen, ni un programa en C lo hace? A lo más un programa en Lisp lo hace, pero tiene sentido porque Lisp es un lenguaje funcional, de modo que los parámetros nunca se modifican. Para simular las modificaciones en Lisp (y en ML y Haskell) se usan contextos. Los contextos se podría decir que son objetos o HashMaps. Apuesto a que los contextos no tienen identidad. Para mí es obvio, no sé para ustedes. Si vamos a usar un paradigma deben entenderlo al revés y al derecho, no mezclarlo con otros paradigmas porque escucharon por ahí que así era más bonito o más OO o lo que sea que hayan escuchado. Si tienes objetos compartidos entonces la "computación" (el cálculo) se hace difícil porque debes proteger todos los objetos compartidos para que no hayan modificaciones concurrentes, es decir, lo contrario de lo que haces cuando usas transacciones. Por eso en Google usan MapReduce, porque es una idea que viene de la programación funcional, en la que siempre se calcula algo nuevo, no se modifica el estado de los objetos que se pasan como parámetro. Capice? Lo que postulo es que es la claridad de conceptos lo que ayuda a tener implementaciones simples que salen de una patada. Si no tienes los conceptos claros terminas con algo tan elegante como Struts con tag libraries que hace que todo sea difícil... ;-) Oye una pregunta para Andrés Valloud, ¿tienes los fuentes de GemStone? Saludos,Guillermo. 2010/10/11 Javier Burroni [email protected]> Hola... La verdad, estaba siguiendo la conversación pasivamente. Guillermo, creo que el problema esta en decir ex-ante, que la solución a un problema sea trivial. No se me ocurre un caso donde eso este bien (no significa que no exista), pero bueno (tampoco se muy bien si yo usaria ex-post la frase). Creo que se agrava cuando el que esta buscando la solución es otra persona. Por otro lado, que algo sea no trivial, no implica que sea dificil (tampoco que sea facil). Así que evitar decir que algo se implementa trivialmente no te convierte en un pesimista -yo soy un pesimista, y se muy bien que no es por eso-. Por otro lado, la cantidad de mails indagando sobre el problema, sin que se haya escrito una sola linea, creo que fue un buen q.e.d. de la no trivialidad del problema, no? :) 2010/10/11 Guillermo Schwarz [email protected]>: > unlp > > Me dijeron que era la mejor universidad de Argentina... parece que > no ;-) > > Y si es tan complicado, ¿porqué no los cuentas dónde están las > complicaciones? > > ¿O no saber cómo hacerlo te convierte en experto como para decir que > nadie más lo puede hacer o cuál es el camino equivocado? > > Sos genial!!! > > No sabes cuánto me hacés reir. :)) > > En todo caso es una falacia típica. Lo mismo que hace Alan Turing cuando ... > dice que si su máquina es indecidible entonces todas lo son. Primero > encuentra el problema equivocado, luego plantéalo de la manera > equivocada, luego presenta una solución que no lo resuelve y que es la > solución más general posible... ¿No se han preguntado porqué todos > estudiamos la indecibilidad de la máquina de Turing universal? Si eso no > es crear the "dark ages", no sé lo que es. > saludos, y "haya paz" (siguiendo con las citas les luthierenses) jb -- " To be is to do " ( Socrates ) " To be or not to be " ( Shakespeare ) " To do is to be " ( Sartre ) " Do be do be do " ( Sinatra ) -- 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
