Vantaggi del linguaggio OOP classico rispetto a quello Go-like

Ho riflettuto molto sul design del linguaggio e su quali elementi sarebbero necessari per un linguaggio di programmazione "ideale", e studiare Go di Google mi ha portato a mettere in discussione molte conoscenze altrimenti comuni.

In particolare, Go sembra avere tutti i vantaggi interessanti della programmazione orientata agli oggetti senza avere effettivamente la struttura di un linguaggio orientato agli oggetti. Non ci sono classi, solo strutture; non esiste eredità di classe / struttura, ma solo incorporamento della struttura. Non ci sono gerarchie, nessuna classe genitore, nessuna implementazione esplicita dell'interfaccia. Invece, le regole di cast del tipo si basano su un sistema libero simile alla "duck-typing", in modo tale che se una struttura implementa gli elementi necessari di un "Reader" o una "Richiesta" o una "Codifica", allora puoi lanciarla e usarla come una.

C'è qualcosa in OOP implementato in C ++ e Java e C # che è intrinsecamente più capace, più gestibile, in qualche modo più potente che devi rinunciare quando ti sposti in un linguaggio come Go? Che vantaggio hai a rinunciare per ottenere la semplicità che questo nuovo paradigma rappresenta?

EDIT
Rimossa la domanda "obsoleta" su cui i lettori sembravano eccessivamente aggrappati e infuriati.

La domanda è: che cosa offre il tradizionale paradigma orientato agli oggetti (con gerarchie e simili) come spesso visto nelle implementazioni del linguaggio comune che non può essere fatto così facilmente in questo modello più semplice? O, in altre parole, se dovessi progettare una lingua oggi, c'è un motivo per cui vorresti includere il concetto di gerarchie di classi?

Non esiste un nuovo paradigma. L'orientamento agli oggetti è un modello che usi per scrivere programmi, che non è nemmeno chiaramente definito. Vari linguaggi forniscono vari tratti tipici dell'orientamento agli oggetti (definizione di nuovi tipi, incapsulamento, gerarchie di tipi, polimorfismo, passaggio di messaggi e altro) ma potrebbero non fornire altri. In questi casi spetta ai programmatori emularli in caso di necessità.

Molti dei linguaggi che forniscono queste funzionalità non hanno un analogo del concetto di classe, ad esempio Javascript e Common Lisp. L'implementazione fornita da linguaggi simili a Java (basati su classi, con singola eredità, interfacce, invio basato sui tipi) è solo una delle possibilità e non necessariamente la migliore.

Che vantaggio hai a rinunciare per ottenere la semplicità che questo nuovo paradigma rappresenta?

Il controllo del tipo per un sistema di tipo strutturale è molto più complesso del semplice controllo se la baseclass si trova nell'elenco di ereditarietà. L'invio virtuale diventa un po 'più complicato e probabilmente meno performante.

Un sistema del genere obsoleta il concetto di OOP?

No. Fintanto che puoi creare il programma in termini di "oggetti che fanno cose" piuttosto che un elenco di istruzioni, un insieme dichiarato di regole o una serie di funzioni a cascata ... l'implementazione non ha importanza. Allo stesso modo, la modifica del sistema di tipi non invalida nessuno dei principi OO comuni.

Puoi ancora lavorare su un tipo di base e non preoccuparti del suo tipo effettivo. Puoi comunque estendere i tipi senza modificarli. Puoi ancora fare in modo che un tipo faccia solo una cosa. È ancora possibile fornire interfacce a grana fine. Puoi ancora fornire astrazioni ai tuoi tipi.

Come una lingua lo consenta, non ha importanza.

Penso che la tua idea di OOP sia un po 'spenta:

Ho inventato il termine "programmazione orientata agli oggetti" e questo {Java e C ++} non è quello che avevo in mente.
- Alan Kay .

La scelta del tipo (sottotipo nominativo, sottotipo strutturale o tipizzazione anatra - o una combinazione di questi) è in gran parte ortogonale a OOP. Ereditarietà e classi sono interamente ortogonali a OOP. Se ti prendi del tempo per giocare con io , verrai a vederlo.

Ora puoi chiedere che tipo di sistemi di tipo sono "migliori" e quali mezzi di riutilizzo e combinazione di codice sono. E prova a determinare i vantaggi e gli svantaggi tra le scelte fatte in Simula (e successivamente portate avanti in C ++, Java e C #) e quelle fatte in Go. Ma queste sono tutte domande diverse e distinte.

In definitiva, OOP è un concetto molto vago e tutti i tentativi di implementarlo arrivano in una grande varietà di sapori. Ma per semplificare davvero le cose, direi che l'idea di base di OOP è comporre sistemi di sottosistemi SOLID . Ora questo rende assolutamente confusa la linea con altri paradigmi, ma speculerei sul fatto che questo è il motivo per cui le lingue multi-paradigma sono aumentate di popolarità di recente e perché Google ha preso il suo colpo con Go.

OOP non è obsoleto.

Come ha detto Andrea, ci sono stati molti concetti proposti come alternativa alle classi (per esempio: la tabella dei tipi di haskell). OOP ha un grande vantaggio: viene insegnato in molti luoghi e la cultura di OOP è ampiamente condivisa tra gli sviluppatori.

Ciò consente una comunicazione più ricca all'interno di un team. Si può parlare più facilmente di fabbriche che di prepromorfismi zygoistomorfi . OOP struttura il modo in cui organizzerai e comunicherai il tuo programma con diagrammi di uso comune. Questa è una risorsa potente.

No, non c'è nulla di nuovo qui, né OOP è obsoleto. Il C ++ ha anche interfacce implicite sotto forma di modelli, ma le persone usano ancora funzioni virtuali. Sono necessarie interfacce esplicite per far fronte, ad esempio, interfacce binarie o interfacce in cui l'altro codice semplicemente non è noto al momento della compilazione.

Si potrebbe sostenere che questo è semplicemente un caso di inferenza rispetto a dichiararlo esplicitamente, che non assomiglia a un "nuovo paradigma" e in realtà è solo più conveniente.