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