Gracias Esteban. Creo que tu respuesta es muy útil.
Saludos,
Juan Vuletich
Quoting 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
Cheers,
Juan Vuletich
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
