Portada
mis comunidades
otras secciones
#6:
En general la argumentación es bastante poco sólida. El resumen es: "No me gusta la filosofía orientada a objetos". Pos fale, campeón ya sabemos tu opinión.
Casi me hace dudar un microsegundo con el argumento de que tienes todos los tipos definidos en un fichero y a continuación pensé en los ficheros .h infumables, cientos, miles de ellos... Perdone usted, señor, pero si usted quiere algunos objetos en un sitio concreto, métalos en un paquete
Casi me hace dudar un microsegundo con el argumento de que tienes todos los tipos definidos en un fichero y a continuación pensé en los ficheros .h infumables, cientos, miles de ellos... Perdone usted, señor, pero si usted quiere algunos objetos en un sitio concreto, métalos en un paquete
#1:
No sabía si traducir 'sucks' por 'apesta' o 'es una mierda'. Me decidí por lo segundo. Seguramente para llamar más la atención 
.
.
#10:
Vaya forma de llorar.
Todo lo que plantea se puede solucionar mediante objetos.
1. Datos y metodos no deben juntarse.
Seguro?
Quiza se esta confundiendo de objeto y deberia hacer un refactor para dividirlo.
2. Todo tiene que ser objetos
Y por que no? La realidad es que todo son objetos.
3. En lenguajes de objetos, los datos se definen por todas partes
Se definen donde hay que definirlos. Si estan por todas partes (y no tiene sentido) es que el diseño es erroneo.
4. Los metodos y propiedades tiene un "scope"
Es una buena manera de evitar debugs epicos. Cualquier dato erroneo en un objeto se puede acotar dentro de su "scope". Si no existieran, habria programadores que modificarian propiedades desde todos los rincones de la aplicacion. Hay que poner el filtro en alguna parte.
Supongo que por crear el Erlang sera una autoridad, pero parece un lloriqueo de principiante. No veo sentido a nada de lo que dice.
Todo lo que plantea se puede solucionar mediante objetos.
1. Datos y metodos no deben juntarse.
Seguro?
Quiza se esta confundiendo de objeto y deberia hacer un refactor para dividirlo.
2. Todo tiene que ser objetos
Y por que no? La realidad es que todo son objetos.
3. En lenguajes de objetos, los datos se definen por todas partes
Se definen donde hay que definirlos. Si estan por todas partes (y no tiene sentido) es que el diseño es erroneo.
4. Los metodos y propiedades tiene un "scope"
Es una buena manera de evitar debugs epicos. Cualquier dato erroneo en un objeto se puede acotar dentro de su "scope". Si no existieran, habria programadores que modificarian propiedades desde todos los rincones de la aplicacion. Hay que poner el filtro en alguna parte.
Supongo que por crear el Erlang sera una autoridad, pero parece un lloriqueo de principiante. No veo sentido a nada de lo que dice.
Comentarios
No sabía si traducir 'sucks' por 'apesta' o 'es una mierda'. Me decidí por lo segundo. Seguramente para llamar más la atención
.
#1
Es equivalente
#2 Bueno, la mierda ciertamente apesta, pero no todo lo que apesta es mierda.
En general la argumentación es bastante poco sólida. El resumen es: "No me gusta la filosofía orientada a objetos". Pos fale, campeón ya sabemos tu opinión.
Casi me hace dudar un microsegundo con el argumento de que tienes todos los tipos definidos en un fichero y a continuación pensé en los ficheros .h infumables, cientos, miles de ellos... Perdone usted, señor, pero si usted quiere algunos objetos en un sitio concreto, métalos en un paquete
#6 No lo he criticado demasiado por que hay cosillas que no estoy muy seguro de si las he entendido bien pero en líneas generales ninguno de los puntos me parece un argumento sólido... Tampoco propone alternativas que solucionen los problemas que la POO soluciona con facilidad...
Vaya forma de llorar.
Todo lo que plantea se puede solucionar mediante objetos.
1. Datos y metodos no deben juntarse.
Seguro?
Quiza se esta confundiendo de objeto y deberia hacer un refactor para dividirlo.
2. Todo tiene que ser objetos
Y por que no? La realidad es que todo son objetos.
3. En lenguajes de objetos, los datos se definen por todas partes
Se definen donde hay que definirlos. Si estan por todas partes (y no tiene sentido) es que el diseño es erroneo.
4. Los metodos y propiedades tiene un "scope"
Es una buena manera de evitar debugs epicos. Cualquier dato erroneo en un objeto se puede acotar dentro de su "scope". Si no existieran, habria programadores que modificarian propiedades desde todos los rincones de la aplicacion. Hay que poner el filtro en alguna parte.
Supongo que por crear el Erlang sera una autoridad, pero parece un lloriqueo de principiante. No veo sentido a nada de lo que dice.
#10 Añadiría que todo lo que aporta un lenguaje OOP ya existía antes, sólo que antes se lo tenía que currar el programador (con bastantes limitaciones). A partir de los OOP es el compilador el que da las facilidades para estructurar mejor el código.
Aquí una respuesta (en Inglés también): http://www.librador.com/2012/07/16/No-thats-not-why-OO-sucks/
A ver si me aclaro, ¿Como las funciones y los datos son diferentes deben ir separados por que si? No me parece un argumento muy potente...
Cuando empecé con la OOP la principal razón era que el compilador debía encargarse de ciertos trabajos que antes hacía el programador. Por ejemplo, hacer que el compilador se encargara del polimorfismo, en vez de estar haciendo tu funciones identicas incluyendo el nombre del tipo de dato en el de la función (ie: save_customer(&customer)).
También se intentaba evitar el rippling, es decir que el cambio en un aspecto del código no afectara a otras partes del programa.
Encapsular la complejidad (ie: dame_saldo() y no preguntes cómo)
Hay muchas otras necesidades de este tipo que no se mencionan en el artículo. Supongo que Erlang habrá dado su respuesta, pero me parece estúpido lo que dice Armstong y es la típica impostura para ser más escuchado.
#15 Precisamente dice que no encuentra evidencias de las razones 1 y 2, no dice que sean malas, dice que no están demostradas.
#9 Que algunos lenguajes no acepten el polimorfismo no significa que sea un invento de la OOP.
La programación funcional acepta polimorfismo de un modo más natural (desde mi punto de vista) que cualquier programación imperativa, por ejemplo.
Además, lo del encapsulamiento tampoco lo considero propio de la orientación a objetos, es casi la base del diseño descendiente (programación modular) que para mí incluye la orientación a objetos pero no se restringe a ella.
Dicho esto, considero como casi todos los comentarios de este meneo, que al Amstrong se le va la olla y que la orientación a objetos tiene ventajas. Yo la usaba sin problemas.
#16 Pues para no decir nada, titulando el artículo como OOP apesta..mejor se calla no? Esta persona no le hace falta demostrar nada, y Erlang no tiene "competencia" dentro de su sector.
#16 Precisamente es lo que digo; y que como los lenguajes no lo soportaban era el programador el que lo apañaba. Una función como save_customer, está haciendo name-mangling a pelo.
Este y el Torlvalds deben hacer buenas migas
Por qué OO fué popular:
Razón 1 - Fué sencillo de aprender.
Y ésto que tiene de malo? Un paradigma tiene que ser hiper-complejo para que se considere serio?.
Razón 2 - Se pensó para hacer el código reusable fácilmente.
Más de lo mismo. Para qué reescribir cosas innecesarias?
Razón 3 - Estuvo hype-ado.
Aquí hablas de Java más que de la OO en general.
Razón 4 - Creó una nueva industria del software.
Ejem....
Con mis respetos hacia Amstrong y Erlang, es una trolleada como una casa sin fundamentos reales. Se nota que no ha programado en Smalltalk. Le podrá gustar más o menos, pero de ahí a decir que apesta con esos fundamentos.... Si nos ponemos así, entonces, bajo sus criterios, ¿por qué no hay ERPs en Erlang?, que sí, que posible es, pero productivo?
Es como la eterna discusión que he tenido con un montón de gente. "Es que C/C++ es lo mejor y más potente, y Object Pascal es una mierda" ... ¿Y por qué en un proyecto en el que debo centrarme (porque es lo realmente importante) en la lógica de negocio, debo de preocuparme de ciertos aspectos que en C/C++ debes preocuparte, y que no tienen nada que ver precisamente con la lógica de negocio?
En todo caso se debería decir que la OOP apesta, en ciertos entornos donde otros paradigmas encajan mejor, pero no de manera tan general. Erlang no es precisamente tampoco la solución a todos los problemas.
No sé, él sabrá...en fin....
Quizás se refiere a su abuso, por ejemplo:
Galaxia.Sistema_Solar.Tierra.España.Mi_ciudad.Mi_casa.Mi_cocina.Mi_sandia.
Con lo fácil que es decir:
Mi_sandia...
#12 Si pero las jerarquías pueden ser muy útiles, como muchas otras cosas de la POO, se ahorra código, problemas, y se logra un nivel de abstracción muy útil. Por ejemplo en tu caso ¿qué pasa cuando quieres saber cuántas frutas hay en Mi_cocina? Sin objetos tienes que hacer la cuenta de forma externa.
Vaya pérdida de tiempo leerme eso. Para ser creador de un lenguaje no profundiza nada de nada.
Titular alternativo: ¿Por qué no programa ni Dios en Erlang?
En ese caso, si, pero si mi programa no va a necesitar recuento de fruta, no debería ser obligatorio crear un objeto, así va de maravilla...
este es el eterno flame, como el tipico windows vs linux vs mac
hacia tiempo que no veia tantas tonterias juntas...
si parece ser que lo único algo interesante de su lenguaje es la gestión de hilos, es decir, algo totalmente independiente de que sea lenguaje secuencial o no...