Faut-il éviter de distraire les débutants avec l'orientée objet ?

[tarikbenmerar]

Faut-il éviter de distraire les débutants avec l'orientée objet ?
Ou serait-il préférable de l'enseigner en premier ?



Faut-il apprendre à un débutant l'orienté objet ? Pour ou contre ? L'avis de James Hague est en tout cas tranché.

Dans un récent billet de son célèbre blog "programming in the twenty-first century", il plaide contre l'introduction de ce concept au nouveau programmeur sous peine de trop les « distraire ».

Hague prend l’exemple de Python, qu’il considère comme un langage où les solutions sont souvent simples à implémenter. Bref, un langage d’introduction idéal pour le débutant, avec une élégance particulière dans l’utilisation des types de donnée de base tels que les dictionnaires. Néanmoins, il estime qu’il faut éviter à tout prix de parler de l'orienté objet, et se contenter de ces outils de base qui s'avèrent assez efficaces pour résoudre la majorité des problèmes pratiques.

Selon Hague, l'introduction de l'orienté objet force le programmeur « à réfléchir non pas en terme de problème et de solution, mais en terme d'architecture ». Pour résumer, l'introduction de nouveaux artefacts issus de la POO ne fera que distraire le programmeur de l'objectif principal, à savoir la résolution du problème.

Ainsi, certains débutants vont jusqu'à abuser de ces concepts, et se retrouvent à créer des hiérarchies inutiles de classes, s'éloignant complètement de ce qu'il faut réellement apprendre.
D'autres groupes se désintéresseront complètement, parce qu’ils trouveront cette couche additionnelle sans sens concret, et rends la programmation encore plus encombrante et lourde.

« À un moment donné, oui, vous devrez aborder la création d'objets sous Python, mais résistez à la tentation de le faire aussi longtemps que vous le pouvez », conseille-t-il.



Et vous ?

Faut-il, d'après vous, éviter de distraire les débutants avec la programmation orientée objet ?
Ou est-il préférable de l'enseigner en premier ?
Python est-il le langage idéal pour apprendre la programmation ?
Ou estimez-vous que d'autres langages remplissent mieux cette tâche ?

Source : Don't Distract New Programmers with OOP

[CapFlow]

Je pense que pour un débutant, il vaut mieux commencer à apprendre la POO après avoir acquis une bonne maitrise du langage en question. Et il faut qu'il s'en sente capable bien sur.

« à réfléchir non pas en terme de problème et de solution, mais en terme d'architecture »

Tout à fait d'accord, quand on commencer à développer avec de la programmation orientée objet, le problème n'est plus "comment faire ceci ?" mais "comment vais-je structurer mon programme ?". C'est pour cela qu'une bonne maitrise du langage utilisé est nécessaire pour savoir avant de commencer à écrire le code comment faire son programme.

[GeoTrouvePas]

Je pense également que l'apprentissage de la P.O.O. ne doit se faire qu'une fois qu'on est à l'aise, qu'on maîtrise et qu'on jongle parfaitement avec les méthodes "de base".

Il vaut mieux commencer par apprendre à marcher correctement avant d'apprendre à courir.......

[gaiasson31]

Faut-il, d'après vous, éviter de distraire les débutants avec la programmation orientée objet ? Ou est-il préférable de l'enseigner en premier ?

En effet je pense qu'il faut commencer par le commencement (ça va je me mouille pas trop ).
L'objet est certes une évolution qui a fait ses preuves dans le monde de la programmation mais vouloir faire une fusée en utilisant des supers moteurs nucléaires de la morkitu avant même de comprendre quelles sont les forces qui s'exercent sur un objet en vol s'avère quelque peu risqué...
L'objet permet de répondre de façon plus simple à certains problèmes mais cloisonne le raisonnement à vouloir catégoriser tous types de problème dans la case "à résoudre avec des objets" (et j'en suis la première victime ayant débuté avec l'objet...).

Python est-il le langage idéal pour apprendre la programmation ? Ou estimez-vous que d'autres langages remplissent mieux cette tâche ?

Pourquoi pas, mais je préfèrerai un langage plus carré qu'élégant, de type Pascal, même si le saint graal serait un langage fait maison par des profs, utilisé uniquement à des fins pédagogiques. La compréhension des concepts de programmation pour un débutant doit le plus possible transcender un langage en temps que tel, qui est empreint d'une certaine philosophie, sous peine de désintéresser certains débutants de la programmation à tord.

[stardeath]

je suis toujours ébahi par les avis à l'emporte pièce sur la manière d'enseigner la programmation ; pas de pointeurs c'est oldschool et trop difficile, pas d'héritage multiple c'est dangereux, pas de template, les messages d'erreurs sont trop incompréhensibles ...

en entendant ça, ça m'étonne pas que les jeunes diplômés ne savent rien faire, soit on leur apprend du tellement haut niveau que libérer la mémoire devient du chinois soit on limite les langages à if-the-else-for-while et dès qu'on sort de ça ils ne savent plus faire.

rien ne vaut c/c++ et 2-3 bribes d'assembleur pour l'apprentissage, au moins les jeunes seront parés pour tout et seront moins surpris si on leur demande de libérer la mémoire (tout le contraire si ils ont commencés par un langage avec gc ...)

[Paul TOTH]

il faut arrêter de penser que "développeur" est un métier unique.

on ne développe pas sous Java, PHP, C++ et VisualBasic de la même façon.

on ne développe pas ComptaFacile, Amadeus et VotrebanqueEnLigne de la même façon (enfin j'espère pour compte compte en ligne).

dernièrement j'ai vu un logiciel de caisse "développé" sous Excel, on coche des prestations et on renseigne la remise et la case "total" donne le montant à payer...les clients sont gérés sur papier...pas besoin d'apprendre la programmation orientée objet pour faire ça. Je ne sais pas si la feuille contient un peu de VBA ou si tout est géré par formule ceci dit.

Or donc, la première question, c'est à quoi veut-on les former ?

[thelvin]

Envoyé par Paul TOTH

Or donc, la première question, c'est à quoi veut-on les former ?

Oui, mais dans tous les cas, le concept d'objet est trop éloigné du but à atteindre (du moins le concept d'objet actif, qui ne soit pas juste une structure qui ne fait rien.)

C'est du moins l'avis qui est décrit par les personnes présentes, et que je partage.
Essentiellement, c'est la différence entre apprendre une chose à la fois, et grosso-modo cinq choses à la fois.

[Lupus Michaelis]

Et pourquoi une telle obsession de la programmation objet, ou orientée objet*?

Je pense que le choix de l'outil d'apprentissage et des paradigmes à enseigner doit dépendre de l'objectif. S'il est de former des programmeurs, commencer par du C et de l'assembleur est le meilleurs moyen d'apprendre à programmer. Cela permet de se concentrer sur quelques problèmes de base*: gestion de la mémoire, structuration, algorithmie.

Après quoi on peut commencer à parler de système, d'interaction l'OS et les autres processus. À partir de là, on peut discuter architecture, responsabilité entre les différentes briques (applications, bibliothèques, OS).

Ainsi le concept d'objet s'introduit de lui-même*: même sans utiliser un langage de programmation objet, n'importe quel logiciel est un objet qui interagi avec d'autres objets (et éventuellement un humain).

Et à partir de ces acquis, on peut introduire la programmation orienté objet. Évidement, le C++ est un langage de choix, mais il n'est pas question ici de maîtriser un langage*: il s'agit d'introduire un concept. Donc faire le tour de quelques langages et de montrer quelles solutions ont été apportées pour implémenter telle ou telle technique relative à la programmation objet. Du C++ au Java (ou C#), en passant par le Javascript, Ruby, Python, etc, sans oublier de mentionner qu'en C aussi, on peut programmer objet en tête.

Mais comme je l'ai dit en introduction, je crois qu'on se focalise trop sur la programmation orienté objets. Les langages fonctionnels sont certainement les plus grand perdant dans l'histoire. D'accord, C++ supporte ce paradigme, mais il est souvent occulté au profit des classes omniscientes.

Maintenant, pour ceux qui ne seront jamais amenés à programmer à plein temps, je pense qu'on peut faire une approche plus légère. Mais je serais bien en peine de leur proposer un programme (de cours).

(PS*: les espaces insécables semblent remplacées)

[Bousk]

Envoyé par stardeath

je suis toujours ébahi par les avis à l'emporte pièce sur la manière d'enseigner la programmation ; pas de pointeurs c'est oldschool et trop difficile, pas d'héritage multiple c'est dangereux, pas de template, les messages d'erreurs sont trop incompréhensibles ...

en entendant ça, ça m'étonne pas que les jeunes diplômés ne savent rien faire, soit on leur apprend du tellement haut niveau que libérer la mémoire devient du chinois soit on limite les langages à if-the-else-for-while et dès qu'on sort de ça ils ne savent plus faire.

rien ne vaut c/c++ et 2-3 bribes d'assembleur pour l'apprentissage, au moins les jeunes seront parés pour tout et seront moins surpris si on leur demande de libérer la mémoire (tout le contraire si ils ont commencés par un langage avec gc ...)

Je suis d'accord avec toi, mais j'ai une approche inverse :
on commence par les concepts simples, sans parler mémoire etc
puis on s'enfonce pour "savoir comment ça marche"

J'ai en tous cas eu de meilleurs résultats ainsi
- tu montres ce qu'on peut faire, et ça parait pas trop compliqué
- tu les as intéressés
- tu montres comment ça marche avec un auditoire captivé

Dans l'ordre inverse
- holala j'ai rien compris
- "haaaaa un pointeur j'ai peur"
- plus personne ne te prête attention

En ce sens Python permet une bonne approche, pour ma part ce fut PHP3
Dans tous les cas un passage par du C me semble primordial, éventuellement par de l'assembleur pour les plus motivés/intéressés
Puis de l'objet, où Python peut encore être utilisé
Tout dépend des contextes qu'on veut montrer, ie on ne pourra pas mettre en relief les avantages de l'héritage multiple ou les dangers de l'héritage en diamant autre qu'en C++

[mewtow]

Personnellement, je suis de ceux qui croient que commencer directement par l'OO n'est pas forcément une bonne chose, et que commencer par du procédural pour terminer par de l'OO est une bonne pédagogie.

Mais cette impression ne vaut strictement rien, et seuls les faits méritent d'être évoqués. Il faut savoir que dans le domaine de la pédagogie, de nombreuses recherches ont étés effectuées et qu'on arrive plus ou moins à savoir comment faire pour bien enseigner. Et dans le domaine de la programmation, on n’échappe pas à ce genre de choses. Ainsi, on sait plus ou moins ce qui rend un langage facile à apprendre et quelles sont les difficultés majeures : vous n'imaginez pas les difficultés que peuvent poser les structures de contrôle et l'assignement (oir ici pour les curieux : http://www.cl.cam.ac.uk/teaching/1011/R201/). Et concernant le débat OOP versus procédural, on a quelques éléments de débat venant d'études de psychologues sur le sujet.

J'ai effectué personnellement quelques recherches sur le sujet, et je suis tombé sur un document qui en parle un petit peu. Commencez à lire le pdf qui va suivre à partir de la page 142 : http://lib.tkk.fi/Diss/2012/isbn9789...9526046266.pdf, vous devriez avoir un paragraphe appelé "Objects are a bone of contention". Je vous laisse vous faire votre avis.

Au final, j'ai retenu que l'apprentissage précoce de l'OOP peut parfaitement marcher : ceux qui commencent par l'OOP n'ont pas de grosses différences de performances avec ceux qui ont commencés par du procédural, même si les difficultés rencontrées par ces deux types d'élèves ne sont pas les mêmes. Par contre, apprendre l'OOP en premier est plus complexe que du simple procédural (la notionnal machine d'un langage OOP est plus complexe que celle d'un langage procédural), ce qui est un désavantage. Personnellement, je suis d'avis de commencer par le procédural et d'expliquer l'OOP en faisant le lien avec les bases du procédural (et notamment en se basant sur la programmation modulaire). C'est le seul moyen que je vois pour apprendre l'OOP en utilisant les méthodes préconisées par la pédagogie explicite (garder une progression du simple au complexe, découpage du cours en petites unités notionnelles acquises en se basant sur les précédentes, pas de concepts "trop généraux" ou ambigus, etc).

[stardeath]

Envoyé par Bousk

...

je suis d'accord qu'il faut des étapes dans la progression, c'est pour cela que je ne suggère que c/c++/assembleur, tu peux très bien faire du simple et du très compliqué sans changer de langage, donc sans se disperser vers des syntaxes/concepts différents.

je continuerai là dessus en préférant l'apprentissage du c++ plutôt que du c, toute la stl permet de se passer de l'apprentissage difficile (lol) des pointeurs (qui doivent au contraire être très rapidement maitrisés en c).

pour la poo, finalement ce n'est que commencer à responsabiliser son code, ne pas en faire assez tôt revient au même niveau que, amha, de ne pas écrire de commentaire dans le code : "j'ai pas le temps d'en écrire maintenant, je le ferai plus tard", sauf que le tard soit n'arrive pas, soit devient une corvée.

comme je l'ai dit dans une autre conversation, on est pas obligé d'enseigner tout ce qu'il y a de compliqué avec un langage comme c++, il y a moyen de faire des trucs simples quand même.

[el_slapper]

Ou alors on prend l'approche Joel Spolsky : on les noie d'entrée sous les pointeurs et la recursion, et on ne garde que ceux qui respirent encore.

Mais, là encore, c'est une question de priorité : veut-on former les gens, ou choisir les plus aptes? Doit-on former tout le monde, et accepter que des gens pas tellement doués soient sur le marché, ou au contraire sabrer pour ne garder que les tous meilleurs, laisant une haine profonde du code à tous les autres? Il n'y a pas de réponse evidente à cette question.

Le posteur original, clairement, cherche à former tout le monde. Il parle d'enseigner la programmation à ses enfants - qu'ils en fassent leur métier ou non.

[Tryph]

Faut-il, d'après vous, éviter de distraire les débutants avec la programmation orientée objet ?
Ou est-il préférable de l'enseigner en premier ?

je suis partagé. je pense que c'est bien d'avoir un minimum de connaissance en algorithmie, c'est déjà plus simple à appréhender et puis de toute façon il faut bien maitriser ça pour remplir les méthode qu'on met dans nos chère classes.
après, faut bien avouer que certains ont du mal avec la philosophie objet et que même s'ils savent faire des classes, les instancier et les utiliser, ils le font à tort et à travers et qu'on se retrouve au final avec quelques chose de pas vraiment mieux structuré qu'avec du procédural.
alors l'un ou l'autre en premier, je sais pas trop, mais moi on m'a appris l'algo avant les principes objet et ce ne m'a pas parut impertinent.



Python est-il le langage idéal pour apprendre la programmation ?
Ou estimez-vous que d'autres langages remplissent mieux cette tâche ?

moi j'ai appris sur du java, ça ne m'a pas déplu.
j'ai un peu mal avec le python, je suis pas fan de la syntaxe, j'ai sans doute trop l'habitude de la syntaxe type C avec des accolades et des points virgules.
ceci dit, je pense que python peut être un bon langage d'apprentissage ne serait-ce que pour l'indentation obligatoire. car même au bout de quelques années de métier, y en qui ont du mal a indenter leur code correctement et je trouve ça particulièrement lourd de repasser derrière.



enfin, et un peu hors-sujet, faut pas croire que parce qu'on a fait ses premieres armes sur un langage de haut niveau, on est incapable de comprendre ce qu'est une libération de mémoire. les premières armes ne sont que les premières armes et chacun peut continuer à apprendre.
et puis quand j'étais en cours, même si presque tous les cours se faisaient avec du java, je me souviens très bien du prof en train de nous expliquer le fonctionnement du GC, les implications d'un passage de variables native ou encapsulée dans un objet, des histoires de pile et de tas, etc...
on n'est pas obligé de faire du C pour comprendre qu'une zone mémoire allouée doit être libérée, pour comprendre ce qu'est un pointeur ou pour appréhender les concepts de passages de variables par valeur ou par référence.
après, je suis entièrement d'accord pour dire que faire au moins un minimum de C pour mettre en pratique directement ces concepts est très utile, mais je ne pense pas que ça soit une obligation.

pour moi un développeur qui n'a aucune idée de ce qu'est un pointeur ou une libération de mémoire a eu un sérieux défaut d'attention pendant ses cours ou des profs complètement à la ramasse.

[anthyme]

J'ai expliquer l'objet, la théorie, les tenants et les aboutissants, les interets à l'utiliser à mon frère qui est en école d'info au début de son cursus.

Ensuite je l'ai laisser suivre ses cours en lui disant "essai de penser comment tu pourrais structurer ce que tu fais en objets".

Il fait ensuite du lisp, caml et autres langages d'apprentissage sans objets.
2 ans plus tard il passe au c# et a une bien meilleure compréhension du modèle objet, de quand et comment extraire du code dans une classe, partage de code etc. Il arrive aussi à être très critique sur des chose codé "n'importe comment".

Je penses qu'il y a une histoire d'habitude dans tout ça, mettez quelqu'un trop a l'aise dans le procédurale et il ne voudra même pas faire de l'objet pensant que ca marche très bien comme ça et il va mettre du temps a acquérir ces notions malgrès lui.

A mon avis comme on ne fais pas de procédurale sans avoir fait un peu de théorie d'algorithmique on ne devrait pas développement de logiciel sans avoir appris de la théorie objet.

[mek-in-gold]

Je suis de ceux qui pensent qu'il faut commencer par la POO.

Je pense qu'au contraire il faut commencer par savoir comment Architecturer et structurer et cela en dehors du principe de coder.

D'abord on fera de la théorie avec des exemples qui ne sont pas du code puisque le but est ici d'apprendre à coder. Après on commence à coder en se servant des bons Design Pattern.

La POO est un concept assez simple si on l'apprend dans un concept général. Beaucoup de langages ne sont qu'orienté objet et ne permettent pas la procédurale. Si la procédurale était un principe obligatoire alors personne ne pourrait commencer par des langages dits seulement objet.

La procédurale est un concept ancien et démodé, il a servit un temps mais les techniques de programmation ont évolué.

Apprendre à programmer doit être quelque chose de constamment évolutif. C'est comme gérer une équipe et lui demander d'exécuter des tâches. Elle sera plus efficace avec une bonne structure réfléchie.

On évolue toujours sur la façon de gérer une équipé et on adapte également toujours selon les besoins.

On n'apprend pas de vieilles méthodes de travail sinon elles restent ancrées et le passage à d'autres méthodes fait naitre la question du 'Pourquoi changer'. La personne n'aura pas forcément envie d'évoluer car elle se sent bien dans son contexte actuel ou elle à ses repères.

Un bon développeur doit être évolutif et penser d'abord à la structure puis après à l'alimenter. Un bon code bien structuré pourra toujours évoluer. Sinon cela s'apparente à une chimère.

Je pense qu'il n'y a pas de meilleur langage plus qu'un autre c'est la façon de l'apprendre et de savoir l'utiliser.

Les langages basés sur la POO reprennent eux-mêmes une architecture et des concept assez communs mis en place par la POO. Ainsi que ce soit en C# , Java ou PHP on retrouve plusieurs concepts de structure et de design pattern communs. Ces similitudes permettent le portage d'un code d'un langage à un autre langage de manière plus simple. On doit bien sur affronter quelque différences techniques mais on n'a pas à repenser autant la structure.

La POO associée à la POA communément appelé programmation orientée aspect, peut aussi faire l'objet d'un certain présentéisme d'un point de vue organisation.

[Thiht]

En un mot il propose d'apprendre la partie algorithmique avant d'apprendre la partie architecture, je vois rien de révolutionnaire à ça. Comme il ne parle pas d'algorithmique mais directement d'un langage, on sous-entend le procédural.
Ce qui s'est toujours fait en somme (du moins je ne connais personne qui fait de l'OO AVANT de faire soit de l'algo pure, soit du procédural, et je vois simplement pas comment ce serait possible).

Pour python comme premier langage je suis pas particulièrement d'accord, tout langage pouvant être utilisé comme procédural est bon pour commencer. A titre personnel j'aurais pas tendance à conseiller python, y a quelques éléments de syntaxe dans les appels de fonctions que je trouvais carrément contre-intuitifs (des fonctions à utiliser soit en procédural, soit en tant que méthodes sur un objet, soit au choix selon le contexte, je trouve ça dégueulasse).

[MarieKisSlaJoue]

Apparemment mon avis ne sera pas majoritaire. Raison de plus pour l'exprimer.
Quand on m'as appris la programmation ça a commencer par les if-else-while-for et voilà.

Ensuite on est directement passer à l'objet mais sans nous le présenter. Mes premier tp été donc de la programmation orienté objet sans qu'ont s'en aperçoivent. (Alors bien sur il avait à coté quelque exo qui prenne 2/3min pour que les base rentre en même temps.)

Mais au final le fait d'être directement dans l'objet nous à permis de comprendre et donc de commencer les cours de POO bien plus vite et efficacement. Bah oui on à déjà les base intuitivement en faite comme les classe et comment ça fonctionne. Je pense donc que pour des cours scolaire où on ne peux pas perdre top de temps sur les bases commencer par l'objet est nécessaire.

Alors maintenant je vais nuancer un peu. Apprendre d'abord les "bases" réfléchir seulement à un problème posé je pense que c'est bon pour quand on travail seul à la maison le soir ou le week end. C'est très bien aborder dans les tutoriels du net et donc là en effet il faudrait éviter l'objet. Mais dans le cadre scolaire je reste sur mon première avis.

Pour quel langage apprendre aux débutant encore une fois personnellement on m'as appris le php/java et python en parallèle ce sont trois langages assez simple donc plutôt pas mal pour commencer. après le C# me semble bien pour les débutants aussi.

Et du coup pour finir j'ai appris le java en commençant direct en POO et le python sans l'aborder. Et bien je suis bien plus a l'aise et autonome en Java qu'en python même sans faire forcément de la POO. Mais je pense que il à eu trop d'autre facteur pour en tirer une conclusion.

[Sorentao]

Faut-il, d'après vous, éviter de distraire les débutants avec la programmation orientée objet ?
Comme beaucoup d'avis postés précédemment, la POO n'est pas l'idéal pour débuter.

Python est-il le langage idéal pour apprendre la programmation ?
C'est un bon langage pour commencer, notamment de par sa syntaxe très axée pseudo-code , mais il y a d'après moi d'autres alternatives toutes aussi valables qu'il est difficile de le qualifier d'idéal. D'expérience, j'ai constaté que le C est une alternative viable, de par son approche bas-niveau initiant au procédural, à la gestion de mémoire, à l'algorithmique qui lui est liée, etc.

Sur le fond je suis d'accord pour dire que l'idéal n'est pas de débuter l'apprentissage par la POO. Il y a cependant un point sur lequel je le suis beaucoup moins :

l'orienté objet force le programmeur « à réfléchir non pas en terme de problème et de solution, mais en terme d'architecture »

C'est absolument le cas. Mais est-ce un mal aussi prononcé qu'il est présenté ici ?
Dans un cadre professionnel, le même code est souvent pris et repris par plusieurs développeurs au fil du temps, pour des raisons d'évolution ou de maintenance. En partant de ce principe, il me parait justifié de prendre au moins autant de temps à réfléchir sur son architecture que sur la solution du produit en tant que tel.

Hormis ce détail, je suis totalement d'accord avec l'avis de James Hague

[playfone]

*Mode Troll ON*
98% des conducteurs de voitures conduisent sans connaitre le fonctionnement d'un moteur right ?
Ils n'ont pas tous des accidents right ?
(A transposer pour un développeur)
*Mode Troll OFF*

C'est vendredi donc j'ai le droit

[transgohan]

Pour ma part ma formation a été algo/C/Java.
Donc l'orienté objet en fin d'apprentissage (j'entends pas par là en fin d'études attention....).
Cela m'a très bien réussi, et ça a tout de même noyé pas mal d'étudiants...
Donc là encore la question du "on enseigne à tout le monde ?" ou "on enseigne à l'élite qui arrive à suivre et les autres ils se démerdent ?".
A ce que je vois des réactions des diplômés sur ce topic c'est plutôt le second cas et c'est pas mal désolant quand même...

J'ai pu voir des étudiants provenant de prépa et donc n'ayant pas eu de formation informatique comme moi grâce à mon DUT. Bah ils ont eu droit à de la programmation avant l'algorythmie... Je vous laisse imaginer le désastre, les projets de fin de semestre sont généralement affreux (pas forcement raté, mais très mal rédigé, très mal pensé) pour cette catégorie de personne.

Il ne faut pas mettre la charue avant les boeufs, certains pensent que seul l'OO est valable. Bah justement non... Cela dépend fortement de votre domaine de travail. Regardez du côté des dev très bas niveau s'ils font souvent de l'orienté objet...
On choisi toujours une technologie en fonction de ce qui colle le mieux à ce que l'on fait, et pas parce qu'on l'aime plutôt qu'une autre... (Bien que quand je vois passer certains projets sous mes yeux on se le demande...)

Bref chaque paradygme a son utilité, on peut pas parler en général que l'OO est mieux qu'un autre c'est totalement hors de contexte... Ce serait comme de dire que la voiture est mieux qu'à pied. Cela dépend de votre parcours !