Il paradigma della programmazione orientata agli oggetti è obsoleto poiché è anti-modulare e anti-parallelo? [chiuso]

Ho letto l'articolo controverso Insegnare FP alle matricole pubblicato da Robert Harper, professore di CMU. Sosteneva che la CMU non avrebbe più insegnato la programmazione orientata agli oggetti nel seno introduttivo, poiché "non è adatto per un curriculum CS moderno".

E ha affermato che:

La programmazione orientata agli oggetti viene eliminata del tutto dal curriculum introduttivo, poiché è sia antimodulare che antir parallelico per sua stessa natura.

Perché considerare OOP come anti-modulare e anti-parallelo?

Si prega di considerare che le esigenze di Harper per l'insegnamento di un corso introduttivo sul curriculum CS sono molto diverse dalle esigenze di un progetto di vita reale . Il suo compito è insegnare concetti fondamentali (ad es. Modularità, parallelismo, induzione) alle matricole. Pertanto è molto importante che la lingua (e il paradigma) scelti possano esprimere questi concetti con il minor numero di cerimonie (sintattiche e concettuali) possibile. Familiarità, supporto degli strumenti, librerie disponibili, prestazioni di esecuzione ecc. Sono completamente irrilevanti in questo contesto. Quindi tienilo a mente quando consideri quanto segue ...

L'opinione che OO sia un risultato anti-modulare dal grande numero di dipendenze verso altre classi, anche gli oggetti di classi ben progettate tendono a finire. Che questo sia un problema - anche agli occhi dei sostenitori di OO - diventa chiaro quando si osserva la proliferazione di quadri di iniezione di dipendenza , articoli, libri e post di blog negli ultimi anni (anche l'ascesa di beffe e mozziconi è interessante).

Un altro suggerimento è l' importanza dei modelli di progettazione e la complessità della loro implementazione - rispetto ad alcuni altri paradigmi di programmazione - ad es. Fabbriche, Costruttore, Adattatore, Ponte, Decoratore, Facciata, Comando, Iteratore, Mediatore, Osservatore, Strategia e metodo del modello e forse i Compositi sono tutti in qualche modo legati al miglioramento della modularità del codice OO.

L'ereditarietà è anche problematica (ad es. Problema di classe di base fragile ) e il polimorfismo (sottotipo) seduce a rovesciare l'implementazione di un algoritmo tra più classi, in cui i cambiamenti possono incresparsi attraverso l'intera catena ereditaria (su e giù!).

L'accusa di essere anti-parallelo è legata all'enfasi dello stato rispetto al calcolo (ovvero mutabilità vs. immutabilità). Il primo rende più coinvolto l' espressione delle dipendenze delle sottocomputer (che è la tesi di Harper sul parallelismo!) Poiché di solito non si può dedurre dalla posizione in cui è gestito lo stato (ovvero il file, dove viene dichiarata la variabile di istanza) quali attori esterni lo cambierà in quel momento.

Un'enfasi sull'immutabilità e sul calcolo rende l'espressione delle dipendenze delle sottocomputer molto più semplice, poiché non esiste una gestione dello stato, ma solo funzioni / calcoli che sono combinati nel luogo in cui si desidera esprimere le dipendenze delle sottocomputer.

Questa è probabilmente un'affermazione audace da fare, ma in qualche modo sospetto che questo Robert Harper non abbia mai scritto software reale in vita sua. Tutto ciò che sembra interessarsi è ML e sistemi di tipo statico. Un contributo così grande come potrebbe essere, non vedo come le sue affermazioni su OOP abbiano rilevanza.

Questo articolo non è controverso. La controversia implica esame, discussione e discussione. Quello che hai qui è un accademico ignorante che formula due accuse piuttosto fondamentali in una sola affermazione, senza preoccuparsi di fornire alcun argomento.

1. L'affermazione sul fatto che OOP sia anti-modulare è assolutamente una sciocchezza. Non so nemmeno come rispondere, non solo non sono stati forniti argomenti, ma anche OOP di progettazione è un approccio per stabilire la modularità con un accoppiamento molto basso tra i singoli moduli attraverso l'incapsulamento e l'astrazione.

2. Affermare che OOP è anti-parallelo dimostra solo una mancanza di comprensione. OOP non blocca alcuna decisione sulla concorrenza. OOP impone solo di nasconderli: se costruito correttamente, non si può dire se l'implementazione di un oggetto sia parallela o meno.
   Quindi in definitiva OOP e la programmazione parallela sono ortogonali. Il modello dell'attore è un modello elegante per la concorrenza che può essere riflesso direttamente in un sistema a oggetti (ma non è necessario), producendo una formidabile combinazione di entrambi.

Il problema con OOP è che poche persone lo capiscono davvero nel senso in cui Alan Kay lo ha definito.

1. OOP è un approccio. In alcune lingue è implementato usando modelli, in altri è possibile utilizzare direttamente i linguaggi linguistici incorporati (ad es. Ruby, Objective-C, Smalltalk, Io ).
2. Contrariamente alla credenza comune, OOP non riguarda le classi. Riguarda gli oggetti e gli oggetti riguardano il passaggio di messaggi o un modo altrettanto incondizionato di incapsulamento e astrazione.

Questo è il motivo per cui Java deve OOP quali bastoni appuntiti sono per il combattimento navale. Questo è vero anche per molti altri cosiddetti "linguaggi OOP", ma la cosa su Java è che sembra essere una credenza comune nelle università, che Java dovrebbe essere usato per insegnare OOP.

Concordo con tutti coloro che ritengono che le introduzioni a OOP con Java debbano essere rimosse dai curricula CS. Penso anche che le persone che chiaramente non hanno una conoscenza fondamentale di OOP non dovrebbero insegnarlo. Quindi è probabilmente meglio se Bob si attiene alla ML per i suoi corsi e semplicemente insegna ciò di cui ha una ferma comprensione.
In questo momento OOP è più un'etichetta alla moda, che alla gente piace attenersi a tutto. Questo danneggia OOP e ha detto la gente. OOP non è obsoleto. Età d'oro di OOP deve ancora venire, quando la gente finalmente capire di cosa si tratta di cosa si tratta , non su (ad esempio risolvere ogni possibile problema utilizzando la parola chiave class500 volte).

Ottieni zeloti di ogni striscia.

La programmazione orientata agli oggetti non è un proiettile d'argento. Non lo è mai stato. Di cosa si tratta, è una vittima di hype. Inevitabilmente, le persone si ammalano dell'hype e inizia a svilupparsi un contraccolpo (indipendentemente dall'utilità effettiva del paradigma).

Tra vent'anni, senza dubbio, avremo altri contraccolpi contro la programmazione funzionale.

Non posso rispondere a questa domanda per intero perché si può solo indovinare i vaghi pensieri del suo autore. Sospetto fortemente che questo articolo stia per causare imbarazzo al suo autore. Non c'è nulla in OOP che suggerisca che non è né modulare né parallelo:

Modularità : un aspetto importante di OOP è che è effettivamente modulare (ma modularità significa cose diverse in contesti diversi). Quindi, indipendentemente dal fatto che l'autore stia parlando di generalizzazione o programmazione statica, non è corretto.

Parallelizzazione : per quanto riguarda la programmazione parallela, la maggior parte dei framework ha supportato le interruzioni, quindi il threading e ora una corretta parallelizzazione, come ciò che vediamo in .Net framework 4.0 e i linguaggi OOP che si fondono su di esso.

Ho il sospetto che l'autore sia diventato una vittima della moda in quanto esiste un'idea sbagliata secondo cui la programmazione funzionale e OOP si escludono a vicenda nell'uso. Esistono stili funzionali nei linguaggi OOP che sono ben documentati, ad esempio Oliver Sturm ha pubblicato in quest'area.

L'autore sostiene che OOP è troppo difficile da capire per i programmatori di matricole, il che può essere vero - anche se ne dubito, dati i requisiti di ingresso per la CMU! Le affermazioni anti-modulari e anti-parallele possono essere vere in un contesto ristretto rispetto ai linguaggi puramente funzionali, ma difficilmente sono una condanna dell'intero paradigma (che sembra funzionare bene per coloro che sanno come usarlo).

Il curriculum proposto insegnerebbe la programmazione funzionale in una classe, la programmazione imperativa (procedurale) in un'altra classe e le strutture di dati in un'altra classe. Una volta che una matricola ha imparato queste 3 cose, dovrebbe essere pronto per imparare OOP.

Personalmente penso che sia eccessivo, ma agli accademici piace provare cose nuove ed estreme. Come contrappeso, il MIT era solito (e potrebbe ancora) insegnare tutti i principali paradigmi di programmazione in una classe di matricole.

Stranamente, entrambe le scuole hanno prodotto dei programmatori davvero bravi. Vai a capire.