Discussion :

[gl]

ça dépend. En batch bancaire, les traitements durent toute la nuit, et doivent avoir fini avant 07h00. Pas besoin de micro-optimiser, mais une surcouche qui te coûte à chaque appel de fonction aussi simple(et fréquent) qu'un calcul de clef RIB?

Dans le même style de "ça dépend", j'ai apprécié la position de Sutter et Alexandrescu dans C++ Coding standard, où une des premières régles est, comme dans beaucoup d'ouvrage sur les bonnes pratiques : Don't optimize prematurly".
Et qui est immédiatement suivi de "Don't pessimize prematurly".

C'est exactement ce dont tu parles dans ton exemple, il n'est pas utile de faire de la micro-optimisation complexe et illisible tant que les mesures n'ont pas montré que ce n'est pas utile. Mais ce n'est pas une raison pour faire du code volontairement sous-optimal lorsqu'une meilleur alternative, tout chose égale par ailleurs, existe.


C'est le seul ouvrage de référence sur les bonnes pratiques où j'ai lu ça alors que ça me semble fondamental. C'est probablement évident pour de nombreux experts (d'où l'absence de cette mention), mais au vu du code que j'ai pu lire ça ne l'est malheureusement pas toujours pour le développeur standard !

[transgohan]

Depuis le temps que cet aspect des choses me turlupine, ce soir je me lance : est-ce que des tests pointus de comparaison ont été réalisés pour savoir si cette assertion était vérifiée ?

Si tu utilises un compilateur récent et maintenu pour ta cible alors non la comparaison est à 99% des cas en bénéfice du C, pas besoin de réécrire soit même l'assembleur.
Mais si tu prend un compilateur pour une cible qui date des années 1980-90 tu trouveras de nombreux cas où le compilateur n'optimise pas bien et qu'il est utile de porter cela en assembleur pour des sections critiques.

Au final on ne dit pas que le C est moins optimisé que l'assembleur.
On dit que certains vieux compilateurs ne sont pas aussi optimisés que ceux qu'on a à disposition de nos jours.

[Nebulix]

..., je ne vois pas pourquoi l'un serait plus lent que l'autre.

Merci d'éclairer ma lanterne.

Un exemple qui me vient à l'esprit concerne les images sous Delphi.
On peut accéder aux pixels par un tableau Pixels[], mais c'est épouvantablement lent. Il y a une autre façon, via des pointeurs beaucoup plus rapide. Je ne comprends pas pourquoi il y a une telle différence, je pense que Pixels doit à chaque appel tester pour tous les formats de pixel possibles, alors que scanline suppose que le programmeur sait à quoi il a affaire. Ecrire du code en assembleur permet de ne faire que le nécessaire alors qu'un compilateur est toujours obligé de voir plus large. Peut être mettre des résultats intermédiaires en mémoire au lieu de les laisser dans les registres du processeur.
Cela dit, ce genre d'optimisation est rarement utile sur la durée totale d'un programme mais peut l'être pour une procédure critique.
Par contre, pour ne pas devoir attendre des heures qu'un programme se termine, il faut bien réfléchir en amont aux meilleurs algorithmes, structures de données, etc.

[deltree]

Un débat intéressant mais il ne faut pas se laisser aller aux effets de mode, je trouve qu'il dresse un tableau un peu noir, et certains clichés sur la programmation objet.

Déjà il parle de jongler avec plusieurs objet en même temps et là c'est un défaut de programmation dans tous les paradigme: c'est du "plat de spagetti".
J'aimerais rappeler un des principes du SOLID, le S signifiant SRP pour Single Responsibility Principle. Un objet doit être autonome et testable seul: une fois qu'on est sur de son fonctionnement on peut le brancher aux autre sans crainte.

ça c'est pour lé théorie, et j'ai vu sur le thread "java11" un autre idée intéressante, c'est que la programmation en couche telle qu'on nous la fait pratiquer en Java, ce n'est pas de la programmation objet... et bien que convaincu à la fois par la programmation Objet et la programmation en couche, je suis assez d'accord:
On fait des couches de services Dao ou autre, qui sont stateless: ça reviens à un module de procédures
On fait des Bean avec uniquement des getter/setter: c'est des structures déguisées.

L'objet apparait néanmoins dès qu'on veut s'abstraire du produit utilisé: des drivers jdbc, des couches d'éccès Web, JMS...

Et c'est la que je veux en venir (désolé si je suis un peu long) c'est plus du multiparadigme: on fait du procédural (éventuellement encapsulé dans des classes singleton ...) tant qu'on n'a pas besoin de polymorphisme, et on passe à l'objet dès qu' veut gérer un certain niveau d'abstraction. ça permet de ne pas abuser de l'héritage et d'éviter le jeu de piste du "qui appelle qui". L'approche multiparadigme apparait dans d'autres langage: python, rust ... et aussi kotlin pour rester sur la jvm. Du reste en java, avec les lambda, on a aussi une approche fonctionnelle.

Quand à passer sur du pur fonctionnel comme c'est la mode, c'est comme vouloir à tout prix faire du pur objet, moi je ne suis pas convaincu, mais ce n'est que mon avis.

[mh-cbon]

J'aimerais rappeler un des principes du SOLID, le S signifiant SRP pour Single Responsibility Principle. Un objet doit être autonome et testable seul: une fois qu'on est sur de son fonctionnement on peut le brancher aux autre sans crainte.

mais c'est pas spécifique à la poo..... en procédurale la question ne se pose même pas.
En composition, tu tentes de faire solid aussi, pourtant tu n'hérites jamais.

ça c'est pour lé théorie, et j'ai vu sur le thread "java11" un autre idée intéressante, c'est que la programmation en couche telle qu'on nous la fait pratiquer en Java, ce n'est pas de la programmation objet... et bien que convaincu à la fois par la programmation Objet et la programmation en couche, je suis assez d'accord:

je sais pas à quoi vous faites référence, ça ressemble à de l'encapsulation.
Si on intéresser à l’étymologie du mot, on trouve cette acceptation commune "(Réseaux informatiques) Inclure un message dans une couche plus interne pour protéger l’accès et faciliter l’utilisation.".
En procédurale lorsque tu fais une fonction pour une requête sql, tu viens d'encapsuler un message sql dans un fonction.

On fait des Bean avec uniquement des getter/setter: c'est des structures déguisées.

Pour sauter dedans à pieds joints, donc pour faire réagir, c'est un exemple de ce qui m’apparaît comme une dégénérescence congénitale glorifiée en concept de bonne pratique.

L'objet apparait néanmoins dès qu'on veut s'abstraire du produit utilisé: des drivers jdbc, des couches d'éccès Web, JMS...

je vois rien de spécifique à la poo. c'est de l'encapsulation avec un interfaçage verticale..

Et c'est la que je veux en venir (désolé si je suis un peu long) c'est plus du multiparadigme: on fait du procédural (éventuellement encapsulé dans des classes singleton ...) tant qu'on n'a pas besoin de polymorphisme, et on passe à l'objet dès qu' veut gérer un certain niveau d'abstraction.

le polymorphisme n'est pas plus spécifique à l'objet. pour faire dans la raillerie, php, js, sont polymorphique.
Le polymorphisme paramétrique n'est pas spécifique à la poo, mais largement adoptée dans ces paradigmes, c'est un constat valable.

[el_slapper]

Mais si de telles optimisations doivent être faites, tu les fais après avoir identifié les goulots d’étranglements et avoir vu que tu avais effectivement des problèmes de performances.
Tu ne vas pas t'amuser à optimiser une fonction qui est appelée une fois par an.

J'ai pris l'habitude, ça coute 10 minutes, et je ne créais pas ce genre de fonctions tous les jours, non plus. Sur des applis de 10, 20, 30 ans d'âge, on passe beaucoup plus de temps en maintenance. Sur les nouvelles, c'était mon standard. Rapport cout-bénéfice généralement immédiat.

Ce n'est donc pas de l'optimisation prématurée, mais des bonnes pratiques/idiom. Comme par exemple utiliser des références constantes au lieu de copier, utiliser ++i au lieu de i++, parcourir les tableaux à partir du dernier index de préférence, faire quelques pré-calculs, vérifier la complexité algorithmique (e.g. O(1), O(n), O(n²),...) etc. etc.

Non, justement. Ce n'est pas de l'optimisation prématurée, c'est juste ne pas coder avec les pieds .

De toute évidence, on a pas le même vocabulaire. Il m'est arrivé, une fois, une seule fois, de faire un algo en O(n4), mais pour le coup, j'ai pris toutes mes précautions pour mesurer le temps consommé. 70 secondes, sur le fameux batch de 5 heures. Là, oui, hors de question d'optimiser plus, le monstre était déjà assez illisible comme ça(faire de la logique ensembliste en COBOL, ça n'est pas raisonnable, mais c'est un autre débat).

je parle d'optimisations simples et qui restent lisibles. Si vous appelez ça "bonnes pratiques", ma foi, je prends.

Vous confondez standard et dogme.

Un standard ne signifie pas qu'on ne puisse pas le remettre en cause, ni même qu'on soit obligé de l'utiliser.

Sauf si ce que tout le monde appelle "standard" est, de facto, dans votre définition, un dogme.

Sauf que cela n'est pas la "faute" à la POO. Ce n'est pas dû à l'essence de la POO, mais à l'incompétence de ses utilisateurs. C'est à dire qu'on pourrait retrouver les même problèmes dans n'importe quel autre paradigme si ses utilisateurs sont pour la plupart incompétents.

Revenons au niveau business. On a deux doctrines, on doit en choisir une, et on en a une qui est plus performante si on trouve des gens de qualité, et l'autre qui fait moins de dégats si on trouve des médiocres. On a beaucoup de mal à trouver des gens de qualité sur le marché. On fait quoi?

On se trompe donc de débat, c'est un problème de formation plus que de paradigme.

Je sais que je parle à un prof, alors ma réponse va sans doute être très, très mal perçue, mais...la qualité de la formation est une illusion. Enfin, jusqu'à un certain point. De nombreuses personnes n'ont pas la tournure d'esprit(je ne parle ni d'intelligence ni de potentiel ni de qualités, hein, juste de tournure d'esprit) pour faire un code correct. On peut leur donner le meilleur prof de l'univers, elles n'y arriveront jamais. Ça se mesure, hein.

Après, une bonne formation aide beaucoup à se mettre dans le bain, à entrer mieux dans les sujets, à prendre de bonnes habitudes, mais tout ceci ne sert à rien face à des gens qui n'ont pas la bonne tournure d'esprit. Ca vaut aussi pour d'autres métiers, chacun ayant sa propre tournure d'esprit (le comptable a intérêt à ne jamais accepter un centime d'erreur, l'informaticien à ne jamais assumer que la machine peut inférer les sous-entendus, le sportif professionnel qu'il peut se permettre de la relâche sur la préparation physique, etc.....). Une tournure d'esprit, ça ne s'apprend pas vraiment. Sois elle est sous-jacente, et il y a juste à la réveiller(ce qui peut être plus ou moins rapide), soit elle est absente, et il n'y a rien à faire.

Et des gens qui n'ont pas la tournure d’esprit vont quand même arriver, avec des scripts horriblement linéaires de 3000 lignes, à faire quand même 2-3 trucs utiles à leur employeur, en procédural(sans procédures, donc, j'ai déjà vu un monstre de 35 0 000 lignes avec 72 fois les mêmes 20 lignes de traitement d'erreur - mais ça marchait). Plus le paradigme utilisé est exigeant, et plus rares seront les gens capables de faire un truc vaguement utile. Le paradigme procédural est le moins exigeant, le paradigme fonctionnel le plus exigeant, l'objet est entre les deux.

Evidemment, quand on a les meilleurs, on ne se pose pas ce genre de questions. Quand on ne les a pas(et par définition, tout le monde ne les a pas), c'est plus compliqué.

(.../...)Quand à passer sur du pur fonctionnel comme c'est la mode, c'est comme vouloir à tout prix faire du pur objet, moi je ne suis pas convaincu, mais ce n'est que mon avis.

C'est le mien aussi - il faut connaitre tous les outils dans la boite à outils, et utiliser ceux qu'on a sans se poser de question - si ce n'est celle de l'utilité. Savoir si c'est du pur stylé? Si c'est maintenable et performant, honnêtement, la pureté du style, je m'en cogne. Il faut que ça marche, et que les gens qui passent derrière puissent maintenir. La qualité attendue des gens qui passeront derrière est donc un critère vital de choix - rien à voir entre mon éditeur de logiciels actuel, et les banques ou je traînais avant.

[Rizzen]

De mon point de vue, je pense pas que la POO soit le problème. Je suis de l'avis de beaucoup que le problème vient en amont et mon expérience me conforte dans l'idée

Je bosse depuis plus de 10 ans dans le dev. En France, les projets sont gérés par des personnes qui n'ont aucune connaissance même de la "technique" et qui ne veulent rien savoir, pilotent uniquement au coût, fond de "l'agile" un prétexte pour changer tout et tout le temps sans compensation, et considèrent les techniques comme des ressources interchangeable comme une barrette de RAM.

Et enfin on balance sur le projet des devs qui ne se posent même pas la question du pourquoi de la demande, donc dev sans comprendre. On leur met une pression monstre pour être dans les temps, n'ont aucune vision globale du projet et ne sont pas encadré par l'archi car il est toujours en mode pompier pour sauver le projet ou le précédent.

Si ça marche c'est la direction qui se jettent des fleurs, si ça marche pas on descend l'équipe technique.

Ca c'est pour du dev interne, quand c'est du progiciel, pour être rentable ça développe la demande bêtement mais sans aucune vision de maintenabilité car faut faire le truc le plus rapidement possible du moment que ça fait ce qu'on demande on s'en fou, le client paiera derrière pour le refaire. Car le commerciale, il vent son produit comme si il vendait des tapis et se contre fou que la réduction pour que le client accepte rend le projet infaisable, il aura sa prime sur ses objectif de ventes.

[mh-cbon]

@el_slapper c'est, pour moi, notoire qu'en info ya pleins de pisseurs de lignes venus là pour le pognon.

[SQUAL]

Bonjour à tous,

j'ai parcouru toutes les réponses de ce post.
Dommage qu'il y ait pas mal de hors sujet et d'attaques personnelles Les échanges m'ont l'air plus destructifs que constructifs.
Mais le débat est très intéressant pour moi, car il pourrait remettre en cause ma vision de la programmation.
Dans ce débat, on a l'air de vouloir comparer deux paradigmes : la prog fonctionnelle et la POO.
Serait il intéressant de tenter un "début de comparaison" entre les deux en programmant une petite appli impliquant un minimum d'objets metier, de fonctions etc ? à la maniere de todoMCV (http://todomvc.com/) dont j'apprécie la démarche.
Est ce qu'un paradigme ,par extension un langage qui utilise ce paradigme, n'a pas une influence sur les outils gravitant autour de ce langage ? (IDE, CI, déploiements ...)
En répondant à ces question, on aura peut être une idée de quel paradigme utiliser dans quel cas, non ?

[mister3957]

La simplicité est le contraire de la complexité

Il y a complexe et compliqué.

Si le problème est complexe alors sa résolution sera complexe, comme dans tout métier.

Le but du jeu est de maîtriser le côté "compliqué" sinon => dette technique.

Donc mauvais argument juste pour dire "la POO c'est d'la merde" gratuitement

[4sStylZ]

J’adore le fait que certains amène l’agile dans le débat. ou la problématique systématique du fait que les besoins changent…
Le sujet – en synthèse – c’est : la POO est il une erreur pour l’orga des bases de codes. Quel rapport avec la choucroute ?

Bref, mon avis là dessus : Tout dépend du projet, de l’équipe de l’entreprise etc.
De plus je trouve que les arguments utilisés par l’ingénieur déforment la réalité du terrain surtout l’histoire d’héritage.

[viper1094]

Utiliser ++i au lieu de i++

Why ?

[Pyramidev]

Le paradigme procédural est le moins exigeant, le paradigme fonctionnel le plus exigeant, l'objet est entre les deux.

En fait, le paradigme le plus exigent, c'est la métaprogrammation (qui, d'ailleurs, peut se combiner avec le fonctionnel et l'objet), car il faut penser comme un concepteur de langages. Mais aucun des langages très utilisés en entreprise n'est vraiment taillé pour ce paradigme.

[Lcf.vs]

De mon point de vue, je pense pas que la POO soit le problème. Je suis de l'avis de beaucoup que le problème vient en amont et mon expérience me conforte dans l'idée

Je bosse depuis plus de 10 ans dans le dev. En France, les projets sont gérés par des personnes qui n'ont aucune connaissance même de la "technique" et qui ne veulent rien savoir, pilotent uniquement au coût, fond de "l'agile" un prétexte pour changer tout et tout le temps sans compensation, et considèrent les techniques comme des ressources interchangeable comme une barrette de RAM.

Et enfin on balance sur le projet des devs qui ne se posent même pas la question du pourquoi de la demande, donc dev sans comprendre. On leur met une pression monstre pour être dans les temps, n'ont aucune vision globale du projet et ne sont pas encadré par l'archi car il est toujours en mode pompier pour sauver le projet ou le précédent.

Si ça marche c'est la direction qui se jettent des fleurs, si ça marche pas on descend l'équipe technique.

Ca c'est pour du dev interne, quand c'est du progiciel, pour être rentable ça développe la demande bêtement mais sans aucune vision de maintenabilité car faut faire le truc le plus rapidement possible du moment que ça fait ce qu'on demande on s'en fou, le client paiera derrière pour le refaire. Car le commerciale, il vent son produit comme si il vendait des tapis et se contre fou que la réduction pour que le client accepte rend le projet infaisable, il aura sa prime sur ses objectif de ventes.

C'est pile poil ce que je reproche aux dirigeants d'équipes de devs... et ce que je reproche aux devs de laisser faire. Et j'ajouterais aussi le gros problème des agences dans la stratégie "à quoi bon faire les choses proprement, maintenables, évolutives, etc., sachant que ceux qui feront la version suivante, ce sera sans doute un autre, sinon, au pire, on refacturera plein pot."

Mais, vraiment, côté développeurs, trop nombreux sont ceux qui n'osent pas dire "stop, on ne fait pas ça", quand un truc n'est pas raisonnable/légal/propre/sécurisé/... et se contentent de faire ce qu'on leur dit, alors que C'EST NOTRE EXPERTISE, si ce n'est pas nous qui y mettons un halte-là, qui va le faire ?

[Lcf.vs]

Why ?

Perso, j'ai proscrit depuis bien des années le ++i,comme le i++ (et idem avec le --), pour 2 raisons toutes simples :

1. être au plus proche possible du pseudo-code (code plus simple à comprendre pour un néophyte)
2. parce qu'en cas de pas différent de 1, il faut changer la notation (réduction de cohérence)

Je fais donc toujours des i += step ou i -= step.

[Sarénya]

Why ?

i++ et ++i ont une valeur de retour, ils ne font pas que modifier i.

Quand tu fait i++, tu retourne la valeur de i avant son incrémentation donc il te faut allouer de l'espace pour stocker i avant son incrémentation pour pouvoir le retourner après, bêtement i++ c'est ça :

Code :

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

1
2
3
4
5
int i_plus_plus(int &i){
    int iTemp = i;
    i+=1;
    return iTemp;
}

alors que ++i retourne juste i+1.

Je ne sais pas si c'est exactement ce qui se passe niveau machine mais si tu n'as pas besoin de savoir la valeur de i avant, il vaut alors mieux utiliser ++i.

Mais comme dit mon vdd on peut éviter de s'en servir

[el_slapper]

En fait, le paradigme le plus exigent, c'est la métaprogrammation (qui, d'ailleurs, peut se combiner avec le fonctionnel et l'objet), car il faut penser comme un concepteur de langages. Mais aucun des langages très utilisés en entreprise n'est vraiment taillé pour ce paradigme.

Tiens, je viens de découvrir un mot. Bon, je connaissais un poil le concept, mais je ne savais pas que ça avait un nom. Quelle horreur. Le truc ultraélitiste réservé à une poignée d'élus. Typiquement ce qu'il ne faut pas faire dès qu'on quitte les hautes sphères universitaires.

[deltree]

Bonjour à tous,

j'ai parcouru toutes les réponses de ce post.
Dommage qu'il y ait pas mal de hors sujet et d'attaques personnelles Les échanges m'ont l'air plus destructifs que constructifs.
Mais le débat est très intéressant pour moi, car il pourrait remettre en cause ma vision de la programmation.
Dans ce débat, on a l'air de vouloir comparer deux paradigmes : la prog fonctionnelle et la POO.
Serait il intéressant de tenter un "début de comparaison" entre les deux en programmant une petite appli impliquant un minimum d'objets metier, de fonctions etc ? à la maniere de todoMCV (http://todomvc.com/) dont j'apprécie la démarche.
Est ce qu'un paradigme ,par extension un langage qui utilise ce paradigme, n'a pas une influence sur les outils gravitant autour de ce langage ? (IDE, CI, déploiements ...)
En répondant à ces question, on aura peut être une idée de quel paradigme utiliser dans quel cas, non ?

Todobackend ça existe :https://www.todobackend.com/

Après je pense qu'il est faux de penser qu'il existe un bon et un mauvais paradigme, il y a juste celui qui est adapté à votre équipe ou pas. Et ça ne se limite pas à la POO ou fonctionnelle, la procédurale existe encore (et d'ailleurs comme je disais, la plupart des programme java sont implémentés "à la procédurale").

Et on peut difficilement comparer point par point, rien qu'en java, on peut implémenter en Vertx, Spring boot, JEE avec ou sans JDBC, Hibernate. A chaque fois les choix d'archi seront différents.
En scala aussi les choix de lib de persistence vont changer le résultat.

[Edrixal]

Tiens, je viens de découvrir un mot. Bon, je connaissais un poil le concept, mais je ne savais pas que ça avait un nom. Quelle horreur. Le truc ultraélitiste réservé à une poignée d'élus. Typiquement ce qu'il ne faut pas faire dès qu'on quitte les hautes sphères universitaires.

Sa dépend... Tu veut pouvoir te la péter en humiliant les autres devs en sortant "C'est pourtant pas compliquer c'est la base ça...", ou pas ? ^^

[el_slapper]

Sa dépend... Tu veut pouvoir te la péter en humiliant les autres devs en sortant "C'est pourtant pas compliquer c'est la base ça...", ou pas ? ^^

je suis horriblement triste parce-que tu as raison.