Hace 5 años | Por ccguy a medium.com
Publicado hace 5 años por ccguy a medium.com

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.

Comentarios

zhensydow

#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.

ur_quan_master

#13 ¿ Constructos que ya nadie usa como los punteros a función?
Que atrevida es la ignorancia.

zhensydow

#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.

ur_quan_master

#18 si tarda dasiado tiempo en compilar quiza lo has configurado mal. En cualquier caso ¿ Comparamos tiempos de ejecución?

o

#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

ur_quan_master

#24 claro, claro... Por eso los programadores de C++ con experiencia estamos tan poco cotizados en el mercado.
lol
lol
lol

o

#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.

elkaladin

#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.

o

#16 Me parece que te ha dado una respuesta bastante buena y educada, no seas grosero.

comadrejo

#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.go
rwxrwxrx 1 luser luser 1906945 feb 15 20:39 helloWorld
drwxrwxr-x 2 luser luser 4096 feb 15 20:40 .
rwxrwxrx 1 luser luser 1958400 feb 15 20:40 helloWord_win64.exe
======= CUT ========

skaworld

#0 como enamorado de la programación funcional... Gracias

a

Yo programo con lo que me da de comer. Lo demás, son guerras religiosas.

D

Si puede hacerse en Fortran, hazlo en Fortran. Si no puede hacerse en Fortran, no merece la pena hacerlo.

Er_Pepe

Larga vida a la programación estructurada!

perro_marron

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.

D

#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).

perro_marron
D

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.

D

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!

maxxcan

Yo sigo usando Lisp que es multiparadigma

ur_quan_master

#7 esa afirmación tus hay que ponerla entre paréntesis...

D

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....

Sendas_de_Vida

Mi querido Basic, dónde estás?.

D

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.

k

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.

Jesuo

Toma programación funcional
PS C:Windowssystem32> tracert www.meneame.net

pkreuzt

#5 ¿De verdad necesitas una shell de PS para hacer un simple traceroute?

Jesuo

#6 la tengo por defecto en vez del cmd lo prefiero así.