On 5/7/08, Guillermo Schwarz <[EMAIL PROTECTED]> wrote:
> Creoque tu ejemplo simplifica demasiado el asunto. No se trata de pensar en
> cualquier cosa.
>
> Pensar en objetos no es necesariamente abstraer, ya que una vez que haz
> llegado al nivel de objetos no puedes seguir abstrayendo, a menos que
> empieces a bajar en la jerarquìa de clases hasta llegar a la clase Object...
Quizás mi error es pensar que entendés de los temas de los que hablás,
esta frase me deja esa duda.
> Sí, es notable. También es notable que no lo hayas leído por ti mismo. ¿No
> existe acaso un principio que se llama DRY: Don't Repeat Yourself?
Sí, principios hay muchos, te gusta particualrmente enumerarlos. El
detalle es entenderlos y aplicarlos dentro de su contexto y semántica.
> Esto del código repetido saca roncha porque seamos honestos, la mayor parte
> de los proyectos nada en código repetido y pensamos que estamos "ok", sólo
> porque tenemos un par de objetos parados por ahí, que no son más que data
> holders.
Bueno, yo conozco todo un abanico de proyectos con gente preparada y
mas sobria al opinar que no adolece de esos problemas. Dos de las
razones son sólida formación y no pensar en código.
>
> No nos veamos la suerte entre gitanos... JA JA JA
: )
Emilio
>
> 2008/5/7 Emilio Oca <[EMAIL PROTECTED]>:
>
>
> >
> > Hola, como para insistir no mas.
> >
> > Si el objetivo fuera reducir código y desarrollar enfocados en el
> > código, que nos impide pensar y modelar enfocados en condicionales,
> > jumps y branchs, para el caso todo se reduce a eso. O mejor aun
> > pensemos en assembler.
> >
> > No, pensamos y nos enfocamos en objetos con la idea de modelar el
> > dominio del problema, de abstraernos, de desarrollar entidades
> > cercanas a los elementos con los que realmente tenemos que lidiar. No
> > código. El código es un medio, como son los jumps, como es el
> > essembler.
> >
> > Guillermo, es notable como aseguras con tanta energía que el enfoque
> > de un paradigma es ahorrar código entre otras afirmaciones, Y páginas
> > mas a bajo compartís como te asombras de entender que las librerías
> > son mas útiles cuando las concebís como un medio de abstracción y no
> > como código no repetido.
> >
> > Saludos.
> >
> > Emilio
> >
> >
> >
> >
> > On 5/7/08, Gabriel <[EMAIL PROTECTED]> wrote:
> > > Es cierto lo que decis, pero hay algo esencial que no comparto, lo
> > > importante no es REDUCIR CODIGO, lo importante es tener un modelo lo mas
> > > sencillo posible para entender, comunicar, modificar, etc. Ahi debe
> estar
> > > enfocado el problema. Naturalmente un codigo fuente que que tiene partes
> > > repetidas no pareceria ser un buen modelo. Por esto es que el hecho de
> no
> > > repetir codigo es una CONSECUENCIA de tener un buen modelo.
> > > El objetivo de programar con objetos es hacer buenos modelos.
> > > Si el objetivo de reducir codigo fuera tan importante entonces podriamos
> > > tener variables con nombres como: i, j, a, b, c, etc. lo mismo con los
> > > nombres de mensajes.
> > > Pero todos sabemos que ese no seria un buen modelo, porque seria
> > > dificultoso de comunicar, entender, modificar. Y seria dificil tambien
> ver
> > > como en ese modelo se refleja el dominio que estamos modelando.
> > >
> > > Igualmente es una opinion, no se que opinan los demas.
> > > Saludos.
> > > Gabriel
> > >
> > > 2008/5/7 Guillermo Schwarz <[EMAIL PROTECTED]>:
> > >
> > > >
> > > > 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
> > > >
> > > >
> > >
> > >
> > > >
> > >
> >
> >
> >
>
>
>
> --
> 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.
-~----------~----~----~----~------~----~------~--~---
