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 <[email protected]>:
> Che, cuando leo este mail me salta Unhandled Exception SIGTROLL, que
> sera?... http://tinyurl.com/7drk6wd
>
> 2012/11/5 Guillermo Schwarz <[email protected]>:
>> +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

Responder a