Version imprimable
Pourquoi devrions-devoir faire un choix? La programmation fonctionnelle est un très bon outil pour travailler sur des ensembles, Et spécialement des ensembles de nombre. Mais pas rapport aux langages orientés objet, ils sont médiocres pour créer des abstractions. Faite une recherche sur Google pour "design pattern". Si c'est possible de la faire avec des langages fonctionnelles, la documentation est si rarissime que l'on peut dire que c'est pratiquement impossible.
C'est une opposition qui n'a pas lieu d'être. L'important c'est de faire ses choix en fonctions de critères pertinents par rapport à son projet et de ne pas se laisser aller par les effets de mode.
Bonjour.
Oui, il a tout compris du problème.Citation:
Envoyé par Patrick Ruiz
Néanmoins, la programmation fonctionnelle n'est pas la réponse à cette lacune. Il suffit juste d'utiliser la POO dans sa définition originelle. C'est rigolo, il explique d'où vient le problème, mais ne fait pas le choix d'en rester à la définition originelle de la POO, et propose du fonctionnel...
Lorsqu'un non développeur est capable de comprendre ton code, parce qu'il représente des choses concrètent, c'est suffisant. En général cela veut dire que même un débutant pourra faire évoluer ton code. La POO "originelle" permet cela.
Le multithreading complique un peu les choses, mais c'est tout.
J'ai eu plus d'un utilisateur non-programmeur capables de lire mon code. Voire même de me dire "Là, il faut changer ça" auquel il manquait un ou deux détails, mais c'était mon boulot d'y penser, donc pas grave).Citation:
Envoyé par moldavi
En COBOL.
Procédural pur.
Ce n'est pas une question de paradigme, c'est une question de clarté dans l'expression écrite. Si tes utilisateurs peuvent comprendre ce que fait ton code, c'est que ton expression écrite emballe les algorithmes de manière élégante et lisible. Pas que tu codes en OO, ou en fonctionnel, ou que sais-je.
(bon, un langage très verbeux comme le COBOL aide bien, aussi; IF Montant-Paiement GREATER THAN 1000000 THEN SET Type-Paiement-Cheque TO TRUE, c'est quand même assez parlant - En C, il faudrait ruser un peu plus pour arriver au même niveau de lisibilité - mais ça reste parfaitement possible à qui se donne la peine)
Je ne vois pas où il y aurait besoin d'astuce pour traduire cela de manière lisible en C :Citation:
Envoyé par el_slapper
Code:
2
Il y a des caractères spéciaux : ">", "(", ")", ";". On parle quand même d'utilisateurs finaux, hein..... La hiérarchisation du code par des parenthèses n'est pas évidente pour eux comme pour nous - le texte pur leur parle plus, même si c'est du franglais. Je t'accorde que la différence est minime, mais mon expérience en formation (sur des progiciels pros, avec une partie technique sur le paramétrage) avec des infirmiers ou des comptables me fait penser que c'est quand même réel.Citation:
Envoyé par Pyramidev
Mais ce n'est pas le point central de mon argumentation. Le point central, c'est que le paradigme n'est pas un gage de lisibilité - ou de non-lisibilité. Spécialement pour un non-spécialiste. Après, l'assembleur ou le BF, je dis pas... Mais ce n'est pas courant, de nos jours, ces langages.
Bonjour.
Pas de soucis sur la clarté dans l'expression écrite, c'est le minimum syndical, quelque soit le langage.Citation:
Envoyé par el_slapper
L'auteur parle de POO, alors je parle aussi de POO. Loin de moi l'idée de parler de Cobol.
Sur la lisibilité du code, et par rapport à la POO, je pensais à autre chose. La compréhension des objets, l'organisation générale du code qui reflète le mieux objet=réel. Donc compréhensible, même par des débutants. Mais c'est un autre débat selon moi. J'avoue avoir avoir été maladroit dans mon message, l'idée était : code simple/concret, code compréhensible/maintenable, mais en POO.
L'auteur tente de résoudre un problème simple et complexe à la fois... La gestion des variables globales, et de facto l'état des objets en POO. Des personnes ont inventé la POO, pour encapsuler ces fameuses variables globales, et avoir une gestion fine et maîtrisée de l'état de ces variables. Ca marche pas mal d'ailleurs, et je ne comprendrai jamais pourquoi il n'y a pas de consensus là-dessus...
Et puis tu as des langages comme javascript. Bah mince, c'est compliqué, ça marche pas bien.
Alors on va faire de l'objet en javascript. Bah mince, c'est pas pas top, et pas typé.
Alors on va faire du Typescript.
Bah mince ça marche pas bien, alors on va faire du fonctionnel... Parce que les langages fonctionnels te certifient que pas de souci avec les états des variables.
Bref, je ne suis pas du tout en phase avec la conclusion de cet auteur, parce que c'est déjà bancal dès le départ.
Pour conclure. dans le développement web (javascript, typescript), ils commencent à se rendre compte que c'est pas top quand tu veux faire des choses un peu poussées et maintenables. Alors ils cherchent des solutions... Que le C++ a déjà résolu, même si ce n'est pas parfait, évidemment.
De plus, tous ces développeurs web qui utilisent les frameworks javascript à la mode, c'est pas bon pour l'écologie. Cela télécharge plein de trucs pour les 3/4 inutiles. C'est pas bon pour la planète, ça fait chauffer les équipements réseaux :).
Quel genre de variable globale encapsules-tu et pourquoi est-ce des variables globales au lieu de variables locales ? Il y a de très fortes chances qu'on soit en désaccord, mais il faut quelques exemples pour pouvoir débattre dessus.Citation:
Envoyé par moldavi
Bonjour.
Cette question est très pertinente.Citation:
Envoyé par Pyramidev
Je vais vite simplifier, avant peut-être de m'expliquer plus tard. Les variables globales sont-elles nécessaires dans un programme ?
J'ai besoin de votre réponse à cette question, avant de vous répondre.
Pour les variables "globales", on peut penser à certains DP de Factory/Singleton/Lazy/Proxy.
Par exemple, je veux charger une image utilisée dans plusieurs bouts de codes, et je ne veux la charger qu'une fois, et que lorsqu'elle sera utilisé pour la première fois.
Certes, on pourrait avoir une variable "contexte" qu'on donne en paramètre de chaque fonctions. Le problème, c'est que suivant le langage, il n'est pas forcément évident de rajouter des choses à cette variable "contexte" de manière propre. Et surtout, il faut garantir que cette variable "contexte" ne soit instanciée qu'une seule fois, donc on se retrouve avec un des problèmes qu'on souhaitait résoudre avec cette variable "contexte".
Il y a pas mal de cas où des variables globales ou d'autres variantes (variables membres statiques, singletons) sont pertinentes. Parmi les exemples qui me viennent à l'esprit :Citation:
Envoyé par moldavi
- On utilise souvent des variables globales immuables pour définir des constantes, par exemple PI.
- Dans les langages à ramasse-miettes comme Java où chaque création d'objet demande de faire une allocation dynamique, dans le cas des classes immuables avec une sémantique de valeur, on utilise le patron de conception Flyweight pour pouvoir réutiliser les mêmes objets au lieu d'en créer plusieurs identiques. La FlyweightFactory peut être un singleton.
- Dans le cas des objets sans état, comme pour le patron de conception Objet nul, je trouve logique que la classe correspondante soit un singleton. Par exemple, une fois, j'avais créé un singleton NullLogger qui dérivait d'une classe Logger et qui ne loguait rien.
- Pour générer des nombres aléatoires, on a besoin d'une graine aléatoire (random seed). Quand on construit deux générateurs de nombres aléatoires basés sur le même algo, pour éviter qu'ils ne génèrent la même séquence de nombres, on a besoin de s'assurer qu'ils s'appuie sur des graines aléatoires distinctes. Pour générer des graines aléatoires distinctes, il peut être pertinent de passer par un état global muable.
- En Python, pour simuler la surcharge de nom de fonction sur le type du premier paramètre, on a functools.singledispatch. La fonction "générale" est alors une variable globale muable qu'on enrichie en enregistrant des couples (type du premier paramètre, fonction correspondante à appeler).
- En C++, si on a peur que de la mémoire volumineuse en cache fasse échouer de futures allocations de mémoire, on peut définir une fonction de libération du cache en question et l'enregistrer avec std::set_new_handler. Cet enregistrement modifie un état global, ce qui est cohérent avec le fait que la mémoire dynamique est une ressource globale.
- Dans du code C++ historique, pour enquêter sur une fuite de mémoire, pour plusieurs classes, je sauvegardais le nombre d'objets de la classe dans une variable membre statique (les constructeurs l'incrémentent et le destructeur la décrémente).
- En Common Lisp, quand on fait de la métaprogrammation avec des macros, on a souvent besoin de générer des symboles uniques pour éviter des collisions de noms. La génération de ces symboles s'appuie sur la variable globale *gensym-counter* qui est un compteur incrémenté à chaque création de symbole.
Il y a sûrement encore d'autres exemples de variables globales que j'approuve.
Mais, dans le code que je lis, quand je vois une variable globale muable ou autre variante (variable membre statique muable, singleton avec état muable), c'est souvent un cas que je désapprouve.
Exemple typique que je désapprouve : on lit un fichier de configuration et on le sauvegarde dans une variable globale ou un singleton pour qu'il soit directement accessible dans tout le programme.
Du coup :
- Quand on lit le code de haut niveau, on ne peut pas savoir quelles opérations dépendent de quelles parties de la configuration, à moins de lire récursivement tout le code appelé. Ce n'est pas gênant pour celui qui a introduit cette variable globale, car il se rappelle qui dépend de quoi. C'est gênant après le départ du développeur, surtout avec le temps car le code grossit de plus en plus et donc il n'y a pas le temps de tout lire avant de modifier le code quand il y a un dev à faire.
- Les tests unitaires sont plus compliqués à écrire (à supposer que l'architecture du code existant n'empêche pas carrément d'ajouter des tests unitaires).
- Quand on passe au multithread, les choses se compliquent.
Dans ce genre de cas, à la place d'une variable globale accessible partout, je passe de paramètre en paramètre la configuration ou bien une partie de la configuration.
Il y a beaucoup d'autres exemples de variables globales muables que je n'approuve pas, mais mon message est déjà long.
Bonjour.
Merci pour vos réponses (Neckara, Pyramidev).
Après vous avoir lu, je confirme, nous sommes d'accord sur les variables globales, et leur apport si elles sont utilisées à bon escient.
Du coup je ne vais pas m'étendre là-dessus, parce que nous risquons juste de "pinailler" sur des détails, et surtout de faire du hors sujet.
Je vais donc recentrer le débat sur l'article, et peut-être essayer de mieux expliquer mon point de vue.
L'auteur compare la POO et le développement web. Je vais en rester là.
Connaissant C, C++ et un peu Javascript/Php, je comprends son désarroi. Nous avons discuté des variables globales, c'est déjà très nuancé avec des langages typés et avec du multithreading, comme vous venez de le démontrer.
Alors maintenant imaginez la même chose avec un langage non typé comme Javascript. Je vous rassure, ces développeurs s'arrachent les cheveux au moindre bug. C'est pour cela qu'ils sont vite passés à l'objet, puis à Typescript, pour faire des programmes un peu plus évolués/maîtrisés.
C'est terminé le temps où tout le monde pouvait faire du Javascript, maintenant il faut un diplôme en sciences occultes...
Néanmoins, malgré ces évolutions du langage Javascript et les Frameworks associés, ils ont un gros souci de permissivité de ce langage, et une écriture non intuitive.
Donc l'auteur propose de faire du fonctionnel. Lorsque tu en es là, c'est surtout parce que ton langage ne te permet/propose pas d'outils pour gérer correctement le multithreading. Il a un problème avec les variables globales et la gestion de leur état, et il cherche des solutions. Je vais me répéter, le langage C++ a déjà résolu ce problème, même si ce n'est pas parfait.
Ce dont je suis persuadé, c'est qu'un débutant qui fait du Javascript, souvent il ne comprend pas l'objet, il ne comprendra pas plus le typage, alors ajouter du fonctionnel là-dessus... Ou comment faire compliqué lorsque l'on peut faire simple. Bref, les développeurs Web Javascript, ils tournent en rond.
Bonjour,Citation:
Envoyé par moldavi
En quoi le fonctionnel est-il plus compliqué ?
Bonjour.
Je ne dis pas que le fonctionnel est plus compliqué, je dis que l'on ajoute de la complexité à l'utilisation d'un langage en ajoutant du fonctionnel, après avoir ajouté de l'objet, puis du typage. Ce sera quoi la prochaine étape ? Tout cela tourne en rond, de mon point de vue.Citation:
Envoyé par SimonDecoline
La base du javascript, c'est langage non typé et abordable par tous, pour pas se prendre la tête. Malheureusement ce langage a des failles (dès la base), pour faire des programmes un peu poussés. Ajoute une dose d'asynchrone, et c'est la panique.
Justement : l'article essaie de voir s'il ne vaudrait pas mieux faire du fonctionnel plutôt que de faire tout le temps de l'objet.Citation:
Envoyé par moldavi
Que vient faire le javascript ici ? Il apparait dans quelques commentaires mais il n'est mentionné nul part dans l'article dvp. L'article parle plutôt de elm ou des fonctionnalités de fonctionnel qui apparaissent dans beaucoup de langages.Citation:
Envoyé par moldavi
JavaScript est typé. Il n'a pas de typage statique ni la possibilité de définir ses propres types complexes mais il est typé.Citation:
Envoyé par moldavi
Quand à l'asynchrone c'est le contexte par défaut que tu sois en browser ou en backend, le web est asynchrone et stateless. Et JS est extrêmement bien équipé pour gérer l'asynchrone du coup je ne comprends pas.
Les bugs et la maintenabilité d'un code n'ont pas de rapport avec le langage (ya plus de liens avec le paradigme du langage en revanche). Ça dépend d'abord et avant tout de l'auteur du code source.Citation:
Envoyé par moldavi
Il y a une multitude d'outils pour écrire des tests de tout type donc pas de raison de s'arracher les cheveux comme tu dis.
La situation que tu décris n'existe plus depuis pratiquement 10 ans. Node a tout changé.
TypeScript ne sert pas à faire de l'objet, il sert à ajouter du typage statique structurel à la transpilation c'est tout. Il ne sert qu'à ça. Peu importe que tu utilises des classes ou des modules pour structurer ton code. Tu as des projets Angular qui utilisent TypeScript et qui ont un design largement inspiré de J2EE et tu as plein de projets React qui utilisent TypeScript et qui ont un design fonctionnel.Citation:
Envoyé par moldavi
Il faut simplement apprendre le langage et les outils les plus courants. Rien de surnaturel là dedans ;) Cela dit l'évolution de son écosystème a été tellement rapide ces dernières années qu'il est possible de l'avoir manqué complètement si on est habitué aux rythmes des langages historiques (Java, C# et pire C++).Citation:
Envoyé par moldavi
Tu ne connais manifestement pas l'écosystème JS du coup je vois mal comment tu peux avancer une telle chose ...Citation:
Envoyé par moldavi
Je suis en total désaccord avec ça. Il ne faut surtout pas utiliser la conception objet comme point d'entrée de la compréhension d'un programme avec un débutant, il faut passer par les tests et donc par les exigences métiers. C'est IMHO le plus grand échec de l'enseignement du développement logiciel, ne pas prendre le problème par le bon bout. Et clairement le paradigme fonctionnel facilite l'écriture des tests.Citation:
Envoyé par moldavi
Sinon JS est à la source de cette remontée en flèche du paradigme fonctionnel vs paradigme objet. La dichotomie décrire ce que fait un objet au lieu de décrire ce qu'il est avec tous les problèmes de divination que ça pose a été largement débattu et documenté (cf MPJ Fun fun function ou Eric Elliott). Probablement du fait de l'extrême évolution des solutions web, décrire un domaine métier qui varie très peu avec de l'objet peu s'entendre mais les projets webs évoluant très vite le fonctionnel est beaucoup plus adapté. La remontée du fonctionnel via JS est une réponse à ce problème d'augmentation de la fréquence des évolutions j'ai l'impression ... Ainsi qu'à des projets de startups qui démarrent sans savoir réellement quel est leur besoin métier (MVP).
Bonjour,
J'ai un doute...
Quand je lis "programmation fonctionnelle", je m'attend non pas à de la programmation à base de fonction (et procédures) qui s'appelle chez moi de la "programmation procédurale", adjectif utilisé par le langage lui-même, mais plutôt à des méthodes/procédures/fonctions/classes orientées "fonctionnel" plutôt que "objet".
Je m'explique. Si j'ai un programme qui doit traiter des individus afin de produire un arbre généalogique, j'ai deux approches possibles :
- Avoir une classe "objet" dans le sens "entité de donnée" que j'appellerai "individu", et je vais pouvoir les stocker dans un objet générique "arbre binaire" et ainsi pouvoir stocker l'arbre généalogique. J'ai des classes "objet", c'est à dire dénuées d'intelligence capable de répondre simplement à ma problématique, par contre totalement générique et valables pour d'autres situations.
- Ou avoir une classe "MembreDeLaFamille" totalement dédiée à ma problématique du moment, contenant une référence vers le père et la mère : j'ai une classe "fonctionnelle", c'est à dire dédiée à ma problématique, mais potentiellement inadaptée à une autre utilisation (dans un annuaire, je vais avoir au maximum 3 ou 4 niveaux de parentalité et énormément d'instances "orphelines", et je ne sais pas gérer les voisins d'une rue avec).
Cette question est généralement résolue par la programmation en couches, type MVC : on a des objets "entité" liés aux données dans une couche, et des objets plus fonctionnels dans la couche métier. Cependant, c'est rapidement le marteau pilon pour gérer des problématiques simples, et on introduit énormément de complexité, soit en recopie de données, soit en encapsulations pour traiter les données d'une couche à l'autre.
En revanche, si la question c'est vraiment "programmation objet ou programmation procédurale", j'avoue ne pas comprendre qu'on puisse se poser la question...
Les traitements à l'intérieur d'un objet sont de toute façon des procédures comme on les écrivait dans les années 70, les variables locales et globales étant simplement les variables de la méthode ou les membres de l'objet...
Donc la programmation objet EST de la programmation procédurale, avec une couche supplémentaire, qui est la notion d'objet.
Je pige pas.
Dans mes bras!!!!!Citation:
Envoyé par StringBuilder
Bon, moi, j'ai une définition un peu différente de l'objet, pour moi, c'est une structure de données qui embarque son propre code (procédural). Mais en fait, ça revient exactement au même, juste en arrivant par un tout autre endroit. à part les spécificités de la couche objet, qui ne sont pas bien méchantes (même si elles peuvent avoir un impact architectural fort), la POO, c'est du procédural dans des objets - je ne peux que plussoyer.
Je ne dis pas que c'est mal, d'ailleurs, à chaque fois que je colle une classe dans mon VBScript (oui je suis un dinosaure), mon collègue hurle que je me fais chier pour rien (il est encore plus dinosaure que moi). J'utilise, donc ça répond à mon besoin, de manière régulière. Je dis juste que ça ne vaut pas tout le ramdam qu'on en fait.
C'est pourtant simple : il s'agit plus de combats identitaires que de réels débats. La POO est une religion. Pour une raison toute simple : les gens bossent mieux quand ils sont passionnés. Rien de tel pour les passionner qu'une bonne guerre de religion - quitte à ce qu'on transforme en montagne une souris à l'occasion.Citation:
Envoyé par StringBuilder
Après, il y a aussi des gens pour qui la "programmation fonctionnelle" fait référence à des langages "purs fonctionnels" comme LISP, ou tout est immutable, tout est résultat, il n'y a pas de variable, et la manière de concevoir les algorithmes est radicalement différente (ils usent et abusent du récursif, avec des astuces poussées pour ne pas couler la pile). Mais ça, c'est un petit groupe de puristes(très forts, très impressionnants, je ne leur arrive pas à la cheville). La plupart des gens vont se gargariser de "programmation fonctionnelle" parce-qu’ils ont collé 3 misérables fonctions dans leur procédural (organisé dans des objets ou pas).
D’où la confusion.
Bon, on est donc d'accord.Citation:
Envoyé par el_slapper
En fait, plutôt que POO vs procédural, j'ai plutôt l'impression que le combat se situe dans le niveau d'objectitude du code.
En effet, pour beaucoup de programmes, mettre en place des notions avancées de la POO, faire de l'héritage, des patterns ou autres joyeusetés ne sert à rien.
Et là je suis d'accord pour dire que ça sert à rien de se lancer dans du MVC pour recopier le résultat d'une requête SQL dans un fichier CSV : quelques lignes de pur procédurale sont amplement suffisantes, sans avoir besoin d'instancier des objets pour chaque ligne, puis sérialiser tout le bordel avec une collection spécialisée...
Mais c'est pas pour autant qu'on n'aura pas besoin d'une classe pour gérer l'accès à la base de données de façon à supporter n'importe quel connecteur de base de données, ou qu'on ne va pas souhaiter inclure la "fonction" dans une classe réutilisable pour d'autres programmes.
En fait, la POO, comme n'importe quelle méthode de développement peut être poussée à l'absurde : 12 classes et des patterns incompréhensibles pour afficher "hello world", tout comme en procédural on peut se retrouver avec 12 fonctions pour arriver au même résultat... ou à l'inverse, coder toute la facturation d'un ERP dans une unique fonction qui fait 60 000 de lignes de code (déjà vu pour de vrai).
À la place de LISP, j'aurais plutôt cité Haskell.Citation:
Envoyé par el_slapper
Si on prend l'exemple de Common Lisp, il y a à la fois des fonctions qui modifient des listes et d'autres qui évitent de modifier l'état des listes en entrée. Par exemple, reverse retourne une nouvelle liste sans toucher à la liste d'origine, tandis que nreverse ne se prive pas de "manger" la liste en entrée. Il y a la même chose avec, par exemple (intersection, nintersection), (substitute, nsubstitute), (substitute-if, nsubstitute-if) et (substitute-if-not, nsubstitute-if-not),
http://clhs.lisp.se/Body/f_revers.htm
http://clhs.lisp.se/Body/f_isec_.htm
http://clhs.lisp.se/Body/f_sbs_s.htm
En outre, pour les fonctions récursives, le standard de Common Lisp ne garantit pas que la tail call optimization est supportée. (Par contre, elle est bien garantie pour d'autres dialectes du Lisp comme Scheme.)
En pratique, la communauté du Common Lisp a adopté la programmation fonctionnelle, mais ce n'était pas imposé par le langage.