Benefícios do OOP clássico sobre o idioma Go-like

Eu tenho pensado muito sobre design de linguagem e quais elementos seriam necessários para uma linguagem de programação "ideal", e o estudo do Google's Go me levou a questionar muitos conhecimentos comuns.

Especificamente, o Go parece ter todos os benefícios interessantes da programação orientada a objetos sem realmente ter a estrutura de uma linguagem orientada a objetos. Não há classes, apenas estruturas; não há herança de classe / estrutura - apenas incorporação de estrutura. Não há hierarquias, classes-pai ou implementações explícitas de interface. Em vez disso, as regras de conversão de tipo baseiam-se em um sistema flexível semelhante à digitação de pato, de modo que, se uma estrutura implementa os elementos necessários de um "Leitor" ou "Solicitação" ou "Codificação", é possível convertê-lo e usá-lo como um.

Existe algo sobre o OOP implementado em C ++ e Java e C # que é inerentemente mais capaz, mais sustentável, de alguma forma mais poderoso que você precisa desistir ao mudar para uma linguagem como Go? Que benefício você tem que desistir para ganhar a simplicidade que esse novo paradigma representa?

EDIT
Removida a pergunta "obsoleta" pela qual os leitores pareciam ficar excessivamente pendurados e enfurecidos.

A questão é: o que o paradigma tradicional orientado a objetos (com hierarquias e coisas semelhantes), como freqüentemente visto em implementações de linguagem comum, tem a oferecer, que não pode ser feito tão facilmente neste modelo mais simples? Ou, em outras palavras, se você fosse projetar uma linguagem hoje, existe algum motivo para incluir o conceito de hierarquias de classe?

Não há novo paradigma. A orientação a objetos é um padrão usado para escrever programas, que nem é claramente definido. Várias linguagens fornecem vários traços típicos da orientação a objetos (definição de novos tipos, encapsulamento, hierarquias de tipos, polimorfismo, passagem de mensagens e mais), mas podem falhar em fornecer outros. Nesses casos, cabe aos programadores imitá-los, se necessário.

Muitas das linguagens que fornecem esses recursos não possuem um análogo ao conceito de classe - por exemplo, Javascript e Common Lisp. A implementação fornecida por linguagens do tipo Java (baseada em classe, com herança única, interfaces, envio baseado em tipo) é apenas uma das possibilidades, e não necessariamente a melhor.

Que benefício você tem que desistir para ganhar a simplicidade que esse novo paradigma representa?

A verificação de tipo para um sistema de tipo estrutural é muito mais complexa do que simplesmente verificar se a classe base está na sua lista de herança. O despacho virtual se torna um pouco mais complicado e provavelmente com menos desempenho.

Esse sistema obsoleta o conceito de POO?

Não. Desde que você possa criar o programa em termos de 'objetos que fazem coisas', em vez de uma lista de instruções, um conjunto declarado de regras ou uma série de funções em cascata ... a implementação não importa. Da mesma forma, alterar o sistema de tipos não invalida nenhum dos princípios comuns de OO.

Você ainda pode trabalhar em um tipo base e não se importar com o tipo real. Você ainda pode estender os tipos sem modificá-los. Você ainda pode fazer um tipo fazer apenas uma coisa. Você ainda pode fornecer interfaces refinadas. Você ainda pode fornecer abstrações para seus tipos.

Como uma linguagem permite isso realmente não importa.

Eu acho que sua idéia sobre OOP está um pouco errada:

Eu inventei o termo 'Programação Orientada a Objetos' e este {Java e C ++} não é o que eu tinha em mente.
- Alan Kay .

A escolha da digitação (subtipo nominativo, subtipo estrutural ou tipagem de pato - ou uma combinação desses) é amplamente ortogonal ao POO. Herança e classes são inteiramente ortogonais ao POO. Se você dedicar algum tempo para brincar com io , verá isso.

Agora você pode perguntar que tipo de sistemas de tipos é "melhor" e quais são os meios de reutilização e combinação de códigos. E tente determinar as vantagens e desvantagens entre as opções feitas no Simula (e posteriormente executadas em C ++, Java e C #) e as feitas no Go. Mas essas são questões diferentes e distintas.

Por fim, OOP é um conceito muito vago e todas as tentativas de implementá-lo vêm em uma enorme variedade de sabores. Mas, para realmente simplificar as coisas, eu diria que a idéia central do OOP é compor sistemas de subsistemas SOLID . Agora, isso confunde absolutamente outros paradigmas, mas eu especularia que essa é a razão pela qual as linguagens multiparadigmas aumentaram em popularidade recentemente e por que o Google fez sua própria tentativa com o Go.

OOP não é obsoleto.

Como Andrea disse, existem muitos conceitos propostos como uma alternativa para as aulas (por exemplo: haskell typeclass). OOP tem um grande benefício: é ensinado em muitos lugares, e a cultura do OOP é amplamente compartilhada entre os desenvolvedores.

Isso permite uma comunicação mais rica dentro de uma equipe. Pode-se falar sobre fábricas mais facilmente do que sobre pré-promorfismos zigo-histomórficos . OOP estrutura a maneira como você organizará e se comunicará sobre seu programa com diagramas comumente usados. Este é um ativo poderoso.

Não, não há nada novo aqui, nem o OOP está obsoleto. O C ++ também possui interfaces implícitas na forma de modelos, mas as pessoas ainda usam funções virtuais. Você precisa de interfaces explícitas para lidar com, por exemplo, interfaces binárias ou interfaces em que o outro código simplesmente não é conhecido no momento da compilação.

Você poderia argumentar que este é simplesmente um caso de inferência versus afirmação explícita, que não é nada como um "novo paradigma" e realmente apenas mais conveniente.