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. > 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 [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
