Beneficios de la OOP clásica sobre el lenguaje Go-like

He estado pensando mucho en el diseño del lenguaje y qué elementos serían necesarios para un lenguaje de programación "ideal", y estudiar Google's Go me ha llevado a cuestionar muchos conocimientos comunes.

Específicamente, Go parece tener todos los beneficios interesantes de la programación orientada a objetos sin tener realmente la estructura de un lenguaje orientado a objetos. No hay clases, solo estructuras; no hay herencia de clase / estructura, solo incrustación de estructura. No hay jerarquías, ni clases principales, ni implementaciones explícitas de interfaz. En cambio, las reglas de conversión de tipos se basan en un sistema suelto similar a la escritura de pato, de modo que si una estructura implementa los elementos necesarios de un "Lector" o una "Solicitud" o una "Codificación", puede emitirlo y usarlo como uno.

¿Hay algo acerca de OOP implementado en C ++ y Java y C # que es inherentemente más capaz, más fácil de mantener y de alguna manera más poderoso que tiene que renunciar al pasar a un lenguaje como Go? ¿A qué beneficio tiene que renunciar para ganar la simplicidad que representa este nuevo paradigma?

EDITAR
Se eliminó la pregunta "obsoleta" por la que los lectores parecían estar demasiado obsesionados y enfurecidos.

La pregunta es, ¿qué ofrece el paradigma tradicional orientado a objetos (con jerarquías y demás) como se ve con frecuencia en implementaciones de lenguaje común que no se puede hacer tan fácilmente en este modelo más simple? O, en otras palabras, si diseñara un lenguaje hoy, ¿hay alguna razón por la que quiera incluir el concepto de jerarquías de clases?

No hay un nuevo paradigma. La orientación a objetos es un patrón que utiliza para escribir programas, que ni siquiera está claramente definido. Varios lenguajes proporcionan diversos rasgos típicos de la orientación a objetos (definición de nuevos tipos, encapsulación, jerarquías de tipos, polimorfismo, transmisión de mensajes y más), pero pueden no proporcionar otros. En esos casos, corresponde a los programadores emularlos si surge la necesidad.

Muchos de los lenguajes que proporcionan estas características no tienen un análogo del concepto de clase, por ejemplo, Javascript y Common Lisp. La implementación proporcionada por lenguajes similares a Java (basados ​​en clases, con herencia única, interfaces, despacho basado en tipos) es solo una de las posibilidades, y no necesariamente la mejor.

¿A qué beneficio tiene que renunciar para ganar la simplicidad que representa este nuevo paradigma?

La verificación de tipo para un sistema de tipo estructural es mucho más compleja que simplemente verificar si la clase base está en su lista de herencia. El despacho virtual se vuelve un poco más complicado y probablemente menos eficiente.

¿Un sistema de este tipo deja obsoleto el concepto de OOP?

No. Siempre que pueda hacer el programa en términos de 'objetos que hacen cosas' en lugar de una lista de instrucciones, o un conjunto declarado de reglas, o una serie de funciones en cascada ... la implementación no importa. Del mismo modo, cambiar el sistema de tipos no invalida ninguno de los principios comunes de OO.

Todavía puede trabajar en un tipo base y no preocuparse por su tipo real. Todavía puede extender los tipos sin modificarlos. Todavía puede hacer que un tipo haga solo una cosa. Todavía puede suministrar interfaces de grano fino. Todavía puede proporcionar abstracciones a sus tipos.

Cómo lo permite un idioma eso realmente no importa.

Creo que su idea acerca de OOP está un poco fuera de lugar:

Inventé el término 'Programación Orientada a Objetos' y esto {Java y C ++} no es lo que tenía en mente.
- Alan Kay .

La elección de la tipificación (subtipificación nominativa, subtipificación estructural o tipificación de pato, o una combinación de ellas) es en gran medida ortogonal a la POO. La herencia y las clases son completamente ortogonales a OOP. Si te tomas un tiempo para jugar con io , verás eso.

Ahora puede preguntar qué tipo de sistemas de tipos son "mejores", y qué medios de reutilización y combinación de códigos lo son. E intente determinar las ventajas y los inconvenientes entre las elecciones realizadas en Simula (y luego en C ++, Java y C #) y las realizadas en Go. Pero todas estas son preguntas diferentes y distintas.

En última instancia, OOP es un concepto muy vago y todos los intentos de implementarlo vienen en una gran variedad de sabores. Pero para simplificar realmente las cosas, diría que la idea central de OOP es componer sistemas de subsistemas SOLIDOS . Ahora, esto desdibuja absolutamente la línea de otros paradigmas, pero especularía que esa es la razón por la cual los lenguajes de paradigmas múltiples han aumentado su popularidad recientemente y por qué Google ha tomado su propia oportunidad con Go.

OOP no es obsoleto.

Como dijo Andrea, se han propuesto muchos conceptos como alternativa a las clases (por ejemplo: clase de tipo haskell). OOP tiene un gran beneficio: se enseña en muchos lugares, y la cultura de OOP se comparte en gran medida entre los desarrolladores.

Esto permite una comunicación más rica dentro de un equipo. Se puede hablar de fábricas más fácilmente que de prepromorfismos zygohistomórficos . OOP estructura la forma en que organizará y se comunicará acerca de su programa con diagramas de uso común. Este es un activo poderoso.

No, no hay nada nuevo aquí, ni la POO está obsoleta. C ++ también tiene interfaces implícitas en forma de plantillas, pero las personas aún usan funciones virtuales. Necesita interfaces explícitas para hacer frente, por ejemplo, interfaces binarias o interfaces donde el otro código simplemente no se conoce en tiempo de compilación.

Se podría argumentar que esto es simplemente un caso de inferencia frente a afirmarlo explícitamente, que no se parece en nada a un "nuevo paradigma" y realmente es más conveniente.