Cierto Juan, no se para que fuiste capaz de realizar lo que yo no podría. No me hagas el mundo incómodo por favor y elimina ese Cuis. Abrazo
Ing. Pablo Digonzelli Sofware Solutions IP Soluciones SRL 25 de Mayo 521. Entrepiso A email: [email protected] email: [email protected] twitter: @pdigonzelli Tel: 0381 4227378 Cel: 0381 155982714 ----- Mensaje original ----- De: "Leo De Marco (Smalltalking)" <[email protected]> Para: [email protected] Enviados: Lunes, 5 de Noviembre 2012 13:19:53 Asunto: RE: Re: [clubSmalltalk] Sobre CUIS y Pharo Que es una "killer application"? vos hiciste una? Donde la puedo ver? De: [email protected] [mailto:[email protected]] En nombre de Guillermo Schwarz Enviado el: lunes, 05 de noviembre de 2012 12:26 Para: [email protected] Asunto: Re: Re: [clubSmalltalk] Sobre CUIS y Pharo +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 < [email protected] > 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 < [email protected] > 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 < [email protected] >: >> 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 >> >> [email protected] >> >> -- >> 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 -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect -- 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 -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
