Ah! Disculpen, agrego algo mas, que me olvide, pequenio, pero para mi importante:
Me gusto mucho ver que desde hace un tiempo, varios desarrollos de Smalltalk (librerias creo) empiezan a usar GitHub. Me parece que brinda gran visilibidad y, sin reinventar la rueda, permiten usar un sistema de codigo distribuido, entendido y consumido por parva (como se dice aca en Argentina) de desarrolladores. Lo que pediria entonces a cualquier VM + libreria de clases de Smalltalk open source, es usar algo asi, un Git en GitHub o algo parecido. Eso, que Uds. me diran “lo tenemos con … (y ahi arriesgo: Monticello? Metacello? Etc….)” para mi, que vengo de “otros pagos” no smalltalkeros, es algo que ha contribuido a entender y difundir lo que se hace. Vean que GitHub es usado por MULTIPLES TECNOLOGIAS. Me resulta agradable y hasta auguro buen porvernir, el que algunos desarrollos Smalltalk comiencen a usar GitHub Ya esta, lo dije.. ;-)… “no me peguen, soy Giordano” Angel “Giordano” Lopez @ajlopez gh:ajlopez From: [email protected] [mailto:[email protected]] On Behalf Of Angel Java Lopez Sent: Tuesday, November 13, 2012 10:58 AM To: [email protected] Subject: Re: [clubSmalltalk] Dolphin murió ? Hola gente! Yo siempre brego por: hay que explorar tener un Smalltalk open source (VM y codigo de clases) sobre una plataforma ya armada que tenga garbage collector, libreria de clases y ecosistema de clases. Mis dos candidatos son .NET y Java, y luego JavaScript. En Java, tienen Red Smalltalk (no lo probe, en general no pruebo mucho otras implementaciones de ese tipo, mientras voy construyendo la mia, quiero tener la mente despejada, abierta, solo luego veo en detalle otras implementaciones): http://www.redline.st/discover/getting-started.html Quiero un Smalltalk minimo, donde la VM pueda cargar mas de una imagen, y una imagen A pueda "operar" sobre otra imagen B. Asi podemos tener una imagen A con todo lo que quieran de entorno de desarrollos, y una imagen B que puede ser minima o no, con el programa en desarrollo (como pasa en otras tecnologias, donde el entorno de desarrollo esta separado de lo que se produce). No se si les gustaria a Uds, pero me parece un camino a explorar. Como no vi que eso fuera facil de implementar en Smalltalk actuales (la soluciones que se me ocurren dependen mucho de la implementacion de bajo nivel de una VM), y como las VM actuales para mi son dificiles de modificar (p.ej. a fines de los noventa vi la implementacion interna de Squeak, con un garbage collector muy particular, etc...), entonces me he decidido ya hace unos anios retomar el trasteo de armar Smalltalk VM, aunque sea caseras, como hacia en los ochenta (donde no tenia forma de conseguir un Smalltalk). Otra cosa que habran visto que me interesa, es, una vez dada una VM razonable, implementar Smalltalk distribuido (algo mostre en Smalltalks 2010). Bueno, otro punto: al tener una VM implementanda sobre .NET, Java o JavaScript, es facil agregar librerias soportadas por esas tecnologias, generalmente soportadas por mas cantidad de gente que las que las usan directamente en Smalltalk, y probadas por miles de personas (en general), mas alla de lo que se probaria si se desarrollaran solamente para Smalltalk. Otro punto que me gustaria tener: un ecosistema de paquetes/librerias en el lenguaje Smalltalk, que no dependa de los dialectos. En Python, hay "dos dialectos" Python 2.x 3.x, EN PRINCIPIO. En Ruby paso algo parecido. En JavaScript/NodeJs tambien. En .NET tambiena aparecio eso, y en Java hace tiempo. No hay que armar paquetes de lenguaje (digo, no escritas en un lenguaje ajeno), que dependan de dialectos. Y un manejador de paquetes sencillo. Aca, el tener un solo manejador de paquetes ha beneficiado a otros ecosistemas (ver Node.js con npm, Ruby con gems, vean que Python aparecio demasiado temprano a este tema, y no pudo consolidar un solo manejador de esos paquetes) Espero que se haya entendido ;-) Nos leemos! Angel "Java" Lopez @ajlopez gh:ajlopez 2012/11/13 Alejandro Pérez <[email protected]> ¿Y por qué no Smalltalk X, de exept? Para cosas personales he hecho cosillas y me parece bastante apañada. Además, multiplataforma y con buenísima integración con librerías C, para los que comentaban el estilo Python de "wrappear" lo que hiciese falta en vez de construir desde 0. Lo que quizás, a veces, es algo confusa su licencia, todo gratis excepto: "[*] Please take a look at the licence conditions, which are part of the download package. If your application has a military, weapon-technical or genetic-engineering background, or if your company produces landmines or is involved in the management of patents on food, animals or humans or is owning any of these, please contact [email protected]. In such a case, we may have to insist on a non-free licence agreement." Pero sería cuestión de hablarlo todo. Saludos 2012/11/13 GallegO <[email protected]> Mientras los vendors de Smalltalk parecen estar más interesados en matarse entre sí para obtener un mayor mercado que sólo está en su imaginación, otros lenguajes se toman los mercados que dejan botados. Jaja parece que hablas de corporaciones gigantes tratando de aniquilarse. ¿De donde sacaste que están interesados en matarse entre si? Pero bueno en fin, Dolphin, según su dueño, no se puede hacer open source por un tema de licencias. Saludos GallegO -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] <mailto:clubsmalltalk%[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] <mailto:clubsmalltalk%[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
