Sì, bueno, al parecer estamos entre los que no tienen idea de lo que estàn hablando y los que tienen un enfoque enciclopèdico que màs bien reùnen definiciones y las encuadernan. No tiene nada de malo tener un conocimiento enciclopédico, lo único malo es que es difícil tener una discusión con una enciclopedia, ya que sabe de todo un poco, pero nada en profundidad.
No es una crítica, pero pensaba que se podía discutir respecto de estos temas, y al parecer no. O presentas las ideas ya digeridas para que el resto las consuma como si fueran televidentes o se toman como grandes provocaciones al status quo y salen con arengas que no son propias de profesionales. Si las ideas no "provocan", ¿cómo se podría pretender aprender algo? Esto al parecer se malentiende como "trolling", digo, algo de provocación debe haber, pero terminan en rencillas personales con ataques que tienen más que ver con falacias ad hominem que con argumentos vàlidos. Las ideas que presenté acá son sumamente básicas. Las reacciones son propias de fanáticos analfabetos. Yo tambièn soy fanàtico de la orientaciòn a objetos, pero no se trata de defenderla a ultranza, debes entender hasta dònde es posible aplicarla y cuando la teorìa empieza a fallar. Todos sabemos que las clasificaciones zoológicas son jerarquìas similares a las jerarquías de herencia de clases y su propòsito es hacer una clasificaciòn (por eso se llaman "clases" en vez de "tipos"), pero se encuentran con el problema del ornitorrinco que es mamìfero y pone huevos ¿bajo què rama lo ponemos?. Este ornitorrinco salìa en la tapa de un conocido libro de orientaciòn a objetos de principios de los 90's y casi como en broma este problema no era tratado en el libro, supongo que por la misma razòn que escuchamos tanto berrinche en este thread: hay gente que se espanta con las contradicciones y se les viene el mundo abajo. A todos estos les tengo una buena y una mala noticia. Buena noticia: Las contradicciones no echan el mundo abajo. Mala noticia: El mundo està lleno de contradicciones. Y el tìpico ejemplo de còmo las jerarquìas fallaban en OOP era la clase empleado con 2 sublclases: empleado temporal y secretaria, que tienen clases distintas, ya que los sueldos y los incentivos son diferentes en ambos casos y por lo tanto sus mètodos han sido overriden. ¿Què hacemos con una secretaria temporal? La respuesta en esa tiempo era usar herencia múltiple en C++, pero aprendimos dolorosamente que no hay manera de implementar la herencia múltiple de manera que no tenga defectos de implementación. Si no existe una implementación posible, el problema es de diseño y no de implementación. A nadie le gusta la crítica, eso se los aseguro, pero es desagradable que los temas no se puedan discutir, incluso si a alguien no le gustan, ya que en los proyectos la gente está principalmente enfocada a lograr los objetivos del proyecto, de modo que no tiene tiempo para discusiones "filosòficas". ¿Si no hay cabida en estos grupos, dònde hay un espacio para conversar estos temas? De todos modos en todos los proyectos hay temas desagradables y alguien debe ser capaz de manejarlos. Hay personas que rehuyen de los temas desagradables y dejan que los hagan otros. Generalmente esos son los jefes. Asì que Emilio y Esteban deben ser jefes o se estàn perdiendo. Gracias por la referencia a Dan Ingalls. En general creo que la gente que critica OOP es bastante inteligente y creo que Dan Ingalls no està aportando nada nuevo a la discusiòn, su descripciòn más bien es una defensa que alguien harìa en los años 70's, cuando Lisp y Smalltalk estaban contra C y Pascal. Supongo que històricamente su defensa de Smalltalk debe tener valor, pero ahora que OOP ha ganado y los lenguajes funcionales parece que se van a tomar el mundo, creo que no tiene mucho sentido. La principal crìtiica a OOP, o por lo menos la que a mì me hace màs sentido, es que las clases no pueden cambiar en tiempo de ejecuciòn (esto no es verdad en Smalltalk, pero si miramos el 99% de los programas escritos en Smalltalk veremos que no se crean clases en tiempo de ejecuciòn). Esto lo veo como un problema sólo cuando estás tratando de hacer cosas realmente inteligentes y entiendo que los defesores del status quo digan que eso no es del mundo real, ya que son simples consumidores de tecnología y no son capaces de crearla. Son programadores con mentalidad de usuario, el mundo para ellos es estático y los cambios les significan un problema. Mi interès es apelar a aquellos a los que el cambio les interesa y necesitan investigar cosas nuevas, como dice Alan Kay, "la mejor manera de predecir el futuro es inventarlo". Lo otro que me gustarìa aclarar es que no comparto la idea de Stepanov de que primero hay que encontrar los algoritmos genèricos y finalmente los objetos. Creo que el valor que tiene OOP es que puedo partir por lo que entiendo e ir modelando hacia lo que no entiendo (y que voy entendiendo en el camino, a medida que avanzo). Lo que sì le concedo a Stepanov es que es difìcil programar max en Java a diferencia de lo que ocurre con STL, pero aún así se puede. Lo que encuentro pobre de Stepanov es que piensa que lo importante es encontrar "algoritmos bonitos", lo que invariablemente significa encontrar código valioso del cual se enamora, ya que el resto "no es valioso". En OOP se suele escribir código desagregado, donde el algoritmo está esparcido y por lo tanto no hay un núcleo central que hace todo, sino que cada parte tiene su responsabilidad. Esto lleva a código mucho más simple y más poderoso que en el caso de STL, que desde mi punto de vista es simplemente el Visual Basic de C++, es decir, permite que programadores mediocres creen còdigo eficiente, sin entender bien lo que estàn haciendo, y mientras STL les provea lo que necesitan estàn bien, si se salen un poco de lo que STL les provee, "lo lamentamos, esa función aún no está implementada". Esto es tìpico del nivel usuario, que prefiere un mundo ordenado donde todas las respuestas estàn dadas y a la mano. Al menos desde mi punto de vista los programadores son aquellos que no están resolviendo siempre los mismos problemas, sino los que crean bibliotecas para los problemas repetidos y se enfrascan en problemas nuevos. Otra de las críticas a Smalltalk, y creo que es la crítica màs fuerte, es que no existe una formalizaciòn de lo que significa un objeto. "un objeto tiene estado y comportamiento " es una definiciòn tan vaga que no es posible razonar respecto de ella y formalismos como el modelo relacional y los lenguajes funcionales probablemente terminen desarrollando los formalismos para capturar la escencia de la programación orientada a objetos. Respecto de los principios de la orientación a objetos, éstos son la base de los patrones GoF. Entiendo que siendo este un grupo de Smalltalk no necesariamente todos pensarán que los patrones GoF son realmente algo provechoso. http://www.apwebco.com/gofpatterns/index.html Y ya que este tema parece que no tiene cabida en este grupo, ¿què les parece el tema propuesto por Paul Graham, respecto de que para tener èxito en una empresa es mejor programar bottom up que programar top down? http://www.paulgraham.com/progbot.html Saludos, Guillermo. 2008/5/8 Gabriel <[EMAIL PROTECTED]>: > Me gustaria que se dejen de lado la descalificación. La discución está por > demás interesante (por lo menos a mi me parece), no dejemos que se arruine. > > Guillermo, a mi me parece que quiza tenemos definiciones distintas de las > cosas y eso trae mas confución. Según lo que decis que leiste en ese texto > habla de que la orientación a objetos es una farsa porque las clases tienen > ciertos problemas. Por ejemplo, segun entendi el problema que nombras ahi es > que te obligan a generalizar desde el principio, es decir, creas una clase > pero todavia no tenes las instancias! entonces estas generalizando sobre > algo que no tenes idea todavia (o tenes una idea vaga). OK > En primer lugar, un ambiente de objetos no tiene por que tener clases, no > es un requisito. En un ambiente de objetos los programas se defien a partir > de OBJETOS QUE COLABORAN ENVIANDOSE MENSAJES. > Por ejemplo, Self es un ambiente de objetos sin clases, esta basado en > prototipos y delegación. Para crear un objeto se clona otro, no hay que > tener clases. > Sin embargo, independientemente de esto, no creo que el mecanismo de > subclasificación sea necesariamente tan malo como plantea ese texto. Cuando > un modelo va madurando, se pueden hacer generalizaciones y no esta mal. El > estar obligado a usar clases es quiza una incomodidad, pero no un > impedimento para hacer buenos diseños. > También hay que tener en cuenta que cuando hacemos una jerarquía, esa > jerarquía modela solo un punto de vista. Un punto de vista que nos es util > en el dominio que estamos manejando. > Cuando Aristoteles armo la primer jerarquía de los seres vivos (vertebrados > e invertebrados; peces, anfibios, reptiles, etc....) es mas que claro que > uso criterios en algún punto arbitrario para definir las diferentes clases. > Podría haberlos clasificado en función de como esta compuesto el tegido > cutaneo (mande fruta para dar un ejemplo). Pero para analizar ciertas cosas, > diferentes puntos de vista pueden ser utiles. > > Con respecto a "OOP modela adecuadamente el mundo", me parece una frase > media vaga, OOP no modela el mundo. Uno puede utilizar un ambiente de > objetos para modelar parte de un dominio, y tratar de que eso que estamos > modelando refleje lo mas posible la porcion esa de la realidad en cuestión y > eso tiene varias ventajas. En primer lugar reduce el gap semantico > http://es.wikipedia.org/wiki/Intervalo_sem%C3%A1ntico y hace que dos > personas puedan entender y comunicar mejor, por lo tanto trabajar mas en > armonia. En segundo lugar, la complejidad de tu modelo siempre va a estar > atadada a la complejidad del dominio modelado y no deberia agregar mas > complejidad (algo que sucede en otros lenguajes). > Mucha gente cree que hay que modelar la realidad hasta el mas minimo > detalle. Eso, en primer lugar es imposible. Y en segundo lugar no es > necesario. Es como decir que si yo quiero calcular el tiempo que me llevaría > llegar a Mar del Plata, tenga que modelar el comportamiento del universo > entero y tener en cuenta todos los infinitos factores. Obviamente que puedo > utilizar un modelo acotado y simplificadisimo y me va a recontra servir para > el problema que quiero resolver. De eso se trata, hagamos modelos > simplificados y acotados, pero que reflejen lo mas posible lo que estamos > modelando! > > Con respecto a lo que decia Alan Kay de que tendria que haberla llamado > orientacion a mensajes, Alan kay no se referia a eso, si no mas bien a que > el late binding es vital para la orientacion o objetos. Alan también dijo > que se sigue construyendo software como los egipcios las piramides, y se > referia a mucho de esto que estamos hablando. > > Los principios de Smalltalk estan basados en todo esto también, te dejo un > texto de Dan Ingalls, principal arquitecto de Smalltalk-80: > http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html > si tenes ganas lee principalmente la seccion "*Language*" > > Conclusión, la clasificación no es el único mecanismo para compartir > comportamiento, pero tambien es util. Se podría combinar con otros como la > delegación y prototipos para etapas mas experimentales y de descubrimiento > del dominio. > > Saludos. > Gabriel > > > > > > > > > > > > 2008/5/8 Esteban A. Maringolo <[EMAIL PROTECTED]>: > > >> 2008/5/8 Emilio Oca <[EMAIL PROTECTED]>: >> > >> > On 5/7/08, Guillermo Schwarz <[EMAIL PROTECTED]> wrote: >> > > Creoque tu ejemplo simplifica demasiado el asunto. No se trata de >> pensar en >> > > cualquier cosa. >> >> > Quizás mi error es pensar que entendés de los temas de los que hablás, >> > esta frase me deja esa duda. >> >> Nadie resiste un archivo.... >> >> < >> http://groups.google.com/group/clubSmalltalk/search?group=clubSmalltalk&q=Troll >> > >> >> >> -- >> Esteban A. Maringolo >> [EMAIL PROTECTED] >> >> >> > > > > -- 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. -~----------~----~----~----~------~----~------~--~---
