On Nov 5, 2012, at 3:00 PM, "Esteban A. Maringolo" <[email protected]> wrote:
> El día 5 de noviembre de 2012 10:40, Esteban Lorenzano > <[email protected]> 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 [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
