Inutile de sombrer dans la violence, il te suffit de faire du Vue pour retrouver clarté, simplicité et harmonieEnvoyé par oooopppp
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
Discussion :
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
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.
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
« Developpez.com est un groupe international de bénévoles dont la motivation est l'entraide au sens large » (incl. forums developpez.net)
Club des professionnels en informatique
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.
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
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é, crdltMerci 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
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 .
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.
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.
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.
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/
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.
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).
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.
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.
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
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.
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.
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...
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.
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.
gl, tu es donc fan de Common Lisp !
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager