Discussion :

[sekaijin]

mais ce que tu dis là st tout aussi vrai pour toute les approche de la programation ce n'est pas propre à la POO.

on ne choisis un langage non pas par rapport au besoin mais par rapport à soit.

c'est malheureux mais c'est ainsi le développeur va toujours cherché à faire ce qu'on lui demande avec l'outil qu'il maitrise le mieux et non avec le plus adapté.

et si le besoin est de faire un prélèvement chirurgical et que le developpeur maitrise la pelleteuse mecanique il utlisera la pelleteuse

il en va ainsi aussi pour la PP un développeur qui maitrise la Programation Procédural là où la Programmation Fonctionnelle alors que la POO est plus adapté, utilisera la PF ou la PP et ce sera tout aussi catastrophique.

Mais au delà de ça qui parmis les développeurs se pose et se demande si l'utilisation de chose comme les moteurs d'inférence ou la programation par contrainte ou toute autre approche plus mathematique ne serait pas à envisager ?

tout ce que tu dis est vrai pour la POO mais c'est aussi vrai pour la PP et pour toutes les approches.

je suis sur que si on fait un sondage sur le site que les approche multi-agents ou la programmation par acteur par exemple n'est jamais envisagé.

les approches de la programmation sont très variées bien plus qu'on ne l'imagine.

pour moi dire que la POO c'est mauvais c'est comme dire que la voiture c'est mauvais ou que le ciel beu c'est mieux que la pluie ça na pas de sens.

A+JYT

[pragmatique]

Je suis globalement d'accord avec ce que tu dis, simplement quelqu'un qui ne maitrise pas trop la PP arrivera tant bien que mal à maintenir du code qui n'est pas à lui et dont la logique lui échappe parfois (il suffit de réecrire un bout du code / une fonction entière pour retomber sur ses pattes).
Par contre quelqu'un qui ne maitrise pas vraiment la POO (comme moi je l'avoue, je ne connais/utilise que les bases) ne pourra maintenir du code issu de la POO que s'il est "bien pensé" : du code POO "pourri" (au niveau conceptuel surtout) est inmaintenable pour quelqu'un qui ne maitrise pas tous les concepts.

Et dans la vraie vie (en entreprise), le code est quasiment toujours malfoutu (pour des raisons de coût/délais tout simplement).

Donc à choisir je préfère du malfoutu PP que POO.

NOTE: pour les moteurs d'inférence et la programmation par contrainte (comme dans le langage Prolog) c'est effectivement très performant pour certains problèmes bien particuliers mais la encore si on ne maitrise pas les concepts on court à la catastrophe.

[sekaijin]

mais là encore c'est aussi vrais pour la PP
un code merdique en PP sera tout aussi non maintenable.

et je ne suis pas d'accord sur le fait qu'un developpeur innexpérimenté en PP arrive à maitriser un code qui ne lui est pas comprehenssible.

A+JYT

[pragmatique]

un code merdique en PP sera tout aussi non maintenable.

Et bien en 15 ans de pratique je n'ai jamais trouvé un seul code en PP que je n'arrive pas à maintenir (quitte à réécrire quelques morceaux) et pourtant j'en ai vu des horreurs.

et je ne suis pas d'accord sur le fait qu'un developpeur innexpérimenté en PP arrive à maitriser un code qui ne lui est pas comprehenssible.

Justement en PP n'y a souvent pas grand chose à "comprendre" car tout est à plat, il suffit de suivre le fil d'ariane pour trouver la sortie du labyrinthe.

[Paul TOTH]

Et bien en 15 ans de pratique je n'ai jamais trouvé un seul code en PP que je n'arrive pas à maintenir (quitte à réécrire quelques morceaux) et pourtant j'en ai vu des horreurs.


Justement en PP n'y a souvent pas grand chose à "comprendre" car tout est à plat, il suffit de suivre le fil d'ariane pour trouver la sortie du labyrinthe.

il es vrai qu'en OO tu as des concepts qui rendent la lecture parfois assez complexe :
- les événements, qui font qu'on ne sait pas forcément à quel moment un code est exécuté
- les méthodes ou classes virtuelles abstraites (ça existe sous Delphi et j'imagine dans tous les langages), à la lecture, tu ne sais PAS quel code est exécuté
- le polymorphisme, finalement quel est le type réel d'un objet ? quel code est invoqué ?

si tu as une vision globale du projet ce sont des atouts, tu te fiches de l'implémentation, l'objet fera ce qu'il doit faire; mais quand tu plonges dans le code pour le comprend, ce sont des pièges.

le pire étant évidemment d'avoir un source que tu ne peux pas compiler (mauvaise plateforme, absence du compilateur, problème de version, traduction depuis un autre langage...) et que ton seul cerveau doit comprendre ce qu'il se passe c'est un exercice auquel je me livre régulièrement pour porter du code C++ vers Delphi :S

mais tu peux faire aussi complexe en PP dès que tu pars dans des pointeurs de fonctions et de donnée.

[deuz59]

Et bien en 15 ans de pratique je n'ai jamais trouvé un seul code en PP que je n'arrive pas à maintenir (quitte à réécrire quelques morceaux) et pourtant j'en ai vu des horreurs.

Justement en PP n'y a souvent pas grand chose à "comprendre" car tout est à plat, il suffit de suivre le fil d'ariane pour trouver la sortie du labyrinthe.

La réécriture a un coût, tu y passes du temps, sans compter les risques d'inefficacité/effet de bord...celui qui passera derrière toi réécrira de nouveau tout, etc...

Chacun aura son "fil d'Ariane", et plus on avance, plus le paquets de noeud grossira avec un code toujours aussi non maintenable.

Le fait que la POO structure permet justement d'éviter cela, mais encore faut-il qu'elle soit utilisée a bon escient.
Si c'est mal structuré à la base et qu'en corrigeant tu n'envisages pas ou n'est pas capable de faire mieux, alors oui la POO ne sera qu'une source d'ennui supplémentaire.
C'est alors un problème de compétence et non de techno, tu feras pas mieux avec la PP, jusque que tu sauras faire.

Beaucoup cherches de fausses excuses dans la POO pour se dédouaner. Cet outil force à être structuré et trop de développeurs préfèrent directement implémenter pour rapidement avoir plein de lignes de code qui font quelquechose...peut être parceque c'est plus naturel/rapide et plus en adéquation avec la manière dont ils ont appris les choses...mais certainement pas parceque c'est la meilleure solution.

Justement en PP n'y a souvent pas grand chose à "comprendre" car tout est à plat

Tu résumes là ce qui, en mon sens, est la source des codes non maintenables et sûrement des critiques envers la POO : les développeurs préfèrent chercher comment on fait quelquechose ou déduire ce qu'un algo est censé faire ou lieu de réfléchir à ce qu'ils font/ce qui est fait...et là pour sûr, la PP leur met moins de bâtons dans les roues que la POO !!!

[Pelote2012]

c'est clair, il faut commencer par les bases, pour comprendre.
le langage objet ne serait rien sans ces bases.
Perso, mon premier boulot a été de codé en Fortran, alors le langage objet ...
Mais une fois les bases acquises, il ne faut pas passer à côté des langages objets, faut vivre avec son temps quand même.

[sekaijin]

Et bien en 15 ans de pratique je n'ai jamais trouvé un seul code en PP que je n'arrive pas à maintenir (quitte à réécrire quelques morceaux) et pourtant j'en ai vu des horreurs.


Justement en PP n'y a souvent pas grand chose à "comprendre" car tout est à plat, il suffit de suivre le fil d'ariane pour trouver la sortie du labyrinthe.

la programation evenementielle en PP lorsque la conception est mal faite
je peux t'assurer que c'est parfois une horreur
et Oui tu semble maitriser la PP et donc en 15 tu n'a jamais eu de pb de comprehention.

mais tu dis que quelqu'un qui ne maitrise pas la POO ne peux pas comprendre un code POO mal fait.

je dis quelqu'un qui ne maitrise pas la PP ne peux pas comprendre un code PP mal faite.

toi tu la maitrise donc tu n'est pas dans ce cas c'est tout.
en 35 ans je peux t'assurer que j'ai vu des horreurs partout. et ce n'est pas un pb de PP ou de POO. quand tu tombe sur des code spagghetti dont la structure semble relever plus du hazard que de la théorie des fractales avec des code qui s'empilent à ne plus en finir avec des fonction qui te change à la volé les pointeur sur les fonctions je peux t'assurer que quelqu'un qui ne maitrise pas ce genre de programmation va avoir le plus grand mal à comprendre ce que fait le code.

et non en POO tout n'est pas à plat.
par exemple GTK qui est je pense un des framwork les mieux structuré en PP pour faire des IHM. je dois dire que si ce framwork était complètement à plat bonjour la m#rd@ à maintenir. heureusement les concepteur ont penssé à hiérarchiser, à classer (ha tien même en PP on classe), bref structurer. mais pourtant même si ce framwork est particulièrement bien construit les concepts de PP ne suffisent pas et pour parvenir à l'écrire le C en tant que langage ne suffit pas. il faut en passer par la macro programmation.

et là lorsque le code est mal structuré mal foutu ça devient un vrai casse tête.

dans les langages dynamiques la plus part des developpeurs n'arrivent pas à maitriser la metaprogrammation c'est a dire du code qui produit du code qui ... qui produit un résultat. rt c'est normal car c'est un concept difficile à maitriser. mais les macro C ne sont rient de plus.
que du code qui produit du code qui produira un exe.

pour finir je ne connais pas beaucoup d'appli dont on puisse dérouler le fil du code du début à la fin.

aujourd'hui de façon explicite ou caché on fait de la programmation evénementielle, de la programmation réactive, de la programmation paralelle etc. et tous ça ne permet pas d'avoir un fil tout d'ariane.

c'est d'ailleur bien souvent parce que les developpeur pense la prog comme un fil d'arriane qu'on a certain bug

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
a=0;
a=a+1;
echo a;

ne donne pas nécessairement 1 c'est fondemental il faut dès le début se sortir cette idée de la tête. Non ce code ne donne pas nécessairement 1 il peut donner bien d'autre chose.

A+JYT

[pragmatique]

les développeurs préfèrent chercher comment on fait quelquechose ou déduire ce qu'un algo est censé faire ou lieu de réfléchir à ce qu'ils font/ce qui est fait

Réfléchir (trop) ça prend du temps comme je l'ai déjà dit, en entreprise le temps c'est de l'argent: la priorité est donc que ça fonctionne "raisonnablement" (dans tous les cas courants) pour un délai/un coût raisonnable lui aussi.
Et là seuls des très bons programmeurs (qui maitrisent à la fois la PP et la POO) pourront choisir la meilleure solution pour aller plus vite, les autres qui vont se cantonner à la POO vont se perdre en divagations qui feront perdre un temps précieux.
En PP au final quand on ne maitrise pas trop, on peut toujours pondre un truc horrible à la va vite pour au moins "avancer" (même si effectivement ça explosera en vol un peu plus tard).
En POO quand on ne maitrise pas, on reste bloqué sur certaines étapes et on n'avance plus ... au bout d'un moment celui qui paye voit rouge (surtout dans une TPE, PME) et on fini assis sur une charrette.

[Paul TOTH]

Réfléchir (trop) ça prend du temps comme je l'ai déjà dit, en entreprise le temps c'est de l'argent: la priorité est donc que ça fonctionne "raisonnablement" (dans tous les cas courants) pour un délai/un coût raisonnable lui aussi.
Et là seuls des très bons programmeurs (qui maitrisent à la fois la PP et la POO) pourront choisir la meilleure solution pour aller plus vite, les autres qui vont se cantonner à la POO vont se perdre en divagations qui feront perdre un temps précieux.
En PP au final quand on ne maitrise pas trop, on peut toujours pondre un truc horrible à la va vite pour au moins "avancer" (même si effectivement ça explosera en vol un peu plus tard).
En POO quand on ne maitrise pas, on reste bloqué sur certaines étapes et on n'avance plus ... au bout d'un moment celui qui paye voit rouge (surtout dans une TPE, PME) et on fini assis sur une charrette.

je ne pense pas, un mauvais développeur fera toujours de mauvais développement quelque soit sa forme.

tu as tendance à prendre le point de vue d'une développeur "qui se débrouille" en procédural et qui va se paumer en objet. Mais prend un développeur Java, il a toujours fait de l'objet car seul l'objet existe en Java (bien qu'on puisse se demander si un objet dont tous les membres sont statiques est encore un objet)...il sera complètement perdu en procédural alors qu'il sera à l'aise en objet. Sans garbage collector il va exploser la mémoire en un rien de temps sans comprendre pourquoi.

Il n'y a pas de raison de bloquer d'avantage sur l'objet que sur du procédural, et que tu utilises des lib ou des frameworks, c'est en connaissant tes outils que tu gagnes du temps.

[pragmatique]

je ne pense pas, un mauvais développeur fera toujours de mauvais développement quelque soit sa forme..

C'est exact, mais les concepts de la PP étant plus simples dans l'ensemble (même si le diable se cache parfois dans les détails), je reste persuadé qu'un mauvais développeur en PP arrivera tant bien que mal à pondre quelquechose, alors qu'un mauvais développeur en POO va à un moment ou un autre arriver sur une impasse qui lui parait insoluble.

tu as tendance à prendre le point de vue d'une développeur "qui se débrouille" en procédural et qui va se paumer en objet.

Sans doute un biais du à mon profil mais j'essaie malgré tout de rester objectif en me basant sur des observations faites quand j'ai collaboré avec d'autres personnes (qui avaient des profils très variés).

Mais toi aussi tu as un biais, tu es bon dans les deux

Il n'y a pas de raison de bloquer d'avantage sur l'objet que sur du procédural, et que tu utilises des lib ou des frameworks, c'est en connaissant tes outils que tu gagnes du temps.

Quid du temps pour acquérir cette connaissance dans les deux cas ?
L'effort initial n'est pas du tout le même en PP (une nouvelle lib par ex) et en POO (un nouveau framework).

[BenoitM]

Quid du temps pour acquérir cette connaissance dans les deux cas ?
L'effort initial n'est pas du tout le même en PP (une nouvelle lib par ex) et en POO (un nouveau framework).

Déjà j'ai un doute que librairie et framework soit lié à la PP ou à la POO

Sinon le temps sera égale quoique surement plus rapide dans un framework qui sont en général mieux structuré.
Le "problème" c'est qu'un framework te permet de faire beaucoup plus de choses et donc parrait parfois plus volumineux

Mais
1) Tu n'es pas obliger de tout lire
2) Si d'un coté tu as un framework et de l'autre 5 bibliotheques pour faire la même chose que le framework, le temps de lecture sera le même (voir plus long car dans un framework tu as une philosophie tandis que dans un 5 librairies différentes, tu auras peut-être 5 logiques différentes
Sans compter le temps que tu auras perdus à chercher les 5 bibliothèques alors qu'avec un framework "tout" t'es fourni directement

Il me semble surtout qu'on ne fait pas la même chose en PP et en POO.

Alors certes un programme en PP sans interface graphique, qui ne fait qu'un insert dans une table sera facilement lisible en PP mais quand tu as des programmes de milier de lignes avec des pointeurs de fonctions, la PP n'est pas toujours simple à lire

[pragmatique]

1) Tu n'es pas obliger de tout lire

Dans une lib c'est encore mieux tu n'est pas obligé de tout comprendre et tu peux sauter carrément tout ce dont tu n'as pas besoin immédiatement.

2) ... dans un framework tu as une philosophie tandis que dans un 5 librairies différentes, tu auras peut-être 5 logiques différentes

Il est bien plus facile de suivres plusieurs logiques même différentes (car individuellement elles restent plus simples qu'un gros framework) , qu'une seule "philosophie" qui t'oblige justement a entrer carrément dans la tête de celui qui a pondu sa "jolie" hierarchie.

Quand je dois rendre un dév. dans les délais, je n'ai pas le temps de philosopher, on en revient toujours au même problème.

[BenoitM]

Dans une lib c'est encore mieux tu n'est pas obligé de tout comprendre et tu peux sauter carrément tout ce dont tu n'as pas besoin immédiatement.

Je vois pas la différence entre une librairie et un framework sur ce point.
C'est le but de ce que tu fais qui va t'obliger ou non a utilisé une partie ou non du framework ou de la bibliothèque.
Part contre je vois une grosse différence entre une libraire/framework écrite en procédurale et une librairie/framework écrite en POO
D'un coté tu auras 10 objets , 50 méthodes et tous sera melanger.

Dans l'autre tu auras surement plus d'objets mais les méthodes seront liées aux objets.
Et quand je travaille avec l'Object "Connection" je me fou un peu de voir les méthodes des autres objets de ma librairies/framework

Il est bien plus facile de suivres plusieurs logiques même différentes (car individuellement elles restent plus simples qu'un gros framework) , qu'une seule "philosophie" qui t'oblige justement a entrer carrément dans la tête de celui qui a pondu sa "jolie" hierarchie.

C'est sur que quand un mec écris un des méthodes GetNomDuChamp/SetNomDuChamp l'autre utilise des propriétés le troisième NomDuChampGet NomDuChampSet c'est hyper pratique, hyperlisible.
Quand tu cherches une info tu dois te demander dans quelles documentation tu dois aller.

Pour faire du .Net/Java tu n'as pas besoin de connaitre plus de fonction que pour faire du c (PP)
Savoir qu'il faut faire printf() ou Console.Write() je pense pas que ca demande plus de temps

Je le dis et je le répète que se soit une librairie en PP ou POO tu devras faire le même effort pour comprendre la logique de la personne qui l'écrit.
Et même une petite libraire peut-être difficile à comprendre, tout dépend comment elle est écrite.
Tu as une libairie ou la connection doit-être ouverte avant de faire une requete une 2eme librairie ou la connection est directement ouverte à chaque Select que tu fais, ce n'est pas parce qu'elle est écrite en PP ou en POO que ca changer quelque chose. C'est le fonctionnement interne de la librairie.

Quand je dois rendre un dév. dans les délais, je n'ai pas le temps de philosopher, on en revient toujours au même problème.

Je te plains et je plains tes programmes en plus je ne pense pas que se soit très productif sur le long terme

Perso quand on m'a demandé de faire un programme qui execute une requete et qui sauve le résultat sous le format csv, je me suis un peu cassé la tête pour mettre la requete a éxécuté dans un fichier , mais quand j'ai du faire un programme pour éxécuté une 2ème et une 3ème requete j'ai pas du réécrire le même programme 3x, j'ai juste ajouté les requetes dans le fichier.
Et quand j'ai du modifié la requete, je n'ai pas du recompilier le programme et le redeployer sur la machine.

[sekaijin]

à te lire je comprends le "rejet" que tu exprime de la POO
tu as vraiment du mal à voir autement que ta propre façon de penser.

c'est assez étonnant de voir qu'à aucun moment tu envisage que quelqu'un puisse être dans la situation opposée.

A+JYT

[BenoitM]

C'est surtout qu'il critique la POO comme si tu étais obligé d'implémenter toutes les pratiques dans toutes les circontances sans compter qu'une partie de ces pratiques ne sont pas forcément liées à la POO.

[Paul TOTH]

c'est quoi le plus simple : OpenGL ou DirectX ?

le framework va apporter des objets génériques pratiques, des listes, des tableaux, de méthodes de tries sur ces objets, qu'on aura du mal à retrouver de façon aussi cohérente en PP

après c'est pas très dur de faire une liste chaînée et un quicksort sur des pointeurs...mais je ne suis pas convaincu que ce soit plus rapide à mettre en place.

après je vois des gens qui font des choses très surprenantes, comme utiliser un objet Memo (zone de saisie multilignes) pour charger un fichier texte et en lire le contenu...ceci dit ça fonctionne et ça n'est pas compliqué, c'est juste pas très conventionnel est-ce pire que d'allouer en procédural un buffer de 1024 octets pour lire 3 caractères et oublier de libérer le buffer ? je suis pas sur

PS: personnellement je déteste la complexe arborescence des objets DirectX et lui préfère de loin l'API contextuel d'OpenGL...quitte à l'habiller avec une couche objets plus digeste que celle de DirectX.

[pragmatique]

@Paul: j'aurai hélas bien du mal à donner un avis sur DirectX ou OpenGL , je ne m'en suis jamais servi (hormis la toute première version de DirectX donc autant dire à la préhistoire ).
Pour le coup du mémo je confirme en Delphi j'ai déjà vu un mémo invisible qui servait à charger le fichier de paramétrage de l'appli, ça surprend
Mais à la rigueur je préfère encore ça aux 10 classes imbriquées du vieux composant Indy FTP v9 qui de surcroit contient des bugs bloquants.
Tout ça pour gérer un dialogue FTP de base, je trouve ça abusif.

Pour les autres : ne changez rien, comme je l'ai dit plus haut pour la santé des TPE c'est une très bonne chose qu'il y ait de la POO partout dans les logiciels des grandes entreprises.

Bon c'est pas tout ça mais j'ai du boulot et il ne se fera pas tout seul ...

[BenoitM]

Bon c'est pas tout ça mais j'ai du boulot et il ne se fera pas tout seul ...

Vu l'heure du message du devrait penser à la POO


je sais c'est bas et facile mais j'aime bien

[pragmatique]

C'était bien tenté mais grâce à la productivité supérieure de la PP sur la POO j'ai pu avoir des tarifs compétitifs qui m'ont permis d'être 100% en télétravail depuis 5 ans donc métro boulot dodo c'est fini pour moi
Là par exemple je vais à peine démarrer ma journée car j'avais quelques paperasses à faire.
Je bosse souvent tard le soir (23h parfois) non pas à cause de la productivité mais à cause de la demande (en clair j'ai trop de clients).
Bon il faut que je me mette au boulot ... on ne me paye pas encore à surfer toute la journée