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

23

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?

xiao
la source
14
Buhwaaaah?! OO facilite la modularité et le parallélisme par rapport à la procédure et n'est pas mutuellement exclusif à FP. Colorie-moi confus.
Matt Ellen, le
4
Ils ont repensé leur programme d'études, il doit donc vendre le nouveau programme et fait des déclarations audacieuses soutenues sans aucune donnée. Rien ne prouve que les programmes fonctionnels complexes soient plus parallèles ou modulaires que leurs homologues OOP.
davidk01
4
@Matt Ellen: OOP est décidément mutuellement exclusif avec FP. La FP repose sur plusieurs concepts clés dont l'un est l'absence d'état mutable. La POO est fondée sur l'existence d'un état mutable dont l'accès est contrôlé en l'enveloppant dans des "objets". L'état mutable et l'état immuable s'excluent mutuellement à peu près par définition. Oui, il est vrai que vous pouvez programmer dans un style fonctionnel avec de nombreux langages POO, mais ce n'est pas la même chose que d'utiliser un langage FP. Et oui, il est vrai que tous les langages FP ne sont pas purs. Cela ne signifie pas pour autant que FP est compatible avec la POO.
JUSTE MON AVIS correct
2
@JUST: J'ai une idée différente de l'exclusivité mutuelle pour vous. Je vois la FP pure et impure comme des sous-ensembles de FP, et donc la POO n'est pas mutuellement exclusive de la FP si vous supposez que la mutabilité est essentielle à la POO. De plus, je ne suis pas d'accord pour dire que la mutabilité est essentielle pour la POO. Vous pouvez réaliser un système entièrement OO en utilisant le passage de messages et ne jamais muter quelque chose.
Matt Ellen

Réponses:

30

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.

Alexander Battisti
la source
10
Les revendications de parallélisme du camp fonctionnel sont souvent exagérées. Les compilateurs pour les langages fonctionnels fonctionnent avec une théorie fondamentale plus propre afin que les implémenteurs aient plus de façons de réorganiser le code avant qu'il ne soit transformé en code machine, mais cela ne signifie pas que si vous donnez aux programmeurs OO les abstractions appropriées pour le parallélisme, ils ne pourront pas pour écrire du code parallèle propre. Jusqu'à présent, les programmeurs procéduraux n'ont obtenu que des verrous et des threads et ils se débrouillent assez bien, je pense, avec ces outils.
davidk01
2
Bien que je sois généralement d'accord avec tout ce que vous dites ici, je voudrais souligner que les modèles de conception viennent dans tous les paradigmes de programmation. Pour la programmation fonctionnelle, je soulignerais des choses telles que les monades et la carte / réduire.
Anm
@ davidk01 Prenez Go par exemple. Il prend en charge la programmation orientée objet et possède d'excellentes primitives de concurrence. Plus important encore, il décolle vraiment pour une programmation simultanée sans être purement fonctionnel.
weberc2
19

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).

back2dos
la source
1
+1 pour la transmission des messages et +1 pour le 'avec Java'. Malheureusement, s'ils supprimaient Java, ils le remplaceraient simplement par C # et continueraient son héritage.
gbjbaanb
@ back2dos +1 pour les critiques, -1 pour Java. Certes, Smalltalk est "beaucoup plus OO" que Java, mais qui l'utilise? Objective-C est difficile pour les débutants tout comme C l'est.
maaartinus
@maaartinus: Vous trouverez que Squeak est largement utilisé dans le domaine éducatif et universitaire, si cela répond à votre question. Aussi pour Java: vous l'aimerez peut-être, je ne le pourrai pas. Tout comme le café, c'est une question de préférence personnelle et il est inutile d'en discuter. Cependant, Java ne convenant pas à une introduction à la POO est à mon humble avis une implication indéniable de la nature de Java et du concept de POO et c'est exactement ce que j'ai dit. La popularité de Java ne fera pas disparaître cela. Quant à C, je vous suggère de lire joelonsoftware.com/articles/ThePerilsofJavaSchools.html .
back2dos
@ back2dos Squeak peut être utilisé dans ces domaines, mais à l'université, j'ai appris le ML. Les deux sont également inutilisables dans l'industrie et méritent d'être étudiés, en raison de leurs concepts. L'article pointu est le pire article de Joel que j'aie jamais lu, il est trop long et à première vue, le message semble être l'importance de traiter les erreurs de segmentation. : D Je suggère vraiment encore Java pour enseigner la POO.
maaartinus le
@maaartinus: Ce que vous avez appris à l'université importe peu dans la question de ce qui devrait être enseigné . Vous n'avez toujours donné aucune raison d'utiliser Java pour enseigner la POO, alors que j'ai donné ce que je considère comme une raison assez solide pour ne pas le faire. De plus, vous n'avez évidemment pas compris l'essence de l'article: les personnes qui ne peuvent pas faire face à des problèmes aussi durs que C ne devraient pas étudier la CS en premier lieu. Je pense que CS ne devrait pas être stupéfait par ce que tout enfant qui aime les ordinateurs peut comprendre. Si nous ne pouvons pas nous mettre d'accord là-dessus, alors une discussion plus approfondie est une perte de temps et de mienne.
back2dos
12

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.

Frank Shearar
la source
1
Il y en a déjà!
quant_dev
1
++ "Vous obtenez des fanatiques de chaque bande." J'étais un universitaire, et mon expérience était la suivante . Les universitaires adorent émettre des opinions provocantes, impressionnant peut-être leurs étudiants.
Mike Dunlavey
5

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.

CarneyCode
la source
4

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.

Steven A. Lowe
la source