Re: Sobre CUIS y Pharo
Locked
1234567
1234567
Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
 
|
Hola Mariano,
El día 11 de noviembre de 2012 18:20, Mariano Martinez Peck <[hidden email]> escribió: >> Quiero dejar el mío (modesto pero es mi experiencia) desde el punto de >> vista de quien desarrolla software comercial (open o no) para clientes >> reales.....y la verdad que en ese contexto, los smalltalks open [1] cada día >> se alejan más de la posibilidad de competir en muchas cosas: > Hola Germán. La verdad que no entiendo porque decís eso. Te respondo abajo Las respuestas que planteas son siempre dentro del micromundo (nanomundo?) de Smalltalk, comparando Pharo con otras soluciones(*). A lo que apunta German es a soluciones tecnológicas mainstream (JS, PHP, Python, etc.), que por mas que algunas sean una patada en las bol... para laburar o debuggear, tienen un codebase y libraries tan grandes que cuesta encontrar una funcionalidad "cómun" (drivers, protocolos, etc) que ya no este implementada. Pharo es una gran solución, pero en este momento esta en un estado en el cual se desarrolla a si mismo, como preparándose para algo mejor, pero para muchos que necesitan hacer algo "hoy" la respuesta no es tan directa y facil de tomar (al momento de elegir otras alternativas no-smalltalk). Yo creo que la visión de Pharo a nivel de calidad de código, prolijidad, y vanguardia hace que se enfoque en cosas de niveles muy altos, olvidándose de resolver temas mundanos y vanales como tienen las variantes mainstream. Osea, no es el kernel lo que esta mal (de hecho creo que cada vez esta mejor) sino que es la carencia de libraries completas para resolución de cosas cotidianas (que son el 95% del software que se hace por lo general) como ORM con scaffolding de GUIs ya resuelto, etc. Creo que es cuestión de tiempo para que esto se de, asi como en su momento Smalltalk era muy pesado para el hardware que existía (y las limitaciones de memoria), creo que en estamos en una nueva meseta donde se daba eso de la dificultad y costo de hostear que se va a ir borrando con el tiempo y otra vez Smalltalk va a tener un empuje. El grupo de Pharo que vos integras, junto con Esteban y otros mas, deberá seguir haciendo lo que hace, será cuestión que surja un grupo de usuarios externos, que tengan la voluntad y dedicación para hacer las libraries que hacen falta. Saludos! Esteban A. Maringolo -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Bueno, por un lado si, y por otro no tiene sentido...
Donde si? cuando valga la pena proveer en Smalltalk algo que esta afuera. El scaffolding, por ejemplo, me parece una porquería, que sirve para hacer ejemplos pero nunca para algo real. Magritte le rompe el totó de lejísimos. Y si, tenes que laburar un poco, pero los otros frameworks tenes que aprenderlos también, y aceptar sus restricciones. Y donde no tiene sentido? Como smalltalkers tenemos la tendencia de pretender replicar todo, y hay un montón de casos en los que no vale la pena perder ese tiempo. En ese sentido, como comunidad tenemos que aprender mucho de la de python: ellos no hacen la librería, simplemente la wrappean y la usan. Ahora con NativeBoost eso no solo es posible, sino trivial. Esteban (el otro) On Nov 12, 2012, at 2:35 PM, "Esteban A. Maringolo" <[hidden email]> wrote: > Hola Mariano, > > El día 11 de noviembre de 2012 18:20, Mariano Martinez Peck > <[hidden email]> escribió: > >>> Quiero dejar el mío (modesto pero es mi experiencia) desde el punto de >>> vista de quien desarrolla software comercial (open o no) para clientes >>> reales.....y la verdad que en ese contexto, los smalltalks open [1] cada día >>> se alejan más de la posibilidad de competir en muchas cosas: > >> Hola Germán. La verdad que no entiendo porque decís eso. Te respondo abajo > > Las respuestas que planteas son siempre dentro del micromundo > (nanomundo?) de Smalltalk, comparando Pharo con otras soluciones(*). > > A lo que apunta German es a soluciones tecnológicas mainstream (JS, > PHP, Python, etc.), que por mas que algunas sean una patada en las > bol... para laburar o debuggear, tienen un codebase y libraries tan > grandes que cuesta encontrar una funcionalidad "cómun" (drivers, > protocolos, etc) que ya no este implementada. > > Pharo es una gran solución, pero en este momento esta en un estado en > el cual se desarrolla a si mismo, como preparándose para algo mejor, > pero para muchos que necesitan hacer algo "hoy" la respuesta no es tan > directa y facil de tomar (al momento de elegir otras alternativas > no-smalltalk). > > Yo creo que la visión de Pharo a nivel de calidad de código, > prolijidad, y vanguardia hace que se enfoque en cosas de niveles muy > altos, olvidándose de resolver temas mundanos y vanales como tienen > las variantes mainstream. > > Osea, no es el kernel lo que esta mal (de hecho creo que cada vez esta > mejor) sino que es la carencia de libraries completas para resolución > de cosas cotidianas (que son el 95% del software que se hace por lo > general) como ORM con scaffolding de GUIs ya resuelto, etc. > > Creo que es cuestión de tiempo para que esto se de, asi como en su > momento Smalltalk era muy pesado para el hardware que existía (y las > limitaciones de memoria), creo que en estamos en una nueva meseta > donde se daba eso de la dificultad y costo de hostear que se va a ir > borrando con el tiempo y otra vez Smalltalk va a tener un empuje. > > El grupo de Pharo que vos integras, junto con Esteban y otros mas, > deberá seguir haciendo lo que hace, será cuestión que surja un grupo > de usuarios externos, que tengan la voluntad y dedicación para hacer > las libraries que hacen falta. > > Saludos! > > Esteban A. Maringolo > > -- > 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 |
|
|
> Y donde no tiene sentido? Como smalltalkers tenemos la tendencia de pretender replicar todo, y hay un montón de casos en los que no vale la pena perder ese tiempo. En ese sentido, como comunidad tenemos que aprender mucho de la de python: ellos no hacen la librería, simplemente la wrappean y la usan.
> Ahora con NativeBoost eso no solo es posible, sino trivial. Ojo con esas aseveraciones... -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
On Nov 12, 2012, at 3:39 PM, Andres Valloud <[hidden email]> wrote: >> Y donde no tiene sentido? Como smalltalkers tenemos la tendencia de pretender replicar todo, y hay un montón de casos en los que no vale la pena perder ese tiempo. En ese sentido, como comunidad tenemos que aprender mucho de la de python: ellos no hacen la librería, simplemente la wrappean y la usan. >> Ahora con NativeBoost eso no solo es posible, sino trivial. > > Ojo con esas aseveraciones... bueno, si... :) 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. > > -- > 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 EstebanLM
El día 12 de noviembre de 2012 11:19, Esteban Lorenzano
<[hidden email]> escribió: > Bueno, por un lado si, y por otro no tiene sentido... > > Donde si? cuando valga la pena proveer en Smalltalk algo que esta afuera. > > El scaffolding, por ejemplo, me parece una porquería, que sirve para hacer ejemplos pero nunca para algo real. > Magritte le rompe el totó de lejísimos. Y si, tenes que laburar un poco, pero los otros frameworks tenes que aprenderlos también, y aceptar sus restricciones. Para mi el scaffolding es como algo que completa huecos, te permite salir con algo funcional y luego darle más vueltas de tuerca si hace falta o si el uso real lo demanda. Nosotros en InfOil tenemos nuestro metamodelo descriptivo que genera editores dinámicamente, muchos son simples y rudimentarios, pero para la mayoría no tenemos que hacer NADA. Si existiese algo que, a nivel web, permitiese hacer eso "muy facil", con las URLs correspondientes, que me permita armar CRUD's minimos no solo a nivel GUI sino tambien con persistencia (asumamos una relacional atras, despues te todo sigue dominando), con explorer de elementos, paginacion, ganaría muchos adeptos. Tendriamos que hacer una estadística nuestra, para saber cuantas clases usan editores específicos y cuantas uno "generico" creado dinamicamente. > Y donde no tiene sentido? Como smalltalkers tenemos la tendencia de pretender replicar todo, y hay un montón de casos en los que no vale la pena perder ese tiempo. En ese sentido, como comunidad tenemos que aprender mucho de la de python: ellos no hacen la librería, simplemente la wrappean y la usan. > Ahora con NativeBoost eso no solo es posible, sino trivial. Si, es muy util poder wrappear las cosas, asi fue que Dolphin implementó mucha de su funcionalidad (respaldada por un buen modelo del lado ST). Creo que es un punto fuerte, pero de nuevo, son cosas de kernel, ahora falta que se empiecen a hacer cosas que generen las librerías como spinoff de un producto concreto. Lo de trivial, dependerá para quien :) > Esteban (el otro) (el mismo) :) -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
On Nov 12, 2012, at 3:53 PM, "Esteban A. Maringolo" <[hidden email]> wrote: > El día 12 de noviembre de 2012 11:19, Esteban Lorenzano > <[hidden email]> escribió: >> Bueno, por un lado si, y por otro no tiene sentido... >> >> Donde si? cuando valga la pena proveer en Smalltalk algo que esta afuera. >> >> El scaffolding, por ejemplo, me parece una porquería, que sirve para hacer ejemplos pero nunca para algo real. >> Magritte le rompe el totó de lejísimos. Y si, tenes que laburar un poco, pero los otros frameworks tenes que aprenderlos también, y aceptar sus restricciones. > > Para mi el scaffolding es como algo que completa huecos, te permite > salir con algo funcional y luego darle más vueltas de tuerca si hace > falta o si el uso real lo demanda. si, pero eso magritte te lo soluciona, con Seaside. Yo en general programo mis paginas web magritte-oriented :)... es muy dificil que haga una página que muestra/pide datos directamente en seaside, me resulta mucho mas cómodo (por lo acostumbrado que estoy) crear un nuevo componente de magritte, si lo que hay no satisface mis necesidades. Por ejemplo, yo hace rato le puse un layer más a seaside (reef), que me permite laburar a un nivel de componentes tambien en lo "micro" (cada elemento de html), y me permite crear componentes ajax etc. de forma simple. Ademas hago mas o menos lo mismo persistiendo (con Voyage, yo no uso relacional normalmente). De forma que, sin usar "scaffolding", tengo todo eso que decís. Y ahi es donde me permito afirmar que, en Smalltalk, scaffolding es una herramienta limitada, podemos hacer cosas mejores. Lo cual me lleva a una cosa que vengo pensando desde hace rato falta en Pharo (y probablemente en toda la comunidad de Smalltalk), además de la gente que tome el kernel y lo use para desarrollar herramientas (que coincido, es algo que falta). Falta también documentación. Y no solo lo básico. Habría que escribir un libro: "Pharo en la empresa", con patrones, arquitecturas, y herramientas típicas para una aplicación de negocios hecha con Pharo. El problema, claro (como siempre), es ¿quién le pone el cascabel al gato? porque escribir un libro lleva un montón de trabajo y el tiempo no es precisamente lo que sobra :) > > Nosotros en InfOil tenemos nuestro metamodelo descriptivo que genera > editores dinámicamente, muchos son simples y rudimentarios, pero para > la mayoría no tenemos que hacer NADA. > > Si existiese algo que, a nivel web, permitiese hacer eso "muy facil", > con las URLs correspondientes, que me permita armar CRUD's minimos no > solo a nivel GUI sino tambien con persistencia (asumamos una > relacional atras, despues te todo sigue dominando), con explorer de > elementos, paginacion, ganaría muchos adeptos. > > Tendriamos que hacer una estadística nuestra, para saber cuantas > clases usan editores específicos y cuantas uno "generico" creado > dinamicamente. > >> Y donde no tiene sentido? Como smalltalkers tenemos la tendencia de pretender replicar todo, y hay un montón de casos en los que no vale la pena perder ese tiempo. En ese sentido, como comunidad tenemos que aprender mucho de la de python: ellos no hacen la librería, simplemente la wrappean y la usan. >> Ahora con NativeBoost eso no solo es posible, sino trivial. > > Si, es muy util poder wrappear las cosas, asi fue que Dolphin > implementó mucha de su funcionalidad (respaldada por un buen modelo > del lado ST). Creo que es un punto fuerte, pero de nuevo, son cosas de > kernel, ahora falta que se empiecen a hacer cosas que generen las > librerías como spinoff de un producto concreto. > > Lo de trivial, dependerá para quien :) > >> Esteban (el otro) > > (el mismo) :) > > -- > 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 Esteban A. Maringolo
Hola:
El 12 de noviembre de 2012 11:53, Esteban A. Maringolo <[hidden email]> escribió:
-- El día 12 de noviembre de 2012 11:19, Esteban Lorenzano Tendriamos que hacer una estadística nuestra, para saber cuantas Comparto mucho esto. De hecho en PHP está ScriptCase que te resuelve mucho de eso trivial que luego, al momento de ponerse a hacerlo NO es tan trivial, o si lo es, pero lleva mucho tiempo.
ScriptCase es el típico producto por el cual pago gustoso lo que cuesta, porque se recupera rapidísimo. 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 |
Re: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
In reply to this post by garduino
2012/11/11 Germán Arduino <[hidden email]> --
Si, claro, discusión en forma positiva. En realidad, todo fue un mal entendido. Cuando vos escribiste: "..y la verdad que en ese contexto, los smalltalks open [1] cada día se alejan más de la posibilidad de competir en muchas cosas:"
pense que toda esa lista era comparando smalltalks open con los no-open, no contra otros lenguajes. Por eso me escribí mi respuesta. Saludos Mariano http://marianopeck.wordpress.com -- 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: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
BTW, para el ejemplo de scaffolding el equipo de DBXTalk (argentinos) fue esponsoreado para eso (incluido entre muchas otras cosas):
(see Phoseydon)
saludos,
-- 2012/11/12 Mariano Martinez Peck <[hidden email]>
Mariano http://marianopeck.wordpress.com 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: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
Muy bueno, igual yo hablaba de algo tipo ActiveRecord, no sólo a armar
las clases (que igual garpa mucho), sino a que un solo metamodelo maneje todo. Se que había una tool que integraba Magritte con GLORP, pero no se en que quedó. Pregunta: DBXtalk , Phoseydon y Neptuno en que estado están con respecto a funcionar en Pharo 1.4 o más bien 2.0 (que es la que me interesa). Saludos! Esteban A. Maringolo El día 12 de noviembre de 2012 15:09, Mariano Martinez Peck <[hidden email]> escribió: > BTW, para el ejemplo de scaffolding el equipo de DBXTalk (argentinos) fue > esponsoreado para eso (incluido entre muchas otras cosas): > > http://dbxtalk.smallworks.com.ar/tools > > (see Phoseydon) > > saludos, > > 2012/11/12 Mariano Martinez Peck <[hidden email]> >> >> >> >> 2012/11/11 Germán Arduino <[hidden email]> >>> >>> Hola Mariano: >>> >>> jaa, yo tb me quería mantener fuera, pero no le pongamos nombre >>> "discusión", es nada más que un intercambio de ideas y seguramente cada uno >>> tiene argumentos sólidos porque la situación y el contexto de cada uno es >>> diferente. >> >> >> Si, claro, discusión en forma positiva. >> En realidad, todo fue un mal entendido. Cuando vos escribiste: "..y la >> verdad que en ese contexto, los smalltalks open [1] cada día se alejan más >> de la posibilidad de competir en muchas cosas:" >> pense que toda esa lista era comparando smalltalks open con los no-open, >> no contra otros lenguajes. Por eso me escribí mi respuesta. >> Saludos >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- > 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: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
2012/11/12 Esteban A. Maringolo <[hidden email]> Muy bueno, igual yo hablaba de algo tipo ActiveRecord, no sólo a armar Bueno, Glorp tiene su paquete ActiveRecord que haría algo parecido a ActiveRecord y le pega a escondidas a Glorp. Pero (creo) nunca lo portamos a Pharo (desde VW). Habría que preguntarle a Guille...
Pregunta: DBXtalk , Phoseydon y Neptuno en que estado están con Mas bien a 1.4. No lo probé en 2.0, tal vez anda de una, no se.
Mariano http://marianopeck.wordpress.com -- 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: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
Hola:
Debería haber un fw tipo rails o django que te lo bajas desde pharo y hace todo. Integrado. Saludos GallegO
El 12 de noviembre de 2012 15:39, Mariano Martinez Peck <[hidden email]> escribió:
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: Re: [clubSmalltalk] Sobre CUIS y Pharo
|
|
que alegria me da leer este tipo de "discusion" en la lista, no por el nivel tecnico ni por los temas sino por el respeto que nos estamos teniendo al hablar lo cual es muy dificil de hacer por email.
Somos una comunidad chica y tenemos que cuidarnos y apoyarnos mas alla de las diferencias!... en fin, solo eso :-) (me levante melancoilico)
2012/11/13 GallegO <[hidden email]> Hola: Hernán Wilkinson Agile Software Development, Teaching & Coaching Phone: +54 - 011 - 6091 - 3125
Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com Address: Alem 693, Floor 5 B, Buenos Aires, Argentina 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
On 11/05/2012 12:33 PM, Andres Valloud wrote:
> Che, cuando leo este mail me salta Unhandled Exception SIGTROLL, que > sera?... http://tinyurl.com/7drk6wd > A que mail te referís? creo que mis filtros bayesianos están andando muy bien ultimanente :) fui a la página de c2.com y browsié y me encontré con esto: > What happens when filename == "a"? bueno, dado que el código de arriba está en C, eso es siempre false (0) así que supongo que si filename == "a" se termina el mundo? se escapa el gato de shrodinger? También dice muy superado que > Besides, memory should be returned in the same method where it > was asked for y muestra un ejemplo que usa malloc(), que claramente, no "devuelve" la memoria que ella misma pidió... es decir, hay excepciones, claramente. Etc, etc... De todas formas el ejemplo es más o menos bueno, también pasa si el strlen(filename) == 0. ahora, strlen()*2?! bueh, nada, chau muy buena la smalltalks -- 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
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 |
|
|
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 EstebanLM
> 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 |
|
|
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]>
To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
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 |
|
|
Yo creo que no pasa tanto por evitar el quilombo de C, sino por una
cuestión de plataforma de ejecución. Hoy en muchas soluciones cloud ya el sistema operativo no es el condicionante, sino qué ejecutas. Muchas veces no tenes la opción de correr un "programa" comun y corriente, sino que tenes que correr sobre lo que ellos proveen. En algunos casos, supongo, que no poder correr sobre JVM es como tener una app hecha para windows y querer correrla en linux. Saludos! pd: anoche probé Pharo con la VM CogDroid en my Galaxy S2 y la verdad que anda mejor que muchas cosas JavaScript que vi por ahi. Lo que si es imposible de usar con la interfaz touch, pero anda... :) Esteban A. Maringolo El día 14 de noviembre de 2012 11:11, Andres Valloud <[hidden email]> escribió: > 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 -- 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 |