Re: Sobre CUIS y Pharo
Locked
1234567
1234567
 
|
Jeje... no, eso lo hace la comunidad que arma la libreria.
Y hay parva de librerias que estan en .NET, Java, y JavaScript QUE NO ESTAN EN C. Ejemplos: todo NHibernate en .NET, Hibernate en Java, y gran parva de modules en Node.js
Nadie sufre "importar quilombos" en esos casos. Es una realidad. Claro, siempre habra algun caso, pero les cuento que en general, hay un ecosistema de librerias y soporte de comunidad, que hacen que UNO no tenga tantos problemas.
Si una libreria es popular, YA esos problemas han sido o seran encarados por la comunidad. Ejemplo, si tengo un require('oracle-driver') en Node.js, y es un modulo popular, es raro que me encuentre con un problema importante que otro no haya encontrado y otro resuelto o este en camino de resolucion.
En anios que tengo con Java, .NET y algunos con Javascript/NodeJs, puedo asegurar que el importar modulos/librerias populares es mucho menos quilombo que trabajar con librerias directamente en C.
Angel "DeathToFFI" Lopez 2012/11/14 Andres Valloud <[hidden email]> O sea que la propuesta es, en vez de "importar" el quilombo de C, To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Andres Valloud-5
A medida que voy pensando mas en lo que implica hacer un outsourcing
de lidiar con C, se me van poniendo los pelos de punta... que se yo, es lo mismo que decir "escribamos la VM en Smalltalk, la traducimos mecanicamente a C, y despues la compilamos sin optimizacion porque hay bugs en el compilador (obviamente, si tu programa no anda la culpa siempre es del compilador :p), ignoramos todos los compiler warnings, y como anda en mi maquina entonces listo"... Por favor no entiendan que me la agarro exclusivamente con Pharo / Squeak / etc, o con alguna persona en particular. El de arriba no es el unico ejemplo ni por las tapas, y ademas ya conte varios otros ejemplos en mi charla de Smalltalks 2009. Lo que observo es la tendencia a largo plazo. El tema es que este tipo de proceder no es tecnicamente correcto, y sin embargo hay un monton de resistencia a mirar el manual de gcc (por ejemplo). Esa postura tambien es una forma de ningunear el trabajo de los demas, y el resultado es un punto de vista que te aisla y te limita. 2012/11/14 Andres Valloud <[hidden email]>: > O sea que la propuesta es, en vez de "importar" el quilombo de C, > "importar" el quilombo de .NET, Java y/o Javascript, asumiendo que > estos lenguajes ya lidian con el tema de "importar" el quilombo de C > de manera correcta. Y eso como se debuggea cuando no anda? > > 2012/11/14 Angel Java Lopez <[hidden email]>: >> Si, por eso un camino a explorar es: >> >> - VM sobre .NET/Java/JavaScript >> >> En esos casos, las librerias que se cargan YA estan escritos en un >> "underlying language" que tiene Garbage Collector y un sistema de tipos >> comun. >> >> No mas FFI, sino simple carga dinamica de modulos, librerias, require, >> etc... >> >> Y esas librerias que se cargan YA estan probadas en el "underlying VM". Y >> soportadas/probadas por parva de gente. >> >> Angel "MyLifeIsAVirtualMachine" Lopez ;-) >> >> 2012/11/14 Andres Valloud <[hidden email]> >>> >>> > siempre hay que tomar en cuenta unas cuantas cosas, obvio... pero a lo >>> > que voy es que no vale la pena hacer una libreria de, ponele criptografía >>> > (ya que german la menciona), sino que es mucho mas productivo usar una >>> > libreria ya existente y ahorrarse de paso el costo de mantenerlo. >>> >>> A lo que voy es que hacer eso te expone al mundo de C, al cual en >>> general se le tiene un cierto rechazo en la comunidad Smalltalk, por >>> lo tanto se tiende a mirarlo asi no mas, y eso a la larga trae >>> problemas de fondo bastante serios. La clase de problemas se puede >>> describir en terminos de todo el undefined behavior que termina >>> ocurriendo en nuestros programas debido especificamente a asumir que, >>> como Smalltalk es simple, y como todo se puede hacer en Smalltalk, >>> entonces C hecho en Smalltalk se vuelve simple por clausura transitiva >>> (o algun asumido equivalente). Pero no es asi... simplemente compilar >>> una VM como corresponde ya es un requilombo. Y el tema de fondo de >>> los FFI es que hay un monton de casos que nunca podran cubrir bien >>> porque no son un compilador de C. Ejemplos hay a patadas. >>> >>> Andres. >>> >>> -- >>> To post to this group, send email to [hidden email] >>> To unsubscribe from this group, send email to >>> [hidden email] >>> >>> http://www.clubSmalltalk.org >> >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by leodm
Ah, una Invisible Machine es una VM de otro lenguaje que usamos para
Smalltalk, así es? ok. El otro día discutíamos (o coincidíamos) con Andres (Valloud) que hubo una o dos generaciones de Smalltalkers que se olvidaron completamente de las VMs. Están los popes de las VMs, que hicieron o fundaron casi todas las VMs que hay (Java HotSpot, V8, Self, .NET, Strongtalk y los Smalltalks), y después de ellos la generación siguiente ni las vio las VMs (eran, digamos, invisibles). Digamos que andaban suficientemente bien. Y la comunidad Smalltalk, de donde salieron casi todas las VMs buenas, dejó de tener expertos en VMs por mucho tiempo, y recién ahora empieza a haber un nuevo movimiento en esta dirección. Esto mismo repercutió en que aparezcan muchos lenguajes con VMs realmente de mierda (Python, PHP, perl... Basic... etc). Si alguien cree que hace falta avance en el mundo de las VMs (hay unos cuantos que lo creemos necesario), hace falta que se vuelva a armar un bullicio al rededor de las VMs, y que más gente meta mano. Esto es, a largo plazo, claro. chau, estoy medio charlatán hoy On 11/14/2012 10:35 AM, [hidden email] wrote: > Es un termino q empezo a emplear ale reimondo cuando empezo a pensar un smalltalk sin vm "propia" q se pudiera montar en v8 (la vm de google) pero q sea flexible para poder montarse sobre cualquier vm javascript, por ej spidermonkey, node o la q fuera. > > Todo esto viene de un largo camino de pensar alternativas c vm propietarias, entre ellas la de dng misma de la q el fue parte en su momento. > > Saludos, > Leo > > > Enviado desde mi BlackBerry de Personal > > -----Original Message----- > From: Gerardo Richarte <[hidden email]> > Sender: [hidden email] > Date: Wed, 14 Nov 2012 01:36:35 > To: <[hidden email]> > Reply-To: [hidden email] > Subject: [clubSmalltalk] Invisible Machine > > Leo De Marco dijo: > >> de allí surgió la formulación de "Invisible Machine" > > Que es una invisible machine > -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
La tension proviene de, por un lado, adquirir una cierta sensibilidad
por los programas y lenguajes elegantes (como Smalltalk), y despues tener que ir y arremangarse en C (o C++ o lo que fuera). Esteticamente es un garron. Me pareceria valioso si se pudiera tener una comprension mas cabal de los minimos requerimientos de una VM de Smalltalk en lo que concierne a C, elegidos con una cierta dosis de pragmatismo, y que se unifique ese concepto en todos los Smalltalks. Y porque dije "pragmatismo"? Porque seguro se puede reimplementar gcc en Smalltalk, pero no me parece que sea el esfuerzo que mas beneficios traiga. 2012/11/14 Gerardo Richarte <[hidden email]>: > Ah, una Invisible Machine es una VM de otro lenguaje que usamos para > Smalltalk, así es? ok. > > El otro día discutíamos (o coincidíamos) con Andres (Valloud) que hubo > una o dos generaciones de Smalltalkers que se olvidaron completamente de > las VMs. Están los popes de las VMs, que hicieron o fundaron casi todas > las VMs que hay (Java HotSpot, V8, Self, .NET, Strongtalk y los > Smalltalks), y después de ellos la generación siguiente ni las vio las > VMs (eran, digamos, invisibles). Digamos que andaban suficientemente > bien. Y la comunidad Smalltalk, de donde salieron casi todas las VMs > buenas, dejó de tener expertos en VMs por mucho tiempo, y recién ahora > empieza a haber un nuevo movimiento en esta dirección. > > Esto mismo repercutió en que aparezcan muchos lenguajes con VMs > realmente de mierda (Python, PHP, perl... Basic... etc). > > Si alguien cree que hace falta avance en el mundo de las VMs (hay unos > cuantos que lo creemos necesario), hace falta que se vuelva a armar un > bullicio al rededor de las VMs, y que más gente meta mano. Esto es, a > largo plazo, claro. > > chau, estoy medio charlatán hoy > > On 11/14/2012 10:35 AM, [hidden email] wrote: >> Es un termino q empezo a emplear ale reimondo cuando empezo a pensar un smalltalk sin vm "propia" q se pudiera montar en v8 (la vm de google) pero q sea flexible para poder montarse sobre cualquier vm javascript, por ej spidermonkey, node o la q fuera. >> >> Todo esto viene de un largo camino de pensar alternativas c vm propietarias, entre ellas la de dng misma de la q el fue parte en su momento. >> >> Saludos, >> Leo >> >> >> Enviado desde mi BlackBerry de Personal >> >> -----Original Message----- >> From: Gerardo Richarte <[hidden email]> >> Sender: [hidden email] >> Date: Wed, 14 Nov 2012 01:36:35 >> To: <[hidden email]> >> Reply-To: [hidden email] >> Subject: [clubSmalltalk] Invisible Machine >> >> Leo De Marco dijo: >> >>> de allí surgió la formulación de "Invisible Machine" >> >> Que es una invisible machine >> > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Gerardo Richarte
¿Y se considera que la JVM es mala?
Porque claramente la JVM es probablemente la VM más estable y más ampliamente disponible en el mundo. Hacer VMs por decir que se puede, no creo que tenga mucho valor, a menos que se logre algo que antes no existía.
Saludos, Guillermo. 2012/11/14 Gerardo Richarte <[hidden email]> Ah, una Invisible Machine es una VM de otro lenguaje que usamos para Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Andres Valloud-5
" El tema es que este tipo de proceder no es
tecnicamente correcto," ¿Cuál tipo de proceder? Si no te explayas un poquito, no se entiende lo quieres decir. 2012/11/14 Andres Valloud <[hidden email]> A medida que voy pensando mas en lo que implica hacer un outsourcing Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Inocencia de dominio [era: Sobre CUIS y Pharo]
|
|
In reply to this post by Angel Java Lopez
Che, cambiemos el subject porque hace
rato que no hablamos de Cuis.
Disculpame, Juan, si te resta publicidad :-) On 14/11/2012 11:17 a.m., Angel Java Lopez wrote: Jeje... no, eso lo hace la comunidad que arma la libreria. En todo esto, ¿dónde quedan las cosas de modelar un dominio, resolver problemas, etc? Por esto lo de inocencia en el subject... Tal vez soy demasiado inocente, pero en nuestra modesta experiencia, cuando usamos librerías de terceras partes de esa manera, qeudamos obligados a volvernos expertos en librerías y comunidades. Es decir, ya nuestro dominio no es más el que tenía nuestro cliente (¿se acuerdan del cliente, el que nos paga y generalmente no le importa un corno en qué está hecha la app?) y empezamos a discutir horas y horas sobre qué library hay que usar, dónde buscar los updates, recorremos foros, leemos miles de emails... y nuestro foco pasó a ser la tecnología, y no el dominio. Yo quiero seguir siendo inocente, no quiero tener que navegar una hora para ver qué switches de compilación tengo que desactivar porque "alguien de una comunidad ya pasó por ahí y lo resolvió". Porque la solución de "alguien de la comunidad", generalmente se reduce a la cuestión muy bien caracterizada por Andrés: el tipo lo probó en su máquina y le anda. Cuando en mi cliente no anda, yo me vuelvo chino... porque estoy usando una tecnología que no entiendo y tengo que estudiarla, y no puedo usar mis herramientas habituales para estudiar (inspector, debugger, todo lo que conocen bien). ¿Es demasiado inocente lo mío? Seguro. Ya tuve que romper esa regla un montón de veces, desde cosas tan simples como querer compilar una VM de Pharo o wrappear unas funciones de DLL de Windows (ah, cómo extraño la vieja documentación) en nuestro ambiente. Pero trato de despegarme lo menos posible, de tener (y leer) la documentación y no usar consejos de "alguien de la comunidad" sobre algo qeu no entiendo. Debo estar viejo... Ya sé que todo el mundo programa así, de hecho me sorprendió mucho ver que Germán (A) admite que él trata de pegar varias cosas y que salgan andando... pero yo creo, e serio, que Smalltalk no es para eso. Ni debe ser para eso. Ahora, peguen nomás... Carlos "flame-warior" Ferro -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Inocencia de dominio [era: Sobre CUIS y Pharo]
|
|
> Tal vez soy demasiado inocente, pero en nuestra modesta experiencia, cuando
> usamos librerías de terceras partes de esa manera, qeudamos obligados a > volvernos expertos en librerías y comunidades. Es decir, ya nuestro dominio > no es más el que tenía nuestro cliente (¿se acuerdan del cliente, el que nos > paga y generalmente no le importa un corno en qué está hecha la app?) y > empezamos a discutir horas y horas sobre qué library hay que usar, dónde > buscar los updates, recorremos foros, leemos miles de emails... y nuestro > foco pasó a ser la tecnología, y no el dominio. Exactamente. > Yo quiero seguir siendo inocente, no quiero tener que navegar una hora para > ver qué switches de compilación tengo que desactivar porque "alguien de una > comunidad ya pasó por ahí y lo resolvió". Porque la solución de "alguien de > la comunidad", generalmente se reduce a la cuestión muy bien caracterizada > por Andrés: el tipo lo probó en su máquina y le anda. Cuando en mi cliente > no anda, yo me vuelvo chino... porque estoy usando una tecnología que no > entiendo y tengo que estudiarla, y no puedo usar mis herramientas habituales > para estudiar (inspector, debugger, todo lo que conocen bien). Tal cual. Los tipicos problemas de los proyectos de la vida real. Cuanto menos complicada sea la estrategia de reuso, mejor. Si llamar a librerias con interface C ya es complicado, lo peor que se puede hacer es una herramienta que "simplifica" la cuestion dando la apariencia de hacer la tarea de investigacion del programador automaticamente. Te saca de contexto, despues viene alguien que sabe en serio y cuando habla ni siquiera reconoces lo que dice como algo que exista. Terminas "negando" o "ignorando" la realidad a proposito, eso es muy peligroso. > ¿Es demasiado inocente lo mío? Seguro. Ya tuve que romper esa regla un > montón de veces, desde cosas tan simples como querer compilar una VM de > Pharo o wrappear unas funciones de DLL de Windows (ah, cómo extraño la vieja > documentación) en nuestro ambiente. > Pero trato de despegarme lo menos posible, de tener (y leer) la > documentación y no usar consejos de "alguien de la comunidad" sobre algo qeu > no entiendo. En mi experiencia de la VM de Cincom, el 99% de lo que se dice en los foros tecnicos es equivalente a /dev/random. Y solo te das cuenta despues de horas y horas, dias y dias, semanas y semanas, y a veces meses y meses de darle y darle hasta que entendes algo en serio. Lo que aprendi de esto es que si no estas super seguro de lo que vas a decir, entonces lo mejor es callarse. A mi me gustaria que existiera la version de 10 paginas de C. Ya seria una simplificacion brutal, la definicion de hoy de C andara cerca de las 1000 paginas, y eso no incluye los manuales de los compiladores ni los SDK ni las plataformas ni nada. Algo asi seria realmente muy util porque bajaria drasticamente el nivel de ruido de fondo en un monton de cosas. Andres. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Guillermo Schwarz
Hace backtracking, esta en el parrafo anterior.
2012/11/14 Guillermo Schwarz <[hidden email]>: > " El tema es que este tipo de proceder no es > tecnicamente correcto," > > ¿Cuál tipo de proceder? > > Si no te explayas un poquito, no se entiende lo quieres decir. > > > 2012/11/14 Andres Valloud <[hidden email]> >> >> A medida que voy pensando mas en lo que implica hacer un outsourcing >> de lidiar con C, se me van poniendo los pelos de punta... que se yo, >> es lo mismo que decir "escribamos la VM en Smalltalk, la traducimos >> mecanicamente a C, y despues la compilamos sin optimizacion porque hay >> bugs en el compilador (obviamente, si tu programa no anda la culpa >> siempre es del compilador :p), ignoramos todos los compiler warnings, >> y como anda en mi maquina entonces listo"... >> >> Por favor no entiendan que me la agarro exclusivamente con Pharo / >> Squeak / etc, o con alguna persona en particular. El de arriba no es >> el unico ejemplo ni por las tapas, y ademas ya conte varios otros >> ejemplos en mi charla de Smalltalks 2009. Lo que observo es la >> tendencia a largo plazo. El tema es que este tipo de proceder no es >> tecnicamente correcto, y sin embargo hay un monton de resistencia a >> mirar el manual de gcc (por ejemplo). Esa postura tambien es una >> forma de ningunear el trabajo de los demas, y el resultado es un punto >> de vista que te aisla y te limita. >> >> 2012/11/14 Andres Valloud <[hidden email]>: >> > O sea que la propuesta es, en vez de "importar" el quilombo de C, >> > "importar" el quilombo de .NET, Java y/o Javascript, asumiendo que >> > estos lenguajes ya lidian con el tema de "importar" el quilombo de C >> > de manera correcta. Y eso como se debuggea cuando no anda? >> > >> > 2012/11/14 Angel Java Lopez <[hidden email]>: >> >> Si, por eso un camino a explorar es: >> >> >> >> - VM sobre .NET/Java/JavaScript >> >> >> >> En esos casos, las librerias que se cargan YA estan escritos en un >> >> "underlying language" que tiene Garbage Collector y un sistema de tipos >> >> comun. >> >> >> >> No mas FFI, sino simple carga dinamica de modulos, librerias, require, >> >> etc... >> >> >> >> Y esas librerias que se cargan YA estan probadas en el "underlying VM". >> >> Y >> >> soportadas/probadas por parva de gente. >> >> >> >> Angel "MyLifeIsAVirtualMachine" Lopez ;-) >> >> >> >> 2012/11/14 Andres Valloud <[hidden email]> >> >>> >> >>> > siempre hay que tomar en cuenta unas cuantas cosas, obvio... pero a >> >>> > lo >> >>> > que voy es que no vale la pena hacer una libreria de, ponele >> >>> > criptografía >> >>> > (ya que german la menciona), sino que es mucho mas productivo usar >> >>> > una >> >>> > libreria ya existente y ahorrarse de paso el costo de mantenerlo. >> >>> >> >>> A lo que voy es que hacer eso te expone al mundo de C, al cual en >> >>> general se le tiene un cierto rechazo en la comunidad Smalltalk, por >> >>> lo tanto se tiende a mirarlo asi no mas, y eso a la larga trae >> >>> problemas de fondo bastante serios. La clase de problemas se puede >> >>> describir en terminos de todo el undefined behavior que termina >> >>> ocurriendo en nuestros programas debido especificamente a asumir que, >> >>> como Smalltalk es simple, y como todo se puede hacer en Smalltalk, >> >>> entonces C hecho en Smalltalk se vuelve simple por clausura transitiva >> >>> (o algun asumido equivalente). Pero no es asi... simplemente compilar >> >>> una VM como corresponde ya es un requilombo. Y el tema de fondo de >> >>> los FFI es que hay un monton de casos que nunca podran cubrir bien >> >>> porque no son un compilador de C. Ejemplos hay a patadas. >> >>> >> >>> Andres. >> >>> >> >>> -- >> >>> To post to this group, send email to [hidden email] >> >>> To unsubscribe from this group, send email to >> >>> [hidden email] >> >>> >> >>> http://www.clubSmalltalk.org >> >> >> >> >> >> -- >> >> To post to this group, send email to [hidden email] >> >> To unsubscribe from this group, send email to >> >> [hidden email] >> >> >> >> http://www.clubSmalltalk.org >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Inocencia de dominio [era: Sobre CUIS y Pharo]
|
|
In reply to this post by Carlos E. Ferro-2
Eso queda como antes, cuando uno importaba una libreria en C en FFI. Eso queda del lado de quien consuma la libreria. Lo mismo pasa en .NET, Java o JavaScript. Consumis la libreria tal cual, o modelas encima de ella.
Puede modelar un wrapper con clases y conducta. O puede modelar un wrapper inicial, apenas un pasamanos de algunas cosas, para ir armando mas solido. A lo que voy, es que eso es perfectamente posible, y sin "importar quilombos" provocados por estar la libreria directamente en C (problemas con los tipos, punteros, ausencia de garbage collector, etc... etc...)
Por supuesto, habra librerias que se necesiten en C, lo primero que se me ocurre por velocidad, como le paso a Python con paquetes cientificos/matematicos. Pero luego hay un ecosistema (en .NET, Java, Javascript) donde, por ejemplo, un driver para acceder a MongoDB, ya esta servido. Y puede servir de base para ir construyendo sobre Smalltalk, sin tener que "reinventar la rueda" cada vez. Si luego, el proyecto progresa (el proyecto Smalltalk que va sobre ese driver) se puede mejorar el wrapper, modelarlo mejor, etc... Y hasta cambiarlo por otra cosa mejor.
Pero hay un mundo ahi afuera para aprovechar. Y a lo que voy, es que no veo que se siga, en el mundo Smalltalk, ese camino: implementar el lenguaje en .NET, Java. Siguen pensando en C, herendando FFI. En otras tecnologias, hay tranquilamente lenguajes nativos (CPython, Ruby), y luego reimplementaciones sobre VMs (Jython, IronPython, IronRuby, JRuby, etc..).
No digo que sea un camino de rosas... lo que me asombra un poco, que pasaron los anios, y no se ha tomado ese camino en el ambiente Smalltalk. Espero que ahora haya algo de movimiento con JavaScript, aunque opino que hubiera sido mas solido y evolutivo haber pasado por .NET o Java. Y tener una Smalltalk VM popular sobre esos, open source, Redline Smalltalk en Java es una esperanza.
Angel "Java" Lopez @ajlopez gh:ajlopez 2012/11/14 Carlos E. Ferro <[hidden email]>
To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Guillermo Schwarz
Como? la JVM es buenísima! claro, todas esas (Java, V8, Strongtalk,
.NET, VW) son buenas, claro. Pero hace falta una nueva pasada. Hay cosas nuevas ahora, y hay gente que las quiere usar (traits/mixins (Smalltalk/Ruby/Python/C++), comportamiento y estado por instancia en vez de clases o traits (Ruby/JavaScript/Self), multi-cores/distrbuido (Roar/Gemstone/Earlang (creo)), cosas de seguridad/privacidad (Newspeak), etc. Para algunas de esas cosas hace falta o viene muy bien para que sea usable, soporte desde la VM. Y esas son solo las cosas que podemos pensar desde nuestro paradigma. Cuando halla una nueva camada de expertos en VMs (y ojalá se continúe) seguro aparecen más cosas saludos On 11/14/2012 11:40 AM, Guillermo Schwarz wrote: > ¿Y se considera que la JVM es mala? > > Porque claramente la JVM es probablemente la VM más estable y más > ampliamente disponible en el mundo. > > Hacer VMs por decir que se puede, no creo que tenga mucho valor, a menos > que se logre algo que antes no existía. > > Saludos, > Guillermo. > > > 2012/11/14 Gerardo Richarte <[hidden email] <mailto:[hidden email]>> > > Ah, una Invisible Machine es una VM de otro lenguaje que usamos para > Smalltalk, así es? ok. > > El otro día discutíamos (o coincidíamos) con Andres (Valloud) que hubo > una o dos generaciones de Smalltalkers que se olvidaron completamente de > las VMs. Están los popes de las VMs, que hicieron o fundaron casi todas > las VMs que hay (Java HotSpot, V8, Self, .NET, Strongtalk y los > Smalltalks), y después de ellos la generación siguiente ni las vio las > VMs (eran, digamos, invisibles). Digamos que andaban suficientemente > bien. Y la comunidad Smalltalk, de donde salieron casi todas las VMs > buenas, dejó de tener expertos en VMs por mucho tiempo, y recién ahora > empieza a haber un nuevo movimiento en esta dirección. > > Esto mismo repercutió en que aparezcan muchos lenguajes con VMs > realmente de mierda (Python, PHP, perl... Basic... etc). > > Si alguien cree que hace falta avance en el mundo de las VMs (hay unos > cuantos que lo creemos necesario), hace falta que se vuelva a armar un > bullicio al rededor de las VMs, y que más gente meta mano. Esto es, a > largo plazo, claro. > > chau, estoy medio charlatán hoy > > On 11/14/2012 10:35 AM, [hidden email] > <mailto:[hidden email]> wrote: > > Es un termino q empezo a emplear ale reimondo cuando empezo a > pensar un smalltalk sin vm "propia" q se pudiera montar en v8 (la vm > de google) pero q sea flexible para poder montarse sobre cualquier > vm javascript, por ej spidermonkey, node o la q fuera. > > > > Todo esto viene de un largo camino de pensar alternativas c vm > propietarias, entre ellas la de dng misma de la q el fue parte en su > momento. > > > > Saludos, > > Leo > > > > > > Enviado desde mi BlackBerry de Personal > > > > -----Original Message----- > > From: Gerardo Richarte <[hidden email] <mailto:[hidden email]>> > > Sender: [hidden email] > <mailto:[hidden email]> > > Date: Wed, 14 Nov 2012 01:36:35 > > To: <[hidden email] > <mailto:[hidden email]>> > > Reply-To: [hidden email] > <mailto:[hidden email]> > > Subject: [clubSmalltalk] Invisible Machine > > > > Leo De Marco dijo: > > > >> de allí surgió la formulación de "Invisible Machine" > > > > Que es una invisible machine > > > > -- > To post to this group, send email to [hidden email] > <mailto:[hidden email]> > To unsubscribe from this group, send email to > [hidden email] > <mailto:clubSmalltalk%[hidden email]> > > http://www.clubSmalltalk.org > > > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Inocencia de dominio [era: Sobre CUIS y Pharo]
|
|
In reply to this post by Angel Java Lopez
Buenas...
> A lo que voy, es que eso es perfectamente posible, y sin "importar > quilombos" provocados por estar la libreria directamente en C (problemas con > los tipos, punteros, ausencia de garbage collector, etc... etc...) Y no, dudo mucho que esto sea cierto en el caso general. Por ejemplo como llamas a stat() en Linux con un FFI? O como usas sockets POSIX sin un compilador? > Y a lo que voy, es que no veo que se siga, en el mundo Smalltalk, ese > camino: implementar el lenguaje en .NET, Java. Siguen pensando en C, > herendando FFI. En otras tecnologias, hay tranquilamente lenguajes nativos > (CPython, Ruby), y luego reimplementaciones sobre VMs (Jython, IronPython, > IronRuby, JRuby, etc..). Bueno, por que sera? Andres. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Gerardo Richarte
> Para algunas de esas cosas hace falta o viene muy bien para que sea
> usable, soporte desde la VM. Y esas son solo las cosas que podemos > pensar desde nuestro paradigma. Cuando halla una nueva camada de > expertos en VMs (y ojalá se continúe) seguro aparecen más cosas Cual es la definicion de un experto en VMs? Que "materias" hay que cursar para recibirse? -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Inocencia de dominio [era: Sobre CUIS y Pharo]
|
|
In reply to this post by Andres Valloud-5
Hmmm... Maese Valloud! No se si entendi tus preguntas.. se me escapa la diferencia actual de las librerias de sockets de bajo nivel.
Pero en el caso de sockets, una Smalltalk VM escrita sobre .NET, Java o JavaScript usaria una implementacion del "underlying VM".
Yo podriar usar Sockets en mi VM .NET, sin tener que implementarlos y sin necesidad de C. Llamo a las librerias que estan disponibles (ya cargadas, o las cargo dinamicamente). He escrito programas en C, con gcc, que manejan los mismos sockets que del otro lado atiendo con Node.js, Java o .NET.
Lo mismo si la Smalltalk VM esta en JavaScript. Me voy sobre Node.js y hago algun require, y tengo sockets disponibles, y http, y mas. Y los puedo usar de forma multiplataforma. El caso tipico es NodeJs: hay cantidad de sistemas escritos, que acceden a funciones del sistema operativo "de abajo", sin importar cual es. Y eso lo construyo una comunidad, que es mas grande que la que puede armar una Smalltalk VM escrita directamente en C.
El sistema operativo es la underlying VM y sus clases, y sus librerias cargadas dinamicamente a pedido. Rara vez se necesitaria entonces ir a C. Y con respecto a tu pregunta
"Bueno, por que sera?" Eso! Cual seria tu respuesta? Y los demas? Por que piensan que pasa eso en el ambiente Smalltalk? Algo comenzo a escribir Richarte (se desperto! ;-) en otro thread, vere si lo entiendo, sino pregunta
Angel "VMSobreVM" Lopez 2012/11/14 Andres Valloud <[hidden email]> Buenas... To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Carlos E. Ferro-2
El 14 de noviembre de 2012 11:44, Carlos E. Ferro <[hidden email]> escribió:
--
Hola Carlos! Como siempre aclaro que son puntos de vista personales y en mi contexto de clientes. Y si, en un punto la cosa se transformó en trabajar o morir con Smalltalk. Trabajar, quiero decir, ganar presupuestos, hacer desarrollos por los cuales clientes (esos que alguien dijo muy bien que no les importa un pito con qué están hechas las cosas) pagan (luego de averiguar en 4 o 5 proveedores) y para poder competir en esos ámbitos hay factores que influyen mucho (q ya los repetí varias veces asi que para no aburrir los voy a obviar acá). Pero a mi personalmente, Smalltalk se me hizo inviable (al menos los que yo usaba (los open y Dolphin)). Saludos. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Andres Valloud-5
Y... hacerse unas cuantas VMs que corran un par de imágenes de algún Smalltalk conocido.
Como todo en la vida, en la cancha se ven los choritos. Saludos, Guillermo.
2012/11/14 Andres Valloud <[hidden email]>
Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Gerardo Richarte
Para usar traits o mixins no es necesario crear una nueva VM.
De hecho en Java uso traits usando una librería. No es tan bonito como que el lenguaje incorpore los traits directamente, pero eso es por falta de acceso a modificar el compilador, no por falta de acceso a modificar la VM.
Multicores? Eso lo hace la JVM directamente. Al parecer para todo lo que dices con la JVM bastaría. Saludos, Guillermo.
2012/11/14 Gerardo Richarte <[hidden email]> Como? la JVM es buenísima! claro, todas esas (Java, V8, Strongtalk, Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Andres Valloud-5
"A medida que voy pensando mas en lo que implica hacer un outsourcing
de lidiar con C, se me van poniendo los pelos de punta... que se yo, es lo mismo que decir "escribamos la VM en Smalltalk, la traducimos mecanicamente a C, y despues la compilamos sin optimizacion porque hay bugs en el compilador (obviamente, si tu programa no anda la culpa siempre es del compilador :p), ignoramos todos los compiler warnings, y como anda en mi maquina entonces listo"..." Estas son las alternativas: 1. hacer un outsourcing de lidiar con C.
2. escribamos la VM en Smalltalk, la traducimos mecanicamente a C
3. la compilamos sin optimizacion porque hay bugs en el compilador
4. ignoramos todos los compiler warnings 5. como anda en mi maquina entonces listo
2012/11/14 Andres Valloud <[hidden email]> Hace backtracking, esta en el parrafo anterior. Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
EAGAIN
2012/11/14 Guillermo Schwarz <[hidden email]>: > "A medida que voy pensando mas en lo que implica hacer un outsourcing > de lidiar con C, se me van poniendo los pelos de punta... que se yo, > es lo mismo que decir "escribamos la VM en Smalltalk, la traducimos > mecanicamente a C, y despues la compilamos sin optimizacion porque hay > bugs en el compilador (obviamente, si tu programa no anda la culpa > siempre es del compilador :p), ignoramos todos los compiler warnings, > y como anda en mi maquina entonces listo"..." > > Estas son las alternativas: > > 1. hacer un outsourcing de lidiar con C. > 2. escribamos la VM en Smalltalk, la traducimos mecanicamente a C > 3. la compilamos sin optimizacion porque hay bugs en el compilador > 4. ignoramos todos los compiler warnings > 5. como anda en mi maquina entonces listo > > > > 2012/11/14 Andres Valloud <[hidden email]> >> >> Hace backtracking, esta en el parrafo anterior. >> >> 2012/11/14 Guillermo Schwarz <[hidden email]>: >> > " El tema es que este tipo de proceder no es >> > tecnicamente correcto," >> > >> > ¿Cuál tipo de proceder? >> > >> > Si no te explayas un poquito, no se entiende lo quieres decir. >> > >> > >> > 2012/11/14 Andres Valloud <[hidden email]> >> >> >> >> A medida que voy pensando mas en lo que implica hacer un outsourcing >> >> de lidiar con C, se me van poniendo los pelos de punta... que se yo, >> >> es lo mismo que decir "escribamos la VM en Smalltalk, la traducimos >> >> mecanicamente a C, y despues la compilamos sin optimizacion porque hay >> >> bugs en el compilador (obviamente, si tu programa no anda la culpa >> >> siempre es del compilador :p), ignoramos todos los compiler warnings, >> >> y como anda en mi maquina entonces listo"... >> >> >> >> Por favor no entiendan que me la agarro exclusivamente con Pharo / >> >> Squeak / etc, o con alguna persona en particular. El de arriba no es >> >> el unico ejemplo ni por las tapas, y ademas ya conte varios otros >> >> ejemplos en mi charla de Smalltalks 2009. Lo que observo es la >> >> tendencia a largo plazo. El tema es que este tipo de proceder no es >> >> tecnicamente correcto, y sin embargo hay un monton de resistencia a >> >> mirar el manual de gcc (por ejemplo). Esa postura tambien es una >> >> forma de ningunear el trabajo de los demas, y el resultado es un punto >> >> de vista que te aisla y te limita. >> >> >> >> 2012/11/14 Andres Valloud <[hidden email]>: >> >> > O sea que la propuesta es, en vez de "importar" el quilombo de C, >> >> > "importar" el quilombo de .NET, Java y/o Javascript, asumiendo que >> >> > estos lenguajes ya lidian con el tema de "importar" el quilombo de C >> >> > de manera correcta. Y eso como se debuggea cuando no anda? >> >> > >> >> > 2012/11/14 Angel Java Lopez <[hidden email]>: >> >> >> Si, por eso un camino a explorar es: >> >> >> >> >> >> - VM sobre .NET/Java/JavaScript >> >> >> >> >> >> En esos casos, las librerias que se cargan YA estan escritos en un >> >> >> "underlying language" que tiene Garbage Collector y un sistema de >> >> >> tipos >> >> >> comun. >> >> >> >> >> >> No mas FFI, sino simple carga dinamica de modulos, librerias, >> >> >> require, >> >> >> etc... >> >> >> >> >> >> Y esas librerias que se cargan YA estan probadas en el "underlying >> >> >> VM". >> >> >> Y >> >> >> soportadas/probadas por parva de gente. >> >> >> >> >> >> Angel "MyLifeIsAVirtualMachine" Lopez ;-) >> >> >> >> >> >> 2012/11/14 Andres Valloud <[hidden email]> >> >> >>> >> >> >>> > siempre hay que tomar en cuenta unas cuantas cosas, obvio... pero >> >> >>> > a >> >> >>> > lo >> >> >>> > que voy es que no vale la pena hacer una libreria de, ponele >> >> >>> > criptografía >> >> >>> > (ya que german la menciona), sino que es mucho mas productivo >> >> >>> > usar >> >> >>> > una >> >> >>> > libreria ya existente y ahorrarse de paso el costo de mantenerlo. >> >> >>> >> >> >>> A lo que voy es que hacer eso te expone al mundo de C, al cual en >> >> >>> general se le tiene un cierto rechazo en la comunidad Smalltalk, >> >> >>> por >> >> >>> lo tanto se tiende a mirarlo asi no mas, y eso a la larga trae >> >> >>> problemas de fondo bastante serios. La clase de problemas se puede >> >> >>> describir en terminos de todo el undefined behavior que termina >> >> >>> ocurriendo en nuestros programas debido especificamente a asumir >> >> >>> que, >> >> >>> como Smalltalk es simple, y como todo se puede hacer en Smalltalk, >> >> >>> entonces C hecho en Smalltalk se vuelve simple por clausura >> >> >>> transitiva >> >> >>> (o algun asumido equivalente). Pero no es asi... simplemente >> >> >>> compilar >> >> >>> una VM como corresponde ya es un requilombo. Y el tema de fondo de >> >> >>> los FFI es que hay un monton de casos que nunca podran cubrir bien >> >> >>> porque no son un compilador de C. Ejemplos hay a patadas. >> >> >>> >> >> >>> Andres. >> >> >>> >> >> >>> -- >> >> >>> To post to this group, send email to [hidden email] >> >> >>> To unsubscribe from this group, send email to >> >> >>> [hidden email] >> >> >>> >> >> >>> http://www.clubSmalltalk.org >> >> >> >> >> >> >> >> >> -- >> >> >> To post to this group, send email to [hidden email] >> >> >> To unsubscribe from this group, send email to >> >> >> [hidden email] >> >> >> >> >> >> http://www.clubSmalltalk.org >> >> >> >> -- >> >> To post to this group, send email to [hidden email] >> >> To unsubscribe from this group, send email to >> >> [hidden email] >> >> >> >> http://www.clubSmalltalk.org >> > >> > >> > >> > >> > -- >> > Saludos cordiales, >> > >> > Guillermo Schwarz >> > Sun Certified Enterprise Architect >> > >> > -- >> > To post to this group, send email to [hidden email] >> > To unsubscribe from this group, send email to >> > [hidden email] >> > >> > http://www.clubSmalltalk.org >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Guillermo Schwarz
SIGTROLL
2012/11/14 Guillermo Schwarz <[hidden email]>: > Y... hacerse unas cuantas VMs que corran un par de imágenes de algún > Smalltalk conocido. > > Como todo en la vida, en la cancha se ven los choritos. > > Saludos, > Guillermo. > > > 2012/11/14 Andres Valloud <[hidden email]> >> >> > Para algunas de esas cosas hace falta o viene muy bien para que sea >> > usable, soporte desde la VM. Y esas son solo las cosas que podemos >> > pensar desde nuestro paradigma. Cuando halla una nueva camada de >> > expertos en VMs (y ojalá se continúe) seguro aparecen más cosas >> >> Cual es la definicion de un experto en VMs? >> >> Que "materias" hay que cursar para recibirse? >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
«
Return to Español (Spanish)
|
1 view|%1 views
| Free forum by Nabble | Edit this page |