Eso queda como antes, cuando uno importaba una libreria en C en FFI. Eso queda del lado de quien consuma la libreria. Lo mismo pasa en .NET, Java o JavaScript. Consumis la libreria tal cual, o modelas encima de ella.
Puede modelar un wrapper con clases y conducta. O puede modelar un wrapper inicial, apenas un pasamanos de algunas cosas, para ir armando mas solido. A lo que voy, es que eso es perfectamente posible, y sin "importar quilombos" provocados por estar la libreria directamente en C (problemas con los tipos, punteros, ausencia de garbage collector, etc... etc...) Por supuesto, habra librerias que se necesiten en C, lo primero que se me ocurre por velocidad, como le paso a Python con paquetes cientificos/matematicos. Pero luego hay un ecosistema (en .NET, Java, Javascript) donde, por ejemplo, un driver para acceder a MongoDB, ya esta servido. Y puede servir de base para ir construyendo sobre Smalltalk, sin tener que "reinventar la rueda" cada vez. Si luego, el proyecto progresa (el proyecto Smalltalk que va sobre ese driver) se puede mejorar el wrapper, modelarlo mejor, etc... Y hasta cambiarlo por otra cosa mejor. Pero hay un mundo ahi afuera para aprovechar. Y a lo que voy, es que no veo que se siga, en el mundo Smalltalk, ese camino: implementar el lenguaje en .NET, Java. Siguen pensando en C, herendando FFI. En otras tecnologias, hay tranquilamente lenguajes nativos (CPython, Ruby), y luego reimplementaciones sobre VMs (Jython, IronPython, IronRuby, JRuby, etc..). No digo que sea un camino de rosas... lo que me asombra un poco, que pasaron los anios, y no se ha tomado ese camino en el ambiente Smalltalk. Espero que ahora haya algo de movimiento con JavaScript, aunque opino que hubiera sido mas solido y evolutivo haber pasado por .NET o Java. Y tener una Smalltalk VM popular sobre esos, open source, Redline Smalltalk en Java es una esperanza. Angel "Java" Lopez @ajlopez gh:ajlopez 2012/11/14 Carlos E. Ferro <[email protected]> > Che, cambiemos el subject porque hace rato que no hablamos de Cuis. > Disculpame, Juan, si te resta publicidad :-) > > > On 14/11/2012 11:17 a.m., Angel Java Lopez wrote: > > 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. > > > En todo esto, ¿dónde quedan las cosas de modelar un dominio, resolver > problemas, etc? > Por esto lo de inocencia en el subject... > Tal vez soy demasiado inocente, pero en nuestra modesta experiencia, > cuando usamos librerías de terceras partes de esa manera, qeudamos > obligados a volvernos expertos en librerías y comunidades. Es decir, ya > nuestro dominio no es más el que tenía nuestro cliente (¿se acuerdan del > cliente, el que nos paga y generalmente no le importa un corno en qué está > hecha la app?) y empezamos a discutir horas y horas sobre qué library hay > que usar, dónde buscar los updates, recorremos foros, leemos miles de > emails... y nuestro foco pasó a ser la tecnología, y no el dominio. > Yo quiero seguir siendo inocente, no quiero tener que navegar una hora > para ver qué switches de compilación tengo que desactivar porque "alguien > de una comunidad ya pasó por ahí y lo resolvió". Porque la solución de > "alguien de la comunidad", generalmente se reduce a la cuestión muy bien > caracterizada por Andrés: el tipo lo probó en su máquina y le anda. Cuando > en mi cliente no anda, yo me vuelvo chino... porque estoy usando una > tecnología que no entiendo y tengo que estudiarla, y no puedo usar mis > herramientas habituales para estudiar (inspector, debugger, todo lo que > conocen bien). > ¿Es demasiado inocente lo mío? Seguro. Ya tuve que romper esa regla un > montón de veces, desde cosas tan simples como querer compilar una VM de > Pharo o wrappear unas funciones de DLL de Windows (ah, cómo extraño la > vieja documentación) en nuestro ambiente. > Pero trato de despegarme lo menos posible, de tener (y leer) la > documentación y no usar consejos de "alguien de la comunidad" sobre algo > qeu no entiendo. > > Debo estar viejo... > Ya sé que todo el mundo programa así, de hecho me sorprendió mucho ver que > Germán (A) admite que él trata de pegar varias cosas y que salgan > andando... pero yo creo, e serio, que Smalltalk no es para eso. Ni debe > ser para eso. > Ahora, peguen nomás... > > Carlos "flame-warior" Ferro > > -- > > * carlos e. ferro *| senior developer* *| *caesar systems * > > [email protected] > > -- > 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
