Smalltalk › Español (Spanish)

Blog

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

112 messages Options

1 ... 3456

Guillermo Schwarz

Re: Blog

Ok, no soy Alan Kay ni Craig Latta si a eso te refieres, (a todo esto
gracias por el link de Spoon, es increíble), pero por otro lado yo
también pensaba que todo era increíblemente complicado porque programé
en C++ por 7 años.

Luego conocí Smalltalk y al hacer unas pruebas para demostrarme a mí
mismo que no funcionaba (o que funcionaba igual de mal que C++), y
pensaba yo, con arduo esfuerzo implementar lo mismo que tenía en C++,
entonces me di cuenta para mi sorpresa que:

1. Todo lo que sabía de C++ era innecesario. En Smalltalk todo es simple
y todo funciona. En particular alguien mencionó que serializar los
bloques no es simple, puede ser, pero ¿porqué? ¿Porque hace referencias
a variables fuera del scope del bloque? Potencialmente sí, pero en la
práctica los bloques en Smalltalk (y las expresiones lambda en Lisp) son
"closures" (cerraduras), de manera que no debiera ser tan difícil:

http://live.exept.de/doc/online/english/programming/stForLispers.html

2. En C++ debes tener cuidado cuando serializas un objeto recursivo, ya
que puedes caer en un loop infinito. En Smalltalk eso estaba resuelto.

http://www.cincomsmalltalk.com/blog/blogView?entry=3293342418

No sé si está resuelto actualmente en Pharo, pero bueno, no creo que sea
más que colocar "markers" cada cierto rato o de cuando en vez... ;-)

Podría seguir pero en realidad ahora pienso al revés. Hay un montón de
cosas que están resueltas en Java, como por ejemplo los EJBs como
servicios remotos de alto desempeño, los proxies que se comportan como
EJBs, los builds automatizados que corren todas las pruebas
automatizadas de un proyecto cuando se hace check-in en Mercurial, la
generación de SQL dinámico a partir de una representación de la base de
datos, ejecutar sobre Google App Engine, tener componentes Java que se
comportan como Swing pero sobre HTML, etc. y que en Smalltalk al parecer
no lo están o están en una fase de creación o son productos comerciales
(y sabemos que Smalltalk no se caracteriza por lo barato, de hecho fue
gracias a su precio que Sun decidió crear Java).

Tampoco es que en Java todo sea color de rosas. Aún los constructores no
hacen dynamic dispatch, ni los métodos estáticos, ni los métodos
privados, etc. Ni hablar de tener bloques o lambda expressions. Las
propuestas de closures son aún más feas que las anotaciones (@ejb).
¿Cómo es posible que en Java aún no existan operadores definidos por el
usuario?

Yo encontraba que leer XML era feo, pero resulta que ahora con los
templates (generics le dicen en Java), con las anotaciones y con los tag
libraries de Struts y con JSF, leer una aplicación Java es casi como
leer Chino pero con comentarios en Sumerio. Indescifrable. Y encuentra
un defecto en alguna biblioteca y te quiero ver debuggeando por semanas.
No es que en C++ no pasara lo mismo, sólo que pasaba con tu propio
código 8-( Ahí inventé las pruebas unitarias semi automáticas en 1993,
pero decidí no contarle a nadie. Mala decisión. (Siempre me he topado
con que las pruebas automatizadas las venden como pruebas de métodos en
vez de probar el protocolo de la clase, y más encima el "protocolo"
ahora se refiere al "method category")...

Creo que tener EJBs en Pharo sería bueno. Hacer un sistema distribuido,
con objetos distribuidos y transaccionales me parece bonito sólo en el
papel, no necesito que automáticamente un objeto de mi imagen viaje a tu
imagen y haga algo, todo lo contrario ¿para qué? ¿No debería haber un
servicio en tu imagen esperando mensajes de la mía, cierto tipo de
mensajes, con cierto protocolo? Me parece mucho más interesante resolver
algo pequeño y bien, el resto, si alguien lo necesita lo puede construir
de manera trivial, pero IMHO partir por "cada objeto es un thread" es un
suicidio a nivel del uso de recursos.

Ok, pero tampoco quiero hacerlo sólo porque la verdad es que ya casi y
todo lo he hecho y salió bien, ¿hay alguna motivación para hacer todo de
nuevo? Naahhh. (ok, no he implementado un intérprete de bytecode, pero
no veo la dificultad de hacer eso, hacía intérpretes cuando estaba en el
colegio). Y más encima a nadie le importó cuando hice un Smalltalk que
conversaba con un servidor en C++, o cuando hice un servidor en C que
ejecutaba un SQL que enviaba una aplicación cliente y que era generado
en tiempo de ejecución. En general mi experiencia es que la gente pide,
pero no porque quiera eso, sino simplemente por pedir, como los nenes,
¿o las nenas? ;-) Luego no saben qué hacer con lo que pidieron.

Simplemente si alguien se sienta 5 minutos y sale con un sistema
distribuido, el resto asume que es trivial y que por lo tanto no
importa. Me he dado cuenta con el tiempo que si realmente a alguien le
importa contribuye con su tiempo (o su dinero) pero idealmente con su
tiempo y de esa manera se produce algo que al resto sí le importa, de
modo que no queda tirado en un rincón y luego se pierde.

Además casi no uso Smalltalk hace mucho tiempo y quedaría todo el código
botado rápidamente porque sinceramente no tengo casos de uso en los que
requiera Smalltalk distruido. Hoy en día todos los sistemas son
distribuidos. Hasta un niño de 15 años puede hacer páginas web y
construir un sistema distribuido en PHP sin necesidad de hacer que
viajen objetos con proxies ni tener garbage collection distribuido,
simplemente usa HTTP y HTML.

De hecho si los sistemas distribuidos eran la gran panacea en los 90's,
hoy en día es cloud computing. Al parecer Smalltalk ya se retiró de toda
polémica y va más bien tratando de alcanzar a reproducir lo que había 20
años atrás debido a la tremenda fragmentación del mercado que implica
que algo está en un vendor y no en otro. Por lo que veo Pharo es la
alternativa más seria a tener un Smalltalk estándar sobre el cuál se
pueda (re)construir lo que había hace 20 años. Puedo estar equivocado,
pero es la misma sensación que me dio Eclipse, un IDE open source que
terminó siendo la base de todos los IDEs modernos en Java. Supongo que
con Pharo va a pasar lo mismo en el mundo Smalltalk.

Prefiero hacer algo que el resto use y que por lo tanto le sirva para
algo.

La gran ventaja, IMHO, de crear un EJB en Smalltalk es que como
Smalltalk no es tipado, al decir ok, este objeto se serializa y se
envía, automáticamente lo hiciste para todos los objetos serializables.
La verdad es que no recuerdo si Smalltalk tiene una convención respecto
de los objetos serializables, pero espero que no.

Supongo que al llegar a un objeto no serializable como podría ser un
socket por ejemplo, simplemente lo ignora o bien tira un error. Fíjense
que lo msimo debe ocurrir si tengo un socket abierto y se me ocurre
guardar la imagen. Si se guarda una representación de un socket abierto
en un archivo, cuando se rescate ese objeto debiera estar en un estado
inválido, simplemente o no se guardó o lo que se guardó no sirve.

Bueno, siempre es un gusto conversar con ustedes, aunque no lo crean, me
hacen recordar buenos tiempos. ;-)

Saludos,
Guillermo.

On Tue, 2010-10-12 at 08:46 -0300, andres wrote:

> Guillermo, todavía no me queda claro si sos un troll o simplemente un
> charlatán que conoce un set de buzzwords y las tira al aire, así que
> cortemos por lo sano: yo te hago una lista de las dificultades de hacer
> el famoso punto 3) del que tanto hablamos y vos te comprometés a filmar
> la pantalla de tu ordenador mientras lo implementás en 16 horas,
> arrancando de la versión 1.1.1 de Pharo one-click y sin usar un
> framework de distribución ya implementado. Después distribuís el
> changeset y los que quieran lo prueban.
>
> Saludos,
> Andrés
>
>
> Guillermo Schwarz escribió:
> > 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.
> >
> > Ejemplos hay muchos:
> >
> > http://cssbl.com/frases-01.htm
> >
> > Ahora yendo específicamente al tema de los objetos distribuidos, no veo
> > porqué sería complicado si puedes:
> >
> > 1. Serializar un objeto (convertirlo en String).
> > 2. Enviarlo por un socket.
> > 3. Deserializarlo al otro lado.
> >
> > Quizás te imaginas que el problema es que las transacciones distribuidas
> > no podrían funcionar. Eso lo resuelven las bases de datos con 2 phase
> > commit. Si estamos hablando de transacciones en memoria (todo en
> > Smalltalk, como me imaginaría a GemStone, sin una base de datos como
> > Oracle por debajo), existe memoria transaccional. Y bueno se puede
> > seguir escarbando, todas esas cosas están resueltas, pero nótese que
> > J2EE (y por ende EJB) sólo llega a la base de datos, no hace ninguna
> > transacción en memoria y esa es la razón por la que los EJB deben ser
> > stateless y no stateful.
> >
> > Si son stateful entonces no hay manera de hacer participar a esos
> > objetos de las transacciones de la base de datos. Ok, si tenemos memoria
> > transaccional e implementamos 2 phase commit en memoria se podría, pero
> > ¿para qué? ¿qué caso de uso lo requiere realmente? Generalmente todas
> > las transacciones se pueden resolver a nivel de base de datos, y por lo
> > menos a mí nunca me ha tocado que sea necesario hacerlo a nivel de RAM.
> >
> > De hecho prefería implementar un SQL en Smalltalk con transacciones y
> > todo que tener que generar engendros que no son ni una cosa ni la otra.
> > (De hecho SQL está implementado en C y en Java, no veo ninguna razón
> > para no poder implementarlo en Smalltalk).
> >
> > Saludos,
> > Guillermo.
> >
> > On Mon, 2010-10-11 at 17:50 -0300, andres wrote:
> >> Guillermo Schwarz escribió:
> >>> Por lo visto ustedes tienen tan claro como yo como implementar todo
> >>> esto.
> >> No, para nada! Justamente por eso esperaba que vos me mostraras cómo;
> >> todo lo que vos considerás trivial yo lo considero complicadísimo y que
> >> lleva meses de implementación, de ahí mi curiosidad. Una pena que no te
> >> sirva de mucho hacerlo :(
> >>
> >>> Bueno, al menos lo que mencionaba respecto de thisContext está
> >>> implementado en Pharo.
> >>>
> >>> Basta con imprimir:
> >>>
> >>> thisContext sender
> >>>
> >>> y se ve que funciona.
> >> Si, tal cual! De ahí ya estamos a un pasito nomás. Grosso, no?
> >>
> >> Bueno, creo que este thread ya no da para mas.
> >>
> >> Saludos!
> >> Andrés
> >>
> >
>

--
Simplex Veri Sigillum

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Francisco Garau

Re: Blog

Guillermo - esta lista nos reune para hablar sobre Smalltalk y en eso tratamos de mantener el foco.

En este mail te vas tanto por las ramas, que ya no se sabe que es lo que queres decir. Si queres contar la historia de tu vida y todas tus experiencias informaticas podes escribir un libro (total es trivial, nada mas tenes que hacer copy-and-paste de todos los mails que has mandado).

- Francisco

2010/10/13 Guillermo Schwarz <[hidden email]>

Ok, no soy Alan Kay ni Craig Latta si a eso te refieres, (a todo esto
gracias por el link de Spoon, es increíble), pero por otro lado yo
también pensaba que todo era increíblemente complicado porque programé
en C++ por 7 años.

Luego conocí Smalltalk y al hacer unas pruebas para demostrarme a mí
mismo que no funcionaba (o que funcionaba igual de mal que C++), y
pensaba yo, con arduo esfuerzo implementar lo mismo que tenía en C++,
entonces me di cuenta para mi sorpresa que:

1. Todo lo que sabía de C++ era innecesario. En Smalltalk todo es simple
y todo funciona. En particular alguien mencionó que serializar los
bloques no es simple, puede ser, pero ¿porqué? ¿Porque hace referencias
a variables fuera del scope del bloque? Potencialmente sí, pero en la
práctica los bloques en Smalltalk (y las expresiones lambda en Lisp) son
"closures" (cerraduras), de manera que no debiera ser tan difícil:

http://live.exept.de/doc/online/english/programming/stForLispers.html

2. En C++ debes tener cuidado cuando serializas un objeto recursivo, ya
que puedes caer en un loop infinito. En Smalltalk eso estaba resuelto.

http://www.cincomsmalltalk.com/blog/blogView?entry=3293342418

No sé si está resuelto actualmente en Pharo, pero bueno, no creo que sea
más que colocar "markers" cada cierto rato o de cuando en vez... ;-)

Podría seguir pero en realidad ahora pienso al revés. Hay un montón de
cosas que están resueltas en Java, como por ejemplo los EJBs como
servicios remotos de alto desempeño, los proxies que se comportan como
EJBs, los builds automatizados que corren todas las pruebas
automatizadas de un proyecto cuando se hace check-in en Mercurial, la
generación de SQL dinámico a partir de una representación de la base de
datos, ejecutar sobre Google App Engine, tener componentes Java que se
comportan como Swing pero sobre HTML, etc. y que en Smalltalk al parecer
no lo están o están en una fase de creación o son productos comerciales
(y sabemos que Smalltalk no se caracteriza por lo barato, de hecho fue
gracias a su precio que Sun decidió crear Java).

Tampoco es que en Java todo sea color de rosas. Aún los constructores no
hacen dynamic dispatch, ni los métodos estáticos, ni los métodos
privados, etc. Ni hablar de tener bloques o lambda expressions. Las
propuestas de closures son aún más feas que las anotaciones (@ejb).
¿Cómo es posible que en Java aún no existan operadores definidos por el
usuario?

Yo encontraba que leer XML era feo, pero resulta que ahora con los
templates (generics le dicen en Java), con las anotaciones y con los tag
libraries de Struts y con JSF, leer una aplicación Java es casi como
leer Chino pero con comentarios en Sumerio. Indescifrable. Y encuentra
un defecto en alguna biblioteca y te quiero ver debuggeando por semanas.
No es que en C++ no pasara lo mismo, sólo que pasaba con tu propio
código 8-( Ahí inventé las pruebas unitarias semi automáticas en 1993,
pero decidí no contarle a nadie. Mala decisión. (Siempre me he topado
con que las pruebas automatizadas las venden como pruebas de métodos en
vez de probar el protocolo de la clase, y más encima el "protocolo"
ahora se refiere al "method category")...

Creo que tener EJBs en Pharo sería bueno. Hacer un sistema distribuido,
con objetos distribuidos y transaccionales me parece bonito sólo en el
papel, no necesito que automáticamente un objeto de mi imagen viaje a tu
imagen y haga algo, todo lo contrario ¿para qué? ¿No debería haber un
servicio en tu imagen esperando mensajes de la mía, cierto tipo de
mensajes, con cierto protocolo? Me parece mucho más interesante resolver
algo pequeño y bien, el resto, si alguien lo necesita lo puede construir
de manera trivial, pero IMHO partir por "cada objeto es un thread" es un
suicidio a nivel del uso de recursos.

Ok, pero tampoco quiero hacerlo sólo porque la verdad es que ya casi y
todo lo he hecho y salió bien, ¿hay alguna motivación para hacer todo de
nuevo? Naahhh. (ok, no he implementado un intérprete de bytecode, pero
no veo la dificultad de hacer eso, hacía intérpretes cuando estaba en el
colegio). Y más encima a nadie le importó cuando hice un Smalltalk que
conversaba con un servidor en C++, o cuando hice un servidor en C que
ejecutaba un SQL que enviaba una aplicación cliente y que era generado
en tiempo de ejecución. En general mi experiencia es que la gente pide,
pero no porque quiera eso, sino simplemente por pedir, como los nenes,
¿o las nenas? ;-) Luego no saben qué hacer con lo que pidieron.

Simplemente si alguien se sienta 5 minutos y sale con un sistema
distribuido, el resto asume que es trivial y que por lo tanto no
importa. Me he dado cuenta con el tiempo que si realmente a alguien le
importa contribuye con su tiempo (o su dinero) pero idealmente con su
tiempo y de esa manera se produce algo que al resto sí le importa, de
modo que no queda tirado en un rincón y luego se pierde.

Además casi no uso Smalltalk hace mucho tiempo y quedaría todo el código
botado rápidamente porque sinceramente no tengo casos de uso en los que
requiera Smalltalk distruido. Hoy en día todos los sistemas son
distribuidos. Hasta un niño de 15 años puede hacer páginas web y
construir un sistema distribuido en PHP sin necesidad de hacer que
viajen objetos con proxies ni tener garbage collection distribuido,
simplemente usa HTTP y HTML.

De hecho si los sistemas distribuidos eran la gran panacea en los 90's,
hoy en día es cloud computing. Al parecer Smalltalk ya se retiró de toda
polémica y va más bien tratando de alcanzar a reproducir lo que había 20
años atrás debido a la tremenda fragmentación del mercado que implica
que algo está en un vendor y no en otro. Por lo que veo Pharo es la
alternativa más seria a tener un Smalltalk estándar sobre el cuál se
pueda (re)construir lo que había hace 20 años. Puedo estar equivocado,
pero es la misma sensación que me dio Eclipse, un IDE open source que
terminó siendo la base de todos los IDEs modernos en Java. Supongo que
con Pharo va a pasar lo mismo en el mundo Smalltalk.

Prefiero hacer algo que el resto use y que por lo tanto le sirva para
algo.

La gran ventaja, IMHO, de crear un EJB en Smalltalk es que como
Smalltalk no es tipado, al decir ok, este objeto se serializa y se
envía, automáticamente lo hiciste para todos los objetos serializables.
La verdad es que no recuerdo si Smalltalk tiene una convención respecto
de los objetos serializables, pero espero que no.

Supongo que al llegar a un objeto no serializable como podría ser un
socket por ejemplo, simplemente lo ignora o bien tira un error. Fíjense
que lo msimo debe ocurrir si tengo un socket abierto y se me ocurre
guardar la imagen. Si se guarda una representación de un socket abierto
en un archivo, cuando se rescate ese objeto debiera estar en un estado
inválido, simplemente o no se guardó o lo que se guardó no sirve.

Bueno, siempre es un gusto conversar con ustedes, aunque no lo crean, me
hacen recordar buenos tiempos. ;-)

Saludos,
Guillermo.

On Tue, 2010-10-12 at 08:46 -0300, andres wrote:
> Guillermo, todavía no me queda claro si sos un troll o simplemente un
> charlatán que conoce un set de buzzwords y las tira al aire, así que
> cortemos por lo sano: yo te hago una lista de las dificultades de hacer
> el famoso punto 3) del que tanto hablamos y vos te comprometés a filmar
> la pantalla de tu ordenador mientras lo implementás en 16 horas,
> arrancando de la versión 1.1.1 de Pharo one-click y sin usar un
> framework de distribución ya implementado. Después distribuís el
> changeset y los que quieran lo prueban.
>
> Saludos,
> Andrés
>
>
> Guillermo Schwarz escribió:
> > 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.
> >
> > Ejemplos hay muchos:
> >
> > http://cssbl.com/frases-01.htm
> >
> > Ahora yendo específicamente al tema de los objetos distribuidos, no veo
> > porqué sería complicado si puedes:
> >
> > 1. Serializar un objeto (convertirlo en String).
> > 2. Enviarlo por un socket.
> > 3. Deserializarlo al otro lado.
> >
> > Quizás te imaginas que el problema es que las transacciones distribuidas
> > no podrían funcionar. Eso lo resuelven las bases de datos con 2 phase
> > commit. Si estamos hablando de transacciones en memoria (todo en
> > Smalltalk, como me imaginaría a GemStone, sin una base de datos como
> > Oracle por debajo), existe memoria transaccional. Y bueno se puede
> > seguir escarbando, todas esas cosas están resueltas, pero nótese que
> > J2EE (y por ende EJB) sólo llega a la base de datos, no hace ninguna
> > transacción en memoria y esa es la razón por la que los EJB deben ser
> > stateless y no stateful.
> >
> > Si son stateful entonces no hay manera de hacer participar a esos
> > objetos de las transacciones de la base de datos. Ok, si tenemos memoria
> > transaccional e implementamos 2 phase commit en memoria se podría, pero
> > ¿para qué? ¿qué caso de uso lo requiere realmente? Generalmente todas
> > las transacciones se pueden resolver a nivel de base de datos, y por lo
> > menos a mí nunca me ha tocado que sea necesario hacerlo a nivel de RAM.
> >
> > De hecho prefería implementar un SQL en Smalltalk con transacciones y
> > todo que tener que generar engendros que no son ni una cosa ni la otra.
> > (De hecho SQL está implementado en C y en Java, no veo ninguna razón
> > para no poder implementarlo en Smalltalk).
> >
> > Saludos,
> > Guillermo.
> >
> > On Mon, 2010-10-11 at 17:50 -0300, andres wrote:
> >> Guillermo Schwarz escribió:
> >>> Por lo visto ustedes tienen tan claro como yo como implementar todo
> >>> esto.
> >> No, para nada! Justamente por eso esperaba que vos me mostraras cómo;
> >> todo lo que vos considerás trivial yo lo considero complicadísimo y que
> >> lleva meses de implementación, de ahí mi curiosidad. Una pena que no te
> >> sirva de mucho hacerlo :(
> >>
> >>> Bueno, al menos lo que mencionaba respecto de thisContext está
> >>> implementado en Pharo.
> >>>
> >>> Basta con imprimir:
> >>>
> >>> thisContext sender
> >>>
> >>> y se ve que funciona.
> >> Si, tal cual! De ahí ya estamos a un pasito nomás. Grosso, no?
> >>
> >> Bueno, creo que este thread ya no da para mas.
> >>
> >> Saludos!
> >> Andrés
> >>
> >
>

--
Simplex Veri Sigillum

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Angel Java Lopez

Re: Blog

In reply to this post by Guillermo Schwarz

Hola gente!

Varios puntos para comentar de lo que envia Guillermo, pero ya los moleste bastante, hoy, pero veamos unos puntos:

- Eso de "un objeto un thread", no era lo que yo sugeria. Yo sugeria: "un agente un thread", y hasta ahora, en los algoritmos que quiero implementar, necesito pocos agentes (orden 5-10). Ya tengo andando eso en AjTalk:
http://code.google.com/p/ajtalk/source/browse/trunk/Src/AjTalk/Language/AgentObject.cs

- Mucho de lo que Guillermo encontro en Smalltalk, yo lo encontre en Java y luego en .NET (notablemente, desde hace unos anios, lambdas, serializables, con algo de closures, tendria que probar cuan serializable es un lambda con closure en .NET). Tengo que implementar la serializacion de bloque en AjTalk, para usar, de ser necesario, cosas como:

nodoRemoto run: [... bloque ... ] with: .. with:...

Pero todavia no ha sido necesario en los casos de uso que tengo. Vere.

- YA serializo objetos en AjTalk, aun con grafos con ciclos, gracias a apoyarme en la serializacion de .NET en Remoting. Supongo que, hace anios, podria haber usado RMI en Java. Ahora hay mas librerias de serializacion en Java. Igual, tengo planeadas alternativas si alguna vez la serializacion con ese apoyo se complica. Por ahora, funciona. Pero mi punto es: vean que apoyarse en Java/.NET <MensajeSubliminalParaElBuenoDeValloud/>(y sus librerias de clases, no solo en la VM), puede hacer mas facil el desarrollo de una VM de Smalltalk. Y accediendo a objetos nativos, hasta puede que facilite la adopcion de Smalltalk. Eso es lo que veo que esta pasando con Clojure: por anios, Common Lisp fue un patito feo, y ahora Clojure, con compilacion y acceso a Java, ha sido abrazado por una comunidad activa. Tambien esta en desarrollo ClojureCLR, sobre .NET.

(espero haber escrito en este email bastante sobre Smalltalk, para no recibir tiron de orejas... avisen! ;-)

Interesantes temas!

Nos leemos!

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

2010/10/13 Guillermo Schwarz <[hidden email]>

Ok, no soy Alan Kay ni Craig Latta si a eso te refieres, (a todo esto
gracias por el link de Spoon, es increíble), pero por otro lado yo
también pensaba que todo era increíblemente complicado porque programé
en C++ por 7 años.

Luego conocí Smalltalk y al hacer unas pruebas para demostrarme a mí
mismo que no funcionaba (o que funcionaba igual de mal que C++), y
pensaba yo, con arduo esfuerzo implementar lo mismo que tenía en C++,
entonces me di cuenta para mi sorpresa que:

1. Todo lo que sabía de C++ era innecesario. En Smalltalk todo es simple
y todo funciona. En particular alguien mencionó que serializar los
bloques no es simple, puede ser, pero ¿porqué? ¿Porque hace referencias
a variables fuera del scope del bloque? Potencialmente sí, pero en la
práctica los bloques en Smalltalk (y las expresiones lambda en Lisp) son
"closures" (cerraduras), de manera que no debiera ser tan difícil:

http://live.exept.de/doc/online/english/programming/stForLispers.html

2. En C++ debes tener cuidado cuando serializas un objeto recursivo, ya
que puedes caer en un loop infinito. En Smalltalk eso estaba resuelto.

http://www.cincomsmalltalk.com/blog/blogView?entry=3293342418

No sé si está resuelto actualmente en Pharo, pero bueno, no creo que sea
más que colocar "markers" cada cierto rato o de cuando en vez... ;-)

Podría seguir pero en realidad ahora pienso al revés. Hay un montón de
cosas que están resueltas en Java, como por ejemplo los EJBs como
servicios remotos de alto desempeño, los proxies que se comportan como
EJBs, los builds automatizados que corren todas las pruebas
automatizadas de un proyecto cuando se hace check-in en Mercurial, la
generación de SQL dinámico a partir de una representación de la base de
datos, ejecutar sobre Google App Engine, tener componentes Java que se
comportan como Swing pero sobre HTML, etc. y que en Smalltalk al parecer
no lo están o están en una fase de creación o son productos comerciales
(y sabemos que Smalltalk no se caracteriza por lo barato, de hecho fue
gracias a su precio que Sun decidió crear Java).

Tampoco es que en Java todo sea color de rosas. Aún los constructores no
hacen dynamic dispatch, ni los métodos estáticos, ni los métodos
privados, etc. Ni hablar de tener bloques o lambda expressions. Las
propuestas de closures son aún más feas que las anotaciones (@ejb).
¿Cómo es posible que en Java aún no existan operadores definidos por el
usuario?

Yo encontraba que leer XML era feo, pero resulta que ahora con los
templates (generics le dicen en Java), con las anotaciones y con los tag
libraries de Struts y con JSF, leer una aplicación Java es casi como
leer Chino pero con comentarios en Sumerio. Indescifrable. Y encuentra
un defecto en alguna biblioteca y te quiero ver debuggeando por semanas.
No es que en C++ no pasara lo mismo, sólo que pasaba con tu propio
código 8-( Ahí inventé las pruebas unitarias semi automáticas en 1993,
pero decidí no contarle a nadie. Mala decisión. (Siempre me he topado
con que las pruebas automatizadas las venden como pruebas de métodos en
vez de probar el protocolo de la clase, y más encima el "protocolo"
ahora se refiere al "method category")...

Creo que tener EJBs en Pharo sería bueno. Hacer un sistema distribuido,
con objetos distribuidos y transaccionales me parece bonito sólo en el
papel, no necesito que automáticamente un objeto de mi imagen viaje a tu
imagen y haga algo, todo lo contrario ¿para qué? ¿No debería haber un
servicio en tu imagen esperando mensajes de la mía, cierto tipo de
mensajes, con cierto protocolo? Me parece mucho más interesante resolver
algo pequeño y bien, el resto, si alguien lo necesita lo puede construir
de manera trivial, pero IMHO partir por "cada objeto es un thread" es un
suicidio a nivel del uso de recursos.

Ok, pero tampoco quiero hacerlo sólo porque la verdad es que ya casi y
todo lo he hecho y salió bien, ¿hay alguna motivación para hacer todo de
nuevo? Naahhh. (ok, no he implementado un intérprete de bytecode, pero
no veo la dificultad de hacer eso, hacía intérpretes cuando estaba en el
colegio). Y más encima a nadie le importó cuando hice un Smalltalk que
conversaba con un servidor en C++, o cuando hice un servidor en C que
ejecutaba un SQL que enviaba una aplicación cliente y que era generado
en tiempo de ejecución. En general mi experiencia es que la gente pide,
pero no porque quiera eso, sino simplemente por pedir, como los nenes,
¿o las nenas? ;-) Luego no saben qué hacer con lo que pidieron.

Simplemente si alguien se sienta 5 minutos y sale con un sistema
distribuido, el resto asume que es trivial y que por lo tanto no
importa. Me he dado cuenta con el tiempo que si realmente a alguien le
importa contribuye con su tiempo (o su dinero) pero idealmente con su
tiempo y de esa manera se produce algo que al resto sí le importa, de
modo que no queda tirado en un rincón y luego se pierde.

Además casi no uso Smalltalk hace mucho tiempo y quedaría todo el código
botado rápidamente porque sinceramente no tengo casos de uso en los que
requiera Smalltalk distruido. Hoy en día todos los sistemas son
distribuidos. Hasta un niño de 15 años puede hacer páginas web y
construir un sistema distribuido en PHP sin necesidad de hacer que
viajen objetos con proxies ni tener garbage collection distribuido,
simplemente usa HTTP y HTML.

De hecho si los sistemas distribuidos eran la gran panacea en los 90's,
hoy en día es cloud computing. Al parecer Smalltalk ya se retiró de toda
polémica y va más bien tratando de alcanzar a reproducir lo que había 20
años atrás debido a la tremenda fragmentación del mercado que implica
que algo está en un vendor y no en otro. Por lo que veo Pharo es la
alternativa más seria a tener un Smalltalk estándar sobre el cuál se
pueda (re)construir lo que había hace 20 años. Puedo estar equivocado,
pero es la misma sensación que me dio Eclipse, un IDE open source que
terminó siendo la base de todos los IDEs modernos en Java. Supongo que
con Pharo va a pasar lo mismo en el mundo Smalltalk.

Prefiero hacer algo que el resto use y que por lo tanto le sirva para
algo.

La gran ventaja, IMHO, de crear un EJB en Smalltalk es que como
Smalltalk no es tipado, al decir ok, este objeto se serializa y se
envía, automáticamente lo hiciste para todos los objetos serializables.
La verdad es que no recuerdo si Smalltalk tiene una convención respecto
de los objetos serializables, pero espero que no.

Supongo que al llegar a un objeto no serializable como podría ser un
socket por ejemplo, simplemente lo ignora o bien tira un error. Fíjense
que lo msimo debe ocurrir si tengo un socket abierto y se me ocurre
guardar la imagen. Si se guarda una representación de un socket abierto
en un archivo, cuando se rescate ese objeto debiera estar en un estado
inválido, simplemente o no se guardó o lo que se guardó no sirve.

Bueno, siempre es un gusto conversar con ustedes, aunque no lo crean, me
hacen recordar buenos tiempos. ;-)

Saludos,
Guillermo.

On Tue, 2010-10-12 at 08:46 -0300, andres wrote:
> Guillermo, todavía no me queda claro si sos un troll o simplemente un
> charlatán que conoce un set de buzzwords y las tira al aire, así que
> cortemos por lo sano: yo te hago una lista de las dificultades de hacer
> el famoso punto 3) del que tanto hablamos y vos te comprometés a filmar
> la pantalla de tu ordenador mientras lo implementás en 16 horas,
> arrancando de la versión 1.1.1 de Pharo one-click y sin usar un
> framework de distribución ya implementado. Después distribuís el
> changeset y los que quieran lo prueban.
>
> Saludos,
> Andrés
>
>
> Guillermo Schwarz escribió:
> > 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.
> >
> > Ejemplos hay muchos:
> >
> > http://cssbl.com/frases-01.htm
> >
> > Ahora yendo específicamente al tema de los objetos distribuidos, no veo
> > porqué sería complicado si puedes:
> >
> > 1. Serializar un objeto (convertirlo en String).
> > 2. Enviarlo por un socket.
> > 3. Deserializarlo al otro lado.
> >
> > Quizás te imaginas que el problema es que las transacciones distribuidas
> > no podrían funcionar. Eso lo resuelven las bases de datos con 2 phase
> > commit. Si estamos hablando de transacciones en memoria (todo en
> > Smalltalk, como me imaginaría a GemStone, sin una base de datos como
> > Oracle por debajo), existe memoria transaccional. Y bueno se puede
> > seguir escarbando, todas esas cosas están resueltas, pero nótese que
> > J2EE (y por ende EJB) sólo llega a la base de datos, no hace ninguna
> > transacción en memoria y esa es la razón por la que los EJB deben ser
> > stateless y no stateful.
> >
> > Si son stateful entonces no hay manera de hacer participar a esos
> > objetos de las transacciones de la base de datos. Ok, si tenemos memoria
> > transaccional e implementamos 2 phase commit en memoria se podría, pero
> > ¿para qué? ¿qué caso de uso lo requiere realmente? Generalmente todas
> > las transacciones se pueden resolver a nivel de base de datos, y por lo
> > menos a mí nunca me ha tocado que sea necesario hacerlo a nivel de RAM.
> >
> > De hecho prefería implementar un SQL en Smalltalk con transacciones y
> > todo que tener que generar engendros que no son ni una cosa ni la otra.
> > (De hecho SQL está implementado en C y en Java, no veo ninguna razón
> > para no poder implementarlo en Smalltalk).
> >
> > Saludos,
> > Guillermo.
> >
> > On Mon, 2010-10-11 at 17:50 -0300, andres wrote:
> >> Guillermo Schwarz escribió:
> >>> Por lo visto ustedes tienen tan claro como yo como implementar todo
> >>> esto.
> >> No, para nada! Justamente por eso esperaba que vos me mostraras cómo;
> >> todo lo que vos considerás trivial yo lo considero complicadísimo y que
> >> lleva meses de implementación, de ahí mi curiosidad. Una pena que no te
> >> sirva de mucho hacerlo :(
> >>
> >>> Bueno, al menos lo que mencionaba respecto de thisContext está
> >>> implementado en Pharo.
> >>>
> >>> Basta con imprimir:
> >>>
> >>> thisContext sender
> >>>
> >>> y se ve que funciona.
> >> Si, tal cual! De ahí ya estamos a un pasito nomás. Grosso, no?
> >>
> >> Bueno, creo que este thread ya no da para mas.
> >>
> >> Saludos!
> >> Andrés
> >>
> >
>

--
Simplex Veri Sigillum

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Guillermo Schwarz

Re: Blog

In reply to this post by Andres Valloud-5

Sí, se llama BucketSort.

http://www.personal.kent.edu/~rmuhamma/Algorithms/MyAlgorithms/Sorting/bucketSort.htm

Y no lo inventé yo.

En el caso que posteaste, era HeapSort O(n log n) en el peor caso, que teóricamente es un poco más rápiodo que QuickSort.O(n log n) en el mejor caso, pero ocurre que en la práctica siempre es más rápido QuickSort porque la constante de HeapSort es más grande.

Saludos,

Guillermo.

2010/10/11 Andres Valloud <[hidden email]>

> 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.

Y... si eso es crear "dark ages", entonces capaz que crear "dark ages"
tambien es decir que tenes un algoritmo de sorting mas rapido que
Quick Sort, a pesar de que hay una demostracion que dice que no se
puede ordenar con complejidad menor a la de Quick Sort, y armar bardo.

> Ejemplos hay muchos:

Si, por ejemplo este:

http://www.c2.com/cgi/wiki?GuillermoSchwarz

:)...

Andres.

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Guillermo Schwarz

Re: Blog

In reply to this post by Javier Burroni

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 <[hidden email]>

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 <[hidden email]>:

> 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 [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Esteban A. Maringolo

Re: Blog

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Francisco Garau

Re: Blog

In reply to this post by Andres Valloud-5

Hola Andres :- te contesto entre lineas...

On Oct 5, 9:29 am, Andres Valloud <[hidden email]> wrote:

> Para nosotros, la unica manera de entender cosas (en plural) es
> mediante la observacion de diferencias de valor. Por ejemplo, si
> absolutamente todos los objetos tuvieran *exactamente* el mismo color
> para nosotros, digamos azul, entonces no podriamos distinguir un
> objeto de otro con la vista. En ese caso, al tener exactamente el
> mismo color, lo que sucede es que efectivamente no hay bordes entre
> objetos. Al no haber diferencia de valor entre un punto y otro,
> entonces no se puede distinguir.
>
> Por lo tanto, lo primero que hay que tener para poder entender mas de
> una cosa, son diferencias de valores, como por ejemplo diferencias de
> color, o diferencias de tono, o de rugosidad, o de olor, o de sabor,
> etc. Si para nosotros no hay diferencia a nivel de sensaciones (ya
> sea por nuestros sentidos exteriores o bien por pensar en una cosa o
> la otra), entonces no es posible distinguir varias cosas a partir de
> lo que se siente completamente homogeneo.

Totalmente de acuerdo. Es mas, en el plano mas abstracto de las ideas
distinguir es el primer paso, luego hay que darle nombre al concepto.

> Si percibimos diferencias, entonces dependiendo de nuestras
> intenciones (ver mas abajo) es posible distinguir objetos diferentes.
> Supongamos que representamos nuestras posibles sensaciones (ya sean
> del mundo exterior o ideas internas en nuestra mente) en un hipercubo
> con una cantidad suficiente de dimensiones. Entonces podemos pensar
> que la analogia de distinguir un objeto es, basicamente, la creacion
> de esferas (o cubos, o prismas, o toros, etc) dentro de este cubo. Es
> mas, siendo que estamos pensando en distinguir una cosa de lo que es
> la no-cosa, estamos hablando de una particion del hipercubo en dos
> regiones: la cosa en cuestion, y el resto. Por ejemplo: el vaso, y el
> resto del universo que no es el vaso. Por lo tanto, hablar de una
> "cosa" ("ese pedazo de vidrio con forma de vaso" y "el resto del
> universo"), es asumir que observamos alguna diferencia de valores en
> el hipercubo, y que a partir de esta observacion elegimos una frontera
> que separa la zona de valores segun nuestro criterio diferentes de
> todos los demas valores posibles.
>
> Llamemos por lo tanto a nuestra idea de "cosa" como una "distincion".
> Cuando hablamos de distinciones, en realidad estamos hablando de
> partir nuestro hipercubo en exactamente dos conjuntos disjuntos, asi
> como la circunferencia en el papel separa el circulo del resto del
> plano.
>
> Esta claro que podemos asignarles nombres a las distinciones, con lo
> que hablar de "vaso", "silla" y demas nos da la posibilidad de
> referirnos a regiones del hipercubo con facilidad. Las distinciones
> tienen dos propiedades interesantes.
>
> 1. Distinguir una vez es lo mismo que distinguir dos veces.
>
> Por ejemplo, en Smalltalk,
>
> 3.
> 3.
>
> es lo mismo que
>
> 3.
>
> 2. Cruzar una distincion una vez, y luego volverla a cruzar, es lo
> mismo que no hacer nada.

Esta bueno. En algun momento lei a Spencer Brown no llegue a
relacionarlo con lo que hacemos en Smalltalk. Hablas de eso en tu
libro de mentoring? (a ver si aprovecho la oferta de Octubre y me lo
compro...)

> Por ejemplo, al enviar un mensaje, la ejecucion cruza el borde del
> sender para entrar en el receiver, y luego la respuesta vuelve a
> cruzar el borde del receiver para volver al sender (notese como hablar
> de sender y receiver hace que esto tenga sentido aun cuando se tengan
> en cuenta cosas como become:). Al volver al sender, de hecho, es como
> no habernos ido. La ejecucion volvio al mismo lugar.

Que pasa si la ejecucion del metodo tiene side-effects en el receiver?
La ejecucion vuelve al mismo lugar pero internamente hay un cambio.

> Cuantos bugs ocurren por no respetar estas dos reglas! Incluso en las
> cosas cotidianas, muchas (si no todas) las situaciones problematicas
> ocurren cuando se viola alguno de estos dos principios. Uno de mis
> ejemplos favoritos es pensar en el tipo que, en vez de devolver el
> auto alquilado, lo vende a un tercero. Esto es una violacion del
> segundo principio, ya que despues de cruzar un borde (obtencion del
> auto *alquilado*), el siguiente cruce del mismo borde no termina en el
> lugar desde donde se habia partido (no tengo mas el auto *que vendi en
> vez de devolver*).

El ejemplo del auto se entiende perfecto. Pero no veo tan claro que
muchos bugs sean causados por violar este principio. Tenes algun
ejemplo de violacion de este principio en Smalltalk?

> Ahora bien, dije antes que uno distingue segun cierta intencion.
> Seguro: una mesa de madera se convierte en leña si la alternativa es
> morir de frio. El alambre y el moco sirven para arreglar cualquier
> cosa (decian).

> Que es una intencion, entonces? Es un filtro que
> reacciona ante ciertos patrones de diferencias de valor. A mayor
> reaccion, mayor intencion.

No entiendo. A que te referis con "reaccion"?

> Parece gustarnos encontrar filtros que se
> maximicen, como los de nuestra cuenta bancaria, o los de nuestra
> realizacion personal, o los de nuestras ideas politicas, etc.
>
> Lo notable de esto es que, si esto es realmente asi, entonces todas
> las cosas con las que creemos lidiar son producto de nuestras
> intenciones. Vemos una mesa si vamos a una reunion. Vemos leña si
> tenemos frio. Vemos una cama si no hay otra cosa. Vemos un lugar
> donde pararnos para llegar mas alto. Y asi siguiendo. Lo que tambien
> es claro es que, siendo que nuestra idea de "cosa" implica separar
> nuestro hipercubo en dos regiones diferentes, existe tambien una
> especie de principio de incertidumbre. Solo tenemos una cierta
> ventana por la cual observar, definida por nuestras intenciones, y el
> hecho de distinguir una cosa impide inmediatamente distinguir una
> multitud de otras cosas contradictorias con la cosa que acabamos de
> distinguir (mesa o leña, pero no las dos al *mismo* tiempo). Hasta
> cierto punto, vemos lo que "queremos" ver.
>
> Y cuando decimos "yo soy esto", que?

Estas pensando en la General Semantics de Korzybski?

- Francisco

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

BrunoBB

Re: Blog

In reply to this post by Manzanos

Leer: Manual de GemStone/S, capitulo Replicates y Forwaders.

Saludos,
Bruno

----Mensaje original----

De: [hidden email]

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.

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.

Capice?

Oye una pregunta para Andrés Valloud, ¿tienes los fuentes de GemStone?

Saludos,

Guillermo.

2010/10/11 Javier Burroni <[hidden email]>

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 <[hidden email]>:

> 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 [hidden email]

To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--

To post to this group, send email to [hidden email]

To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Guillermo Schwarz

Re: Blog

?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, "[hidden email]" <[hidden email]> escribió:

Leer: Manual de GemStone/S, capitulo Replicates y Forwaders.

Saludos,
Bruno

----Mensaje original----

De: [hidden email]

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 <[hidden email]>

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 <[hidden email]>:

> 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 [hidden email]

To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--

To post to this group, send email to [hidden email]

To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Gerardo Richarte

Re: Blog

In reply to this post by Angel Java Lopez

On 10/13/2010 08:10 AM, Angel Java Lopez wrote:
> - Eso de "un objeto un thread",
mirá este video de Dave Ungar (OOPSLA 2008),
http://vimeo.com/4121181

un objeto un core, en un chip de 64 cores, squeak toqueteado,
tiene unos gráficos de distribución de carga en los cores que
son geniales.

perdón si me pierdo algunos cometnarios del thread este, algunos
mails los salteo

saludos,
gera

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

BrunoBB

Re: Blog

In reply to this post by Manzanos

Primero hay que leer el/los manual/es (que lo bajas de la pagina de GemStone/S).

Luego cuando se sabe como funciona se podes evaluar a gusto.

Saludos,
Bruno

----Mensaje original----

De: [hidden email]

Fecha: 14/10/2010 09:31

Para: "[hidden email]"

CC: ""

Asunto: Re: [clubSmalltalk] Blog

?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, "[hidden email]" <[hidden email]> escribió:

Leer: Manual de GemStone/S, capitulo Replicates y Forwaders.

Saludos,
Bruno

----Mensaje original----

De: [hidden email]

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 <[hidden email]>

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 <[hidden email]>:

> 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 [hidden email]

To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--

To post to this group, send email to [hidden email]

To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--

To post to this group, send email to [hidden email]

To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--

To post to this group, send email to [hidden email]

To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

Andres Valloud-5

Re: Blog

In reply to this post by Francisco Garau

> Esta bueno. En algun momento lei a Spencer Brown no llegue a
> relacionarlo con lo que hacemos en Smalltalk. Hablas de eso en tu
> libro de mentoring? (a ver si aprovecho la oferta de Octubre y me lo
> compro...)

Si... el libro habla bastante de la relacion entre lo que dice Spencer
Brown y lo que hacemos en Smalltalk. Incluso hay un apendice que
compara Design Principles Behind Smalltalk y Laws of Form. Spencer
Brown visito PARC en 1979.

> Que pasa si la ejecucion del metodo tiene side-effects en el receiver?
> La ejecucion vuelve al mismo lugar pero internamente hay un cambio.

El receiver sigue siendo un objeto con n slots... el problema seria si
la identidad del receiver se rompiera (notese que la identidad no se
rompe con become:, oneWayBecome:, etc).

> El ejemplo del auto se entiende perfecto. Pero no veo tan claro que
> muchos bugs sean causados por violar este principio. Tenes algun
> ejemplo de violacion de este principio en Smalltalk?

Hay un monton... especialmente con el primer axioma que dice que usar
un nombre una vez es lo mismo que usarlo dos veces. Entonces, todas
las equivocaciones (usar la misma palabra para dos cosas diferentes)
son violaciones del primer axioma. En Smalltalk, un ejemplo seria
equivocarse con las variables temporales y mandarle become: al objeto
equivocado. En C, pointer aliasing.

>> Ahora bien, dije antes que uno distingue segun cierta intencion.
>> Seguro: una mesa de madera se convierte en leña si la alternativa es
>> morir de frio. El alambre y el moco sirven para arreglar cualquier
>> cosa (decian).
>
>> Que es una intencion, entonces? Es un filtro que
>> reacciona ante ciertos patrones de diferencias de valor. A mayor
>> reaccion, mayor intencion.
>
> No entiendo. A que te referis con "reaccion"?

Mayor reaccion del filtro.

>> Y cuando decimos "yo soy esto", que?
>
> Estas pensando en la General Semantics de Korzybski?

No, ni idea de que es eso.

Andres.

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

1 ... 3456