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 <[email protected]> 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 <[email protected]>: >> 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 <[email protected]> >>> >>> > 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 [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 -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
