Le paradigme de programmation orientée objet est-il dépassé car il est anti-modulaire et anti-parallèle? [fermé]

J'ai lu l'article controversé Teaching FP to freshmen publié par Robert Harper, professeur à la CMU. Il a affirmé que la CMU n'enseignerait plus la programmation orientée objet dans le cours d'introduction car elle est «inadaptée à un programme CS moderne».

Et il a affirmé que:

La programmation orientée objet est entièrement éliminée du programme d'introduction, car elle est à la fois anti-modulaire et anti-parallèle par sa nature même.

Pourquoi considérer la POO comme anti-modulaire et anti-parallèle?

Veuillez considérer que les besoins d'Harper pour enseigner un cours d' introduction au programme CS sont très différents des besoins d'un projet réel . Son travail consiste à enseigner des notions fondamentales (par exemple la modularité, le parallélisme, l'induction) aux étudiants de première année. En tant que tel, il est très important que la langue (et le paradigme) choisis puissent exprimer ces concepts avec aussi peu de cérémonie (syntaxique et conceptuelle) que possible. La familiarité, la prise en charge des outils, les bibliothèques disponibles, les performances d'exécution, etc. sont complètement hors de propos dans ce contexte. Veuillez donc garder cela à l'esprit lorsque vous envisagez les éléments suivants ...

L'opinion selon laquelle OO est anti-modulaire résulte du grand nombre de dépendances à d'autres classes, même avec des objets de classes bien conçues. Que ce soit un problème - même aux yeux des partisans de l'OO - devient clair lorsque vous regardez la prolifération des cadres d'injection de dépendance , des articles, des livres et des articles de blog au cours des dernières années (la montée des simulations et des talons est également intéressante).

Un autre indice est l' importance des modèles de conception et la complexité de leur mise en œuvre - par rapport à d'autres paradigmes de programmation - par exemple, usines, constructeur, adaptateur, pont, décorateur, façade, commande, itérateur, médiateur, observateur, stratégie et méthode de modèle et peut-être les composites sont tous en quelque sorte liés à l'amélioration de la modularité du code OO.

L' héritage est également problématique (par exemple Fragile base de classe Problème polymorphisme) et (sous - type) à un déversée séduit la mise en œuvre d'un algorithme entre plusieurs classes, où les changements peuvent répercuter sur toute la chaîne d'héritage (haut et bas!).

L'accusation d'être anti-parallèle est liée à l' accent mis sur l'état par rapport au calcul (aka. Mutabilité vs immuabilité). Le premier le rend plus impliqué pour exprimer les dépendances des sous-calculs (ce qui est le point de vue de Harper sur le parallélisme!) Car vous ne pouvez généralement pas déduire de l'emplacement où l'état est géré (aka. Le fichier, où la variable d'instance est déclarée) quels acteurs extérieurs va le changer à quel moment.

L'accent mis sur l'immuabilité et le calcul rend l'expression des dépendances des sous-calculs beaucoup plus facile, car il n'y a pas de gestion d'état, juste des fonctions / calculs qui sont combinés à l'endroit où vous souhaitez exprimer les dépendances des sous-calculs.

C'est probablement une affirmation audacieuse à faire, mais je soupçonne en quelque sorte que ce Robert Harper n'a jamais vraiment écrit de logiciel réel de sa vie. Tout ce dont il semble se préoccuper, ce sont les systèmes de type ML et statiques. Aussi importante que cela puisse être, je ne vois pas en quoi ses affirmations sur la POO sont pertinentes.

Cet article n'est pas controversé. La controverse implique examen, argumentation et discussion. Ce que vous avez ici, c'est un universitaire ignorant qui met deux accusations assez fondamentales dans une seule déclaration, sans prendre la peine de fournir des arguments.

1. L'affirmation selon laquelle la POO est anti-modulaire est tout simplement absurde. Je ne sais même pas comment y répondre, non seulement aucun argument n'a été fourni, mais la conception orientée objet est également une approche pour établir la modularité avec un couplage très faible entre les modules individuels grâce à des moyens d'encapsulation et d'abstraction.

2. Affirmer que la POO est anti-parallèle démontre simplement un manque de compréhension. La POO ne bloque aucune décision concernant la concurrence. La POO ne fait que les masquer: s'ils sont correctement construits, vous ne pouvez pas dire si l'implémentation d'un objet est parallèle ou non.
   Ainsi, en fin de compte, la programmation OOP et parallèle sont orthogonales. Le modèle d'acteur est un modèle élégant de concurrence qui peut être directement reflété dans un système d'objets (mais pas nécessairement), produisant une formidable combinaison des deux.

Le problème avec la POO est que peu de gens le comprennent réellement dans le sens où Alan Kay l'a défini.

1. La POO est une approche. Dans certains langages, il est implémenté à l'aide de modèles, dans d'autres, vous pouvez directement utiliser des idiomes de langage intégrés (par exemple Ruby, Objective-C, Smalltalk, Io ).
2. Contrairement à la croyance commune, la POO ne concerne pas les classes. Il s’agit d’objets et d’objets, de la transmission de messages ou d’une méthode d’encapsulation et d’abstraction tout aussi transparente.

C'est pourquoi Java est pour OOP ce que les bâtons pointus sont pour le combat naval. Cela est également vrai pour de nombreux autres soi-disant "langages OOP", mais la chose à propos de Java est, qu'il semble être une croyance commune dans les universités, que Java devrait être utilisé pour enseigner la POO.

Je suis d'accord avec tous ceux qui pensent que les introductions à la POO avec Java devraient être supprimées des programmes CS. Je pense également que les personnes qui n'ont manifestement pas une compréhension fondamentale de la POO ne devraient pas l'enseigner. Il est donc probablement préférable que Bob s'en tienne au ML pour ses cours et qu'il enseigne simplement ce qu'il a une bonne compréhension de.
En ce moment, la POO est plus une étiquette à la mode, que les gens aiment coller à tout. Cela nuit à la POO et dit les gens. La POO n'est pas obsolète. L' âge d' or de la POO est encore à venir, lorsque les gens comprennent enfin ce qu'il est sur ce qu'il est pas au sujet (par exemple , résoudre tous les problèmes possibles en utilisant le mot - clé class500 fois).

Vous obtenez des fanatiques de chaque bande.

La programmation orientée objet n'est pas une solution miracle. Ça ne l'a jamais été. Qu'est-ce que c'est, est victime de battage médiatique. Inévitablement, les gens en ont assez du battage médiatique et un contrecoup commence à se développer (quelle que soit l'utilité réelle du paradigme).

Dans vingt ans, nous aurons sans aucun doute un autre contrecoup contre la programmation fonctionnelle.

Je ne peux pas répondre à cette question dans son intégralité car on ne peut que deviner les pensées vagues de son auteur. Je soupçonne fortement que cet article est sur le point de gêner son auteur. Rien dans la POO ne suggère qu'elle n'est ni modulaire ni parallèle:

Modularité : Un aspect majeur de la POO est qu'il est en effet modulaire (mais la modularité signifie des choses différentes dans des contextes différents). Donc, que l'auteur parle de généralisation ou de programmation statique, il a tort.

Parallélisation : Comme pour la programmation parallèle, la plupart des frameworks ont pris en charge les interruptions puis le threading et maintenant la parallélisation appropriée, comme ce que nous voyons dans .Net Framework 4.0 et les langages OOP qui s'y boulonnent.

Je soupçonne que l'auteur est devenu une victime de la mode en ce qu'il existe une idée fausse selon laquelle la programmation fonctionnelle et la POO sont mutuellement exclusives. Il existe des styles fonctionnels dans les langages POO qui sont bien documentés, par exemple, Oliver Sturm a publié dans ce domaine.

L'auteur soutient que la POO est trop difficile à comprendre pour les programmeurs de première année, ce qui peut être vrai - bien que j'en doute, étant donné les conditions d'entrée pour la CMU! Les déclarations anti-modulaires et anti-parallèles peuvent être vraies dans un contexte étroit par rapport aux langages purement fonctionnels, mais ne sont guère une condamnation de l'ensemble du paradigme (qui semble fonctionner très bien pour ceux qui savent l'utiliser).

Le programme proposé enseignerait la programmation fonctionnelle dans une classe, la programmation impérative (procédurale) dans une autre classe et les structures de données dans une autre classe. Une fois qu'un étudiant de première année a maîtrisé ces 3 choses, il doit être prêt à apprendre la POO.

Personnellement, je pense que c'est exagéré, mais les universitaires aiment essayer des choses nouvelles et extrêmes. Comme contrepoids, le MIT enseignait (et pourrait encore) enseigner tous les principaux paradigmes de programmation dans une classe de première année.

Curieusement, les deux écoles ont produit de très bons programmeurs. Allez comprendre.