Grosso-modo je plussoie Chris_27, je vais juste réagir sur 2 points

- "Et au risque de me répéter, la POO n'apporte pas de gain ni dans la structure du code, ni dans sa maintenabilité, ni dans sa réutilisabilité. "
Hum, ton post d'après vante les mérite du couplage héritage/polymorphisme. Je t'accord la réutilisabilité, mais rien que ce couplage apporte un gros gain pour la structuration et surtout la maintenance, à moins que paradoxalement, t'aies une manière d'aborder la POO purement procédurale

" dans la mesure où un code en POO est environ 4 fois plus long que son équivalent en fonctionnel, j'ai envie de dire que non. " Ah bah oui, il semble bien que t'aies une conception prodécurale ^^

J epense que l'avantage principal de la POO est qu'il apporte une facon de penser qui est plus naturelle pour la majorite des programmeurs. Chris mentionne que la programmation fonctionnelle est beaucoup plus concise que la POO. C'est certainement vrai, mais personnellement des etudiants qui sont dans mon labo en ce moment, je ne pense pas qu'un seul arrivera a se plonger dans un code ecrit en programmation fonctionnelle. Parcontre tous comprendront un code ecrit en programmation objet.

Je pense que c'est pour ca que la POO a ete aussi populaire dans ces 20 dernieres annees. L'unite de la programmation objet est une representation d'un concept physique. L'unite de la programmation fonctionnelle (ou imperative) est calculatoire. Ils sont moins naturels.

"Hum, ton post d'après vante les mérite du couplage héritage/polymorphisme. "
oui, parce que c'est ce mécanisme là qui offre une vraie possibilité d'extension au code. On peut ajouter ou changer une implantation d'une la classe abstraire sans impacter le reste du code. C'est là la vraie force de la POO.

Note bien que j'ai dit "ajouter" et "changer". Ce n'est donc pas de la réutilisabilité. Ce n'est pas non plus de la maintenance, puisque il y a du neuf à la fin de l'opération. Et enfin ce n'est pas de la structuration... elle a été faite bien en amont quand il a été décidé de faire de la POO, puis de mettre en place une structure avec une classe abstraire dont on a alors fixé la signature/le type/la déclaration.

Pour le reste, je pense que si tu passais les 6 prochains mois de ta vie à coder en Haskell, tu comprendrais mieux ma vision (absolument pas) procédurale des choses.

Yep, mais la maintenance ne se limite pas à l'optimisation. Tu m'arrêtes si je dis une connerie, mais l'informatique est le seul domaine où la maintenance est un concept abstrait, puisqu'il faut voir évoluer le contexte pour en avoir besoin. Du coup l'une des définitions de la maintenance devrait être de pouvoir modifier la structure en fonction des besoins du dit contexte (virtuel ou réel).

Pour ma remarque sur la conception procédurale, c'était pour te chatouiller sur le fait de mesurer la lisibilité du code avec le nombre de lignes, mais je ne sais effectivement pas quelle logique à donné naissance à Haskell, donc il y a surement des éléments qui m'échappent

Godrik Je ne sais plus de qui il vient, mais ça me rappelle un peu l'adage "Montre-moi ton code, dissimule tes structures de données, je continuerai à être mystifié. Montre-moi tes structures de données et je n'aurai sans doute pas besoin de voir ton code, il me semblera évident."

Du coup je suis pas sur que ce soit spécifique au contraste fonctionnel/OO , même si ça apporte un aspect de lisibilité plus naturel, comme tu dis.

Fais le test, donnes leur les headers en pâture pour voir

]pseudotest[ : "Yep, mais la maintenance ne se limite pas à l'optimisation." la maintenance n'a rien à voir avec l'optimisation (et je n'ai jamais parlé d'optimisation d'ailleurs).

La maintenance de code, c'est s'assurer que le code continue de fonctionner correctement une fois livré. C'est donc essentiellement de la correction de bugs et des correctifs mineures liés à l'évolution de l'environnement (libs, OS) sur lequel le code est exécuté.

" Du coup l'une des définitions de la maintenance devrait être de pouvoir modifier la structure en fonction des besoins du dit contexte (virtuel ou réel). " bien sûr que non. Ce que tu décris, ça peut être une clause du cahier des charges demandant la poursuite de développement (ou au moins la possibilité de le faire) en cas de besoin. En ce sens, c'est de l'évolutivité et non de la maintenance.

SoueulsDotNet : "Mouais les langages fonctionnels ont aussi leur limite hein ?" je t'arrête tout de suite avant que tu ne me fasses dire quelque chose que je n'ai pas dit. Mon point est simplement que toutes les histoires de maintenabilité/structuration/réutilisabilité du code ne sont pas propres à la POO, et donc que c'est faux de dire que l'avantage de la POO est qu'elle permet toutes ces choses.

On fait des choses très élégantes en programmation fonctionnelle. C'est juste que ce n'est pas très répandu en entreprise pour le moment. Comme la programmation par aspect. Comme la programmation orientée objet dans les années 80, j'imagine.

"dans la mesure où un code en POO est environ 4 fois plus long que son équivalent en fonctionnel, j'ai envie de dire que non. Après, ma conception du code facile à lire, à développer et à maintenir implique que le code doit être le plus court possible"

Absolument pas d'accord. Tu écris souvent plus avec OO (même si les IDE comme Eclipse font qu'au final tu tapes pas beaucoup plus de code, voire moins), mais ce n'est ni plus difficile à lire, ni à développer ni à maintenir. Un code concis peut être une vraie plaie à lire et un code long mais structuré peut se lire très simplement. Ecrire le moins de caractères possibles n'est pas une règle du génie logiciel.
Et puis bon, la phase où on écrit une masse de code en POO, c'est lorsqu'on créé des bibliothèques et qu'on veut parer proprement à toutes les utilisations possible. Pour un produit fini, la POO ça permet d'être rapide. Il ne me faut pas plus d'instructions en Java qu'en C pour créer une fenêtre contenant un bouton qui fait "Hello World" quand on clique dessus.

"Maintenir = Faire rester quelqu'un, quelque chose dans une position, une situation données."

Sauf qu'un code, si personne n'y touche délibérément, il reste toujours le même lors de l'utilisation du logiciel final (contrairement à une machine qui va s'user ou se corroder). Serait-tu en train de dire que le terme maintenance est impropre quand on parle d'un logiciel ? A noter que corriger des bugs présents dans une version, c'est apporter des évolutions au programme (et non le faire rester dans sa position).

"C'est une mauvaise interprétation de croire que ces outils de conceptions de code sont là uniquement pour faire de la POO. "

UML ne sert pas qu'à faire de la POO, je n'ai pas dit le contraire. Mais implémenter un programme UML sans POO c'est atroce. UML et l'objet c'est quand même intimement lié.

"En vrai, les autres paradigmes apportent leurs propres problèmes et solutions. La question n'est donc pas tant de savoir si je pourrais faire du design pattern"

Pas besoin de grosses connaissances en DP, moi-même j'en ai peu.

"J'ai deux définitions pour les design patterns :
1. astuce pour résoudre un problème technique complexe en POO.
2. technique utilisée par un ingénieur pour résoudre un problème tout en évitant d'analyser exactement ce problème. "

Pour moi un DP c'est surtout un outil de modélisation. Pas besoin de réinventer ce qui a déjà été pensé. Après on peut tout a fait se passer des DP pour développer, autrement dit, les repenser par soi-même. Mais ce serait un peu recréer A* à chaque fois qu'on a envie de recalculer un plus court chemin.

"Et là, la réponse en entreprise est : avec la POO, on ne sait faire que ça. "

Il faut se demander pourquoi. Les entreprises sont relativement rationnelles, et si la POO a été retenue par rapport à l'impératif ou au fonctionnel qui existaient pourtant bien avant, c'est qu'il y a une bonne raison. Un choix a été fait à un moment donné par quasiment toutes les entreprises du monde. Ou bien elles ont toutes trouvé des avantages à ce paradigme qu'elles ne trouvaient pas chez d'autres, ou bien elles ont toutes suivies exactement en même temps un effet de mode. Mais alors pourquoi ce n'est pas les langages fonctionnels qui ont été concernés par cette mode ? En pratique ce qu'il ressort le plus souvent des langages fonctionnels c'est que c'est très élégant, mais que l'effort de concentration nécessaire pour écrire ou relire du code fonctionnel est bien plus important qu'avec l'objet : c'est moins intuitif, on pense naturellement en termes d'objets et non en terme de fonctions.

Après il y a les goûts et les couleurs. J'ai du coder 6 mois avec du fonctionnel, et j'ai détesté car ça ne me paraissait pas naturel. Peut-être que si j'avais commencé avec le fonctionnel ce serait l'inverse ?

"mais ce n'est ni plus difficile à lire" c'est de facto plus long (et donc plus fatigant) à lire. ça ne dérange pas certain, mais moi ça me dérange.

"Serait-tu en train de dire que le terme maintenance est impropre quand on parle d'un logiciel ?" non, je dis juste que ça veut dire maintenir (au sens du dictionnaire). Qu'on ne vienne pas me dire après que la POO permet de maintenir du code quand les exemples qu'on me donne sont l'évolution de code. De tels exemples sont pertinents, mais ils ne contredisent pas le fait que la POO n'apporte pas plus qu'un autre paradigme en terme de maintenabilité.

"UML et l'objet c'est quand même intimement lié. " évidemment, la syntaxe d'UML a été conçue pour l'OO à la base. Mais tout ce que ça prouve, c'est qu'on a des outils pour modéliser/structurer du code en POO. Et ce que je dis, c'est que ceci n'a absolument rien de propre à la POO.

"Mais ce serait un peu [stupide de] recréer A* à chaque fois qu'on a envie de recalculer un plus court chemin. " ça ne le devient que lorsqu'on a bien analysé les besoins et les capacités des implantations dont on dispose.

Je reproche justement aux gens qui me parlent trop de Design Pattern (et de POO en général) d'oublier qu'il faut toujours analyser la situation avant de choisir la solution à adopter.

"si la POO a été retenue [...] c'est qu'il y a une bonne raison."
je vois plusieurs raisons :
1. c'est plus facile de faire illusion avec de la POO (jargon technique, code volumineux, effet de mode...)
2. c'est ce qui est globalement le plus enseigné (au moins en France)
2bis. le fonctionnel en revanche c'est peu enseigné, et surtout très mal.
3. on a oublié pourquoi on ne faisait pas programmation fonctionnelle, et surtout pourquoi la raison n'a plus lieu d'être aujourd'hui (parce que oui, c'était lent à l'exécution un programme codé en fonctionnel ... il y a 15 ans).
4. on a la flemme de changer ses habitudes, ou du point de vue entreprise, on ne veut pas prendre de risque.

De mon point de vue, seule la 2bis est une bonne raison.

"Mais alors pourquoi ce n'est pas les langages fonctionnels qui ont été concernés par cette mode ?" parce qu'à l'époque, le C++ c'était plus efficace et moins dépaysant que le Standard ML ou Haskell (ou Lisp). Le choix me parait logique,

PS: j'ai commencé par le C en vrai.

PPS: et je n'ai jamais voulu lancé un débat fonctionnel VS POO (d'ailleurs, j'ai retardé au maximum le moment où j'allais parlé de programmation fonctionnelle). Le seul but de mon intervention était (et est toujours) de souligner le vrai intérêt de la POO (= la possibilité d'évolution du code) et de nier les autres intérêts couramment avancé mais qui n'en sont pas.