Cita:
Empezado por Ñuño Martínez
De la propia definición de objeto... La comunicación entre objetos se realiza (por definición) mediante mensajes y estos (por definición) no revelan los detalles de su implementación, de hecho no tienen por qué ser respondidos de forma síncrona.
|
Ah, la definición del que invento la OO!
http://programmers.stackexchange.com...bject-oriented
Un paradigma que cumple mas de cerca esa definición es el modelo de actor:
https://en.wikipedia.org/wiki/Actor_model
Cita:
Empezado por Ñuño Martínez
Discrepo, y mucho. Personalmente me cuesta horrores hacerme una idea de cómo funcionan los programas Python .... En serio, en cuanto se meten en algo más complicado que obtener un dato y darle salida, me parece incluso más caótico que un mal programa escrito en PHP.
|
Eso si suena raro! Se que muchos detestan la identacion (significativa) pero decir que python no es legible? Mas cerca del pseudocodigo no hay. Que ejemplo podrías dar? Que es un ejemplo de algo legible?. De mas esta decir que los lenguajes que considero legibles (pascal, python, fox) tienen un aspecto de "bloques" que me parece muy intuitivo (y recuerdo que en el libro
Code Complete había un estudio al respecto, de como ese estilo identado era mas claro). Aunque viendo que hay gente que le parece legible los lenguajes basados en LISP....
Lo que no me gusta de python es no poder darle los tipos a las variables. Cuando se ve una
funcion read(name) no se puede deducir que pide y que devuelve y el compilador no te ayuda. Creo que el balance ideal es que el lenguaje sea tipado y permita escapar a dinámico, por ejemplo:
http://cobra-language.com/. Me imagino que si se hace Customer.Name es tipado pero si se hace Customer..Name es dinámico.
Una de las cosas que le saco a python, es que no importa que código de quien este leyendo, todo parece escrito por la misma persona. Eso es algo que es difícil de encontrar en otros lenguajes.
------
Ultimamente están saliendo muchas cosas interesantes. Por ejemplo están
http://julialang.org/ y
http://nimrod-lang.org/. También, corriendo sobre erlang,
http://elixir-lang.org/. Pero en cuanto a la OO, creo que me inclino mas por el
modelo de GO.
Eso porque luego de todo este tiempo, me he dado cuenta que una jerarquía de clases tiende a ser la abstracción
equivocada y el rehusó es mas problemático. Aparte, que cuando se entiende el propósito original de la OO de Alan y como se implementa el modelo de Actor se hace evidente (en mi opinión) que un programa se debe hacer mediante composición y se usan objetos para encapsular sub-procesos.
Digo que es equivocada porque es muy difícil de descomponer una jerarquía de clases, y recomponer funcionalidad para crear nuevos objetos. Por ejemplo, si se hace un control visual, digamos un listado para agenda de contactos, de donde derivo todo? Si lo saco de un grid me cargo del grid lo que no quiero (y es la abstracción errónea) y si lo saco de una lista lo mismo, no tengo lo que ya tiene el grid, y no es fácil hacer tipo "virtual", así que toca hacer casi todo desde cero. Con la composición no es así, es igual a hacer programación funcional -pero tipo OO- en donde si quieres algo combinas funciones hasta lograrlo, pero igual puedes obtener el pedacito que necesitas sin cargarte toda una jerarquía detrás...