Navigation

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

  1. #61
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    juin 2002
    Messages
    2 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : juin 2002
    Messages : 2 165
    Points : 4 478
    Points
    4 478
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    ç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 !

  2. #62
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    2 940
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 940
    Points : 8 667
    Points
    8 667
    Par défaut
    Citation Envoyé par Jipété Voir le message
    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.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  3. #63
    Membre expérimenté
    Profil pro
    chercheur
    Inscrit en
    avril 2004
    Messages
    815
    Détails du profil
    Informations personnelles :
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : chercheur

    Informations forums :
    Inscription : avril 2004
    Messages : 815
    Points : 1 351
    Points
    1 351
    Par défaut
    Citation Envoyé par Jipété Voir le message
    ..., 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.
    Ce qui s'énonce clairement se conçoit bien ( Le hautbois)

  4. #64
    Membre confirmé
    Inscrit en
    mai 2007
    Messages
    334
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 334
    Points : 492
    Points
    492
    Par défaut
    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.

  5. #65
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    février 2016
    Messages
    185
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2016
    Messages : 185
    Points : 412
    Points
    412
    Par défaut
    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.

  6. #66
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 062
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 062
    Points : 28 052
    Points
    28 052
    Par défaut
    Citation Envoyé par Neckara Voir le message
    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.

    Citation Envoyé par Neckara Voir le message
    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.

    Citation Envoyé par Neckara Voir le message
    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.

    Citation Envoyé par Neckara Voir le message
    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?

    Citation Envoyé par Neckara Voir le message
    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é.

    Citation Envoyé par deltree Voir le message
    (.../...)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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  7. #67
    Membre habitué Avatar de Rizzen
    Profil pro
    Inscrit en
    janvier 2008
    Messages
    115
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France

    Informations forums :
    Inscription : janvier 2008
    Messages : 115
    Points : 141
    Points
    141
    Par défaut
    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.
    Java'ldire à tout le monde

  8. #68
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    février 2016
    Messages
    185
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2016
    Messages : 185
    Points : 412
    Points
    412
    Par défaut
    @el_slapper c'est, pour moi, notoire qu'en info ya pleins de pisseurs de lignes venus là pour le pognon.

  9. #69
    Membre habitué
    Inscrit en
    juillet 2002
    Messages
    190
    Détails du profil
    Informations forums :
    Inscription : juillet 2002
    Messages : 190
    Points : 161
    Points
    161
    Par défaut Poo poo pidouu houu
    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 ?

  10. #70
    Membre expérimenté
    Profil pro
    Inscrit en
    février 2004
    Messages
    1 811
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2004
    Messages : 1 811
    Points : 1 532
    Points
    1 532
    Par défaut
    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
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  11. #71
    Membre éprouvé Avatar de 4sStylZ
    Homme Profil pro
    Null
    Inscrit en
    novembre 2011
    Messages
    290
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Null
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 290
    Points : 937
    Points
    937
    Par défaut
    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.

  12. #72
    Membre éclairé Avatar de viper1094
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2019
    Messages
    570
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mai 2019
    Messages : 570
    Points : 839
    Points
    839
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Utiliser ++i au lieu de i++
    Why ?
    "C'est d'un ennui…"

    Shikamaru Nara

  13. #73
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 047
    Points : 4 482
    Points
    4 482
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    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.

  14. #74
    Membre éclairé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    713
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 713
    Points : 779
    Points
    779
    Par défaut
    Citation Envoyé par Rizzen Voir le message
    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 ?
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

    Une alternative à jQuery, Angular, Vue.js, React, ... ? Testez anticore, en quelques secondes à peine !
    (Contributions bienvenues)

  15. #75
    Membre éclairé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    713
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 713
    Points : 779
    Points
    779
    Par défaut
    Citation Envoyé par viper1094 Voir le message
    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.
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

    Une alternative à jQuery, Angular, Vue.js, React, ... ? Testez anticore, en quelques secondes à peine !
    (Contributions bienvenues)

  16. #76
    Membre habitué
    Homme Profil pro
    Étudiant
    Inscrit en
    février 2017
    Messages
    36
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 23
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : février 2017
    Messages : 36
    Points : 137
    Points
    137
    Par défaut
    Citation Envoyé par viper1094 Voir le message
    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

  17. #77
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 062
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 062
    Points : 28 052
    Points
    28 052
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  18. #78
    Membre confirmé
    Inscrit en
    mai 2007
    Messages
    334
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 334
    Points : 492
    Points
    492
    Par défaut
    Citation Envoyé par SQUAL Voir le message
    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.

  19. #79
    Membre éprouvé
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2016
    Messages
    342
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2016
    Messages : 342
    Points : 1 075
    Points
    1 075
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    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 ? ^^

  20. #80
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 062
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 062
    Points : 28 052
    Points
    28 052
    Par défaut
    Citation Envoyé par Edrixal Voir le message
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

Discussions similaires

  1. Microsoft exhorte le gouvernement britannique à ne pas imposer ODF comme standard
    Par Hinault Romaric dans le forum Logiciels Libres & Open Source
    Réponses: 18
    Dernier message: 28/02/2014, 11h27
  2. ECMA International adopte JSON comme standard
    Par Stéphane le calme dans le forum Actualités
    Réponses: 10
    Dernier message: 22/10/2013, 01h12
  3. Yahoo! considère toujours Bing comme un concurrent
    Par Katleen Erna dans le forum Actualités
    Réponses: 3
    Dernier message: 26/08/2009, 04h47
  4. [E07] Produit considérant les blancs comme "zero"
    Par BME2411 dans le forum Excel
    Réponses: 10
    Dernier message: 15/01/2009, 11h06

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo