Ah, Goedel a encore frappé (indécidabilité)Envoyé par Garulfo
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Ah, Goedel a encore frappé (indécidabilité)
Et dans ces pléthores combien utiliseront correctement l'OO ? D'après ce que j'observe quotidiennement depuis 10 ans, je peux te dire : pas beaucoup.
J'admet que la POO n'est pas facile. J'ai pas de honte à dire qu'il m'a fallu des années pour comprendre, mais surtout de vouloir approfondir le sujet. Et sur ma petite experience perso, ceux qui ont eu un long passé avec le procédural ont eu du mal a comprendre et puis il y a ceux qui ne comprendrons jamais alors qu'ils savent programmer en procédural.
Quand je dis POO, c'est pas juste utiliser l'encapsulation mais bel et bien faire de l'héritage, utiliser des interfaces, créer des classes basées sur une architecture cohérente, et pas une méga classe, parce qu'on peut facilement faire du code spaghetti.
Il serait interessant de faire un sondage sur le temps moyen d'adaptation des personnes à la programmation objet.
Tu as sorti ma réponse du contexte. Je défendais le fait que l'un n'était pas meilleur que l'autre. Je n'ai jamais dit que c'était exactement la même chose et qu'il y avait les mêmes désavantages et avantages. Dans le fil d'où est tiré la réponse cité par Souviron, plusieurs disaient que la POO c'est mieux car c'est plus naturel.
Mais il y a aussi l'autre cas : de plus en plus, on apprend la POO comme premier paradigme. Les étudiants ont alors du mal à s'adapter à l'autre paradigme. Lorsque c'est du fonctionnel pur qu'on leur apprend, le passage a l'impératif est toujours plus difficile.
Au final, de manière non surprenante, la première chose enseignée occulte un peu les autres chez une majorité de personne. Mais avec un effort, elles développent les autres points de vues.
On est bien d'accord — ai-je d'ailleurs sous-entendu quoi que ce soit dans un sens contraire ? Je passe mon temps à défendre l'idée que l'utilisation de « naturel » comme argument ou contre-argument est absolument terrible. La plupart du temps ce n'est que pour cacher son manque d'argument.
Orthographie bien son nom tant qu'à faire : Gödel.Ah, Goedel a encore frappé (indécidabilité)
Pourtant, quand je lis cet article dont le sujet a déjà été mentionné sur DVP, je ne suis pas tout à fait convaincu.
C'est de la gymnastique cérébrale. Passé d'un paradigme à un autre, c'est changé de schéma de raisonnement. Je veux dire que le problème fondamental pour tout langage, c'est son enseignement.
Si les gens veulent se mettre à UML alors qu'ils n'ont jamais fait de POO, c'est comme faire des intégrales sans connaître les dérivées en math. Il y a une démarche logique d'apprentissage et s'il manque l'une ou l'autre notion, on peut coincer rapidement.
Bien entendu, il y a des individus très doués et qui intuitivement trouveront la solution au problème. La compréhension d'un paradigme dépend à la fois de l'enseignement/formation mais aussi de l'autoformation, c'est à dire completer sa connaissance sur des sujets.
Dans une contexte professionnel, c'est plus difficile d'apprendre car il faut du temps.
Pour revenir à cet article, en fait il serait judicieux de voir les paradigmes en parallèle un peu comme on apprend une langue étrangère en parallèle de langue maternelle. Comme toujours, il faut du temps et une bonne méthode d'apprentissage !
J'ai déjà cité plus haut ce avec quoi j'étais d'accord, mais je vais expliciter quelques points :
Comme on l'a soulevé dans les posts ci-dessus, cela dépend entièrement de ta formation.
Pour moi, physicien à la base, je pense "objet", mais sans les termes que tu utilises...
Et je me sers de C comme un langage "objet" : j'ai des encapuslations, j'ai des "classes", des "instances", j'ai des méthodes, j'ai des modules par objets, j'ai des méthodes "de classe", etc etc...
Pour moi en tant que physicien ayant appris (avec 3h de formation) le Fortran IV comme premier langage, un langage "procédural" est "naturel" en ce sens qu'il ne nécessite pas de notions supplémentaires par rapport à la base de ce que je veux faire : lire/écrire des fichiers, faire des calculs, formatter et imprimer des résultats.
La modélisation de ce sur quoi je travaille est justement une modélisation, qui n'a rien à voir avec le langage avec lequel je vais la programmer. Les notions nécessaires à cette modélisation sont purement liées au problème physique auquel je fais face.
Une fois ceci fait, je la programme.
Comme de plus j'ai passé pratiquement les 27 années de ma vie professionnelle a faire des logiciels avec de lourdes IHM, la programmation événementielle m'est familière, pour ne pas dire automatique.
Ce qui fait que, les 2 cumulés, je programme en C basé sur une structure événementielle, avec des objets physiques, possiblement héritant de certains autres, avec des méthodes spécifiques pour certains objets.
Donc, pour terminer, c'est uniquement parce que dans l'enseignement on vous a appris l'OO que vous trouvez ça "naturel" et plus facile à exploiter. Pour moi ce n'est pas naturel et c'est plus difficile à exploiter.
Donc je ne te crie pas dessus, je dis simplement que ton point de vue est biaisé..
Absolument. Car le langage n'est rien, c'est comment on l'utilise...
Là encore, pourquoi vouloir faire mal pendant un certain temps (le temps d'apprentissage afin de passer maître) ce qu'on peut faire bien instantanément avec un outil qu'on maîtrise ??J'admet que la POO n'est pas facile. J'ai pas de honte à dire qu'il m'a fallu des années pour comprendre, mais surtout de vouloir approfondir le sujet. Et sur ma petite experience perso, ceux qui ont eu un long passé avec le procédural ont eu du mal a comprendre et puis il y a ceux qui ne comprendrons jamais alors qu'ils savent programmer en procédural
Ce n'est pas "la mode" ou "l'enseignement" ou "les croyances" qui serait une raison de changer. Ce serait l'efficacité.
Or quelqu'un (et c'est valable pour tous les métiers) qui possède son métier et ses techniques, pourquoi devrat-il en changer ??
Si son résultat est aussi fiable et simple que celui obtenu par quelqu'un d'aussi expérimenté dans une autre technique, quelle serait la raison ?
Absolument d'accord. Et cela rejoint mes observations depuis le début de ces débats (dans les autres fils également).
On ne fait pas mieux avec l'enseignement d'aujourdhui. On fait différemment. Mais quelqu'un de bon avec d'anciens outils fera qelque chose de mieux que quelqu'un de médiocre avec les nouveaux.
Quand on lit :
et que l'on regarde les journaux, entre les retards d'Airbus et autres échecs retentissants ces dernières années, projets se basant pourtant sur les dernières "méthodologies", "normes" (CMMi niveau 3 et au dessus), formalismes (UML et autres), on a globalement du mal à voir l'amélioration...
- Mathematics requirements in CS programs are shrinking.
- The development of programming skills in several languages is giving way to cookbook approaches using large libraries and special-purpose packages.
- The resulting set of skills is insufficient for today’s software industry (in particular for safety and security purposes) and, unfortunately, matches well what the outsourcing industry can offer. We are training easily replaceable professionals.
Loin de moi l'idée d'être polémique, puisque j'ai déjà mentionné ce avec quoi j'étais d'accord plus haut. Je relève simplement certains faits qui ont l'air d'apparaître comme "allant de soi" pour certains (ici et ailleurs), mais qui sont loin d'être établis...
Je pense que cette citation résume ma pensée:
Ce qui veut dire que je ne suis non plus borné à la POO, que les langages fonctionnels peuvent aussi m'interesser."if the only tool you have is a hammer, every problem looks like a nail".
Le truc aussi, c'est que dès qu'on bosse dans de grosses structures, le choix de paradigme est imposé. Là ou je bosse, c'est COBOL impératif pour les batchs et Java objet pour les transactions. Etant parfois amené à passer d'un camp à l'autre, il vaut mieux être capable de penser des deux manières.....
Sinon, +1000 avec souviron : un médiocre avec une bonne méthode va transformer de l'or en chair à saucisses. J'ai connu un exemple de specs UML magnifiques(sans ironie) "retravaillées" par une ignare et qui ont finies illisibles. L'outil, là encore, était excellent. Mais appliqué par des gens qui ne le comprennent pas, le résultat est habituel. Et le médiocre de se cacher derrièrre CMMIUMLISOEAQF pour masquer ses propres insuffisances et sortir le parapluie.
Après, si on me fournit un quarteron de petits jeunes qui ne savent penser qu'objet, je n'aurait aucun scrupule à utiliser leur savoir-faire au maximum. Si je récupère des anciens formés à l'impératif, mon choix d'outils sera sans doute différent.....
+1, vaut mieux avoir plusieurs cordes à son arc. Au delà du paradigme, le langage est aussi imposé.
En règle général, c'est pas le développeur qui choisi
+1
J'osai pas en parlé, mais c'est absolument vrai. Sans aller très loin, avec Merise, on est déjà bien servi.
Je ne suis pas sûr de comprendre. Tu as l'air de dire que tu n'es pas d'accord avec moi mais ta conclusion va dans le même sens… quid donc ?
- oui, j'ai pas lu jusqu'au bout. En principe, l'un ne doit pas occulté l'autre ... en théorie.
Non, mais il peut ou non propager...En règle général, c'est pas le développeur qui choisi
Soit par un certain "prosélytisme", comme ce qu'on voit souvent ici, soit par "ignorance" lorsqu'il est à un poste pour sélectionner des candidats ou des techniques...
Je ne sais plus quoi penser à ce sujet. La mondialisation donne un pouvoir absolu aux mastondontes de l'informatique, ça me fait dég**ler. On est HS.
Voilà un point qui m'enchante en POO. On part d'une analyse qui descend jusqu'aux diagrammes de classe. Et les solutions exemples traités en UML semblent tellement parfait qu'on se croit dans un rêve.
Non pas du tout..
Depuis une dizaine d'années, tout est sélectionné Objet.
Mais ce n'est pas que de la reponsabilité des "mastodontes". Chacun y a sa part : enseignement, "prosélytisme" de jeunes enthousiasmés, "ignorance" et suivi de décideurs. Mais donc aussi toute personne travaillant en informatique, y compris comme simple développeur..
C'est bien pour ça qu'on disait plus haut : cela se vaut, et c'est fortement teinté par ta formation.
...pour peu que les gens qui font les specs soient compétents. Et en impératif, désolé, mais quand les specs sont bien faites, il n'y a plus qu'à dérouler - ça m'est arrivé aussi(et c'est aussi rare). C'est juste une autre manière de penser. Au final, on fait la même chose - juste suivant une autre philosophie. Et quand les specs UML sont massacrées, ça donne le même résultat qu'en impératif.
Conception, pas spec.Et quand les specs UML sont massacrées, ça donne le même résultat qu'en impératif.
Exit, les écrans monochrome (pas partout). C'est quand même un progrès.Depuis une dizaine d'années, tout est sélectionné Objet.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager