Re: Sobre CUIS y Pharo
Locked
1234
... 7
1234
... 7
Re: Sobre CUIS y Pharo
 
|
Quoting "Esteban A. Maringolo" <[hidden email]>:
Hola Esteban, Espero que no te moleste que copie a ClubSmalltalk, Es simple. Dentro de los objetivos de Pharo está hacer un kernel pequeño y limpio, para cargar paquetes opcionales. Una manera de hacer eso es tomar todo lo que hay en Pharo y no en Cuis, y convertirlo en paquetes que se carguen en Cuis. O sea, adoptar Cuis como kernel. Así, alcanzarían este objetivo que se propusieron en sólo algunos meses de trabajo. Al paso que van, y con los años que van pasando, parece bastante claro que por el camino que están recorriendo, nunca van a llegar. Saludos, To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
El 31 de octubre de 2012 13:51, Juan Vuletich (mail lists)
<[hidden email]> escribió: > Quoting "Esteban A. Maringolo" <[hidden email]>: > Es simple. Dentro de los objetivos de Pharo está hacer un kernel pequeño y > limpio, para cargar paquetes opcionales. Una manera de hacer eso es tomar > todo lo que hay en Pharo y no en Cuis, y convertirlo en paquetes que se > carguen en Cuis. O sea, adoptar Cuis como kernel. Así, alcanzarían este > objetivo que se propusieron en sólo algunos meses de trabajo. Al paso que > van, y con los años que van pasando, parece bastante claro que por el camino > que están recorriendo, nunca van a llegar. Y esta impresión tuya al respecto del error de no adoptar Cuis como Kernel se la hiciste llegar a alguno de los "importantes" dentro del grupo de Pharo? Quizas no vean claramente que ganan al hacerlo, para algunas cosas noté algunas posiciones algo estrechas, que luego de cierto debate terminaron "torciendo el brazo". Tenes idea de qué cosas crees que detienen a la gente de Pharo en la adopción de Cuis? Saludos! Esteban A. Maringolo -- 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: Sobre CUIS y Pharo
|
|
Quoting "Esteban A. Maringolo" <[hidden email]>:
> El 31 de octubre de 2012 13:51, Juan Vuletich (mail lists) > <[hidden email]> escribió: > >> Quoting "Esteban A. Maringolo" <[hidden email]>: > >> Es simple. Dentro de los objetivos de Pharo está hacer un kernel pequeño y >> limpio, para cargar paquetes opcionales. Una manera de hacer eso es tomar >> todo lo que hay en Pharo y no en Cuis, y convertirlo en paquetes que se >> carguen en Cuis. O sea, adoptar Cuis como kernel. Así, alcanzarían este >> objetivo que se propusieron en sólo algunos meses de trabajo. Al paso que >> van, y con los años que van pasando, parece bastante claro que por el camino >> que están recorriendo, nunca van a llegar. > > Y esta impresión tuya al respecto del error de no adoptar Cuis como > Kernel se la hiciste llegar a alguno de los "importantes" dentro del > grupo de Pharo? Si, unas cuantas veces. La primera vez fue una conversacion privada con Ducasse antes de que él empezara con Sapphire, luego renombraado como Pharo. Eso fue en 2007, si recuerdo bien. En ese entonces yo ya estaba trabajando desde hacía algún tiempo en lo que todavía no se llamaba Cuis, pero ya estaba disponible y había sido anunciado en la lista de Squeak. (Era mi "Etoys free Squeak") Cuando Ducasse me contó que estaba planeando hacer un fork de Squeak, le propuse que aunáramos esfuerzos. La última vez fue este año, o el año pasado. > Quizas no vean claramente que ganan al hacerlo, para > algunas cosas noté algunas posiciones algo estrechas, que luego de > cierto debate terminaron "torciendo el brazo". Creo que ven claramente qué ganarían. Alcanza con browsear Cuis 5 minutos, o hacer cualquier métrica de tamaño o complejidad de código. Quizás además vean claramente qué perderían. Autonomía? Control? La posición de gurú? > Tenes idea de qué cosas crees que detienen a la gente de Pharo en la > adopción de Cuis? No. No lo sé. Quizás, soberbia. Pero habría que preguntarle a ellos. (Y leer entre líneas). > Saludos! > > Esteban A. Maringolo > http://www.clubSmalltalk.org Saludos, Juan Vuletich -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
El día 31 de octubre de 2012 14:10, Juan Vuletich (mail lists)
<[hidden email]> escribió: > Quoting "Esteban A. Maringolo" <[hidden email]>: >> Y esta impresión tuya al respecto del error de no adoptar Cuis como >> Kernel se la hiciste llegar a alguno de los "importantes" dentro del >> grupo de Pharo? > Si, unas cuantas veces. > > La primera vez fue una conversacion privada con Ducasse antes de que él > empezara con Sapphire, luego renombraado como Pharo. Eso fue en 2007, si > recuerdo bien. En ese entonces yo ya estaba trabajando desde hacía algún > tiempo en lo que todavía no se llamaba Cuis, pero ya estaba disponible y > había sido anunciado en la lista de Squeak. (Era mi "Etoys free Squeak") > Cuando Ducasse me contó que estaba planeando hacer un fork de Squeak, le > propuse que aunáramos esfuerzos. Curioso el nombre Sapphire, considerando que en InfOil nuestra plataforma de negocios (hecha en Smalltalk) se llama Zafiro. >> Quizas no vean claramente que ganan al hacerlo, para >> algunas cosas noté algunas posiciones algo estrechas, que luego de >> cierto debate terminaron "torciendo el brazo". > Creo que ven claramente qué ganarían. Alcanza con browsear Cuis 5 minutos, o > hacer cualquier métrica de tamaño o complejidad de código. > Quizás además vean claramente qué perderían. Autonomía? Control? La posición > de gurú? Lo de autonomía entiendo que podría ser, cada vez se comportan más como un vendor privado, pero open source. El resultado final habrá que comprobarlo, quizas dejan más gente afuera de la que podría sumarse. Pero la realidad es que ciertos desarrollos si no son "sponsoreados" tampoco se completarían en tiempo y forma. Qué es lo que impide que, por ej, Cuis se integre como kernel de Squeak? Osea... hacer de Squeak un mejor Smalltalk y forzar a que Pharo deba competir para superarlo? Que relación tiene Cuis con Spoon? (en concepto, digo). Parece que cada un número muy bajo de Smalltalkers hay una versión particular de Smalltalk. >> Tenes idea de qué cosas crees que detienen a la gente de Pharo en la >> adopción de Cuis? > No. No lo sé. Quizás, soberbia. Pero habría que preguntarle a ellos. (Y leer > entre líneas). Voy a preguntarlo. :) Saludos! -- 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: Sobre CUIS y Pharo
|
|
Quoting "Esteban A. Maringolo" <[hidden email]>:
> El día 31 de octubre de 2012 14:10, Juan Vuletich (mail lists) > <[hidden email]> escribió: >> Quoting "Esteban A. Maringolo" <[hidden email]>: >>> Y esta impresión tuya al respecto del error de no adoptar Cuis como >>> Kernel se la hiciste llegar a alguno de los "importantes" dentro del >>> grupo de Pharo? >> Si, unas cuantas veces. >> >> La primera vez fue una conversacion privada con Ducasse antes de que él >> empezara con Sapphire, luego renombraado como Pharo. Eso fue en 2007, si >> recuerdo bien. En ese entonces yo ya estaba trabajando desde hacía algún >> tiempo en lo que todavía no se llamaba Cuis, pero ya estaba disponible y >> había sido anunciado en la lista de Squeak. (Era mi "Etoys free Squeak") >> Cuando Ducasse me contó que estaba planeando hacer un fork de Squeak, le >> propuse que aunáramos esfuerzos. > > Curioso el nombre Sapphire, considerando que en InfOil nuestra > plataforma de negocios (hecha en Smalltalk) se llama Zafiro. Si, y que en Gemstone hay Gems y Stones. >>> Quizas no vean claramente que ganan al hacerlo, para >>> algunas cosas noté algunas posiciones algo estrechas, que luego de >>> cierto debate terminaron "torciendo el brazo". >> Creo que ven claramente qué ganarían. Alcanza con browsear Cuis 5 minutos, o >> hacer cualquier métrica de tamaño o complejidad de código. > >> Quizás además vean claramente qué perderían. Autonomía? Control? La posición >> de gurú? > > Lo de autonomía entiendo que podría ser, cada vez se comportan más > como un vendor privado, pero open source. > El resultado final habrá que comprobarlo, quizas dejan más gente > afuera de la que podría sumarse. > Pero la realidad es que ciertos desarrollos si no son "sponsoreados" > tampoco se completarían en tiempo y forma. > > Qué es lo que impide que, por ej, Cuis se integre como kernel de > Squeak? Osea... hacer de Squeak un mejor Smalltalk y forzar a que > Pharo deba competir para superarlo? En Squeak no hay voluntad de hacer grandes cambios. Fijate en los reportes de las reuniones del Board. > Que relación tiene Cuis con Spoon? (en concepto, digo). Para hacer imágenes mínimas con Spoon, Cuis es un mejor punto de partida que Squeak o Pharo. > Parece que cada un número muy bajo de Smalltalkers hay una versión > particular de Smalltalk. Si. No me parece mal. >>> Tenes idea de qué cosas crees que detienen a la gente de Pharo en la >>> adopción de Cuis? >> No. No lo sé. Quizás, soberbia. Pero habría que preguntarle a ellos. (Y leer >> entre líneas). > > Voy a preguntarlo. :) > > Saludos! Saludos, Juan Vuletich -- 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 Esteban A. Maringolo
Sin ánimo de ofender, creo que lo mejor que pudo pasar es que no se convirtieran en el mismo producto.
¿Porqué? Por varias razones: 1. Por alguna razón NO LES GUSTÓ Cuis.
2. Como tú dices, Cuis es más limpio que Pharo. Eso implica que al juntar ambos proyectos ahora Cuis no sería tan limpio. 3. ¿Porqué piensas que reimplementar Pharo sobre Cuis sería tan dificl? En general un proyecto grande es inmanejable, porque es demasiado complejo. Si Cuis es tan bueno como dices, mucha gente lo va a usar y eventualmente van a cooperar con código contigo.
“The mind is sharper and keener in seclusion and uninterrupted solitude. No big laboratory is needed in which to think. Originality thrives in seclusion free of outside influences beating upon us to cripple the creative mind. Be alone, that is the secret of invention; be alone, that is when ideas are born. That is why many of the earthly miracles have had their genesis in humble surroundings.” - Nikola Tesla
Saludos, Guillermo.
-- 2012/10/31 Esteban A. Maringolo <[hidden email]> El día 31 de octubre de 2012 14:10, Juan Vuletich (mail lists) 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 |
Re: Sobre CUIS y Pharo
|
|
Quoting Guillermo Schwarz <[hidden email]>: > Sin ánimo de ofender, creo que lo mejor que pudo pasar es que no se convirtieran en el mismo producto. No hay ninguna ofensa. > ¿Porqué? > Por varias razones: > 1. Por alguna razón NO LES GUSTÓ Cuis. Eso es una perogrullada. Si hubieran tomado a Cuis como base, habría sido evidencia de que sí les gustó... > 2. Como tú dices, Cuis es más limpio que Pharo. Eso implica que al juntar ambos proyectos ahora Cuis no sería tan limpio. El riesgo de eso es bastante bajo. A la hora de protejer a Cuis, soy bastante testarudo. > 3. ¿Porqué piensas que reimplementar Pharo sobre Cuis sería tan dificl? Eh? Yo no dije eso. > En general un proyecto grande es inmanejable, porque es demasiado complejo. Si Cuis es tan bueno como dices, mucha gente lo va a usar y eventualmente van a cooperar con código contigo. > “The mind is sharper and keener in seclusion and uninterrupted solitude. No big laboratory is needed in which to think. Originality thrives in seclusion free of outside influences beating upon us to cripple the creative mind. Be alone, that is the secret of invention; be alone, that is when ideas are born. That is why many of the earthly miracles have had their genesis in humble surroundings.” - Nikola Tesla Si, estoy de acuerdo con eso. Eso tiene mucho que ver con el origen de Smalltalk en Xerox Parc... > Saludos, > Guillermo. > Saludos, Juan Vuletich -- 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 J. Vuletich (mail lists)
El 31/10/2012 13:51, Juan Vuletich (mail lists) escribió:
> Quoting "Esteban A. Maringolo" <[hidden email]>: > >> >> Hola Juan, >> >> Leí esto en la lista de SqueakRos (no estoy suscripto) >> >> /"Lo de Pharo sí es una pena. Todavía no entendieron que Cuis les >> permitiría ir a donde quieren más rápido, y con un resultado mejor."/ >> >> Podrías ampliar un poco? >> >> Gracias! > > Hola Esteban, > > Espero que no te moleste que copie a ClubSmalltalk, > > Es simple. Dentro de los objetivos de Pharo está hacer un kernel pequeño > y limpio, para cargar paquetes opcionales. Una manera de hacer eso es > tomar todo lo que hay en Pharo y no en Cuis, y convertirlo en paquetes > que se carguen en Cuis. O sea, adoptar Cuis como kernel. Así, > alcanzarían este objetivo que se propusieron en sólo algunos meses de > trabajo. Al paso que van, y con los años que van pasando, parece > bastante claro que por el camino que están recorriendo, nunca van a llegar. > Mmm, ¿te parece que son tan inocentes? Los académicos tienen necesidad de publicar papers. Una manera de hacerlo es escribir un poco de software, mostrar que más o menos funciona y escribirlo en un artículo. Un software robusto requiere un poco más que eso. Además están en otra, los revisores de las revistas científicas no deciden aceptar un paper por mejorar procedimientos de instalación, manuales, o depurar cosas viejas y aburridas. Saludos > Saludos, > Juan Vuletich > > -- > 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 |
|
|
El día 5 de noviembre de 2012 01:06, Hernán Morales Durand
<[hidden email]> escribió: > Mmm, ¿te parece que son tan inocentes? Los académicos tienen necesidad de > publicar papers. Una manera de hacerlo es escribir un poco de software, > mostrar que más o menos funciona y escribirlo en un artículo. Un software > robusto requiere un poco más que eso. > > Además están en otra, los revisores de las revistas científicas no deciden > aceptar un paper por mejorar procedimientos de instalación, manuales, o > depurar cosas viejas y aburridas. O sea que en tu opinión la gente de Pharo tiene como objetivo usarlo sólo como una excusa para publicar papers y obtener fondos para "financiarse"? Saludos! -- 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 J. Vuletich (mail lists)
>> ¿Porqué?
>> Por varias razones: >> 1. Por alguna razón NO LES GUSTÓ Cuis. > > Eso es una perogrullada. Si hubieran tomado a Cuis como base, habría sido > evidencia de que sí les gustó... ... pero puede haberles gustado sin necesidad de que lo usaran... esta medio binario este asunto... 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 hernanmd
On 05/11/2012 01:06 a.m., Hernán
Morales Durand wrote:
Mmm, ¿te parece que son tan inocentes? Los académicos tienen necesidad de publicar papers. Una manera de hacerlo es escribir un poco de software, mostrar que más o menos funciona y escribirlo en un artículo. Un software robusto requiere un poco más que eso. Hernán, me parece que con esto estás muy equivocado. La robustez es una de las preocupaciones del proyecto Pharo, y eso se ve. Pero eso, por supuesto es discutible. El proyecto tiene muchas facetas aparte de la académica, no es para producir papers sino que lo veo funcionando al revés: el hecho de posibilitar papers hace que Ducasse pueda tener una pila de estudiantes (muchos argentinos) trabajando en Pharo, y que al mismo tiempo avancen académicamente, terminando doctorados. Y hay muchos proyectos en marcha que son, justamente, las cosas que vos decís: procedimientos de instalación, debugging... Un ejemplo directo que me viene a la mente es Hazelnut, de Guillermo Polito. Ahora lo va a presentar en Smalltalks, pero no tiene ningún interés académico, es una herramienta para configurar fácilmente imágenes con paquetes... Y, por supuesto, los libros de Pharo by Example de Ducasse, donde colabora mucha gente. Los libros tienen muy poco reconocimiento académico... Saludos -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Calmense muchachos, porque no pensamos en la arquitectura en el mundo de IT?
https://i.chzbgr.com/completestore/12/10/29/PRrf9YpvQEiyxpjNtY9mLA2.jpg 2012/11/5 Carlos E. Ferro <[hidden email]>: > On 05/11/2012 01:06 a.m., Hernán Morales Durand wrote: > > Mmm, ¿te parece que son tan inocentes? Los académicos tienen necesidad de > publicar papers. Una manera de hacerlo es escribir un poco de software, > mostrar que más o menos funciona y escribirlo en un artículo. Un software > robusto requiere un poco más que eso. > > Además están en otra, los revisores de las revistas científicas no deciden > aceptar un paper por mejorar procedimientos de instalación, manuales, o > depurar cosas viejas y aburridas. > > > Hernán, me parece que con esto estás muy equivocado. > La robustez es una de las preocupaciones del proyecto Pharo, y eso se ve. > Pero eso, por supuesto es discutible. > > El proyecto tiene muchas facetas aparte de la académica, no es para producir > papers sino que lo veo funcionando al revés: el hecho de posibilitar papers > hace que Ducasse pueda tener una pila de estudiantes (muchos argentinos) > trabajando en Pharo, y que al mismo tiempo avancen académicamente, > terminando doctorados. > > Y hay muchos proyectos en marcha que son, justamente, las cosas que vos > decís: procedimientos de instalación, debugging... Un ejemplo directo que me > viene a la mente es Hazelnut, de Guillermo Polito. Ahora lo va a presentar > en Smalltalks, pero no tiene ningún interés académico, es una herramienta > para configurar fácilmente imágenes con paquetes... Y, por supuesto, los > libros de Pharo by Example de Ducasse, donde colabora mucha gente. Los > libros tienen muy poco reconocimiento académico... > > Saludos > -- > > carlos e. ferro | senior developer | caesar systems > > [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 -- 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, como pharo-dev asalariado, estoy en mi deber de responder esto.
No quería meterme porque me parece una perdida absoluta de tiempo, pero viendo por donde empieza a rumbear esto... Cuis no se puede usar como núcleo de Pharo por varios motivos: 1) Cuis quiere ser un Smalltalk-80 limpio, Pharo ni siquiera tiene interés en mantenerse como Smalltalk (de ahí el slogan "Smalltalk inspired") 2) Cuis es el proyecto de Juan, y como el bien mismo dijo "tiene un control muy fuerte de lo que hay adentro", Pharo pretende ese mismo control para si mismo. Por ejemplo, en 2.0 cambiamos el schema de Behavior, para añadir un atributo "layout"... en el primer paso para transformar los atributos de una instancia en "first class instances"... slots, bah, y no solo #symbols como hasta ahora. Dado que eso hace que Pharo deje de ser un st80 (al igual que la inclusion de Traits, btw), es difícil pensar que eso se pudiera consensuar con Juan, ¿no? Y en todo caso el equipo de Pharo, por supuesto, reclama para sí el mismo control que Juan reclama para su proyecto (¿Y que es lo malo de esto?) 3) Pharo pretende construir una reificación completa del concepto de imágen (hacer Pharo new y tener una imagen idem con la que comunicarse, y que esta imagen pueda correrse en otros threads, cores e incluso máquinas). Por supuesto, esto escapa al objetivo de Cuis, y requiere cambios en el Kernel que no son pocos. (Hazelnut, de hecho, es el primer paso de un largo camino en ese sentido) 4) Asimismo Pharo pretende cambiar cosas como el formato de la imagen (no un binario, sino una serializacion, que permita cargar la misma imagen en arquitecturas 64bits), eliminar el sources files y modificar los changes y lo que se guarda ahí. 5) Todo eso junto con la fundación de una plataforma que permita hacer software para negocios. Cualquiera que se haya tomado en serio promocionar un lenguaje sabe que eso no es tan fácil, que requiere construir una infraestructura que en mucho rebasa lo meramente técnico, pero que también tiene algunos elementos técnicos que son necesarios cumplir: procesos de reconstrucción (no habilitados con el proceso evolutivo de ahora), requerimientos de seguridad (que hoy no existe) y un larguísimo etc. De lo "no tecnico", lo más importante es crear una estructura que pueda ofrecer seguridad a empresas (con soporte y la garantía de que "hay alguien atrás"). En esencia, el único objetivo común que tienen Cuis y Pharo es el de modularización, y hasta eso se encara con filosofías distintas (dado que no es solo separación, sino interacción entre módulos, etc.)... y por supuesto que hay ideas muy buenas en Cuis, y nosotros mantenemos un ojo ahí para ver que podemos "tomar prestado" (y tambien en Squeak), pero no veo por qué se insiste tanto en algo que simplemente no se ajusta a la realidad, la posibilidad de construir un Pharo o un Squeak a partir de un Cuis... Y no se ajusta a la realidad entre otras cosas porque pedir eso atrapa los ambientes los unos con los otros impidiéndoles evolucionar a todos. Después, bueno... los argumentos mezquinos realmente no me interesan, me parece que no contribuyen en nada a tener un debate constructivo, así que discúlpenme si no me detengo en ellos. Saludos, Esteban On Nov 5, 2012, at 1:38 PM, Andres Valloud <[hidden email]> wrote: > Calmense muchachos, porque no pensamos en la arquitectura en el mundo de IT? > > https://i.chzbgr.com/completestore/12/10/29/PRrf9YpvQEiyxpjNtY9mLA2.jpg > > 2012/11/5 Carlos E. Ferro <[hidden email]>: >> On 05/11/2012 01:06 a.m., Hernán Morales Durand wrote: >> >> Mmm, ¿te parece que son tan inocentes? Los académicos tienen necesidad de >> publicar papers. Una manera de hacerlo es escribir un poco de software, >> mostrar que más o menos funciona y escribirlo en un artículo. Un software >> robusto requiere un poco más que eso. >> >> Además están en otra, los revisores de las revistas científicas no deciden >> aceptar un paper por mejorar procedimientos de instalación, manuales, o >> depurar cosas viejas y aburridas. >> >> >> Hernán, me parece que con esto estás muy equivocado. >> La robustez es una de las preocupaciones del proyecto Pharo, y eso se ve. >> Pero eso, por supuesto es discutible. >> >> El proyecto tiene muchas facetas aparte de la académica, no es para producir >> papers sino que lo veo funcionando al revés: el hecho de posibilitar papers >> hace que Ducasse pueda tener una pila de estudiantes (muchos argentinos) >> trabajando en Pharo, y que al mismo tiempo avancen académicamente, >> terminando doctorados. >> >> Y hay muchos proyectos en marcha que son, justamente, las cosas que vos >> decís: procedimientos de instalación, debugging... Un ejemplo directo que me >> viene a la mente es Hazelnut, de Guillermo Polito. Ahora lo va a presentar >> en Smalltalks, pero no tiene ningún interés académico, es una herramienta >> para configurar fácilmente imágenes con paquetes... Y, por supuesto, los >> libros de Pharo by Example de Ducasse, donde colabora mucha gente. Los >> libros tienen muy poco reconocimiento académico... >> >> Saludos >> -- >> >> carlos e. ferro | senior developer | caesar systems >> >> [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 > > -- > 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 |
Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
El día 5 de noviembre de 2012 10:40, Esteban Lorenzano
<[hidden email]> escribió: > Bueno, como pharo-dev asalariado, estoy en mi deber de responder esto. > No quería meterme porque me parece una perdida absoluta de tiempo, pero viendo por donde empieza a rumbear esto... Se agradece :) > Cuis no se puede usar como núcleo de Pharo por varios motivos: > 1) Cuis quiere ser un Smalltalk-80 limpio, Pharo ni siquiera tiene interés en mantenerse como Smalltalk (de ahí el slogan "Smalltalk inspired") Nunca le presté atención a la parte "inspired". Aunque para mi seguirá siendo un Smalltalk, diferente, Quizas no un ST80, pero Smalltalk al fin. > 2) Cuis es el proyecto de Juan, y como el bien mismo dijo "tiene un control muy fuerte de lo que hay adentro", Pharo pretende ese mismo control para si mismo. > Por ejemplo, en 2.0 cambiamos el schema de Behavior, para añadir un atributo "layout"... en el primer paso para transformar los atributos de una instancia en "first class instances"... slots, bah, y no solo #symbols como hasta ahora. Dado que eso hace que Pharo deje de ser un st80 (al igual que la inclusion de Traits, btw), es difícil pensar que eso se pudiera consensuar con Juan, ¿no? Y en todo caso el equipo de Pharo, por supuesto, reclama para sí el mismo control que Juan reclama para su proyecto (¿Y que es lo malo de esto?) En lo personal no veo nada de malo y esto responde bien de fondo a mi pregunta inicial a Juan. Lo único que quizas se lamenta es la fragmentación que tenemos siendo tan pocos, pero comparto el hecho que no puede subordinarse un proyecto a otro, cuando la visión y expectativas son tan diferentes. > 3) Pharo pretende construir una reificación completa del concepto de imágen (hacer Pharo new y tener una imagen idem con la que comunicarse, y que esta imagen pueda correrse en otros threads, cores e incluso máquinas). [SNIP] No logro entender el uso directo de esto, salvo en un futuro con procesadores de n-cores. > 4) Asimismo Pharo pretende cambiar cosas como el formato de la imagen (no un binario, sino una serializacion, que permita cargar la misma imagen en arquitecturas 64bits), eliminar el sources files y modificar los changes y lo que se guarda ahí. Qué se gana con esto con respecto a una "conversión" a 64 bits? Osea, salvo que se quiera tener un sólo image para 32 y para 64, para evitarse el proceso de conversión. > 5) Todo eso junto con la fundación de una plataforma que permita hacer software para negocios. Cualquiera que se haya tomado en serio promocionar un lenguaje sabe que eso no es tan fácil, que requiere construir una infraestructura que en mucho rebasa lo meramente técnico, pero que también tiene algunos elementos técnicos que son necesarios cumplir: procesos de reconstrucción (no habilitados con el proceso evolutivo de ahora), requerimientos de seguridad (que hoy no existe) y un larguísimo etc. > De lo "no tecnico", lo más importante es crear una estructura que pueda ofrecer seguridad a empresas (con soporte y la garantía de que "hay alguien atrás"). Esto, entiendo, es lo que diferencia a Pharo hoy, y de ahi mi comentario inicial de su comportamiento como un vendor más pero open-source (y abierto a la comunidad también). Lo que todavía no entiendo es por qué le siguen metiendo fichas a Morphic :) Gracias por el aporte! Saludos! -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
On Nov 5, 2012, at 3:00 PM, "Esteban A. Maringolo" <[hidden email]> wrote: > El día 5 de noviembre de 2012 10:40, Esteban Lorenzano > <[hidden email]> escribió: >> Bueno, como pharo-dev asalariado, estoy en mi deber de responder esto. >> No quería meterme porque me parece una perdida absoluta de tiempo, pero viendo por donde empieza a rumbear esto... > > Se agradece :) > >> Cuis no se puede usar como núcleo de Pharo por varios motivos: >> 1) Cuis quiere ser un Smalltalk-80 limpio, Pharo ni siquiera tiene interés en mantenerse como Smalltalk (de ahí el slogan "Smalltalk inspired") > > Nunca le presté atención a la parte "inspired". > > Aunque para mi seguirá siendo un Smalltalk, diferente, Quizas no un > ST80, pero Smalltalk al fin. Si, pero no es un ST80, ni quiere serlo. > >> 2) Cuis es el proyecto de Juan, y como el bien mismo dijo "tiene un control muy fuerte de lo que hay adentro", Pharo pretende ese mismo control para si mismo. >> Por ejemplo, en 2.0 cambiamos el schema de Behavior, para añadir un atributo "layout"... en el primer paso para transformar los atributos de una instancia en "first class instances"... slots, bah, y no solo #symbols como hasta ahora. Dado que eso hace que Pharo deje de ser un st80 (al igual que la inclusion de Traits, btw), es difícil pensar que eso se pudiera consensuar con Juan, ¿no? Y en todo caso el equipo de Pharo, por supuesto, reclama para sí el mismo control que Juan reclama para su proyecto (¿Y que es lo malo de esto?) > > En lo personal no veo nada de malo y esto responde bien de fondo a mi > pregunta inicial a Juan. > > Lo único que quizas se lamenta es la fragmentación que tenemos siendo > tan pocos, pero comparto el hecho que no puede subordinarse un > proyecto a otro, cuando la visión y expectativas son tan diferentes. Y si, me parece que es lamentable, pero el precio a pagar por no tener fragmentación es estancamiento, me parece (al menos hoy por hoy) > >> 3) Pharo pretende construir una reificación completa del concepto de imágen (hacer Pharo new y tener una imagen idem con la que comunicarse, y que esta imagen pueda correrse en otros threads, cores e incluso máquinas). [SNIP] > > No logro entender el uso directo de esto, salvo en un futuro con > procesadores de n-cores. - Cloud - Multi-thread - Desarrollo remoto - Desarrollo en un ambiente hacia otro "limpio" (onda en uno tengo el "IDE" y en otro los objetos que necesita mi desarrollo, sin "estorbos") - Usos en seguridad > >> 4) Asimismo Pharo pretende cambiar cosas como el formato de la imagen (no un binario, sino una serializacion, que permita cargar la misma imagen en arquitecturas 64bits), eliminar el sources files y modificar los changes y lo que se guarda ahí. > > Qué se gana con esto con respecto a una "conversión" a 64 bits? Osea, > salvo que se quiera tener un sólo image para 32 y para 64, para > evitarse el proceso de conversión. Se gana mantener una sola imágen. No es tan fácil producir imágenes de 32 y 64 y mantener las dos... necesitas hacer un trace y escribir el archivo en un formato x, etc. igual, así que mejor si eso se hace de una forma compatibl. > >> 5) Todo eso junto con la fundación de una plataforma que permita hacer software para negocios. Cualquiera que se haya tomado en serio promocionar un lenguaje sabe que eso no es tan fácil, que requiere construir una infraestructura que en mucho rebasa lo meramente técnico, pero que también tiene algunos elementos técnicos que son necesarios cumplir: procesos de reconstrucción (no habilitados con el proceso evolutivo de ahora), requerimientos de seguridad (que hoy no existe) y un larguísimo etc. >> De lo "no tecnico", lo más importante es crear una estructura que pueda ofrecer seguridad a empresas (con soporte y la garantía de que "hay alguien atrás"). > > Esto, entiendo, es lo que diferencia a Pharo hoy, y de ahi mi > comentario inicial de su comportamiento como un vendor más pero > open-source (y abierto a la comunidad también). Bueno, es adoptar un modelo que puede producir algunos ingresos como para pagar desarrolladores (ejem, yo :) Y suponiendo que la comunidad es lo suficientemente grande como para mover Pharo sin necesidad de desarrolladores, sigue siendo necesario para garantizar fiabilidad y que empresas puedan considerarlo una opción válida (más allá de los llaneros solitarios de ahora). > > > Lo que todavía no entiendo es por qué le siguen metiendo fichas a Morphic :) Ja... no lo hacemos. Morphic esta en un punto en el que hacerlo andar bien cuesta más trabajo que hacer uno nuevo. Pero no es tan fácil reemplazarlo porque ahora todo corre sobre él (y porque la vm esta estúpidamente casada con la asunción de que va a tener morphic del otro lado). Igual, el proyecto es hacerlo algo opcional para el año que viene. Yo estoy avanzando con Mars y otros están haciendo otras cosas (como Fernando con Gaucho y Juan con Morphic3), todos se van a poder cargar sin pasar por Morphic. Esteban > > Gracias por el aporte! > > Saludos! > > -- > 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 |
Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
In reply to this post by EstebanLM
+1
Lo único que agregaría es que Cuis al parecer no tiene ningún motivo para existir, ya que Pharo ocupó su lugar. Si Cuis realmente es más modular o más orientado al objeto o tiene alguna otra característica que lo haga superior, entonces debiera existir alguna "kill application" sobre Cuis que lo demuestre y que sea imposible de implementar sobre Pharo y sobre todo el resto de los Smalltalks disponibles.
A mí me parece imposible hacer eso (a pesar de que aún no entiendo bien cómo funciona la modularización en Pharo y al menos me imagino algo funcionando mejor), para mí todavía el problema es irreductible. A lo mejor el fabricante de Cuis nos puede iluminar al respecto...
Saludos, Guillermo. 2012/11/5 Esteban Lorenzano <[hidden email]> Bueno, como pharo-dev asalariado, estoy en mi deber de responder esto. 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 |
Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
Che, cuando leo este mail me salta Unhandled Exception SIGTROLL, que
sera?... http://tinyurl.com/7drk6wd 2012/11/5 Guillermo Schwarz <[hidden email]>: > +1 > > Lo único que agregaría es que Cuis al parecer no tiene ningún motivo para > existir, ya que Pharo ocupó su lugar. > > Si Cuis realmente es más modular o más orientado al objeto o tiene alguna > otra característica que lo haga superior, entonces debiera existir alguna > "kill application" sobre Cuis que lo demuestre y que sea imposible de > implementar sobre Pharo y sobre todo el resto de los Smalltalks disponibles. > > A mí me parece imposible hacer eso (a pesar de que aún no entiendo bien cómo > funciona la modularización en Pharo y al menos me imagino algo funcionando > mejor), para mí todavía el problema es irreductible. A lo mejor el > fabricante de Cuis nos puede iluminar al respecto... > > Saludos, > Guillermo. > > > 2012/11/5 Esteban Lorenzano <[hidden email]> >> >> Bueno, como pharo-dev asalariado, estoy en mi deber de responder esto. >> No quería meterme porque me parece una perdida absoluta de tiempo, pero >> viendo por donde empieza a rumbear esto... >> >> Cuis no se puede usar como núcleo de Pharo por varios motivos: >> >> 1) Cuis quiere ser un Smalltalk-80 limpio, Pharo ni siquiera tiene interés >> en mantenerse como Smalltalk (de ahí el slogan "Smalltalk inspired") >> >> 2) Cuis es el proyecto de Juan, y como el bien mismo dijo "tiene un >> control muy fuerte de lo que hay adentro", Pharo pretende ese mismo control >> para si mismo. >> Por ejemplo, en 2.0 cambiamos el schema de Behavior, para añadir un >> atributo "layout"... en el primer paso para transformar los atributos de una >> instancia en "first class instances"... slots, bah, y no solo #symbols como >> hasta ahora. Dado que eso hace que Pharo deje de ser un st80 (al igual que >> la inclusion de Traits, btw), es difícil pensar que eso se pudiera >> consensuar con Juan, ¿no? Y en todo caso el equipo de Pharo, por supuesto, >> reclama para sí el mismo control que Juan reclama para su proyecto (¿Y que >> es lo malo de esto?) >> >> 3) Pharo pretende construir una reificación completa del concepto de >> imágen (hacer Pharo new y tener una imagen idem con la que comunicarse, y >> que esta imagen pueda correrse en otros threads, cores e incluso máquinas). >> Por supuesto, esto escapa al objetivo de Cuis, y requiere cambios en el >> Kernel que no son pocos. (Hazelnut, de hecho, es el primer paso de un largo >> camino en ese sentido) >> >> 4) Asimismo Pharo pretende cambiar cosas como el formato de la imagen (no >> un binario, sino una serializacion, que permita cargar la misma imagen en >> arquitecturas 64bits), eliminar el sources files y modificar los changes y >> lo que se guarda ahí. >> >> 5) Todo eso junto con la fundación de una plataforma que permita hacer >> software para negocios. Cualquiera que se haya tomado en serio promocionar >> un lenguaje sabe que eso no es tan fácil, que requiere construir una >> infraestructura que en mucho rebasa lo meramente técnico, pero que también >> tiene algunos elementos técnicos que son necesarios cumplir: procesos de >> reconstrucción (no habilitados con el proceso evolutivo de ahora), >> requerimientos de seguridad (que hoy no existe) y un larguísimo etc. >> De lo "no tecnico", lo más importante es crear una estructura que pueda >> ofrecer seguridad a empresas (con soporte y la garantía de que "hay alguien >> atrás"). >> >> En esencia, el único objetivo común que tienen Cuis y Pharo es el de >> modularización, y hasta eso se encara con filosofías distintas (dado que no >> es solo separación, sino interacción entre módulos, etc.)... y por supuesto >> que hay ideas muy buenas en Cuis, y nosotros mantenemos un ojo ahí para ver >> que podemos "tomar prestado" (y tambien en Squeak), pero no veo por qué se >> insiste tanto en algo que simplemente no se ajusta a la realidad, la >> posibilidad de construir un Pharo o un Squeak a partir de un Cuis... Y no se >> ajusta a la realidad entre otras cosas porque pedir eso atrapa los ambientes >> los unos con los otros impidiéndoles evolucionar a todos. >> >> Después, bueno... los argumentos mezquinos realmente no me interesan, me >> parece que no contribuyen en nada a tener un debate constructivo, así que >> discúlpenme si no me detengo en ellos. >> >> Saludos, >> Esteban >> >> On Nov 5, 2012, at 1:38 PM, Andres Valloud <[hidden email]> >> wrote: >> >> > Calmense muchachos, porque no pensamos en la arquitectura en el mundo de >> > IT? >> > >> > https://i.chzbgr.com/completestore/12/10/29/PRrf9YpvQEiyxpjNtY9mLA2.jpg >> > >> > 2012/11/5 Carlos E. Ferro <[hidden email]>: >> >> On 05/11/2012 01:06 a.m., Hernán Morales Durand wrote: >> >> >> >> Mmm, ¿te parece que son tan inocentes? Los académicos tienen necesidad >> >> de >> >> publicar papers. Una manera de hacerlo es escribir un poco de software, >> >> mostrar que más o menos funciona y escribirlo en un artículo. Un >> >> software >> >> robusto requiere un poco más que eso. >> >> >> >> Además están en otra, los revisores de las revistas científicas no >> >> deciden >> >> aceptar un paper por mejorar procedimientos de instalación, manuales, o >> >> depurar cosas viejas y aburridas. >> >> >> >> >> >> Hernán, me parece que con esto estás muy equivocado. >> >> La robustez es una de las preocupaciones del proyecto Pharo, y eso se >> >> ve. >> >> Pero eso, por supuesto es discutible. >> >> >> >> El proyecto tiene muchas facetas aparte de la académica, no es para >> >> producir >> >> papers sino que lo veo funcionando al revés: el hecho de posibilitar >> >> papers >> >> hace que Ducasse pueda tener una pila de estudiantes (muchos >> >> argentinos) >> >> trabajando en Pharo, y que al mismo tiempo avancen académicamente, >> >> terminando doctorados. >> >> >> >> Y hay muchos proyectos en marcha que son, justamente, las cosas que vos >> >> decís: procedimientos de instalación, debugging... Un ejemplo directo >> >> que me >> >> viene a la mente es Hazelnut, de Guillermo Polito. Ahora lo va a >> >> presentar >> >> en Smalltalks, pero no tiene ningún interés académico, es una >> >> herramienta >> >> para configurar fácilmente imágenes con paquetes... Y, por supuesto, >> >> los >> >> libros de Pharo by Example de Ducasse, donde colabora mucha gente. Los >> >> libros tienen muy poco reconocimiento académico... >> >> >> >> Saludos >> >> -- >> >> >> >> carlos e. ferro | senior developer | caesar systems >> >> >> >> [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 >> > >> > -- >> > 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 > > > > > -- > 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 |
Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
Mira vos, a los de www.c2.com tambien les tira SIGTROLL leer esta pagina...
http://c2.com/cgi/wiki?GuillermoSchwarz 2012/11/5 Andres Valloud <[hidden email]>: > Che, cuando leo este mail me salta Unhandled Exception SIGTROLL, que > sera?... http://tinyurl.com/7drk6wd > > 2012/11/5 Guillermo Schwarz <[hidden email]>: >> +1 >> >> Lo único que agregaría es que Cuis al parecer no tiene ningún motivo para >> existir, ya que Pharo ocupó su lugar. >> >> Si Cuis realmente es más modular o más orientado al objeto o tiene alguna >> otra característica que lo haga superior, entonces debiera existir alguna >> "kill application" sobre Cuis que lo demuestre y que sea imposible de >> implementar sobre Pharo y sobre todo el resto de los Smalltalks disponibles. >> >> A mí me parece imposible hacer eso (a pesar de que aún no entiendo bien cómo >> funciona la modularización en Pharo y al menos me imagino algo funcionando >> mejor), para mí todavía el problema es irreductible. A lo mejor el >> fabricante de Cuis nos puede iluminar al respecto... >> >> Saludos, >> Guillermo. >> >> >> 2012/11/5 Esteban Lorenzano <[hidden email]> >>> >>> Bueno, como pharo-dev asalariado, estoy en mi deber de responder esto. >>> No quería meterme porque me parece una perdida absoluta de tiempo, pero >>> viendo por donde empieza a rumbear esto... >>> >>> Cuis no se puede usar como núcleo de Pharo por varios motivos: >>> >>> 1) Cuis quiere ser un Smalltalk-80 limpio, Pharo ni siquiera tiene interés >>> en mantenerse como Smalltalk (de ahí el slogan "Smalltalk inspired") >>> >>> 2) Cuis es el proyecto de Juan, y como el bien mismo dijo "tiene un >>> control muy fuerte de lo que hay adentro", Pharo pretende ese mismo control >>> para si mismo. >>> Por ejemplo, en 2.0 cambiamos el schema de Behavior, para añadir un >>> atributo "layout"... en el primer paso para transformar los atributos de una >>> instancia en "first class instances"... slots, bah, y no solo #symbols como >>> hasta ahora. Dado que eso hace que Pharo deje de ser un st80 (al igual que >>> la inclusion de Traits, btw), es difícil pensar que eso se pudiera >>> consensuar con Juan, ¿no? Y en todo caso el equipo de Pharo, por supuesto, >>> reclama para sí el mismo control que Juan reclama para su proyecto (¿Y que >>> es lo malo de esto?) >>> >>> 3) Pharo pretende construir una reificación completa del concepto de >>> imágen (hacer Pharo new y tener una imagen idem con la que comunicarse, y >>> que esta imagen pueda correrse en otros threads, cores e incluso máquinas). >>> Por supuesto, esto escapa al objetivo de Cuis, y requiere cambios en el >>> Kernel que no son pocos. (Hazelnut, de hecho, es el primer paso de un largo >>> camino en ese sentido) >>> >>> 4) Asimismo Pharo pretende cambiar cosas como el formato de la imagen (no >>> un binario, sino una serializacion, que permita cargar la misma imagen en >>> arquitecturas 64bits), eliminar el sources files y modificar los changes y >>> lo que se guarda ahí. >>> >>> 5) Todo eso junto con la fundación de una plataforma que permita hacer >>> software para negocios. Cualquiera que se haya tomado en serio promocionar >>> un lenguaje sabe que eso no es tan fácil, que requiere construir una >>> infraestructura que en mucho rebasa lo meramente técnico, pero que también >>> tiene algunos elementos técnicos que son necesarios cumplir: procesos de >>> reconstrucción (no habilitados con el proceso evolutivo de ahora), >>> requerimientos de seguridad (que hoy no existe) y un larguísimo etc. >>> De lo "no tecnico", lo más importante es crear una estructura que pueda >>> ofrecer seguridad a empresas (con soporte y la garantía de que "hay alguien >>> atrás"). >>> >>> En esencia, el único objetivo común que tienen Cuis y Pharo es el de >>> modularización, y hasta eso se encara con filosofías distintas (dado que no >>> es solo separación, sino interacción entre módulos, etc.)... y por supuesto >>> que hay ideas muy buenas en Cuis, y nosotros mantenemos un ojo ahí para ver >>> que podemos "tomar prestado" (y tambien en Squeak), pero no veo por qué se >>> insiste tanto en algo que simplemente no se ajusta a la realidad, la >>> posibilidad de construir un Pharo o un Squeak a partir de un Cuis... Y no se >>> ajusta a la realidad entre otras cosas porque pedir eso atrapa los ambientes >>> los unos con los otros impidiéndoles evolucionar a todos. >>> >>> Después, bueno... los argumentos mezquinos realmente no me interesan, me >>> parece que no contribuyen en nada a tener un debate constructivo, así que >>> discúlpenme si no me detengo en ellos. >>> >>> Saludos, >>> Esteban >>> >>> On Nov 5, 2012, at 1:38 PM, Andres Valloud <[hidden email]> >>> wrote: >>> >>> > Calmense muchachos, porque no pensamos en la arquitectura en el mundo de >>> > IT? >>> > >>> > https://i.chzbgr.com/completestore/12/10/29/PRrf9YpvQEiyxpjNtY9mLA2.jpg >>> > >>> > 2012/11/5 Carlos E. Ferro <[hidden email]>: >>> >> On 05/11/2012 01:06 a.m., Hernán Morales Durand wrote: >>> >> >>> >> Mmm, ¿te parece que son tan inocentes? Los académicos tienen necesidad >>> >> de >>> >> publicar papers. Una manera de hacerlo es escribir un poco de software, >>> >> mostrar que más o menos funciona y escribirlo en un artículo. Un >>> >> software >>> >> robusto requiere un poco más que eso. >>> >> >>> >> Además están en otra, los revisores de las revistas científicas no >>> >> deciden >>> >> aceptar un paper por mejorar procedimientos de instalación, manuales, o >>> >> depurar cosas viejas y aburridas. >>> >> >>> >> >>> >> Hernán, me parece que con esto estás muy equivocado. >>> >> La robustez es una de las preocupaciones del proyecto Pharo, y eso se >>> >> ve. >>> >> Pero eso, por supuesto es discutible. >>> >> >>> >> El proyecto tiene muchas facetas aparte de la académica, no es para >>> >> producir >>> >> papers sino que lo veo funcionando al revés: el hecho de posibilitar >>> >> papers >>> >> hace que Ducasse pueda tener una pila de estudiantes (muchos >>> >> argentinos) >>> >> trabajando en Pharo, y que al mismo tiempo avancen académicamente, >>> >> terminando doctorados. >>> >> >>> >> Y hay muchos proyectos en marcha que son, justamente, las cosas que vos >>> >> decís: procedimientos de instalación, debugging... Un ejemplo directo >>> >> que me >>> >> viene a la mente es Hazelnut, de Guillermo Polito. Ahora lo va a >>> >> presentar >>> >> en Smalltalks, pero no tiene ningún interés académico, es una >>> >> herramienta >>> >> para configurar fácilmente imágenes con paquetes... Y, por supuesto, >>> >> los >>> >> libros de Pharo by Example de Ducasse, donde colabora mucha gente. Los >>> >> libros tienen muy poco reconocimiento académico... >>> >> >>> >> Saludos >>> >> -- >>> >> >>> >> carlos e. ferro | senior developer | caesar systems >>> >> >>> >> [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 >>> > >>> > -- >>> > 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 >> >> >> >> >> -- >> 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 |
Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
In reply to this post by EstebanLM
Gracias Esteban. Creo que tu respuesta es muy útil.
Saludos, Juan Vuletich Quoting Esteban Lorenzano <[hidden email]>: > Bueno, como pharo-dev asalariado, estoy en mi deber de responder esto. > No quería meterme porque me parece una perdida absoluta de tiempo, > pero viendo por donde empieza a rumbear esto... > > Cuis no se puede usar como núcleo de Pharo por varios motivos: > > 1) Cuis quiere ser un Smalltalk-80 limpio, Pharo ni siquiera tiene > interés en mantenerse como Smalltalk (de ahí el slogan "Smalltalk > inspired") > > 2) Cuis es el proyecto de Juan, y como el bien mismo dijo "tiene un > control muy fuerte de lo que hay adentro", Pharo pretende ese mismo > control para si mismo. > Por ejemplo, en 2.0 cambiamos el schema de Behavior, para añadir un > atributo "layout"... en el primer paso para transformar los > atributos de una instancia en "first class instances"... slots, bah, > y no solo #symbols como hasta ahora. Dado que eso hace que Pharo > deje de ser un st80 (al igual que la inclusion de Traits, btw), es > difícil pensar que eso se pudiera consensuar con Juan, ¿no? Y en > todo caso el equipo de Pharo, por supuesto, reclama para sí el mismo > control que Juan reclama para su proyecto (¿Y que es lo malo de esto?) > > 3) Pharo pretende construir una reificación completa del concepto de > imágen (hacer Pharo new y tener una imagen idem con la que > comunicarse, y que esta imagen pueda correrse en otros threads, > cores e incluso máquinas). Por supuesto, esto escapa al objetivo de > Cuis, y requiere cambios en el Kernel que no son pocos. (Hazelnut, > de hecho, es el primer paso de un largo camino en ese sentido) > > 4) Asimismo Pharo pretende cambiar cosas como el formato de la > imagen (no un binario, sino una serializacion, que permita cargar la > misma imagen en arquitecturas 64bits), eliminar el sources files y > modificar los changes y lo que se guarda ahí. > > 5) Todo eso junto con la fundación de una plataforma que permita > hacer software para negocios. Cualquiera que se haya tomado en serio > promocionar un lenguaje sabe que eso no es tan fácil, que requiere > construir una infraestructura que en mucho rebasa lo meramente > técnico, pero que también tiene algunos elementos técnicos que son > necesarios cumplir: procesos de reconstrucción (no habilitados con > el proceso evolutivo de ahora), requerimientos de seguridad (que hoy > no existe) y un larguísimo etc. > De lo "no tecnico", lo más importante es crear una estructura que > pueda ofrecer seguridad a empresas (con soporte y la garantía de que > "hay alguien atrás"). > > En esencia, el único objetivo común que tienen Cuis y Pharo es el de > modularización, y hasta eso se encara con filosofías distintas (dado > que no es solo separación, sino interacción entre módulos, etc.)... > y por supuesto que hay ideas muy buenas en Cuis, y nosotros > mantenemos un ojo ahí para ver que podemos "tomar prestado" (y > tambien en Squeak), pero no veo por qué se insiste tanto en algo que > simplemente no se ajusta a la realidad, la posibilidad de construir > un Pharo o un Squeak a partir de un Cuis... Y no se ajusta a la > realidad entre otras cosas porque pedir eso atrapa los ambientes los > unos con los otros impidiéndoles evolucionar a todos. > > Después, bueno... los argumentos mezquinos realmente no me > interesan, me parece que no contribuyen en nada a tener un debate > constructivo, así que discúlpenme si no me detengo en ellos. > > Saludos, > Esteban > > On Nov 5, 2012, at 1:38 PM, Andres Valloud <[hidden email]> wrote: > >> Calmense muchachos, porque no pensamos en la arquitectura en el mundo de IT? >> >> https://i.chzbgr.com/completestore/12/10/29/PRrf9YpvQEiyxpjNtY9mLA2.jpg >> >> 2012/11/5 Carlos E. Ferro <[hidden email]>: >>> On 05/11/2012 01:06 a.m., Hernán Morales Durand wrote: >>> >>> Mmm, ¿te parece que son tan inocentes? Los académicos tienen necesidad de >>> publicar papers. Una manera de hacerlo es escribir un poco de software, >>> mostrar que más o menos funciona y escribirlo en un artículo. Un software >>> robusto requiere un poco más que eso. >>> >>> Además están en otra, los revisores de las revistas científicas no deciden >>> aceptar un paper por mejorar procedimientos de instalación, manuales, o >>> depurar cosas viejas y aburridas. >>> >>> >>> Hernán, me parece que con esto estás muy equivocado. >>> La robustez es una de las preocupaciones del proyecto Pharo, y eso se ve. >>> Pero eso, por supuesto es discutible. >>> >>> El proyecto tiene muchas facetas aparte de la académica, no es >>> para producir >>> papers sino que lo veo funcionando al revés: el hecho de posibilitar papers >>> hace que Ducasse pueda tener una pila de estudiantes (muchos argentinos) >>> trabajando en Pharo, y que al mismo tiempo avancen académicamente, >>> terminando doctorados. >>> >>> Y hay muchos proyectos en marcha que son, justamente, las cosas que vos >>> decís: procedimientos de instalación, debugging... Un ejemplo >>> directo que me >>> viene a la mente es Hazelnut, de Guillermo Polito. Ahora lo va a presentar >>> en Smalltalks, pero no tiene ningún interés académico, es una herramienta >>> para configurar fácilmente imágenes con paquetes... Y, por supuesto, los >>> libros de Pharo by Example de Ducasse, donde colabora mucha gente. Los >>> libros tienen muy poco reconocimiento académico... >>> >>> Saludos >>> -- >>> >>> carlos e. ferro | senior developer | caesar systems >>> >>> [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 >> >> -- >> 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 > Cheers, Juan Vuletich -- 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: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
In reply to this post by Guillermo Schwarz
Contesto como "el fabricante de Cuis". El mensaje de Esteban muestra que los objetivos de Pharo son bastante diferentes que los de Cuis ( http://www.jvuletich.org/Cuis/Index.html ). Me parece entonces que estás muy equivocado al decir que Pharo ocupó su lugar: son 2 lugares muy distintos Si aún creés que es así, te aconsejo que browsees los 2 sistemas, e intentes comprenderlos. Algunas métricas de complejidad y tamaño de código pueden ayudar. Por otra parte, no creo tener ninguna obligación de mostrar una killer application. Hago Cuis porque quiero un Smalltalk como la gente. Y lo comparto porque soy generoso. Los smalltalkers que tengan criterios técnicos y estéticos similares a los míos lo apreciarán y lo usarán (y colaborarán con el proyecto, si quieren). Y los que no, no. Saludos, Juan Vuletich Quoting Guillermo Schwarz <[hidden email]>: +1
Cheers, 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 |