" 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 <[email protected]> > 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 <[email protected]>: > > 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 > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
