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, là et là 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 palm123 (site web personnel) . Évalué à 4. Dernière modification le 14 novembre 2012 à 13:38.
pas compris la phrase, il en manque un bout ?
s/particper/participé
ウィズコロナ
[^] # Re: typo ?
Posté par BAud (site web personnel) . Évalué à 2.
corrigée (et quelques autres).
[^] # Re: typo ?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . É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 BAud (site web personnel) . Évalué à 2.
patch pris en compte, merci.
[^] # Re: typo ?
Posté par barmic . Évalué à 3. Dernière modification le 14 novembre 2012 à 14:33.
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 :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: typo ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Ce n'était pas un drame. Juste une phrase nominale, soit une tournure stylistique mettant en valeur un nom. Pour présenter quelqu'un, ça ne paraît pas vraiment inadéquat.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# libre
Posté par Octabrain . É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 barmic . Évalué à 6. Dernière modification le 14 novembre 2012 à 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.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: libre
Posté par guppy . É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 Octabrain . Évalué à 2.
Il l'a quand même popularisée.
[^] # Re: libre
Posté par BAud (site web personnel) . Évalué à 7.
de l'intérêt de parler d'une révolution ! ;-)
[^] # Re: libre
Posté par Maclag . Évalué à 5.
c'est un peu l'Apple de l'algo sur la racine carrée quoi…
---------->[ ]
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 14 novembre 2012 à 15:59.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: libre
Posté par oinkoink_daotter . Évalué à 5.
N'est-ce pas plutôt le rangeCheck d'Oracle ?
[^] # Re: libre
Posté par reno . Évalué à 10.
Yes, Apple eux ils brevettent les rectangles aux coins arrondis..
[^] # Re: libre
Posté par oinkoink_daotter . Évalué à 9.
Et les scroll list qui font chboing quand on arrive en bas :-)
[^] # Re: libre
Posté par FantastIX . É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 Troy McClure (site web personnel) . Évalué à 3.
C'est cool le truc de la racine carré mais ça ne sert plus à rien depuis un certain nombre d'années
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: libre
Posté par Shuba . É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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . É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.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: libre
Posté par 2PetitsVerres . É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 weeber (site web personnel) . É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 Thomas Debesse (site web personnel) . É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 Flo . É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 reno . Évalué à 2.
Relis l'article, les avantages y sont bien listés il me semble.
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 barmic . Évalué à 2.
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.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Avantages de la programmation fonctionnelle?
Posté par fmaz fmaz . É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 reno . É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 Flo . Évalué à 4.
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 reno . Évalué à 2.
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 barmic . Évalué à 7.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Avantages de la programmation fonctionnelle?
Posté par Ontologia (site web personnel) . É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.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Avantages de la programmation fonctionnelle?
Posté par Shuba . Évalué à 2.
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 Ontologia (site web personnel) . É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.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Avantages de la programmation fonctionnelle?
Posté par max22 . É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 Axioplase ıɥs∀ (site web personnel) . É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 navaati . É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 Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
C'est référentiellement transparent, System.Random.RIO?
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 navaati . É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 Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Ok :)
[^] # Re: Avantages de la programmation fonctionnelle?
Posté par barmic . Évalué à 1.
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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# HashLife
Posté par reno . É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 Imagine2 . É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 saimn . É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 Perthmâd (site web personnel) . É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 Nerdiland de Fesseps . É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.
# Scala
Posté par Imagine2 . É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 benja . Évalué à 2. Dernière modification le 14 novembre 2012 à 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 Zylabon . É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 Duncan Idaho . É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 Duncan Idaho . É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 reno . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.