Blog
Locked
123456
123456
 
|
Hola, Carlos:
Yo lo leí, altamente recomendable, pero para pocos, -square heads refrain-. Del mismo palo, -de hecho de un maestro- recomiendo cualquiera de Osho -o en su defecto satyam shivam sundram, acá traducido como "La pasión por lo imposible" o al menos es uno muy parecido, hay uno muy bueno que se llama "Zaratustra a god that can dance" excelente.
Creo que ninguno lo leyó, si no, no se harían estos planteos que son sólo planteos de la mente que quiere y necesita hacer de todo un objeto....que grande eckhart :). Dejen de pensar tanto.
Saludos
-- 2010/10/5 Guillermo Schwarz <[hidden email]> Opiniones son opiniones y desde ese punto de vista son todas respetables, sin embargo si el texto no es mas que citas no explicadas y comentarios como "leete este libro" quedamos en el mismo punto donde partimos, pero con la sensación de que es mucho mas difícil de lo que parece. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Guillermo Schwarz
El día 5 de octubre de 2010 16:27, Guillermo Schwarz
<[hidden email]> escribió: > Opiniones son opiniones y desde ese punto de vista son todas respetables, > sin embargo si el texto no es mas que citas no explicadas y comentarios > como "leete este libro" quedamos en el mismo punto donde partimos, pero con > la sensación de que es mucho mas difícil de lo que parece. > Guillermo, es mucho más difícil de lo que parece :) Para que te des una idea, de algunos pasajes del Fedón o la República hay gente que se dedica toda una vida a escribir, y cualquier buen comentador de Platón cita en griego, y desde ya que uno tiene que tener el Liddell-Scott. En este caso prefiero recomendarte un buen comentador o traductor, cuya lectura es mucho más valiosa que unas pocas líneas que yo te pueda escribir por acá, y por otro lado es muy difícil que la lectura de un Ross, Burnyeat o Jaeger (no es Mick, es otro) te deje en el mismo punto donde partiste. Al que sepa aprovecharlo bien, y al que no, tambien. > Y si mas encima decimos "esto es muy complejo" es porque o no lo entendemos > o no queremos que el interlocutor entienda. O también sucede que sabemos que el interlocutor no está capacitado aún para entender ciertas cuestiones de ciertos autores, a partir del vocabulario que utiliza absolutamente carente de terminología técnica filosófica. Pueden pasar muchas cosas. Saludos, Hernán -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Nahuel Silva
"Pensar tanto" ja ja ja Eso me recuerda a un presidente latinoamericano que decía que había leído a Sócrates. Lo de cosificar y lo de objetivizar los conceptos del lenguaje que se produce en smalltalk no es un principio filosofico sino que corresponde a un nombre para algo que se produce en todos los lenguajes de programacion y que simplementecae trata de uniformidad. Eso de darsela de filósofos por algo tan simple no tiene sentido, aunque debo reconocer que en el caso de smalltalk, gracias a la uniformidad todo resulta tan simple. Saludos, Guillermo Schwarz. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
En realidad yo cuando hablo de modelar "la realidad" justamente me refiero a eso, a transformar en objetos los conceptos y entidades del lenguaje, quizá la palabra "realidad" es la que presta a confusión (dado que por lo que veo su significado es muy discutido filosoficamente). Esto no necesariamente tiene que hacerse luego de subrayar palabras en los requerimientos (de hecho me parece una muy mala práctica). Esto puede hacerse de manera incremental a medida que uno va programando, modelando y descubriendo el dominio. Muchas veces también surgen objetos que no tienen que ver con el dominio que se está programando si no que tienen más que ver con el dominio "computacional", es decir, cuestiones implementativas (persistencia, transaccionalidad, seguridad, etc).
Por otro lado, aprovecho a mencionarte algo de lo que comentaste en algún momento de Alan Kay sobre que la hubiese llamado programación orientada a mensajes (en lugar de objetos). Leí el artículo en donde menciona eso (si no me equivoco era una entrevista), en realidad él se refiere a que el verdadero poder de la programación con objetos está en late binding, y es algo que muchos lenguajes/programadores pierden de vista, especialmente cuando hablan de "llamadas a métodos" y no de objetos enviando mensajes.
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: [Off topic] Re: [clubSmalltalk] Blog
|
|
In reply to this post by hernanmd
On Tue, 2010-10-05 at 07:46 +0200, Hernán Morales Durand wrote:
> Hola Guillermo, > > Vamos a aclarar algunas cosas :) > > El día 5 de octubre de 2010 06:50, Guillermo Schwarz > <[hidden email]> escribió: > > Anda, sí, es lo mismo, sólo quería aclarar un poco el lenguaje. > > > > Tanto creen estos griegos que el infinito no puede existir que Leucipo y > > Demócrito inventan el átomo como una idea no comprobable en su tiempo de > > que nada se puede dividir para siempre, ya que eso implicaría que al > > menos algo, en algún sentido, es infinito. La idea fundamental de los > > griegos de que el universo es finito estaría en cuestionamiento, lo que > > No es por aguarte la sopa :) pero hay que poner un poco las cosas en > contexto, la idea de la imposibilidad de lo infinito aparece en > realidad en las escuelas de Gorgias y Plotino (y Lao-tsé en China) > pero en el contexto de que quieren trascender el Ser hacia el concepto > de la nada, el Ser para estas escuelas es la fuente de todas las > cosas, mmmmh... no me suena. En el caso de Lao Tse o Lao Tzu (que significa maestro Lao), ocurre que indica algo en su única obra, el Tao Te King o Tao Te Ching (libro de la virtud del Tao), que todas las cosas cambian gracias al Tao pero el Tao es permanente, en otras palabras, si nos atenemos al pensamiento Griego, las cosas que existen, cambian, las que no existen, es decir las que son conceptuales, no cambian, por lo tanto el Tao es meramente conceptual. Pues bien Lao Tse indica que todas las cosas fueron generadas por el Tao y el Tao proviene del Uno. Creo que es muy críptica la cita, muy difícil de entender para los no iniciados en el Taoísmo, en particular a mí me parece que puede estar hablando de cualquier cosa, pero ateniéndose al lugar y tiempo del cuál procedía (500 ac, contemporáneo de Confucio), supongo que sus palabras corresponden a algo con sentido práctico, porque es en la actualidad que las personas buscan un sentido místico o trascendental de las cosas, en esos tiempos (fin del periodo de los reinos combatientes), las personas estaban más enfocadas en el sentido práctico de la vida. Da la casualidad que todas las grandes filosofías fueron generadas en periodos con grandes guerras, porque es la desesperación de los problemas causados por la guerra que hace que las personas se vean sometias a situaciones por las que nunca pensaron pasar o siquiera que pudieran suceder, lo que les hace tener otro punto de vista y darse cuenta de las cosas, muy parecido al concepto de maya y de nirvana de la filosofía hindú (maya = apariencia, nirvana = realidad). ¿Porqué digo esto? Porque cuando un sistema falla es que nos damos cuenta cómo realmente funciona. Si tenemmos un auto que anda siempre, pensamos que apretando el pedal todo funciona, pero cuando tiene una pana, debemos darnos cuenta de cuáles son los mecanismos que hacen que funcione. Ahora bien, como ingenieros ese es el tipo de realidad que vivimos y que a mi entender corresponde a la idea de nirvana, pero existen otros tipos de realidades, las realidades creadas, por ejemplo, cuando creas capas de abstracción con ideas que previamente no existían. Eso es muy común en Smalltalk. De hecho lo interesante es que es el proceso inverso del nirvana, en vez de darte cuenta de los mecanismos, los ocultas tras de una capa de abstracción que es sólo apariencia (maya), hasta llegar al punto en el que sólo queda la apariencia y los mecanismos desaparecen desde el punto del usuario de la capa de abstracción. Me ha pasado que incluso reemplazas la implementación por otra y todo sigue funcionando igual e incluso hasta más rápido. > por lo que no podrían imaginar que tuviese ni comienzo ni > final, así que no es que creían tipo patota que el infinito no puede > existir, de hecho me resulta difícil creer que de alguno de los > pensadores helénicos de los que se conservan textos se pudiese > encontrar algo así escrito. Ah sí, ¿porqué? No es que sepa leer cóptico http://www.stshenouda.com/coptlang/copthist.htm de hecho quienes aprenden se demoran decenas de años en aprender como dices tú, pero me pregunto si encuentras que algún pensador griego entra en contradicción con la idea de que el infinito no existe. Yo lo veo así: el infinito existe por comprensión, pero no por extensión. ;-) > Lo que sí vas a encontrar por ejemplo en > Gorgias es que un Ser infinito no puede existir porque lo limitaría el > espacio y tiempo, y el Ser es anterior a esto. Bueno en Platón en > realidad lo que se estudia es el problema del No-Ser, pero esto es > algo mucho más complejo. Es como un juego de palabras sin sentido, como la paradoja de Russell. http://plato.stanford.edu/entries/russell-paradox/ > > Pero como sea, todo esto está encerrado en el programa metafísico del > Uno, Unidad o Ser de cada pensador. Platón en el Fedón te dice que "no > hay nada que pueda existir si no es participando en su propia esencia" ¿Será lo mismo que dije yo antes? Creo que sí. > (trad. de Benjamin Jowett), para Aristóteles en cambio el propósito de > la filosofía era la pregunta "porqué?" cuya respuesta era la causa y > la última era el Motor Inmóvil que es su causa teleológica y principio > simple. Como ves, no se puede abarcar tan fácilmente algunos temas > porque la mayoría de los conceptos importantes en los griegos estaban > entrelazados en varios textos, y sin un tratamiento sistémico. Pues bien si leemos la biblia el gran pensador llamado Jesús de Nazareth dijo: "no dejes que tu mano derecha sepa lo hace la izquierda" y todo el mundo hoy lo interpreta como que en una organización debe haber segregación de funciones. No tengo nada contra la segregación de funciones, me parece muy bien. Pero da la casualidad que en Nepal te saludan y comen con la derecha y se limpian al trasero con la izquierda, porque no conocen el papel confort. Imagino que en la época de Jesús tampoco sabían de esto, de modo que la frase me hace mucho sentido. ¿No será que a los filósofos de la antigüedad, que de seguro eran personas simples, les dan una significación a sus textos que se contradice con la condición en la que vivían? > > Para ser un poco más estrictos, no es que Sócrates "emprende contra" > los sofistas, ni tampoco que los sofistas tenían tanta visión taoísta > :) (en verdad en Filosofía Comparativa se analiza mucho más la > influencia India en los helénicos). No estoy diciendo que el taoísmo y el sofismo sea lo mismo, pero vaya que se parece. Hoy en día se utiliza la palabra sofismo en forma despectiva para referirse a filosofías desprestigiadas o deliberadamente creadas para engañar a personas con poca educación. En los tiempos de la antigua grecia el conocimiento es sofismo y la filosofía era un invento de Sócrates que efectivamente emprende contra los sofistas abiertamente. http://www.personal.kent.edu/~jwattles/sophists.htm > > > pondría en duda su filosofía de apropiarse primero de todos los > > recursos. También entraría en contradicción con la idea de la entropía > > en termodinámica que dice que la energía de un sistema cerrado tiende a > > disiparse (o a volverse menos disponible). > > > > En todo caso hay que leer a Platón con cuidado. > > y en lo posible con varios Seminarios de Griego encima :) No creo que se pueda aprender mucho de Platón ni aunque éste hablara Castellano. La razón es que su pensamiento está claramente influido por los acontecimientos de su época, al entender dónde y cupando vivía nos daríamos cuenta que piensa puras trivialidades, así como hablar con una persona de esta época lleva inevitablemente a las mismas ideas (todo es tan largo y difícil), ¿no seŕa que no nos tomamos el tiempo para pensar lo que estamos haciendo de manera de no desperdiciar el tiempo siempre haciendo lo mismo? ¿No será que por no querer perder el tiempo, por querer disfrutar de la vida, no nos tomamos un tiempo para reflexionar respecto de lo que hacemos y por lo tanto acabamos como en el mito de Sísifo? > > > El pibe escribe en Res > > Publicae (La República o la Cosa Pública) que no puede haber democracias > > que se sustenten para siempre porque degeneran en populismos, que son > > luego sofocados por el rigor de las dictaduras. > > > > ¿Será por eso que nuestros padres fundadores fundaron repúblicas y no > > democracias? > > > > Saludos, > > Guillermo. > > > Saludos > > Hernán > -- 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 |
|
|
In reply to this post by Andres Valloud-5
Es cierto, debe haber diferencias en los atributos para poder distinguir
las cosas. Y son las cosas las que tienen atributos, la nada no puede tener atributos. Esta es una de las críticas que le hace Nikola Tesla a Albert Einstein. Ahora bien, en Física abundan los memes de que es la simetría la que permite descubrir nuevas relaciones, y la simetría es la ausencia, o al menos la reducción, de las diferencias en los valores. Si todo fuera simétrico, entonces nada se podría hacer. Por ejemplo no podríamos extraer energía, porque al extraerla, la misma cantidad de energía tendría que ir en sentido opuesto. La falta de simetría es por lo tanto lo que mueve al mundo. ;-) Si todas las cosas dependen de las intenciones, ¿dónde dejas la ley de las consecuencias indeseadas (unintended consequences)? Saludos, Guillermo. On Tue, 2010-10-05 at 01:29 -0700, Andres Valloud 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. > > 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. > > 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. > > 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*). > > 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. 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? > > Andres. > > 2010/10/5 Francisco Garau <[hidden email]>: > > Hola Norberto, > > > > Muy bueno tu blog - me gusta mucho la claridad y profundidad con la > > que escribís. > > > > Las preguntas que a mi me quedan luego de leer tus artículos son: que > > es la realidad? como modelamos la realidad? si modelamos con objetos, > > somos objetivos? es posible ser objetivo? > > > > Para responder estas preguntas en el mundo informático, me parece > > interesante ver como analiza un problema similar Christopher Alexander > > en su articulo "A city is not a tree" [1]. Para resumirlo, si > > analizamos la estructura de una ciudad, terminamos con una estructura > > de árbol o un reticulado? > > > > Entiendo que Aristoteles se inclinaba mas a clasificar los objetos de > > la realidad con una estructura de árbol: es decir, una mesa ES una > > mesa y nada mas. > > > > - Francisco > > > > [1] http://www.rudi.net/pages/8755 > > > > > > > > > > 2010/10/4 Norberto Manzanos <[hidden email]>: > >> Fah. ¡cuántas cosas que escribiste! Me alegra que estemos en lo mismo, en el > >> sentido de mirar a los objetos con el prisma de la filosofía. Mi postura > >> filosófica es bastante distinta, pero eso es lo que hace que sea más > >> interesante. > >> Voy a ir leyendo tu blog y lo engancharé con mis notas. > >> > >> Saludos > >> Norberto > > > > -- > > To post to this group, send email to [hidden email] > > To unsubscribe from this group, send email to [hidden email] > > > > http://www.clubSmalltalk.org > -- 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 |
|
|
> 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 [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Gaboto
Polimorfismo. Esa es la idea de fondo.
¿para qué? Según yo para hacer programas genéricos, en los que las diferencias están en las pequeñas clases que implementan los diferentes comporatamientos, pero el algoritmo general es siempre el mismo. ¿Porqué alguien querría hacer algo como eso? Por ejemplo si pensamos que las empresas en el futuro serán todas como Google, dando servicios por la red, entonces todas las empresas querrán programar sus algoritmos una sola vez y luego sólo irlos adaptando un poco en la medida que vayan captando nuevos clientes con nuevas necesidades. Saludos, Guillermo. On Tue, 2010-10-05 at 20:21 -0300, Gabriel Brunstein wrote: > > > Lo de cosificar y lo de objetivizar los conceptos del lenguaje > que se produce en smalltalk no es un principio filosofico sino > que corresponde a un nombre para algo que se produce en todos > los lenguajes de programacion y que simplementecae trata de > uniformidad. > > > En realidad yo cuando hablo de modelar "la realidad" justamente me > refiero a eso, a transformar en objetos los conceptos y entidades del > lenguaje, quizá la palabra "realidad" es la que presta a confusión > (dado que por lo que veo su significado es muy discutido > filosoficamente). Esto no necesariamente tiene que hacerse luego de > subrayar palabras en los requerimientos (de hecho me parece una muy > mala práctica). Esto puede hacerse de manera incremental a medida que > uno va programando, modelando y descubriendo el dominio. Muchas veces > también surgen objetos que no tienen que ver con el dominio que se > está programando si no que tienen más que ver con el dominio > "computacional", es decir, cuestiones implementativas (persistencia, > transaccionalidad, seguridad, etc). > > > Por otro lado, aprovecho a mencionarte algo de lo que comentaste en > algún momento de Alan Kay sobre que la hubiese llamado programación > orientada a mensajes (en lugar de objetos). Leí el artículo en donde > menciona eso (si no me equivoco era una entrevista), en realidad él se > refiere a que el verdadero poder de la programación con objetos está > en late binding, y es algo que muchos lenguajes/programadores pierden > de vista, especialmente cuando hablan de "llamadas a métodos" y no de > objetos enviando mensajes. > > > > > El 05-10-2010, a las 15:47, Nahuel Silva > <[hidden email]> escribió: > > > > > > Hola, Carlos: > > > > > > Yo lo leí, altamente recomendable, pero para pocos, -square > > heads refrain-. Del mismo palo, -de hecho de un maestro- > > recomiendo cualquiera de Osho -o en su defecto satyam shivam > > sundram, acá traducido como "La pasión por lo imposible" o > > al menos es uno muy parecido, hay uno muy bueno que se llama > > "Zaratustra a god that can dance" excelente. > > Creo que ninguno lo leyó, si no, no se harían estos planteos > > que son sólo planteos de la mente que quiere y necesita > > hacer de todo un objeto....que grande eckhart :). > > > > > > Dejen de pensar tanto. > > > > > > Saludos > > > > 2010/10/5 Guillermo Schwarz <[hidden email]> > > Opiniones son opiniones y desde ese punto de vista > > son todas respetables, sin embargo si el texto no es > > mas que citas no explicadas y comentarios como > > "leete este libro" quedamos en el mismo punto donde > > partimos, pero con la sensación de que es mucho mas > > difícil de lo que parece. > > > > Y si mas encima decimos "esto es muy complejo" es > > porque o no lo entendemos o no queremos que el > > interlocutor entienda. > > > > Haz la prueba de crear una aplicación utilizando la > > metodología de encontrar los sustantivos, de > > utilizar el has-a e is-a para encontrar las > > relacones entre las clases y vas a llegar a la > > conclusión de que el sistema esta mal modelado, > > muchos métodos inútiles y pocas clases que hacen > > todo y que cuesta poner a punto, con todo amarrado > > siendo imposible agregar mas funcionalidad > > posteriormente. > > > > La principal razón es que el software no existe para > > "modelar la realidad" (a menos que sea un software > > para predecir el clima), sino que intenta resolver > > uno o varios casos de uso de usuario > > (funcionalidades reales por la cuales el cliente > > esta dispuesto a pagar). Ese es el valor que el > > cliente y el usuario ven en el software, su > > comportamiento externo. > > > > Las jerarquías de clases son solamente formas de > > organizar el codigo internamente de manera de > > escribir la menor cantidad de código repetido > > posible. Existen otras técnicas para lograr lo > > mismo, por ejemplo las monadas en haskell. De hecho > > xmonad es un Window mánager heho en haskell y según > > dicen tiene menos líneas de código que cualquier > > otro window mánager. > > > > Se podría decir que si > > > > c = CPU del programador > > f = cantidad de funcionalidades > > R = líneas de código repetido > > T = líneas totales > > > > > > Entonces: > > > > C = f / TR > > > > Saludos, > > Guillermo Schwarz. > > > > El 05-10-2010, a las 14:48, Hernán Morales Durand > > <[hidden email]> escribió: > > > > > > > > El día 5 de octubre de 2010 04:43, Francisco > > Garau <[hidden email]> escribió: > > Hola Norberto, > > > > Muy bueno tu blog - me gusta mucho > > la claridad y profundidad con la > > que escribís. > > > > Las preguntas que a mi me quedan > > luego de leer tus artículos son: que > > es la realidad? como modelamos la > > realidad? si modelamos con objetos, > > somos objetivos? es posible ser > > objetivo? > > > > > > Es un poco complicado encarar así el tema de > > la realidad. No hay que > > olvidar que "realidad" es una palabra de uso > > ordinario y cargada de > > ambiguedad. Este tema está lleno de > > sociologías y filosofías > > subjetivistas, y se ha escrito tanto que uno > > puede pasar la vida > > leyendo y no terminar jamás: la realidad > > física newtoniana fue > > fantástica en su época, pero demostró ser > > inútil para la ciencia > > contemporánea, y la realidad que pretenden > > explicar los físicos > > teóricos o matemáticos son inútiles para los > > filósofos de la ciencia, > > que a su vez formulan más conceptos inútiles > > para los metafísicos, > > etc. Lamentablemente no hay forma de que uno > > se pueda saltar el > > vocabulario filosófico (que toma años > > adquirir) para tratar estos > > temas seriamente. > > > > Para responder estas preguntas en el > > mundo informático, me parece > > interesante ver como analiza un > > problema similar Christopher > > Alexander > > en su articulo "A city is not a > > tree" [1]. Para resumirlo, si > > analizamos la estructura de una > > ciudad, terminamos con una > > estructura > > de árbol o un reticulado? > > > > > > Mmm no, Alexander no es el pensador más > > apropiado para preguntarse por > > modelos cognitivos per se. Por ej. el > > trabajo del primer Alexander > > (principios de los 60) tiene que ver con el > > capital social, su > > pensamiento político y la sociedad de > > mercado democrática, la > > participación activa de la ciudadanía, etc. > > En este sentido hay un > > ensayo que se llama "The city as Mechanism > > for Sustaining Human > > Contact" que está relacionado más con su > > proyecto y, de hecho, el > > trabajo por el cual más se lo conoce "A > > pattern language" habla de > > patrones que pueden generar formas de vivir > > en una ciudad, o sea, > > diseño urbano humanista. El siempre está > > busca de patrones que forman > > y transforman a la sociedad democrática, > > como influencia en sus > > relaciones, como se intensifican de acuerdo > > a las necesidades de la > > población y la estructura de los entornos en > > donde vive. > > > > Para un análisis más informático > > (¿conexionista?) de la realidad hay > > otros autores más cercanos. > > > > Entiendo que Aristoteles se > > inclinaba mas a clasificar los > > objetos de > > la realidad con una estructura de > > árbol: es decir, una mesa ES una > > mesa y nada mas. > > > > > > Y... es un poco más complicado que eso, > > aunque es otro tema que es un > > clásico. Ya entender los primeros capítulos > > de las Categorías requiere > > una introducción al vocabulario de > > Aristóteles, por ej. que significa > > que una cosa esté "presente en un > > sujeto" (de lo que es predicable > > pero nunca presente, de lo nunca predicable > > pero presente, de lo > > predicable y presente y ni predicable ni > > presente, de qué significa > > que esté presente, etc.), y cosas como el > > principio de discriminación > > y univocidad. Es complicado :) > > > > Saludos, > > > > Hernán > > > > -- > > To post to this group, send email to > > [hidden email] > > To unsubscribe from this group, send email > > to clubSmalltalk > > +[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 clubSmalltalk > > +[hidden email] > > > > http://www.clubSmalltalk.org > > -- > To post to this group, send email to > [hidden email] > To unsubscribe from this group, send email to clubSmalltalk > +[hidden email] > > http://www.clubSmalltalk.org > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to clubSmalltalk > +[hidden email] > > http://www.clubSmalltalk.org -- 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 |
|
|
In reply to this post by Andres Valloud-5
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.
Guillermo. On Tue, Oct 5, 2010 at 11:14 PM, Andres Valloud <[hidden email]> wrote:
-- 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 |
|
|
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 <[hidden email]> Suena a que tiraste la toalla. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
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 <[hidden email]> Hola gente! -- 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 |
|
|
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 <[hidden email]> Autopoyesis es copia, no autoorganización. Que conduzca a la autoorganización es otra cosa. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
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. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
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 <[hidden email]>
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
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 <[hidden email]> Hola gente! -- 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 |
|
|
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 <[hidden email]> En Smalltalk lo que dices de migrar un objeto de una máquina a otra es (o debería ser) trivial. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
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 <[hidden email]> Hola gente! -- 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 |
|
|
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 <[hidden email]> Pero de alguna manera hay que decirle que los números y los strings no los "remotee". -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
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."
Saludos,
Guillermo. 2010/10/7 Angel Java Lopez <[hidden email]> Hola gente! -- 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 |
|
|
In reply to this post by Guillermo Schwarz
On 10/06/2010 08:16 PM, Guillermo Schwarz wrote:
> En Smalltalk lo que dices de migrar un objeto de una máquina a otra es > (o debería ser) trivial. che trivial, te invito a hacerlo -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
«
Return to Español (Spanish)
|
1 view|%1 views
| Free forum by Nabble | Edit this page |