Hola Abel, Me perdì con tanta respuesta a este thread y revisàndolo me di cuenta que tenìa unas respuestas pendientes.
Esto de los objetos biològicos se debe a que el inventor de Smalltalk, Alan Kay, estudiò biología molecular y por eso según él tiene este "bias" de mirar el mundo como un sistema de objetos independientes que se comunican a través de mensajes químicos, entonces viendo el trabajo que habían hecho en Simula le sirvió de inspiración para crear un lenguaje en el que no existiera otro mecanismo que objetos y mensajes entre ellos. Acà está su biografía para los que quieran corroborar lo que he escrito: http://ei.cs.vt.edu/~history/GASCH.KAY.HTML Eso de reducir el código repetido en realidad es algo fundamental, mucho más fundamental que la orientación a objetos, primero porque la precede en el forma de la creación de subrutinas en FORTRAN, y además porque otros mecanismos más avanzados como AOP y Traits, que escapan de las "cadenas" de las jerarquías de clases, también siguen el mismo principio de eliminar el código repetido. Si haces un análisis del código repetido de un proyecto cualquiera verás que entre el 10% y el 70% del código es código repetido. Si lo pudiéramos eliminar los proyectos serían mucho más económicamente rentables y además el costo de mantención disminuiría, sin mencionar que además la calidad del código fuente subiría sólo por el hecho de que habría menos defectos, y sería más fácil solucionarlos. Respecto de crear prototipos, esa es la tìpica solución para guardar "estado" en la clase factory, donde el factory es realmente un objeto del mismo tipo que simplemente se clona. Es interesante para ambientes gráficos en los que quieres que el usuario sea capaz de crear sus propios tipos de objetos (algo así como un GUI painter en el que el usuario pueda definir sus nuevos elementos gráficos, Smalltalk Express tenía algo así, y escrito en muy pocas líneas de código). De esto estamos hablando que era del año 1996, estamos en el 2008, 12 años después, y aún no veo nada parecido en Java (bueno excepto un framework que estoy desarrollando parecido a Seaside pero en Java). Tmabièn existen lenguajes prototìpicos en los que no existe la herencia sino que el ùnico mecanismo para crear nuevos objetos es sacar una copia de los anteriores, irlos modificando (agregando mètodos por ejemplo) y leugo volver a sacar copia. Me parece que Smalltalk està pintado para hacer eso. Respecto de la pregunta que hace gallego, no he tenido la suerte de trabajar sólo con traits. En general lo que me detiene es que se tenga que crear un lenguaje especial para trabajar con traits, prefiero usar una biblioteca, pero no sólo eso, además se debe encontrar un problema en el que no baste con Proxy sino que además sea necesario usar Traits, pero desafortunadamente los proyectos en los que he participado son demasiado fáciles. Eso es bueno y es malo. Es malo porque no hay proyectos lo suficientemente desafiantes como para aprender nuevas tecnologìas (a menos que SOA y activemq sean considerados "nuevos", a mi parecer no son más que los mismos viejos lobos con disfraz de nuevas ovejas), pero por otro lado me parece que es bueno porque significa que si aprendes Traits tendràs una oportunidad de hacefr negocio en las tecnologías que se vienen. Uno de los temas que me parece interesante es la integración de las tecnologías de bases de datos relacionales y la orientación a objetos. En particular hay papers y publicaciones en general de Codd y Date que critican duramente a SQL, que como lenguaje deja mucho que desear. Me parece que esa crítica está revelando una oportunidad. Por otro lado la integración de tecnologías de orientación a objetos con SQL da entre risa y pena, pretende resolver que los programadores escriban tanto SQL (como Hibernate por ejemplo), pero la integración es increíblemente pobre. Me da la impresiòn que ambos problemas estàn relacionados y que se podrìa construir un modelo mucho más coherente y eficiente (tengo rudimentos ya implementados), de modo que no haya que darse tantas vueltas para implementar el modelo de base de datos y realizar los mappings. de hecho, creo que lo importante es tener claridad respecto de què se està modelando, el resto debiera deducirse automàticamente, hasta las pantallas deberìan deducirse autmàticamente a partir del modelo, y no deberìa ser necesario utilizar generadores de còdigo, sino que tener una biblioteca pequeña de unos 10 KLOC y una descripciòn del sistema de unas 500 LOC y todo el resto deberìan ser datos. Hasta donde he podido llegar el sistema es increíblemente eficiente y fácil de implementar. El único problema es que necesito gente que le interese y que tenga tiempo disponible. Bueno aparte de eso, hacerlo en Smalltalk me parece riesgoso, ya que depende del vendor si tu producto corre o no, mientras que en Java lo he probado en todos los app servers a los que he tenido acceso y corre igualito. Creo que eso es importante. Migrarlo a Smaltalk luego sería fácil, pero al revés no me parece que sea cierto. Mi inspiración en esto es la biblioteca curses en C++. Esa biblioteca podái manejar cientos de terminales difrentes de manera muy eficiente. Cuando empezamos a tener problemas de desemepeño se nos ocurrió reimplementr curses. Al principio tuvimos mucho éxito, pero luego en la medida que nuestra biblioteca fue creciendo, curses nos empezó a ganar. ¡Sorpresa! La razón es que curses era de alto nivel, de modo que aunque ciertas operaciones no eran lo más eficientemente posible, aún así, las optimizaciones de alto nivel que tenía la hacían más eficiente en una aplicación con suficiente operaciones a nivel de pantalla, al mismo tiempo que estaba garantizado que podría manejar montones de pantallas diferentes, incluso nuevas si salían a pesar que ya no salían y casi todas las que habían se habían estandarizado en 2: ansi y vt100. Pues bien, el resultado es que nos dimos cuenta que curses era una capa de abstracción respecto de los temrinales que terminaba siendo más eficiente. Es es contra intuitivo, pero los hechos son más importantes que las intuiciones. Y empezamos a mirar más nuestras bibliotecas como capas de abstracción y negándonos a dejar que se transparentara la implementación. El resultado fue que pudimos colocar optimizaciones que de otra manera no hubiéramos podido. Y raya para la suma, las capas de abstracción se podían poner una sobre otra haciendo que el sistema fuera mucho más eficiente de lo que hibiera sido si hubiéramos dejado que se transparentara la implementación, sin ademàs mencionar que necesariamente tenáimos menos defectos porque al crear la capa de abstracción estábamos efectivamente logrando que en caso de que el diseño interno tuviera defectos se puediera cambiar sin afectar a los usuarios de la biblioteca, el resultado fue mejor por lo tanto no sólo desde el punto de vista del desemepeño, sino además desde el punto de vista de la calidad. saludos, Guillermo. 2008/4/25 Abel Armoa <[EMAIL PROTECTED]>: > Hola Guillermo: > No entendí qué querés decir con "creación de objetos biológicos". ¿Qué son > los objetos biológicos? > En cuanto a que la idea de la orientación a objetos como reducción de > código repetido a través de jerarquías de clases, no estoy de acuerdo. Me > parece que el hecho de evitar la repetición de código es mejor verlo como > una consecuencia, y no como parte del corazón de la orientación a objetos. > Por otra parte, hacés referencia a jerarquías de clases, sin embargo creo > que es posible trabajar con objetos en ambientes de prototipación, donde no > tendrías las jerarquías de clases en primera instancia. En este caso, según > la segunda definición, no estaríamos hablando de orientación a objetos, > cuando en realidad sí entran dentro de la categoría. > > Saludos, > Abel Armoa > > 2008/4/25 Guillermo Schwarz <[EMAIL PROTECTED]>: > > La idea de la orientaciòn a objetos se puede ver como la creaciòn de > > objetos biológicos (de ahí su nombre, no muy apropiado por cierto, por parte > > de Alan Kay que fue el inventor del término y que estudió biología > > molecular), pero además se puede ver como la reducción del código repetido a > > través de las jerarquías de clases. > > > > Acà hay un ejemplo de Traits y cómo se puede eliminar la repetición de > > las colecciones en Smalltalk: > > http://portal.acm.org/citation.cfm?doid=949305.949311 > > > > "La" explicación de Traits: > > http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf en > > Smalltalk. > > > > Saludos, > > Guillermo. > > > > 2008/4/23 Jose Gregoris <[EMAIL PROTECTED]>: > > > > Hola gente. > > > > > > Perdon que me meta en la charla, pero no entendí esto: > > > > > > * He leìdo de proyectos que estàn tratando de programar todo con > > > Traits (muy parecido a los Mixins), pero en vez de usar herencia para > > > resolver los comportamientos similares, encadenan Traits. Al parecer la > > > desilusiòn de las jerarquìas de clases nos ha llevado a esto, lo que hace > > > que los lenguajes sean cada vez màs dinámicos, ya que en tiempode > > > ejecución > > > se podría agregar un trait a un objeto sin necesidad de instanciarlo de > > > nuevo > > > *,* mientras que con las jerarquìas de clases hay que recompilarlo > > > todo. > > > * > > > Sobre todo lo de recompilar todo, se refieren a ST o ( JAVA C#) > > > Saludos kiko > > > > > > > > > *Guillermo Schwarz <[EMAIL PROTECTED]>* escribió: > > > > > > El mayor problema que tienen tanto Java como C# es que tienen early > > > binding en vez de late binding, es decir, se trata de resolver todo en > > > tiempo de compilaciòn, de modo que el truco del #doesNotUnderstand no es > > > practicable ni en Java ni en C# (ok, todos sabemos que sì tienen late > > > binding, pero es menos late que en el caso de Smalltalk). > > > > > > Sin embargo en Java desde la versiòn 1.3 existen los dynamic proxies > > > que vienen a hacer lo mismo pero con tipos estàticos. Ahora bien, la > > > cantidad de lìneas de còdigo para hacer lo mismo bordea las 70 lìneas de > > > código dependiendo de còmo se cuente, es decir unas 10 veces màs. Sin > > > embargo considero que eso no es lo impresionante si despuès de todo eso se > > > meterà dentro de una biblioteca, de modo que da lo mismo la cantidad de > > > lìneas de còdigo, lo impresionante es el còdigo resultante con que queda > > > la > > > aplicaciòn, que al tener proxies dinàmicos permite asociaciones en tiempo > > > de > > > ejecuciòn. > > > > > > El truco surgiò inicialmente en Smalltalk como el patròn de diseño > > > llamado Proxy. Luego se concirtiò en Mixins para simular herencia > > > múltiple. > > > Luego se convirtió en AOP que finalmente es lo mismo. > > > > > > He leìdo de proyectos que estàn tratando de programar todo con Traits > > > (muy parecido a los Mixins), pero en vez de usar herencia para resolver > > > los > > > comportamientos similares, encadenan Traits. Al parecer la desilusiòn de > > > las > > > jerarquìas de clases nos ha llevado a esto, lo que hace que los lenguajes > > > sean cada vez màs dinámicos, ya que en tiempode ejecución se podría > > > agregar > > > un trait a un objeto sin necesidad de instanciarlo de nuevo, mientras que > > > con las jerarquìas de clases hay que recompilarlo todo. > > > > > > Saludos, > > > Guillermo. > > > > > > 2008/4/21 GallegO <[EMAIL PROTECTED]>: > > > > > > > > > > > Hola Bruno: > > > > > > > > Bruno Buzzi Brassesco escribió: > > > > > > > > > > Discutiendo con un amigo que decía que Smalltalk no tenia herencia > > > > > múltiple. > > > > > > > > > > Aunque sea discutible la necesidad de herencia múltiple, me > > > > pregunte > > > > > cuan rápido se podrá implementar herencia múltiple en Smalltalk y > > > > > poner a prueba su flexibilidad. > > > > > > > > > > En "7 líneas de código" o 5 minutos ... hice esto: > > > > > > > > > > Se puede discutir sobre la validez de la implementación (la > > > > variable # > > > > > superinstances y sus implicaciones) pero NO es el punto central. > > > > > > > > > > Lo central es que si en 5 minutos se puede hacer esto, que será > > > > > después de estar un año trabajando sobre un tema... > > > > > > > > > > Implementa algo así en C# (u otro) valor!!! > > > > > > > > > Muy bueno! > > > > Se llega a resultados sorprendentes. Lo que no entiendo es porque en > > > > C# > > > > no se podría hacer lo mismo. Me gustaría que me explicaras los > > > > motivos > > > > (por los cuales no se puede) ya que eso que mostraste es muy simple. > > > > > > > > Saludos > > > > GallegO > > > > > > > > > > > > > > > > > > > > > -- > > > Saludos cordiales, > > > > > > Guillermo Schwarz > > > Sun Certified Enterprise Architect > > > ------------------------------ > > > > > > Yahoo! Encuentros > > > Ahora encontrar pareja es mucho más fácil, probá el nuevo Yahoo! > > > Encuentros. > > > Visitá http://yahoo.cupidovirtual.com/servlet/NewRegistration > > > > > > > > > > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect --~--~---------~--~----~------------~-------~--~----~ Has recibido este mensaje porque estás suscrito a Grupo "ClubSmalltalk" de Grupos de Google. Si quieres publicar en este grupo, envía un mensaje de correo electrónico a [email protected] Para anular la suscripción a este grupo, envía un mensaje a [EMAIL PROTECTED] Para obtener más opciones, visita este grupo en http://groups.google.com/group/clubSmalltalk?hl=es. -~----------~----~----~----~------~----~------~--~---
