+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

Responder a