El problema con los lenguajes orientados a objetos es que tienen todo este entorno implícito que llevan consigo. Querías un plátano, pero lo que conseguiste fue un gorila sosteniendo el plátano y toda la selva.
#3:
Te ahorro un click: otro apóstol del new age funcional.
Me quedo con el C y C++ así puedo programar con los paradigmas y herramientas que me hagan falta en cada ocasión y sin comprometer el rendimiento. Funcional, oo, templates... Lo que requiera el momento.
¿Inconveniente del c++? Que lleva tiempo y dedicación programar bien, al contrario de con los chorras lenguajes de scripts funcionales tan de moda últimamente.
#4:
Pues yo me acabo de compilar un "Hello world" en Go cuyo ejecutable solo ocupa 26 megas. Luego diréis que Go no es eficiente
Te ahorro un click: otro apóstol del new age funcional.
Me quedo con el C y C++ así puedo programar con los paradigmas y herramientas que me hagan falta en cada ocasión y sin comprometer el rendimiento. Funcional, oo, templates... Lo que requiera el momento.
¿Inconveniente del c++? Que lleva tiempo y dedicación programar bien, al contrario de con los chorras lenguajes de scripts funcionales tan de moda últimamente.
#3 Si fuese ese el unico inconveniente del C++. Como si no tuviese tiempos de compilación excesivos, una obsesion compulsiva por tener compatibilidad con C y constructos que ya nadie usa....etc
De moda por que la gente empieza a ver las ventajas de no tener side effects cuando el paralelismo ha estado al alcance de todo el mundo. El runrun funcional lleva desde el principio de los lenguages de programacion y ya hace años (facil más de 10 y 15) que popes de C/C++ alababan al paradigma funcional en general y a Haskell (p.e: Tim Sweeney) en particular.
Y los "chorras lenguages de scripts" fueron primeros en cosas que ahora incorpora el C++ como buenamente puede, como por ejemplo lambdas, expresiones constantes ...etc.
#19 Si hablas de sistemas real time o sistemas operativos vale, para todo lo demás es una perdida de tiempo, la productividad, que es lo que hace una empresa gane dinero y te pueda pagar, es mucho más alta con otros lenguajes.
De todas formas los hombres de verdad programamos en asm
#25 Estás mezclando cosas, si es difícil y hay poca gente se paga más... O no, depende de muchas cosas. Arquitectura se paga bien, Big data se paga bien y en general programadores senior en empresas buenas cobran bastante bien. Ahora saca tus conclusiones.
#24 Otros lenguajes son más fáciles de aprender y los programadores más baratos. No se cambia a un lenguaje de script por cuestiones técnicas, sólo por que es más barato.
Quien ha escrito este articulo deberia leer a wirth https://en.m.wikipedia.org/wiki/Niklaus_Wirth y tratar de entender un poco lo que es la programacion estructurada, que es la base sobre la que se construyo la OOP. Muchos de los problemas que expone, se solucionan simplemente no usando clases. Nunca he sido muy fan de la OOP, pero los problemas que describe el articulo son relativos a metodologia y no a paradigma.
#21 Eeeeexacto. Por ejemplo, el problema de la "clase frágil" es un problema de mala programación: NUNCA se debe llamar desde un método de una clase a otro método de la misma clase que sea público (y, por tanto, sobreescribible). Si programase bien y ambos métodos públicos llamasen a un método privado que sea el que añade el elemento a la lista, el problema estaría resuelto.
Lo mismo para la estructura de herencia "en diamante": para empezar, no todos los lenguajes lo permiten precisamente por ese problema que él expone (que parece que lo ha descubierto él, pero es algo que cualquiera que haya estudiado POO por encima debería conocer), y precisamente por eso se inventaron las interfaces.
Lo de que la encapsulación falla si pasas en el constructor un objeto por referencia, pues más de lo mismo. ¡También falla si pones todas las propiedades de un objeto como públicas! La solución es hacer las cosas bien: o creas ese objeto directamente en el código del constructor para que sea completamente privado, o bien te aseguras de que ese objeto que pasas soporte el paradigma del observador y te enganchas a todas las señales que te interesan para detectar cualquier cambio externo.
Lo de que la jerarquía es para contenedores ya me ha matado. Directamente no se ha enterado de nada.
Que la programación orientada a objetos no ha sido la gran revolución que prometía no lo discuto, y que es complicado la reutilización también (aunque, por cierto, la reutilización se supone que era más para "componentes", pero bueno); pero de ahí a decir que es inútil y que lo mejor que podemos hacer es abandonarla completamente me parece absurdo. Y ya no digamos justificarlo con esos argumentos "de baratillo". Lo que hay que hacer es utilizarla donde sea adecuada, y donde no, utilizar otro paradigma (benditos lenguajes multiparadigma).
Y bueno, el problema de que el contador no se incremente como él espera se soluciona si el programador de la clase padre programa con cuidado y sabe que ese método se va a redefinir. Ejemplo de como hacer eso en python y funciona perfectamente:
El título da tan en el centro de la pequeña diana que se ha ganado mi voto positivo incluso antes de que yo mismo pudiera darme cuenta 💖 💖 💖 💖 💖 💖 💖 💖 💖 💖 💖
¿Desde cuándo en este puto mundo la auténtica programación lógica tiene que ver con las estúpidas subjetividades de la mente humana orientadas a ganar dinero fácil y rápido?
Para que veáis, que este mundo no va todo de simples intuiciones....
el problema de la programación orientada a objetos no son los objetos por sí mismos (por llamarlo de alguna manera) sino que todo el soporte te viene en forma de frameworks, y si te casas con el framework se te viene con la suegra a casa y acabas condicionado a hacerlo todo como te dice el framework.
Conclusión, si te doy un cuchillo seguro que te sacas las tripas. Como si no se pudieran hacer barbaridades con la programación funcional como las que propone como "ejemplos paradigmáticos" de la programación orientada a objetos.
Comentarios
Te ahorro un click: otro apóstol del new age funcional.
Me quedo con el C y C++ así puedo programar con los paradigmas y herramientas que me hagan falta en cada ocasión y sin comprometer el rendimiento. Funcional, oo, templates... Lo que requiera el momento.
¿Inconveniente del c++? Que lleva tiempo y dedicación programar bien, al contrario de con los chorras lenguajes de scripts funcionales tan de moda últimamente.
#3 Si fuese ese el unico inconveniente del C++. Como si no tuviese tiempos de compilación excesivos, una obsesion compulsiva por tener compatibilidad con C y constructos que ya nadie usa....etc
De moda por que la gente empieza a ver las ventajas de no tener side effects cuando el paralelismo ha estado al alcance de todo el mundo. El runrun funcional lleva desde el principio de los lenguages de programacion y ya hace años (facil más de 10 y 15) que popes de C/C++ alababan al paradigma funcional en general y a Haskell (p.e: Tim Sweeney) en particular.
Y los "chorras lenguages de scripts" fueron primeros en cosas que ahora incorpora el C++ como buenamente puede, como por ejemplo lambdas, expresiones constantes ...etc.
#13 ¿ Constructos que ya nadie usa como los punteros a función?
Que atrevida es la ignorancia.
#16 constructos como compilar concatenando ficheros include añadiendo problemas extra e incrementando el tiempo que pasó en mnm.
Uhhh punteros a funciones que malote! Cuidado no te cortes un pie con el azadón.
#18 si tarda dasiado tiempo en compilar quiza lo has configurado mal. En cualquier caso ¿ Comparamos tiempos de ejecución?
#19 Si hablas de sistemas real time o sistemas operativos vale, para todo lo demás es una perdida de tiempo, la productividad, que es lo que hace una empresa gane dinero y te pueda pagar, es mucho más alta con otros lenguajes.
De todas formas los hombres de verdad programamos en asm
#24 claro, claro... Por eso los programadores de C++ con experiencia estamos tan poco cotizados en el mercado.
#25 Estás mezclando cosas, si es difícil y hay poca gente se paga más... O no, depende de muchas cosas. Arquitectura se paga bien, Big data se paga bien y en general programadores senior en empresas buenas cobran bastante bien. Ahora saca tus conclusiones.
#24 Otros lenguajes son más fáciles de aprender y los programadores más baratos. No se cambia a un lenguaje de script por cuestiones técnicas, sólo por que es más barato.
#16 Me parece que te ha dado una respuesta bastante buena y educada, no seas grosero.
Pues yo me acabo de compilar un "Hello world" en Go cuyo ejecutable solo ocupa 26 megas. Luego diréis que Go no es eficiente
#4 ¿Porque no dice que ocupa 2,6 Gigabytes el "hello world" en Go?
Total puestos a inventar...
======= CUT ========
$ go version
go version go1.11.4 linux/amd64
$ cat helloWorld.go
package main
import "fmt"
func main() ">
$ go build helloWorld.go
$ env GOOS=windows GOARCH=amd64 go build -o helloWord_win64.exe helloWorld.go
$ ls -ltra
total 3792
drwxrwxr-x 16 luser luser 4096 feb 15 20:37 ..
rwrw-r-- 1 luser luser 73 feb 15 20:38 helloWorld.gorwxrwxrx 1 luser luser 1906945 feb 15 20:39 helloWorlddrwxrwxr-x 2 luser luser 4096 feb 15 20:40 .
rwxrwxrx 1 luser luser 1958400 feb 15 20:40 helloWord_win64.exe======= CUT ========
#0 como enamorado de la programación funcional... Gracias
Yo programo con lo que me da de comer. Lo demás, son guerras religiosas.
Si puede hacerse en Fortran, hazlo en Fortran. Si no puede hacerse en Fortran, no merece la pena hacerlo.
Larga vida a la programación estructurada!
Quien ha escrito este articulo deberia leer a wirth https://en.m.wikipedia.org/wiki/Niklaus_Wirth y tratar de entender un poco lo que es la programacion estructurada, que es la base sobre la que se construyo la OOP. Muchos de los problemas que expone, se solucionan simplemente no usando clases. Nunca he sido muy fan de la OOP, pero los problemas que describe el articulo son relativos a metodologia y no a paradigma.
#21 Eeeeexacto. Por ejemplo, el problema de la "clase frágil" es un problema de mala programación: NUNCA se debe llamar desde un método de una clase a otro método de la misma clase que sea público (y, por tanto, sobreescribible). Si programase bien y ambos métodos públicos llamasen a un método privado que sea el que añade el elemento a la lista, el problema estaría resuelto.
Lo mismo para la estructura de herencia "en diamante": para empezar, no todos los lenguajes lo permiten precisamente por ese problema que él expone (que parece que lo ha descubierto él, pero es algo que cualquiera que haya estudiado POO por encima debería conocer), y precisamente por eso se inventaron las interfaces.
Lo de que la encapsulación falla si pasas en el constructor un objeto por referencia, pues más de lo mismo. ¡También falla si pones todas las propiedades de un objeto como públicas! La solución es hacer las cosas bien: o creas ese objeto directamente en el código del constructor para que sea completamente privado, o bien te aseguras de que ese objeto que pasas soporte el paradigma del observador y te enganchas a todas las señales que te interesan para detectar cualquier cambio externo.
Lo de que la jerarquía es para contenedores ya me ha matado. Directamente no se ha enterado de nada.
Que la programación orientada a objetos no ha sido la gran revolución que prometía no lo discuto, y que es complicado la reutilización también (aunque, por cierto, la reutilización se supone que era más para "componentes", pero bueno); pero de ahí a decir que es inútil y que lo mejor que podemos hacer es abandonarla completamente me parece absurdo. Y ya no digamos justificarlo con esos argumentos "de baratillo". Lo que hay que hacer es utilizarla donde sea adecuada, y donde no, utilizar otro paradigma (benditos lenguajes multiparadigma).
#28 buenos ejemplos de antipatterns https://en.m.wikipedia.org/wiki/Anti-pattern este por ejemplo https://en.m.wikipedia.org/wiki/Call_super
Y bueno, el problema de que el contador no se incremente como él espera se soluciona si el programador de la clase padre programa con cuidado y sabe que ese método se va a redefinir. Ejemplo de como hacer eso en python y funciona perfectamente:
https://pastebin.com/yqL262Bj
Otra cosa es programar de cualquier manera.
Un tío que no sabe lo que es una interface se permite el lujo de decir que la programación orientada a objetos no sirve.
¡Ole!
Yo sigo usando Lisp que es multiparadigma
#7 esa afirmación tus hay que ponerla entre paréntesis...
El título da tan en el centro de la pequeña diana que se ha ganado mi voto positivo incluso antes de que yo mismo pudiera darme cuenta 💖 💖 💖 💖 💖 💖 💖 💖 💖 💖 💖
¿Desde cuándo en este puto mundo la auténtica programación lógica tiene que ver con las estúpidas subjetividades de la mente humana orientadas a ganar dinero fácil y rápido?
Para que veáis, que este mundo no va todo de simples intuiciones....
Mi querido Basic, dónde estás?.
el problema de la programación orientada a objetos no son los objetos por sí mismos (por llamarlo de alguna manera) sino que todo el soporte te viene en forma de frameworks, y si te casas con el framework se te viene con la suegra a casa y acabas condicionado a hacerlo todo como te dice el framework.
Conclusión, si te doy un cuchillo seguro que te sacas las tripas. Como si no se pudieran hacer barbaridades con la programación funcional como las que propone como "ejemplos paradigmáticos" de la programación orientada a objetos.
Toma programación funcional
PS C:Windowssystem32> tracert www.meneame.net
#5 ¿De verdad necesitas una shell de PS para hacer un simple traceroute?
#6 la tengo por defecto en vez del cmd lo prefiero así.