"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 <[email protected]>

> Hace backtracking, esta en el parrafo anterior.
>
> 2012/11/14 Guillermo Schwarz <[email protected]>:
> > " 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
>
> --
> 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

Responder a