Pharo 1.4

> **
>
>
>
>
>
> El 28 de junio de 2012 11:05, Edgar J. De Cleene <[hidden email]>escribió:
>
>  **
>>
>>
>> > Individual Pharo Association Member: Yearly fee 40 Euros
>> > Golden Individual Pharo Association Member: Yearly fee 99 Euros
>>
>> Es lo que veo
>>
>>
> A la marosca, no habia visto lo de los "fees".
>
> No me queda claro que pasa si elegís no pagar nada...... Se puede usar
> igual? (Eso había dicho Stef al principio).
>
>
>
>> Tambien veo que a 1.4 la bola que se le da no sirve si todos estan
>> pensando
>> (y trabajando como vos Guille y muchos mas) en 2.0 , que es casi
>> incompatible...
>>
>>
> Bueno, inverti unas horitas en 2.0, francamente nada de las cosas más
> comunes cargan.....puede que sean pavadas
> arreglar, pero no tengo el tiempo.....
>
>
>
>> Y del otro lado (Squeak) , parecen estar contentos con la paz de los
>> cementerios
>>
>> Eso es raro también, digo, parece haber muy poco movimiento no?
>
>
>
>>  Menos mal que Angel nos va a convencer a todos que nos dediquemos a
>> JavaScript :=)
>>
>> Con todo respeto a Angel y a otros (AleR y Nico Petton), yo no quiero
> trabajar con Javascript
>
> Por que no Cuis? Creo que cada día me convenzo más......sólo que me da
> mucho trabajo portar las cosas
> que necesito y luego mantenerlas, pero si queremos un Smalltalk, ahi
> tenemos uno!
>
> Saludos.
>
>
>  
>

> **
>
>
> Hola @ajlopez!!
>
> El 29 de junio de 2012 09:38, Angel Java Lopez <[hidden email]>escribió:
>
> **
>>
>>
>> Jaja... sigue tranquilo en Smalltalk, maese @garduino ;-)
>>
>> No hace falta "trabajar" en Javascript, sino seguir en Smalltalk,
>> consumiendo un "underlying language and ecosystem".
>>
>>
> Por supuesto que no puedo desconocer todo lo que hay hecho y se puede usar
> en los "underlying languages and ecosystems" pero lo mio
> va más allá. Estoy demasiado acostumbrado a trabajar de una manera, con la
> imagen, manipulando los objetos, inspeccionado, corrigiendo on the
> fly.....que no tengo casi nada de ganas de hacerlo de otra manera (Estuve
> haciendo unos trabajos en Java, como te comenté, y putié  como para
> escribir un libro).
>
>
>
>> De ahi, mi interes con Node.js: tienen un buen ecosistema, vibrante,
>> multiplataforma en la mayoria de los casos, etc. Y la esperanza de:
>> programas en Smalltalk, haces TDD en Smalltalk, con tu entorno preferido,
>> fileOut, y luego se ejecuta en otros entornos (Javascript es uno posible y
>> muy maleable).
>>
>>
> Esto que planteás sería un paso más, si tenés la certeza que lo que vos
> hiciste en tu Smalltalk luego va a funcionar en donde lo quieras
> injertar.....pero, si ahi va a estar finalmente el ambiente de producción,
> no dejo de sentir como que finalmente no trabajás en Smalltalk.
>
> Por ejemplo surge un problema en una app hecha de esa forma y ejecutando
> en Node.js......y tenés que reproducirlo, digo, no me parece muy fácil y ni
> tampoco que se pueda hacer en el ambiente Smalltalk.....
>
>
>
>> Que diferencia hay con trabajar con Smalltalk solo? Como mencionaba,
>> aprovechar lo que esta hecho en el "underlying
>> language/platform/ecosystem".  Se aparta de la idea de Smalltalk como
>> sistema operativo: una idea interesantisima, pero que ha conspirado, IMO, a
>> su adopcion y difusion.
>>
>>
> Bueno, yo sigo creyendo en eso....(adaptado a nuestros días sería la
> metáfora de hacer TODO lo posible DENTRO de mi Smalltalk) y casi nada o
> nada fuera. Puede sonar un poco utópico frente a las tecnologías actuales,
> muy fragmentadas.....pero a mi me parece la mejor relación costo-beneficio.
>
>
>
>> Por ejemplo, para mi, imagen minima seria NO TENER entorno de desarrollo.
>> El entorno de desarrollo ya esta bien en Pharo, etc.. Luego, deberia poder
>> exportarse algo, y ejecutar minimamente. Para poner un ejemplo, de nuevo,
>> disculpen que no se entienda todo, pero el tema me interesa.... ;-)...
>> Amber tiene una forma de decir: "ejecuta esto en modo development, con
>> entorno de desarrollo, browser de clases, etc..." o "ejecuta esto en modo
>> production".
>>
>>
> No se si Amber tiene eso y francamente, tampoco entendi bien la idea final
> de Amber (más allá de permitir hacer algunas cosas que también se pueden
> hacer con WebDav). Entiendo que se pueden reusar miles de cosas hechas en
> Javascript y ahí si veo un valor importante pero, honestamente, no me
> imagino muchas aplicaciones (de negocios) en Amber o con ese paradigma.
>
>
>> Para mi, "modo production" es: lo que tengo en un fileOut .st, lo levanto
>> en un entorno/VM C#, o en un entorno/VM Javascript/Node.js, o en un entorno
>> Ruby, Y cuando necesito un servidor Web, por poner un caso, con ruteo de
>> MVC, en vez de escribirlo totalmente en Smalltalk, aprovecho lo que ya esta
>> en cada plataforma de abajo. Si necesito un driver de conexion a Oracle, la
>> plataforma de abajo seguramente tiene uno, ya probado en miles de entornos
>> y situaciones distintas, mas alla de Smalltalk.
>>
>>
> Sip, entiendo, sólo que no lo veo tan probable de conseguir (me refiero a
> lo que dije más arriba) como solución de problemas, pruebas, etc.
>
>
>
>> Es un camino a explorar.
>>
>> Estoy crazy, Macaya? ;-)
>>
>>
> Bueno, acá todos lo estamos un poco, no está mal eso :)
>
> Pero esta bárbaro charlar estas cosas, y entender las ideas del otro, a mi
> me super interesan este tipo de conversaciones y este es el espíritu de
> este lugar.
>
> Saludos!
>
>  
>

> **
>
>
> Gracias, maese @garduino, por comentar!
>
> Bien, un tema que me quedo en el tintero, resumido porque ya escribi un
> monton en esta lista hoy.
>
> Todo esto tambien puede derivar en algo que siempre tengo en la cabeza:
>
> - Tener una VM multiplataforma, open source, con underlying language y
> garbage collector, libreria de clases de base, etc.
>
> Es decir, en vez de decir Visual Works (disculpen, no recuerdo si se llama
> asi) solo lo tienen en Windows, lo tienen en otras plataformas.
>
> Y con "underlying", tener acceso a los widgets de las plataformas de
> abajo, como el caso de Eclipse con SWT (donde los widgets son por
> plataforma) o el caso de Java son Swing (que no me gusta tanto).
>
> Y con "garbage collector" para que los constructores de VM no tengan que
> dejar el alma haciendo o green threads solamente, o un GC multithread, y
> mas... cada vez que aparece una VM.
>
> Y para que Valloud no tenga que estar viendo: y ahora como compilo a
> 64bits y que todo siga andando?
>
> O como comente antes:  no tener que estar viendo de donde saco un driver
> de ODBC, o del ultimo NoSql, y demas...  Toda la cantidad de programadores
> de la plataforma de abajo lo reclama, y lo obtiene, para ellos, y para la
> VM Smalltalk que imagino. Cualquier cosa que aparezca en la "underlying" se
> puede aprovechar en la VM, sin necesidad de "convoluted FFI" y esas cosas.
>
> Teniendo una VM sobre .NET o Java, se consigue mucho de todo esto. No veo
> razon para seguir latigandose con C para armar VMs. Pero bueno, es una
> opinion mia, no me peguen, soy Giordano! ;-)
>
> (Otros lenguajes siguieron ese camino: Python con Jython y otros, Ruby con
> JRuby, IronRuby, ... etc...)
>
> Ese camino permitiria que el bueno de @garduino siguiera trabajando en
> Smalltalk, en practicamente cualquier entorno, plataforma que aparezca. Y
> con la eleccion de aprovechar o no lo que venga como agregado por la
> tecnologia de "abajo".
>
> Por que Javascript entonces? Bien, por que Clojure en Javascript ahora?
> Debe haber varias razones, pero leyendo
> https://github.com/clojure/clojurescript/wiki/Rationale
> rescato
> JavaScript's Reach
>
> There are many environments (e.g. browsers) in which JavaScript is the
> only programmable technology. There are others (e.g. mobile) where
> JavaScript is the most portable development approach. And JavaScript is
> widely used as an extension or scripting language, e.g. as an extension or
> indexing language in a database.
> Por eso digo: no desarrollar Smalltalk sobre Javascript, me parece que
> intentar una IDE completa Smalltalk en Javascript, es too much, desarrollar
> donde quieras. Pero tener un accesorio mas, una VM de JS, permite llegar a
> eso donde las otras plataformas de base (con garbage collector,
> multiplaforma, como .NET/Java) no llegan.
>
> Me imagino Smart TV con Smalltalk, corriendo sobre las plataformas de base
> (.NET/Java/Javascript)
>
> Si, ya se, tengo que largar la bock y volver a la liberty ;-)
>
> 2012/6/29 Germán Arduino <[hidden email]>
>
>> **
>>
>>
>> Hola @ajlopez!!
>>
>> El 29 de junio de 2012 09:38, Angel Java Lopez <[hidden email]>escribió:
>>
>> **
>>>
>>>
>>> Jaja... sigue tranquilo en Smalltalk, maese @garduino ;-)
>>>
>>> No hace falta "trabajar" en Javascript, sino seguir en Smalltalk,
>>> consumiendo un "underlying language and ecosystem".
>>>
>>>
>> Por supuesto que no puedo desconocer todo lo que hay hecho y se puede
>> usar en los "underlying languages and ecosystems" pero lo mio
>> va más allá. Estoy demasiado acostumbrado a trabajar de una manera, con
>> la imagen, manipulando los objetos, inspeccionado, corrigiendo on the
>> fly.....que no tengo casi nada de ganas de hacerlo de otra manera (Estuve
>> haciendo unos trabajos en Java, como te comenté, y putié  como para
>> escribir un libro).
>>
>>
>>
>>> De ahi, mi interes con Node.js: tienen un buen ecosistema, vibrante,
>>> multiplataforma en la mayoria de los casos, etc. Y la esperanza de:
>>> programas en Smalltalk, haces TDD en Smalltalk, con tu entorno preferido,
>>> fileOut, y luego se ejecuta en otros entornos (Javascript es uno posible y
>>> muy maleable).
>>>
>>>
>> Esto que planteás sería un paso más, si tenés la certeza que lo que vos
>> hiciste en tu Smalltalk luego va a funcionar en donde lo quieras
>> injertar.....pero, si ahi va a estar finalmente el ambiente de producción,
>> no dejo de sentir como que finalmente no trabajás en Smalltalk.
>>
>> Por ejemplo surge un problema en una app hecha de esa forma y ejecutando
>> en Node.js......y tenés que reproducirlo, digo, no me parece muy fácil y ni
>> tampoco que se pueda hacer en el ambiente Smalltalk.....
>>
>>
>>
>>> Que diferencia hay con trabajar con Smalltalk solo? Como mencionaba,
>>> aprovechar lo que esta hecho en el "underlying
>>> language/platform/ecosystem".  Se aparta de la idea de Smalltalk como
>>> sistema operativo: una idea interesantisima, pero que ha conspirado, IMO, a
>>> su adopcion y difusion.
>>>
>>>
>> Bueno, yo sigo creyendo en eso....(adaptado a nuestros días sería la
>> metáfora de hacer TODO lo posible DENTRO de mi Smalltalk) y casi nada o
>> nada fuera. Puede sonar un poco utópico frente a las tecnologías actuales,
>> muy fragmentadas.....pero a mi me parece la mejor relación costo-beneficio.
>>
>>
>>
>>> Por ejemplo, para mi, imagen minima seria NO TENER entorno de
>>> desarrollo. El entorno de desarrollo ya esta bien en Pharo, etc.. Luego,
>>> deberia poder exportarse algo, y ejecutar minimamente. Para poner un
>>> ejemplo, de nuevo, disculpen que no se entienda todo, pero el tema me
>>> interesa.... ;-)... Amber tiene una forma de decir: "ejecuta esto en modo
>>> development, con entorno de desarrollo, browser de clases, etc..." o
>>> "ejecuta esto en modo production".
>>>
>>>
>> No se si Amber tiene eso y francamente, tampoco entendi bien la idea
>> final de Amber (más allá de permitir hacer algunas cosas que también se
>> pueden hacer con WebDav). Entiendo que se pueden reusar miles de cosas
>> hechas en Javascript y ahí si veo un valor importante pero, honestamente,
>> no me imagino muchas aplicaciones (de negocios) en Amber o con ese
>> paradigma.
>>
>>
>>> Para mi, "modo production" es: lo que tengo en un fileOut .st, lo
>>> levanto en un entorno/VM C#, o en un entorno/VM Javascript/Node.js, o en un
>>> entorno Ruby, Y cuando necesito un servidor Web, por poner un caso, con
>>> ruteo de MVC, en vez de escribirlo totalmente en Smalltalk, aprovecho lo
>>> que ya esta en cada plataforma de abajo. Si necesito un driver de conexion
>>> a Oracle, la plataforma de abajo seguramente tiene uno, ya probado en miles
>>> de entornos y situaciones distintas, mas alla de Smalltalk.
>>>
>>>
>> Sip, entiendo, sólo que no lo veo tan probable de conseguir (me refiero a
>> lo que dije más arriba) como solución de problemas, pruebas, etc.
>>
>>
>>
>>> Es un camino a explorar.
>>>
>>> Estoy crazy, Macaya? ;-)
>>>
>>>
>> Bueno, acá todos lo estamos un poco, no está mal eso :)
>>
>> Pero esta bárbaro charlar estas cosas, y entender las ideas del otro, a
>> mi me super interesan este tipo de conversaciones y este es el espíritu de
>> este lugar.
>>
>> Saludos!
>>
>>
>  
>