Journal Adopter un style de programmation fonctionnel

60
14
nov.
2012

John Carmack, c'est ce développeur de renom chez IdSoftware, qui a participé à la création de titres phares du jeu vidéo PC avec la série des Doom, des Wolfenstein et des Quake. Bien que n'étant pas des logiciels libres, leurs moteurs sont régulièrement libérés et LinuxFR se fait l'écho de ces libérations depuis sa création (ici, et par exemple). Bref tout ça pour dire que je sais bien qu'il ne fait pas du logiciel libre, mais d'une certaine manière, il a contribué pour beaucoup à des jeux libres.

John Carmack (contrairement à d'autres) n'est pas connu pour ses trolls, mais au contraire, il a (ou du moins tente d'avoir) toujours une position mesurée et réfléchie. Il tient un blog dans lequel il parle de ses expériences dans le développement et de différentes techniques qui y sont liées. Son dernier billet de blog « Functional Programming in C++ » (dont je souhaite me faire l'écho) est une tentative d'expliquer comment adopter un style de programmation fonctionnelle, malgré l'utilisation d'un langage qui ne l'est pas.

C'est vraiment un article très intéressant (qui, de plus, a été traduit en français sur developpez.com) et agréable à lire.

Ce que je trouve particulièrement intéressant, c'est de prendre réellement les avantages de la programmation fonctionnelle (les fonctions pures, c'est-à-dire sans effets de bord) dans les langages que l'on trouve un peu de partout (rien dans ce qu'il décrit n'est spécifique au C++, on peut appliquer les mêmes méthodes à du C, du Java, du perl ou du python). Il ne s'arrête donc pas aux lambdas fonctions qui, bien que très agréables à utiliser, sont plus proches du sucre syntaxique que d'un véritable style de programmation.

En outre, il explique comment faire évoluer une base de code en prenant en compte ces principes. Chez IdSoftware, ils possèdent une grande base de code en C++ qui continue d'être utilisée, ils ne peuvent pas se permettre de la jeter pour la réécrire. Bref, c'est vraiment agréable à lire, pas moralisateur, juste quelques conseils à garder en tête.

Si vous regardez son blog, son précédent billet parle d'analyse de code statique. C'est encore une fois intéressant, mais plus proche d'un retour d’expérience sur les différents outils qu'il a eu à disposition et la manière de s'en servir.

Bonne lecture à tous.

PS : si vous avez dans vos flux d'autres perles de ce type, je serais très intéressé d'y jeter un œil.

  • # typo ?

    Posté par (page perso) . Évalué à  4 . Dernière modification : le 14/11/12 à 13:38

    John Carmack développeur de renom chez IdSoftware et qui a participer à la création de titres phares du jeu vidéo PC avec la série des Doom, des Wolfenstein et des Quake

    pas compris la phrase, il en manque un bout ?

    s/particper/participé

    carte des attaque DDOS http://map.ipviking.com/

    • [^] # Re: typo ?

      Posté par (page perso) . Évalué à  2 .

      corrigée (et quelques autres).

      • [^] # Re: typo ?

        Posté par (page perso) . Évalué à  1 .

        Pour la faute, oui, mais il manque un bout à la phrase ou alors elle n'est pas correctement construite.
        Si on enlève la subordonnée relative, il reste :
        « John Carmack développeur de renom chez IdSoftware. » Du coup, il n'y a pas de verbe dans cette phrase, c'est un peu bizarre. En ajoutant le verbe "être" au minimum, on en fait une phrase correcte.

        • [^] # Re: typo ?

          Posté par (page perso) . Évalué à  2 .

          patch pris en compte, merci.

        • [^] # Re: typo ?

          Posté par . Évalué à  3 . Dernière modification : le 14/11/12 à 14:33

          Si on enlève la subordonnée relative, il reste :

          Tu as raison, j'ai toujours ce problème quand je fais des subordonnées trop longues, je me perd dans mes phrases. Comme on m'a toujours dis, quand ça arrive, on coupe la phrase :

          Je viens aujourd'hui vous parler d'un billet de blog de John Carmack. Pour ceux qui ne le connaîtraient pas, c'est ce développeur de renom chez IdSoftware, qui a participé à la création de titres phares du jeu vidéo PC avec la série des Doom, des Wolfenstein et des Quake.

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

  • # libre

    Posté par . Évalué à  10 .

    "Bref tout ça pour dire que je sais bien qu'il ne fait pas du logiciel libre, mais d'une certaine manière il a contribué pour beaucoup à des jeux libres."

    Bien sûr que si, il fait du logiciel libre. Il a écrit une grande quantité de code libre, et plutôt du bon.

    • [^] # Re: libre

      Posté par . Évalué à  6 . Dernière modification : le 14/11/12 à 14:37

      Oui, l'idée était surtout de dire que ce n'est pas parce qu'il écris du logiciel qui reste propriétaire quelques années qu'il ne contribue pas au libre.

      […] plutôt du bon.

      Il a révolutionné la manière d'écrire une fonction racine carré par exemple et l'a libéré. C'est un peu plus créatif que le fameux « checkrange » d'Apple.

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: libre

        Posté par . Évalué à  4 .

        Cette histoire de racine carrée n'est visiblement pas de lui.

        Source :
        http://fr.wikipedia.org/wiki/John_Carmack

        • [^] # Re: libre

          Posté par . Évalué à  2 .

          Il l'a quand même popularisée.

          • [^] # Re: libre

            Posté par (page perso) . Évalué à  7 .

            de l'intérêt de parler d'une révolution ! ;-)

            • [^] # Re: libre

              Posté par (page perso) . Évalué à  5 .

              c'est un peu l'Apple de l'algo sur la racine carrée quoi…

              ---------->[ ]

      • [^] # Re: libre

        Posté par (page perso) . Évalué à  3 . Dernière modification : le 14/11/12 à 15:59

        Il a révolutionné la manière d'écrire une fonction racine carré par exemple et l'a libéré.

        Cela ne vient pas de lui. http://en.wikipedia.org/wiki/Methods_of_computing_square_roots#Reciprocal_of_the_square_root http://en.wikipedia.org/wiki/Fast_inverse_square_root

        EDIT : je suis trop lent :/

      • [^] # Re: libre

        Posté par . Évalué à  5 .

        C'est un peu plus créatif que le fameux « checkrange » d'Apple.

        N'est-ce pas plutôt le rangeCheck d'Oracle ?

        • [^] # Re: libre

          Posté par . Évalué à  10 .

          Yes, Apple eux ils brevettent les rectangles aux coins arrondis..

          • [^] # Re: libre

            Posté par . Évalué à  9 .

            Et les scroll list qui font chboing quand on arrive en bas :-)

            • [^] # Re: libre

              Posté par . Évalué à  2 .

              Si tu savais le bruit que j'ai fait en éclatant de rire quand j'ai lu ton commentaire :D .

      • [^] # Re: libre

        Posté par (page perso) . Évalué à  3 .

        C'est cool le truc de la racine carré mais ça ne sert plus à rien depuis un certain nombre d'années

        • [^] # Re: libre

          Posté par (page perso) . Évalué à  2 .

          On utilise quoi maintenant ? Une implémentation hardware du truc ?

          • [^] # Re: libre

            Posté par . Évalué à  1 .

            Les GPUs ont une fonction racine carrée inverse accessible via les shaders, donc je suppose que ça se fait en hard.

        • [^] # Re: libre

          Posté par (page perso) . Évalué à  2 .

          C'est moi, ou ces algorithmes ne paraissent guère plus élaborés[*] que ceux généralement employés pour calculer des racines carrées ou inverses de racines carrées ? Simplement, la précision requise est si faible qu'aucune itération n'est effectuée ?

          [*] à l'exception de quelques astuces qui risquent fort de rendre le résultat architecture dépendant.

          • [^] # Re: libre

            Posté par (page perso) . Évalué à  4 .

            à l'exception de quelques astuces qui risquent fort de rendre le résultat architecture dépendant.

            Pas vraiment. C'est juste dépendant du standard IEEE.

            Simplement, la précision requise est si faible qu'aucune itération n'est effectuée ?

            La précision est plus tôt bonne avec une seule itération de newton-raphson…
            error

      • [^] # Re: libre

        Posté par . Évalué à  3 .

        fsqrts %l1, %l2

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

  • # Autre perle

    Posté par (page perso) . Évalué à  4 .

    Le Graphics Programming Black Book de Michael Abrash, est téléchargeable gratuitement. Il parle beaucoup d'implémentation et d'optimisation (souvent en assembleur) du code derrière les moteurs de Doom et Quake. Ce n'est pas récent, mais cela reste toujours très intéressant à lire, en particulier l'approche pour optimiser et tester le code.

    • [^] # Re: Autre perle

      Posté par (page perso) . Évalué à  10 .

      Dans l'idée, il y a l'excellent Doom3 Source Code Review par Fabien Sanglard (en anglais), avec des trucs très intéressants tout du long et des interviews à la fin !

      Le travail de John Carmack est une objet d'étude : on peut l'étudier, on peut l'expliquer, le décrire, l'enseigner, on peut s'en inspirer, on peut le retravailler. Ce n'est que dans ces conditions que le logiciel est réellement une science !

      Le logiciel libre est une nécessité scientifique et une nécessité culturelle : le logiciel peut difficilement nourrir une tradition et une culture s'il n'est pas libre. L'œuvre de John Carmack dépasse les jeux d'id Software.

      ce commentaire est sous licence cc by 4 et précédentes

  • # Avantages de la programmation fonctionnelle?

    Posté par . Évalué à  3 .

    Hormis le fait évident qu'appliquer ce style de programmation rend les tests plus faciles, j'aimerais bien savoir quels sont les arguments pour ce type de programmation? Et en particulier, est-ce applicable à l'informatique de gestion? Et comment? Quelqu'un a-t-il vu/travaillé sur des exemples?
    C'est intéressant en tout cas, et à l'encontre de ce que je vois d'habitude. D'ailleurs, avec la généralisation des architectures SOA, j'ai l'impression qu'on produit du code de moins en moins fonctionnel. Beaucoup de comportements dépendent du contexte, et il y a une sorte de "contamination" généralisée du contexte. Seulement, est-ce que cela découle du type d'architecture (SOA et langage objet) ou bien de la manière dont c'est implémenté?
    Ce qui me fait dire cela, c'est que quand je codais en C, en C++ et en VB, il y a longtemps, je me rappelle que j'implémentais surtout des fonctions "pures". Et c'était assez facile à tester unitairement. Maintenant, c'est très compliqué.

    Bon, je précise que mes cours de Lisp, le seul langage fonctionnel que j'ai côtoyé, datent de mes études, que ça fait très longtemps, et de toute manière je ne me rappelle pas qu'on ait évoqué les avantages de ces langages, pas tellement de théorie, et pas du tout leur application hors du domaine de l'intelligence artificielle, où s'inscrivait ce cours.

    • [^] # Re: Avantages de la programmation fonctionnelle?

      Posté par . Évalué à  2 .

      j'aimerais bien savoir quels sont les arguments pour ce type de programmation?

      Relis l'article, les avantages y sont bien listés il me semble.

      est-ce applicable à l'informatique de gestion?

      Les langages de programmation font tous la même chose (à part ceux non "Turing-complet") donc ils sont applicable à tous les domaines (à part les problèmes de performance des implémentations).

      • [^] # Re: Avantages de la programmation fonctionnelle?

        Posté par . Évalué à  2 .

        Les langages de programmation font tous la même chose (à part ceux non "Turing-complet") donc ils sont applicable à tous les domaines (à part les problèmes de performance des implémentations).

        Les langages qui ne gèrent pas de portée d'identifiants (imagine un shell sans mot-clef local) ne permettent pas d'écrire des fonctions pures.

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: Avantages de la programmation fonctionnelle?

          Posté par . Évalué à  4 .

          Oui mais à partir du moment où il est Turing puissant, tu peux écrire un interpréteur pour un langage pur.

        • [^] # Re: Avantages de la programmation fonctionnelle?

          Posté par . Évalué à  2 .

          1) Même en utilisant des fonctions impures, tu peux obtenir le même résultat en global.

          2) Tu peux peut-être gérer toi-même une pile?
          Un tableau global et un index dans ce tableau, la fonction appelée incrémente l'index de la quantité de mémoire nécessaire et décrèmente l'index en sortie de fonction.

      • [^] # Re: Avantages de la programmation fonctionnelle?

        Posté par . Évalué à  4 .

        Relis l'article, les avantages y sont bien listés il me semble.
        Oui, réutilisabilité, testabilité, compréhension et maintenabilité. Mais ces avantages sont également mis en avant par les promoteurs des langages objet. J'aimerai voir des preuves :) ou au moins des arguments un peu plus développés, au-delà d'un programme de 3 lignes. Le seul argument qui ressort est l'indépendance par rapport aux threads.

        Sinon, oui, bien sûr c'est applicable en théorie. Mais en pratique? Est-ce que ça vaut la peine de se casser la tête pour implémenter la majorité de mon code de cette manière? Lui parle de programmer des jeux. Mais concevoir programmer des outils et des batchs de gestion est assez différent, je pense, car très dépendant de l'extérieur (base de données / fichiers / application externe).

        J'aimerais bien voir un exemple, même simple, de ce qu'on peut faire. Par exemple, imaginons qu'on ait une base de clients avec une table client. Si on souhaite juste faire une recherche du nom du client en fonction de son identifiant dans la table, ce n'est pas une fonction pure (puisque son résultat dépend de l'état de la base). Donc comment séparer ce qui est "impur" (dépendant de l'état de la base de données) de ce qui peut être codé en fonctions "pures"?

        • [^] # Re: Avantages de la programmation fonctionnelle?

          Posté par . Évalué à  2 .

          Mais en pratique? Est-ce que ça vaut la peine de se casser la tête pour implémenter la majorité de mon code de cette manière?

          Je ne sais pas, n'étant pas programmeur fonctionnel et dans tout les cas c'est difficile à dire, car certains langages comme Scala se revendiquent fonctionnel ET objet, et en plus entre Lisp et Haskell bien que les deux soient "fonctionnels" ce n'est pas du tout la même chose..

        • [^] # Re: Avantages de la programmation fonctionnelle?

          Posté par . Évalué à  7 .

          Par exemple, imaginons qu'on ait une base de clients avec une table client. Si on souhaite juste faire une recherche du nom du client en fonction de son identifiant dans la table, ce n'est pas une fonction pure (puisque son résultat dépend de l'état de la base). Donc comment séparer ce qui est "impur" (dépendant de l'état de la base de données) de ce qui peut être codé en fonctions "pures" ?

          Tu peut par exemple créer une fonction qui va faire la récupération des données (donc impure) et tu lui fait utiliser une fonction pure pour les traiter. L'avantage c'est que tu va pouvoir faire des tests unitaires simples et complets sur ton traitement (il gère les valeurs nulles ? comment se comporte il si l'utilisateur n'existe pas ? etc). S'il s'agit du traitement que tu parle c'est très (trop ?) trivial, mais dès que ton traitement est un peu évolué, tu y gagne.

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: Avantages de la programmation fonctionnelle?

          Posté par (page perso) . Évalué à  10 .

          Il se trouve que je code en ce moment une GED d'environ 15 ksloc en OCaml, et je peux peut-être t'éclairer sur le fonctionnel en informatique de gestion.

          Quand tu fais une appli qui interagit beaucoup avec le monde extérieur, il ne faut pas non plus être un ayatollah de la pureté (de toutes façon, si tu veux vraiment être un ayatollah, tu peux toujours coder en monades) : l'essentiel est que ta fonction prend des paramètres avec un typage fixe et renvoi des données ayant un typage fixe et ne travaille qu'avec ceux-ci (plus les variables locales).

          L'intérêt du fonctionnel n'est pas là (en tout cas en ce qui me concerne), mais plutôt :

          • L'absence de boucles (qui personnellement m'insupporte) au profit de l'utilisation de map/filter/find/exists et fold (quand tu as acquis une certaine expérience pour le fold). Utiliser ces fonctions rend le code plus propre et plus court, parallélisable naturellement et beaucoup plus facile à coder

          • L'ordre supérieur, qui te permet de définir des fonctions de fonctions de … , ce qui te permet d'écrire des fonction ultra générique que tu vas pouvoir spécialiser en fonction de différents contextes. Par exemple, j'ai une fonction construitArbo qui va construire une arborescence de fichiers d'un espace utilisateur Alfresco. Je donne à construitArbo 2 paramètres, une fonction qui se charge de faire le "ls" (contrainte Alfresco, je suis obligé de faire comme ça), et une fonction qui va effectuer des traitements sur chaque noeud de l'arbre. Ainsi, je peux donner différentes fonctions en paramètre de construitArbo, ce qui peut être utile si j'utilise un FS Unix-lie pour faire un ls, ou si je dois appliquer un traitement différent sur mes noeuds.

          • Le fait de disposer d'un typage vraiment puissant, en particulier le type somme, qui te permet de mettre la complexité de ton appli dans la définition des types et ainsi de bénéficier des vérifications de type du compilateur, qui a tendance à accepter de compiler lorsqu'il ne reste plus beaucoup de bugs (depuis un an de dev 90% de mes bugs viennent d'erreur dans les requêtes SQL, la définition d'url, bref la communication avec l'exterieur)

          • L'interdiction ou l'absence de valeur nulle, ce qui t'évites des monceaux de bugs. Dans une SSII, sur un gros projet où j'ai essentiellement débugué du Java pendant 8 mois, j'ai calculé que j'ai couté 15 000 € à la SNCF à corriger des nullPointerException. Franchement, j'ai gagné des mois de code grâce à ça.

          • Complètement thread-safe et donc scalable, Carmack l'a très bien expliqué, inutile de revenir là dessus. Si, juste pour dire que dans mon appli, les rares infos qu'on mettrait habituellement en mémoire globale, je les ais mis dans un Memcache (un Couchbase maintenant), donc j'ai qu'à lui donner l'url du serveur memcache (dans son fichier de conf) et je peux démarrer autant d'instance serveur que je veux. En plus individuellement, elles scalent elles-même automatiquement.

          Bref, ce que dit simplement Carmack, c'est : quand vous écrivez une fonction, faites en sorte qu'elle soit pure dans le sens où, à l'intérieur de celle-ci on n'interagit qu'avec les paramètres d'entrés et les variables locales.

          Tu peux évidemment aller beaucoup plus loin, mais si tu respectes déjà cette hygiène simple dans l'écriture de tes fonctions/méthodes, c'est déjà beaucoup.

          Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

          • [^] # Re: Avantages de la programmation fonctionnelle?

            Posté par . Évalué à  2 .

            quand vous écrivez une fonction, faites en sorte qu'elle soit pure dans le sens où, à l'intérieur de celle-ci on n'interagit qu'avec les paramètres d'entrés et les variables locales.

            Il faudrait aussi ne pas modifier les arguments passés par référence. D'ailleurs c'est une bonne idée de faire ça, mes derniers bugs venaient d'une fonction qui modifiait deux fois au lieu d'une le paramètre passé en référence. Si j'avais choisi de coder une fonction pure, je n'aurais jamais pu écrire un bug pareil.

            • [^] # Re: Avantages de la programmation fonctionnelle?

              Posté par (page perso) . Évalué à  2 .

              J'ai tellement plus l'habitude des langages où on peut changer la valeur par référence ;-p
              Dans ces cas là, dans la mesure du possible faire un clone.

              Le problème en est donc l'optimisation du GC : les langages fonctionnels sont fait pour gérer ces valeurs qu'on réalloc au lieu de les modifier en place, et parfois c'est optimisé pour se comporter comme une modification de référence.

              Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

        • [^] # Re: Avantages de la programmation fonctionnelle?

          Posté par . Évalué à  1 .

          Pour séparer le pur de l'impur, en Haskell il y a les monades. Par contre je ne saurai pas encore t'expliquer ce que c'est.
          Si ça t'intéresse, il y a le bouquin "Programming in Haskell" qui n'est pas trop épais, et qui donne un aperçu de ce que c'est que les monades, mais pas suffisant pour tout comprendre je pense, mais très bien pour débuter en Haskell. Et en lien avec ce bouquin il y a une série de vidéos de cours (gratuit) de Haskell qui reprend ce qu'il y a dans le livre à cette adresse : lien Et sinon il y a Real World Haskell, où tout est expliqué en détail mais je ne l'ai pas encore lu…

          • [^] # Re: Avantages de la programmation fonctionnelle?

            Posté par (page perso) . Évalué à  4 .

            Non.
            Pour séparer le pur de l'impur, il y a LA monade IO.
            Les autres monades, comme Maybe ou Continuation, n'ont rien à voir avec la pureté…

            • [^] # Re: Avantages de la programmation fonctionnelle?

              Posté par . Évalué à  1 .

              (Pour chipoter, hein :] )

              Non, même pas.
              Haskell (ou tout du moins son sous-ensemble Safe Haskell) est un langage entièrement pur, simplement il offre la possibilité de déclarer une valeur (main ∷ ∀a.IO a) dont il se trouve qu'elle va être exécutée par la plateforme sous-jacente. Mais ça ne fait pas partie de la sémantique du langage à proprement parler : en Haskell toutes les fonctions sont pures et toutes les valeurs sont référentiellement transparentes, point.

              • [^] # Re: Avantages de la programmation fonctionnelle?

                Posté par (page perso) . Évalué à  2 .

                C'est référentiellement transparent, System.Random.RIO?

                randomRIO (-1,1) >>= (\x -> if x == 1 then return 1 else undefined)
                
                

                Soit ça retourne, soit ça lance une exception (ou je pourrais le faire non-terminer).
                Effectivement, du point de vue type, c'est correct, mais du point de vue execution, c'est non-déterministe, et ça me parait donc difficilement référentiellement transparent…

                • [^] # Re: Avantages de la programmation fonctionnelle?

                  Posté par . Évalué à  4 .

                  Je m'explique :
                  D'un point de vue purement « langage », ce programme ne fait que construire une action qui, quand elle est exécutée, peut aléatoirement retourner soit 1 soit bottom. Mais l'action qui est construite sera toujours la même indépendamment du référentiel.

                  Donc oui, je maintient : la valeur System.Random.RIO, quelque soit le contexte, est toujours la même action. Que le résultat de son exécution varie, c'est une autre histoire.

    • [^] # Re: Avantages de la programmation fonctionnelle?

      Posté par . Évalué à  1 .

      Seulement, est-ce que cela découle du type d'architecture (SOA et langage objet) ou bien de la manière dont c'est implémenté ?

      Je pense que ça découle de la manière dont s'est implémenté en partie et une autre bonne partie viens de l'écosystème (je pense à Java EE). Dans les technologies Java EE (je ne sais pas ce qu'il en est de .Net par exemple) beaucoup de choses se bases sur le contexte et il faut produire un effort particulier pour réduire le couplage entre ton code et le reste du système qui n'est pas forcément fait (pour pleins de raison).

      De plus (en tout cas dans les contextes où j'ai travaillé) dans ce genre de programme, on réfléchis plus au niveau module (ou composants) que par fonction et (en principe) un composant doit pouvoir travailler tout seul et ce dernier a les même propriétés qu'une fonction pure (à quelques exceptions près).

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

  • # HashLife

    Posté par . Évalué à  6 .

    Un article qui m'a fait changer d'avis sur la programmation fonctionnelle que je considérais comme "naturellement inefficace"(*), c'est une implémentation alternative du jeu de la vie:
    http://www.drdobbs.com/jvm/an-algorithm-for-compressing-space-and-t/184406478
    http://en.wikipedia.org/wiki/Hashlife

    *: "As an extreme example, you can write a pure DrawTriangle() function that takes a framebuffer as a parameter and returns a completely new framebuffer with the triangle drawn into it as a result. Don’t do that."

    • [^] # Can your programming language do this?

      Posté par . Évalué à  3 .

      Un autre article (de 2006) qui m'avait aussi influencé. Sur un ton humoristique, il explique pourquoi Google avait "inventé" MapReduce et pourquoi Microsoft ne pouvait pas le faire au même moment. Simplement parce-que les ingénieurs de Google avaient été à l'école FP. (Depuis, MS a fait F# :-)

  • # Python

    Posté par (page perso) . Évalué à  4 .

    pour Python, une présentation qui a buzzée un peu ces derniers temps:
    Functional Programming with Python: http://ua.pycon.org/static/talks/kachayev/

    • [^] # Re: Python

      Posté par (page perso) . Évalué à  5 .

      Ouais enfin en Python, tu rates l'essentiel des langages de programmation fonctionnelle, à savoir la puissance du système de types.

      Python et Lisp, même combat !

      • [^] # PHP

        Posté par . Évalué à  1 .

        Il y a aussi Functional PHP, présentée lors de la DrupalCon Munich de cet été. Très bonne introduction à la programmation fonctionnelle pour les développeurs habitués à d'autres paradigmes.

        "Imperative Programming is following a recipe for a cake, Procedural Programming is singing a song with a refrain, Functional Programming is a spreadsheet with formulas"

  • # Scala

    Posté par . Évalué à  4 .

    Pour ceux qui souhaitent découvrir la programmation fonctionnelle, je recommande scala. Un cours gratuit de 7 semaines vient de se terminer sur Coursera, mais peut-être que les lectures sont encore en ligne. Les exercices étaient tous excellents, et tirés du livre de référence: Structure and Interpretation of Computer Programs.
    Ce style de programmation vit un net regain d'intérêt depuis quelques années, notamment depuis l'arrivée des processeurs multi-cores et du fameux "Claude" (vous savez, le nuage toussa). Un grand avantage dans ces deux cas et que la programmation fonctionnelle favorise les données dites "immutable", qu'on ne peut plus modifier une fois initialisées (comme une String en Java). Le traitement parallèle des données devient donc trivial, puisqu'il n'y a plus de données partagées et donc de concurrence d'accès (i.e synchronisation). Une fonction ne modifie pas ses paramètres d'entrée, n'a pas d'effets de bord, et est donc parfaitement reproductible quel que soit le contexte d'exécution (ce qui fait que les programmes fonctionnels sont plus facilement testables).
    Il y bien d'autres arguments, et on ne (re)fera pas le débat ici. Un point important apporté par l'article et qu'il est possible d'adopter des principes fonctionnels avec presque tous les langages, par exemple en ne modifiant pas ses variables, en utilisant des algorithmes récursifs, ou en passant des fonctions en paramètre d'autres fonctions (si le langage le permet, comme avec des pointeurs en C ou des "function object" en C++). Bien sûr, un vrai langage fonctionnel sera toujours plus adapté au style.
    Pour ceux qui aiment des arguments plus terre à terre, mon expérience montre qu'un programme en scala est nettement plus concis (2 à 3 fois) que son équivalent Java, et nettement plus maintenable (moins de bugs subtils de synchronisation qui au final sont souvent très longs et difficiles à corriger).

    • [^] # Re: Scala

      Posté par . Évalué à  2 . Dernière modification : le 14/11/12 à 18:25

      Pour les (futurs) fans du lisp, il y a clojure qui est sympa aussi. Comme scala, il y a des mécanismes pour gèrer simplement la concurrence et cela tourne sur la JVM.

      • [^] # Re: Scala

        Posté par . Évalué à  -1 .

        Et pour les futur fans du lisp, fuyez CommonLisp. Scheme, Clojure,… Les jolis Lisp c'est pas ce qui manque. Le seul truc sympa à faire en CL c'est un musée des horreurs.

        Please do not feed the trolls

  • # Article interessant

    Posté par . Évalué à  6 .

    L'article est interessant, et j'adore les discussions dans les commentaires.

    Un detail qui me chagrine un peu toutefois: est-ce possible de trouver un article/documentation/point de vue qui ne presente pas la programmation fonctionnelle sous l'angle "faisons une factorielle ou un quick sort, vous allez voir c'est epatant". Effectivement, c'est toujours epatant, mais j'avoue avoir du mal a relier ca au vrai monde.

    Quand je programme autre chose qu'un exemple jouet pour m'amuser, je ne reimplemente pas le quick sort. Je fais des operations basiques genre "valider les entrees utilisateur", "iterer sur des lignes de ma base de donnee", "construire une reponse pour l'utilisateur"… Ce sont des cas completement triviaux qui, au pifometre, represente la majorite du travail de developpement pour la majorite des developpeurs. Je me pourleche quand je dois ecrire un algo de parcours de graphe un peu marrant, mais ca arrive… une fois par an. Dans les autres cas, je ne vois pas bien ce que la PF peut m'apporter:
    - d'une part, je ne trouve pas d'introduction a la PF sur de vrais applications
    - d'autre part, il est difficile, voir contre-productif de se forcer a faire des fonctions "pures": elles s'en approchent souvent par defaut (pas d'effet de bord), ou alors les rendre pures est inutile (cas typique: je passe a ma fonction un objet qui est mon entree de base de donnee, j'y fait des modifications et je sauvegarde tout ca a la fin).

    Je trouve la PF fascinante, j'ai adore en faire et j'adorerait en faire a nouveau (dans un autre registre, j'adore le JS pour ca), mais j'avoue ne pas arriver a faire correspondre cet interet avec ce que je dois effectivement produire a la fin de la journee.

    • [^] # Re: Article interessant

      Posté par . Évalué à  3 .

      Je me repond a moi meme parce que je suis un connard pretentieux:
      Real World Haskell semble etre un tres bon debut. Je m'en rejouis d'avance!

      • [^] # Re: Article interessant

        Posté par . Évalué à  3 .

        Haskell a quand même le gros inconvénient que les performances sont assez difficile a évaluer (principalement à cause du lazy par défaut), c'était l'inconvénient principal noté dans un rapport sur l'utilisation d'Haskell.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.