?Y donde se obtiene ese libro?
Por cierto, puede que se hayan mandado un trabajo hiper complejo en
gemstone, pero eso no significa que no existan enfoques mas simples.
Por ejemplo, lo típico que enseñan en sistemas operativos es que
debes proteger los objetos compartidos con mutexes o critical
sections. En Windows hacen la distinción de que un mutex protege
procesos, mientras que critical sections protege threads, mientras que
en el curso de sistemas operativos no se hacia diferencia (estoy
hablando de hace como 20 anios eso si).
Bueno, y alguna vez en algun proyecto protegíamos todo con critical
sections e implementábamos transacciones con eso, pero el código era
un enredo y funcionaba hiper lento.
A lo que voy es que hay buenas implemnteciones y malas
implementaciones, así como también buenos diseños y malos diseños.
Imho la sola idea de que el programador se daba leer un libro para
poder usar un sistema (gemstone/s en este caso) en vez de recibir una
explicación que quepa en una servilleta, mientras que en el caso de
transacciones de bd el tipo efectivamente recibe una instrucción en
una serilleta y listo, me dice que el diseño de gemstone/s no es el
correcto.
Saludos,
Guillermo Schwarz.
El 14-10-2010, a las 7:35, "[email protected]" <[email protected]
> escribió:
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 intel
ectual que se puede resolver bien con algo de esfuerzo los motiva, c
uando en realidad si partes de un diseño mal concebido no puedes ten
er una buena implementación aunque lo debuggees por años.
Ejemplos de cómo no se debe hacer hay muchos. Partamos por el ejempl
o que mencionaba Angel donde algunos objetos son threads, ¿qué haces
con los objetos apuntados por el thread? Supongamos que decides ser
ializarlos para enviarlos a la máquina remota, ¿tendrás 2 copias
de cada objeto? ¿cómo te aseguras que sean coherentes? Porque record
emos 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 Arge
ntino de apellido Tichy que venía fascinado con Smalltalk y venía co
n 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 Lis
p es un lenguaje funcional, de modo que los parámetros nunca se modi
fican.
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 contrar
io 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 GemSton
e?
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 q
ue
> 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. Prime
ro
> encuentra el problema equivocado, luego plantéalo de la manera
> equivocada, luego presenta una solución que no lo resuelve y que e
s la
> solución más general posible... ¿No se han preguntado porqué tod
os
> 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
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
