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. #101
    Expert éminent sénior
    Citation Envoyé par oooopppp Voir le message
    Quand je vois Facebook avec react et Google avec angular j'ai qu'une envie c'est de claquer la tête de l'un contre l'autre en espérant leur faire rentrer un peu de plomb dans la tête !
    Inutile de sombrer dans la violence, il te suffit de faire du Vue pour retrouver clarté, simplicité et harmonie
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  2. #102
    Expert confirmé
    Citation Envoyé par oooopppp Voir le message
    Bonjour à tous,
    et bien j'enchaîne assez rapidement de grosses applications, ... 1 mois et une semaine....
    Il est tout simplement impossible que ce soit une grosse application dans un délai si court. Que ce que tu as produit soit maintenable, c'est bien possible, mais c'est certainement lié au fait que ça a 1 mois d'age.

  3. #103
    Expert éminent
    Citation Envoyé par oooopppp Voir le message
    (.../...) Pour preuve, je viens de coder un système de vente en ligne multi vendeurs avec chaque son propre paiement par CB et le tout en Ajax et en ... 1 mois et une semaine, ça fonctionne bien, pas de bug et le code est super maintenable,
    (.../...)
    Merci de nous indiquer de quel(s) site(s) marchand(s) il s'agit, nous ne tenons pas à voir un jour nos coordonnées dans la nature
    https://documentcyborg.com
    Transform any web page into a document
    Copy and paste the following URL to try it : https://documentcyborg.com/faq

    Liste des balises BB - Forum du club des développeurs et IT Pro
    Jeu de balises basé sur le langage HTML - Permettent d'ajouter, de formater vos messages avec une syntaxe plus simple et ne déformera pas l'affichage des pages...

    Les meilleurs cours et tutoriels sur la programmation et l'informatique professionnelle - developpez.com

  4. #104
    Membre éclairé
    Ok, l'auteur (le troll) descend la programmation orientée objet en flamme (plus précisément, il cible plus Java et C# que la POO).
    Ses arguments font globalement mouche sur moi, qui pratique beaucoup la POO.
    Son analyse sent le vécu et se retrouve dans le mien.

    D'un autre côté, il semble être un fan boy de la programmation fonctionnelle.
    Dans son article, la programmation procédurale est mentionnée 3 fois et la programmation fonctionnelle 36 fois (j'ai compté).

    Son article est un gros troll anti POO et une pub pour la programmation fonctionnelle, pas du tout une mise en comparaison équitable des différents paradigmes.

    On peut facilement écrire un autre article qui fait passer la programmation fonctionnelle pour une limace paraplégique (et un autre qui démontre que la programmation procédurale ne permet que de faire des spaghettis avariées).

    Non la programmation fonctionnelle ne va pas mettre fin au réchauffement climatique.
    Plus concrètement, par exemple, Erlang promeut l'échange de messages entre des sortes de "processus" (des processus Erlang, pas des processus du système d'exploitation) au sein de l'application (d'un même vrai processus système).
    Là ou en Java on aurait un simple appel de méthode, Erlang fait une copie d'un message (pourtant immutable) et le pousse dans la file d'attente d'un autre processus.
    Dans un paquet de cas, cette approche ajoute une énorme pénalité en terme de performance sans apporter grand chose.
    Autre exemple, est ce normal que ça a été bien la merde d'ajouter un truc bateau comme les maps dans Erlang ?


    Bref, la triste vérité c'est que la POO est pas géniale, mais la programmation fonctionnelle non plus. Et la procédurale non plus.
    Peu importe le paradigme, le code d'une application un tant soit peu complexe écrite par un groupe de développeurs finit malheureusement toujours comme un gros tas de lignes hétérogènes, à l'architecture oubliée et à la maintenance en forme de calvaire.
    (Et on peut appliquer le même raisonnement aux monolithes vs micro-services, à React vs Angular, blonde vs brune.)

    Déterminer quel est le meilleur paradigme (et ensuite langage, dépendances, architecture...) pour un nouveau projet reste et restera peut être toujours un casse tête chinois aboutissant sur une décision non optimale.
    Et non ce n'est peut être pas une erreur que la POO soit la plus utilisée, même si c'est pourri. Il y a toujours pire.

  5. #105
    Membre habitué
    Citation Envoyé par micka132 Voir le message
    Il est tout simplement impossible que ce soit une grosse application dans un délai si court. Que ce que tu as produit soit maintenable, c'est bien possible, mais c'est certainement lié au fait que ça a 1 mois d'age.
    Oui je me suis servi d'un projet de boutique unique et personnelle comme base mais oui c'est possible, je suis tapé 238 heures en un mois et bien sûr j'ai des preuves concrètes en ligne, si tu veux vérifier, envoie moi un mp et je te donnerai des logs de connexion et l'URL

    Citation Envoyé par Escapetiger Voir le message
    Merci de nous indiquer de quel(s) site(s) marchand(s) il s'agit, nous ne tenons pas à voir un jour nos coordonnées dans la nature
    Pour le paiement tu comprendras que je travaille pas directement avec mastercard, je passe par stripe et comme l'autre collègue, log. Et URL sur demande en mp, et c'est presque 240 heures en 1 mois et une semaine mais j'ai été malade une semaine, merci de respecter mon travail avant de critiquer, c'est pour moi un véritable exploit personnel et j'ai pris cher au niveau physique, mais on ne peut nier une réalité, crdlt

  6. #106
    Membre éclairé
    Citation Envoyé par oooopppp Voir le message
    Oui je me suis servi d'un projet de boutique unique et personnelle comme base mais oui c'est possible, je suis tapé 238 heures en un mois et bien sûr j'ai des preuves concrètes en ligne, si tu veux vérifier, envoie moi un mp et je te donnerai des logs de connexion et l'URL
    Si tu cumules les heures , mais que tu programmes mal , tu n ' as donc rien fait de ces heures perdues , c 'est bien de partir d ' un canevas , mais cela reste une ossature , ce n’est pas " magique " et la sécurisation d ' un site , ce n 'est pas seulement un certificat SSL . Ne serais ce que ta proposition ci-dessus indique que tu n'as pas réfléchi , mais bon , je suis peu être un peu trop sourcilleux sur le sujet , si la BDD client est protégé par ADMIN/ADMIN sur un SGBD non mis à jour , que les mots de passes sont en base 64 et qu ' un simple débordement de tampon , même pas du DDOS , fait péter le site très bien , tu mérites ta médaille au chocolat .

  7. #107
    Inactif  
    POO sans RAD
    Le titre exact de l'article est POO sans RAD.

    J'ai cherché RAD dans l'article sans rien trouver. Donc l'article est inutile.

  8. #108
    Membre habitué
    Toujours les mêmes rengaines
    Toujours les même rengaines.
    Je vais pas remettre deux balles dans la machine, juste quelques remarques :

    a) le gars ne fait que parler d'héritage et des problèmes que ça pose, mais tout développeur OO confirmé sait très bien qu'on utilise beaucoup plus la composition que l'héritage

    b) le paradigme fonctionnel me semble tout sauf simple. Et si c'était si bien, ça se serait imposé naturellement depuis 10 ans et plus qu'on nous serine avec sa supériorité.

    c) quel que soit le paradigme, c'est la qualité du développeur qui est essentielle. On peut avoir des codebase énormes en impératif qui soient parfaitement maintenables et évolutifs, même avec des langages pourris qui favorisent les mauvaises pratiques.

    d) la remarque précédent s'applique encore plus avec la POO ; l'expérience est essentielle pour ne pas pondre des bouzins incompréhensibles blindés d'abstraction et de design patterns superflus

    e) l'approche objet doit être pensée comme une approche systémique, avec une société d'objets, chacun focalisé sur on rôle et qui s'échangent des messages pour collaborer -> c'est exactement ce que le gars nous dis vouloir faire, et c'est exactement ce qu'une bonne conception OO permet de faire.

  9. #109
    Expert éminent sénior
    J'ai vu ce lien en premier sur le Daily WTF, où il a sa place.
    C'est le monsieur "mon exemple de 'refactoring' OO crée une interface et une factory pour un code qui n'a qu'une seule implémentation et un seul comportement".

    C'est aussi le gars qui considère que l'héritage a "un objet parent et un objet enfant"...
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  10. #110
    Expert éminent sénior
    Citation Envoyé par damthemad Voir le message
    (..../....)c) quel que soit le paradigme, c'est la qualité du développeur qui est essentielle.(.../...)
    Je ne suis pas d'accord avec tout ce que tu dis, mais au final, le point central, c'et ça. Et je suis 1000% d'accord. Je n'ai pas retrouvé ce vieux post de Steve McConnel de 2001 ou il avait, chiffres à l'appui, montré que la méthode, c'est bien, mais ça fait gagner dix fois moins que de recruter des gens qui font l'affaire. J'ai trouvé ça, mais il me semblait qu'il y avait un résumé plus exploitable qui démontrait de manière plus percutante cette phrase que tu dis.

    Ca précise également que la qualité des intervenants(managers, experts métiers.....) compte tout autant.

    EDIT : ah, j'ai presque trouvé : http://shapingsoftware.com/2008/09/0...st-and-effort/

    Citation Envoyé par ce blog qui reprend les données de Steve Mcconnell
    According to McConnell, these are the 7 personnel-oriented factors and their influence rating:

    Application Experience (1.51)
    Communications Factors (1.53)
    Language and Tool Experience (1.43)
    Personnel Continuity (1.51)
    Platform Experience (1.40)
    Programmer Capability (1.76)
    Analyst Capability (2.00)
    The 7 personnel-oriented factors can exert a cummulative influence range of 24.6. (Multiply each factor … 1.51 x 1.53 x 1.43 … etc.)

    3 Seniority-Oriented Factors
    Experience alone is a big factor. According to McConnell, here’s the three seniority-oriented factors and their influence rating:

    Application Experience (1.51)
    Language and Tool Experience (1.43)
    Platform Experience (1.40)
    The 3 seniority-oriented factors can exert a cumulative influence range of 3.02.
    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.

  11. #111
    Membre confirmé
    Citation Envoyé par damthemad Voir le message
    b) le paradigme fonctionnel me semble tout sauf simple. Et si c'était si bien, ça se serait imposé naturellement depuis 10 ans et plus qu'on nous serine avec sa supériorité.
    Le paradigme fonctionnel est plus facile à comprendre, ne serait ce que parce que l'on est initié à ce paradigme par la pratique des mathématiques. Le paradigme objet est bien plus difficile a appréhender parce que l'on ne l'utilise pas dans la vie courante et que contrairement à ce qu'avancent ses promoteurs, le paradigme objet est tout sauf naturel (non une voiture ne se conduit pas elle même, enfin pas jusqu'a il y a relativement peu de temps).
    Enfin pour ce qui est des techno qui s'imposent naturellement, il suffit d'y regarder de plus pres pour constater qu'il y a souvent de grosses structures qui poussent derrière. Il y a aussi l'inertie qui fait qu'un langage a beau avoir toutes les qualités du monde, il mettra des années avant de percer, parce que tout le code et les libraries sur le marché sont faits dans l'ancien langage qui, en dépit du fait que ce soit très moche, a le mérite de fonctionner (et même très bien vu les x generations de dev qui sont passé derrière pour optimiser).

  12. #112
    Membre éprouvé
    Sauf que, dans les faits, tout le monde code en objet et personne en fonctionnel.
    Sur Youtube je suis "Le développeur des cavernes"
    https://www.youtube.com/channel/UCSz...bYl_pSNMv_zerQ

  13. #113
    Membre confirmé
    Citation Envoyé par Jamatronic Voir le message
    Sauf que, dans les faits, tout le monde code en objet et personne en fonctionnel.
    Dans les faits les faits beaucoup programment en fonctionnel avec un langage dit objet sans le savoir. Il n'y a qu'a voir les petits jeunes qui ne connaissent et ne jurent que par l'objet coder à coup de composition, et faire des appels récursifs parfois sans toucher aux variables d'instance.
    Je fais la même chose par héritage et par l'utilisation de traits. Je ne dénature pas l'interface de mes classes en avec des méthodes destinées aux algos de calcul utilisées par d'autres methodes servant d'accesseur et je ne me retrouve pas avec une trace de 3km de long au moindre dump. Pourtant je suis probablement celui qui la formation en POO la plus courte.

  14. #114
    Rédacteur/Modérateur

    La programmation fonctionnelle, c'est très bien pour manipuler des scalaires (booléens, nombres, ou chaînes de caractères --- pour certains langages, une chaîne de caractère n'est pas un scalaire).
    C'est aussi intéressant pour la partie présentation (ou vue) d'une application pour faire du "stateless", avec les avantages de traçabilité et de maintenance que cela comporte.

    Maintenant, il faut aussi admettre que la vraie vie n'est pas aussi pure que le monde des fonctions, ou aussi organisée que le monde des classes. Une application qui fait vraiment des choses utiles aura toujours besoin de son "hack", de sa bidouille pas très propre mais qui tout de même se révèle bien pratique et efficace.

    Il y a des enjeux tout aussi importants que sont les temps de réponse, l'empreinte mémoire ou tout simplement le "il faut d'abord que ça marche" pour que la programmation puisse se résumer qu'à un seul paradigme.
    Tutoriels et FAQ TypeScript

  15. #115
    Membre régulier
    J'ai du mal à comprendre la position de l'auteur qui vise à dire que la POO serait un facteur de mauvaise qualité de code. Avec ou sans POO, des exemples et expériences vécues de codes pourris bon à jeter sont légions.

    Par contre, des implémentations de code qui auraient été illisibles en programmation purement procédural, j'en connais des paquets.

    Un débat sur un non-débat en quelque sorte

  16. #116
    Expert confirmé
    Dans l'industrie, si la programmation fonctionnelle était le standard à la place de la POO, alors je pense que le code pourri aurait été moins pourri.

    Avec un style fonctionnel, la majorité des fonctions sont pures, donc ne dépendent que de leurs paramètres et n'ont de conséquences que via leur valeur de retour.
    Du coup, c'est plus dur de faire du code avec des dépendances cauchemardesques où toute donnée est accessible depuis tout le programme et où tout appel de fonction peut avoir des conséquences sur des parties insoupçonnées du programme. Cela reste possible si on conçoit deux tonnes de fonctions qui prennent en paramètre beaucoup plus d'infos que nécessaire et qui retournent beaucoup plus d'informations que nécessaire que l'on diffuse explicitement partout, mais cela demande plus d'efforts d'écriture.

  17. #117
    Expert éminent sénior
    Citation Envoyé par Pyramidev Voir le message
    Dans l'industrie, si la programmation fonctionnelle était le standard à la place de la POO, alors je pense que le code pourri aurait été moins pourri.(.../...)
    Il y aurait surtout moins de code, parce-que moins de codeurs. Le fonctionnel est beaucoup moins accessible que l'objet, et encore moins que le procédural. J'ai vu bien des horreurs en procédural, faites par des gens qui auraient abandonné le fonctionnel immédiatement, faute d'arriver à quoi que ce soit. Le procédural ou l'objet, un gnou, il copie-colle, il change comme une brute, et il a un résultat qui fait presque ce qu'il veut. En fonctionnel, le gnou, son cerveau, il appuie sur la touche "STOP".

    Le truc, c'est que le code horrible en procédural ou en objet, fait par des gnous, il rend parfois bien des services.
    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. #118
    Rédacteur/Modérateur

    J'ajouterai que devoir réfléchir (même plus de quelques secondes) pour être obligé de faire du récursif en lieu et place d'une simple boucle toute bête parce qu'impossible en fonctionnel, ou devoir galérer avec des d'objets imbriqués en faisant des copies en cascade parce qu'il n'est pas possible non plus de manipuler des entités mutables, c'est tout de même fâcheux.

    La programmation fonctionnelle a un côté "esthétique" indéniable, et c'est très bien si on en reste à des fonctions "simples". Mais dès qu'il faut faire des accès en bases, des I/O, enfin des trucs qui font vraiment des choses, cela ne relève plus du monde des fonctions. Et pourtant, c'est indispensable pour une "vraie" application.

    En plus, paradoxalement, l'une des promesses de la programmation fonctionnelle qui serait de mieux pouvoir prédire le comportement d'un programme puisque "mathématisé" est aussi mise à mal puisqu'il est prouvé par la théorie qu'on ne peut pas dans l'absolu prévoir le temps d'exécution d'un programme fonctionnel (qui peut être très long si mal écrit, justement à cause des récursions et des copies d'objets en pagaille). Chose qui est à contrario mieux évaluable en simple programmation procédurale. Comme quoi...
    Tutoriels et FAQ TypeScript

  19. #119
    Rédacteur

    Citation Envoyé par yahiko Voir le message
    J'ajouterai que devoir réfléchir (même plus de quelques secondes) pour être obligé de faire du récursif en lieu et place d'une simple boucle toute bête parce qu'impossible en fonctionnel
    L'alternative fonctionnelle de la plupart des boucles, surtout si elles sont simples, c'est davantage le trio map/filter/reduce (ou les collections en compréhension) que les constructions récursives.

    A contrario, un certain nombre d'algorithme s'exprime plus facilement en récursif qu'en boucle et demande un effort certain pour passer en boucle. Je pense aussi que la facilité ressentie tient beaucoup de nos habitudes, et que ce qui semble plus immédiat (ou naturel, ou évident, ou ...) à quelqu'un est surtout ce dont il a l'habitude.

    Citation Envoyé par yahiko Voir le message
    ou devoir galérer avec des d'objets imbriqués en faisant des copies en cascade parce qu'il n'est pas possible non plus de manipuler des entités mutables, c'est tout de même fâcheux.
    Sous le capot, les compilateurs et interpréteurs arrivent quand même pas mal à optimiser ces copies. Que ce soit avec du copy-on-write, en modifiant malgré tout les objets initiaux qui ne sont plus utilisés (c'est la différence entre le comportement normatif vu du langage où il y a un copie et le détail d'implémentation où le compilateur peut, voir doit s'il est de qualité, éliminer les copies inutiles) ou autres techniques.



    Après, j'avoue que personnellement, j'ai plutôt une préférence pour les langages multi-paradigmes qui proposent à la fois des mécanismes impératifs et d'autres plutôt fonctionnels, de l'objet et du procédural, etc. Et je pioche dedans en fonction des besoins, ce qui me permet d'avoir du code qui tend pas mal vers du fonctionnel tout en faisant du pur impératif dans d'autres module, mais en isolant au maximum les effets de bords. Bref essayer de tirer le meilleur partie des deux mondes.

  20. #120
    Membre éprouvé
    gl, tu es donc fan de Common Lisp !
    Sur Youtube je suis "Le développeur des cavernes"
    https://www.youtube.com/channel/UCSz...bYl_pSNMv_zerQ

###raw>template_hook.ano_emploi###