Programmation fonctionnelle à la hausse?

42

J'ai remarqué récemment que les langages de programmation fonctionnels gagnent en popularité . J'ai récemment vu comment l' indice de Tiobe montre une augmentation de leur popularité par rapport à l'année dernière bien que la plupart d'entre eux n'atteignent même pas les 50 langues les plus populaires selon cet indice.

Et c'est le cas depuis assez longtemps. La programmation fonctionnelle n’est tout simplement pas devenue aussi populaire que d’autres modèles (c.-à-d. La programmation orientée objet).

J'ai toutefois constaté un regain d'intérêt pour le pouvoir de la programmation fonctionnelle et, maintenant que les multicœurs sont de plus en plus populaires, les développeurs ont commencé à s'intéresser à d'autres modèles de concurrence déjà explorés dans le passé par des langages tels que Haskell et Erlang.

Je constate avec un vif intérêt le fait que, malgré leur manque d’acceptation de la part de la communauté, de plus en plus de langues de ce type continuent d’apparaître. Clojure (2007), Scala (2003), F # (2002) ne sont que trois exemples de la dernière décennie.

J'ai moi-même investi du temps à apprendre Haskell et Scala. Et je trouve un grand potentiel dans le paradigme qui était nouveau pour moi alors qu’il était là-bas depuis si longtemps.

Et bien sûr, ma plus grande question est de savoir si l’un d’eux va devenir assez populaire pour qu’il soit envisagé de s’efforcer de le faire, mais c’est une question à laquelle même Mandrake n’a pas pu répondre, malgré tout le bruit que les gens font à leur sujet.

Ce que je veux demander, c'est:

  • Dans quels scénarios devrais-je considérer un langage de programmation fonctionnel plus apte à effectuer une tâche donnée? Outre le problème de la programmation parallèle très populaire qui a récemment fait fureur.
  • Si je décidais de passer à un langage de programmation fonctionnel, lequel considéreriez-vous comme le plus gros piège auquel je serais confronté? (Outre le changement de paradigme et la difficulté d'évaluer les performances en raison d'une évaluation paresseuse).
  • Avec autant de langages de programmation fonctionnels, comment choisir celui qui convient le mieux à vos besoins?

Toute recommandation pour des recherches ultérieures sera plus que bienvenue.

J'ai recherché des opinions sur le Web, et il semble que toute cette popularité renouvelée vienne de l'idée que nous allons bientôt nous retrouver face à la loi de Moore et que les langages de programmation fonctionnels viendront nous sauver héroïquement. Mais si tel est le cas, je dirais qu'il y a plus de probabilités que les langages populaires existants s'adaptent au paradigme.

Certains d’entre vous, ayant peut-être plus d’expérience au quotidien avec ces langues, peuvent offrir plus de perspicacité sur le sujet. Toutes vos opinions seront mieux appréciées et soigneusement examinées.

Merci d'avance!

programming-languages functional-programming Edalorzo
la source
4
C'est Erlang, pas Earlang (j'aurais édité votre message, mais le système n'autorise pas les modifications d'une lettre).
quant_dev
6
Cela vaut la peine de dire - il n'y a pas de ligne de démarcation entre les langages fonctionnel et impératif. Les langues de la famille ML ne sont pas exemptes d’effets secondaires et supportent les déclarations et structures impératives ainsi que les variables modifiables. Certains langages impératifs - qui me viennent à l’esprit - Python et Javascript - ont d’importantes fonctionnalités empruntées à la programmation fonctionnelle. Personnellement, j'espère voir des idées plus fonctionnelles d'usage courant - en particulier la recherche de motifs.
Steve314
1
Avoir quelques fonctionnalités communes aux langages fonctionnels ne rend pas nécessairement un langage "fonctionnel". La programmation fonctionnelle concerne autant une manière de penser et de concevoir des programmes qu’un aspect spécifique du langage.
Mipadi
2
@ mipadi - et vous pouvez donc appliquer la philosophie fonctionnelle dans n’importe quelle langue, dans la mesure où le permettent les outils disponibles. Vous pouvez écrire du code de style fonctionnel en Python (dans les limites), et dans cette mesure, Python est un langage fonctionnel. Et vous pouvez écrire du code de style impératif dans ML, et dans cette mesure, ML est un langage impératif. Ce n'est pas tout à fait la même chose que "les mauvais programmeurs peuvent écrire Fortran dans n'importe quelle langue", bien que ce soit un piège facile à tomber si vous interprétez mal mon propos.
Steve314
1
@ mipadi - mais si le langage impératif avait toutes les constructions fonctionnelles normales, vous pouviez tout faire avec un langage fonctionnel - l'écart serait comblé, et la question serait "Quelle est la meilleure façon de le faire" plutôt que "quelle est la manière fonctionnelle / impérative". La famille ML a déjà fermé cette lacune, vraiment, mais parce qu'il est appelé fonctionnel, nous pensons à son style comme style fonctionnel plutôt que de simplement bon style.
Steve314

Réponses:

24

Dans quels scénarios devrais-je considérer un langage de programmation fonctionnel plus apte à effectuer une tâche donnée? Outre le problème de la programmation parallèle très populaire qui a récemment fait fureur.

Tout ce qui implique la création d'une séquence d'éléments de données dérivés à l'aide d'un certain nombre d'étapes de transformation.

Essentiellement, le "problème de tableur". Vous avez des données initiales et un ensemble de calculs ligne par ligne à appliquer à ces données.

Nos applications de production font un certain nombre de résumés statistiques de données; tout cela est mieux abordé fonctionnellement.

Une chose commune que nous faisons est une fusion de trois ensembles de données monstrueux. Semblable à une jointure SQL, mais pas aussi généralisé. Ceci est suivi par un certain nombre de calculs de données dérivées. Ce ne sont que des transformations fonctionnelles.

L'application est écrite en Python, mais dans un style fonctionnel utilisant des fonctions de générateur et des tuples nommés immuables. C'est une composition de fonctions de niveau inférieur.

Voici un exemple concret de composition fonctionnelle.

for line in ( l.split(":") for l in ( l.strip() for l in someFile ) ):
    print line[0], line[3]

C'est un des moyens par lesquels la programmation fonctionnelle influence des langages tels que Python.

Parfois, ce genre de chose s’écrit:

cleaned = ( l.strip() for l in someFile )
split = ( l.split(":") for l in cleaned )
for line in split:
     print line[0], line[3]

Si je décidais de passer à un langage de programmation fonctionnel, quels sont selon vous les plus gros pièges à affronter? (Outre le changement de paradigme et la difficulté d'évaluer les performances en raison d'une évaluation paresseuse).

Les objets immuables sont le plus difficile des obstacles.

Souvent, vous finissez par calculer des valeurs qui créent de nouveaux objets au lieu de mettre à jour des objets existants. L'idée que c'est un attribut modifiable d'un objet est une habitude mentale difficile à briser.

Une fonction de propriété ou de méthode dérivée est une meilleure approche. Les objets avec état sont une habitude difficile à briser.

Avec autant de langages de programmation fonctionnels, comment choisir celui qui convient le mieux à vos besoins?

Ce n'est pas grave au début. Choisissez n'importe quelle langue à apprendre. Une fois que vous savez quelque chose, vous êtes en mesure d'en choisir un autre pour répondre à vos besoins.

J'ai lu sur Haskell simplement pour comprendre ce qui manque à Python.

S.Lott
la source
5
@edalorzo: Python n'est pas faiblement typé. C'est très, très fortement typé. Il n'y a pas d'opérateur de casting, il est donc plus fortement typé que Java ou C ++.
S.Lott
5
@ S.Lott - l'aide à la vérification de types statiques ne vous aide-t-elle pas avec les outils de refactoring IDE et les outils de type intellisense? Si la compilation en arrière-plan est en cours et que vous vérifiez les types de manière statique, cela ne signifie-t-il pas que vous pouvez automatiser davantage vos outils? Je conviens que si vous avez une couverture de code à 100% dans vos tests, elle le détectera. Vous devez savoir que moins de 50% du code de production de l'entreprise dispose d'une couverture de tests unitaires, n'est-ce pas? :) Il y a un monde réel dans lequel nous devons vivre.
Scott Whitlock
8
@ S.Lott "La vérification de type statique n'est pas très utile. Peu importe qu'il s'agisse d'une vérification statique effectuée par un compilateur ou d'une vérification à l'exécution. Vous écrivez toujours la même quantité de code et le même nombre de tests unitaires. " Euh, non. Le point entier de vérification de type statique est qu'il attrape les insectes, par conséquent, il massivement réduit la quantité de tests requis.
Jon Harrop
3
@ S.Lott "Python n'est pas faiblement typé. Il est très, très fortement typé." Python jette implicitement entre les types numériques, qui sont faiblement typés.
Jon Harrop
3
@ Steve314 "Après tout, la vérification de type statique détecte certaines erreurs qui correspondent à certaines règles de base. Les tests unitaires, en principe, peuvent détecter toutes ces erreurs et bien d'autres." Non. La vérification statique prouve l'exactitude d'un aspect d'un programme. Les tests unitaires cherchent à réfuter l'exactitude mais ne prouvent pas l'exactitude. Les tests unitaires ne remplacent pas la vérification de type statique, ni aucun autre type de preuve.
Jon Harrop
23

"Fonctionnel" est un ensemble de fonctionnalités différentes, dont chacune est utile indépendamment, et je trouve plus utile d'examiner chacune d'elles individuellement.

Immutabilité

Maintenant que je suis au courant, chaque fois que je peux obtenir un résultat immuable, j'essaie toujours de le faire, même dans un programme orienté objet. Il est plus facile de raisonner sur le programme si vous avez des données de type valeur. En règle générale, vous avez besoin de mutabilité pour des éléments tels que les interfaces graphiques et les goulots d'étranglement des performances. Mes entités (utilisant NHibernate) sont également modifiables (ce qui est logique car elles modélisent des données stockées dans une base de données).

Fonctions en tant que types de première classe

Quel que soit votre choix, le fait de contourner les délégués, les actions ou les fonctions est un moyen très pratique de résoudre toute une série de problèmes du monde réel, comme le "modèle au milieu". J'ai également constaté que transmettre un délégué, une action ou une fonction à un objet était plus propre que de laisser cette classe déclarer un événement et de le lier à cet événement (en supposant qu'il n'y ait normalement qu'un seul "écouteur"). Lorsque vous savez qu'il existe un écouteur, l'action de rappel peut être transmise en tant que paramètre constructeur (et être stockée dans un membre immuable!).

Pouvoir composer des fonctions (par exemple, se transformer Action<T>en un simple Actionest également très utile dans certains scénarios.

Nous devrions également noter la syntaxe Lambda ici, car vous n’obtenez la syntaxe Lambda que lorsque vous promouvez des fonctions en types de première classe. La syntaxe Lambda peut être très expressive et concise.

Monades

Certes, c’est mon point faible, mais je crois comprendre que les flux de travail de calcul en F #, tels que le asyncflux de travail, sont une monade. C'est une construction subtile mais très puissante. C'est aussi puissant que le yieldmot - clé utilisé pour créer des IEnumerableclasses en C #. Il s’agit essentiellement de construire une machine à états pour vous sous les couvertures, mais votre logique semble linéaire.

Évaluation paresseuse et récursivité

Je les ai mises ensemble parce que, même si elles sont toujours regroupées en tant que caractéristiques de la programmation fonctionnelle, elles ont si rapidement pénétré dans des langages autrement impératifs qu'il est difficile de les appeler fonctionnelles.

Expressions S

J'imagine que je ne sais pas trop où mettre ceci, mais la possibilité de traiter le code non compilé comme un objet (et de l'inspecter / le modifier), comme Lisp S-Expressions ou LINQ Expressions, est, à certains égards, l'outil le plus puissant de la programmation fonctionnelle. La plupart des nouvelles interfaces "fluentes" et des DSL .NET utilisent une combinaison de syntaxe lambda et d'expressions LINQ pour créer des API très concises. Sans parler de Linq2Sql / Linq2Nhibernate où votre code C # est "magiquement" exécuté en SQL au lieu de code C #.

C'était la longue réponse à la première partie de votre question ... maintenant ...

Si je décidais de passer à un langage de programmation fonctionnel, quels sont selon vous les plus gros pièges à affronter? (Outre le changement de paradigme et la difficulté d'évaluer les performances en raison d'une évaluation paresseuse).

Le plus gros écueil auquel j'ai été confronté a été d'essayer de trouver la limite entre l'utilisation de solutions fonctionnelles et les solutions impératives. Cependant, après avoir essayé les deux approches plusieurs fois, vous commencez à vous faire une idée de ce qui fonctionnera mieux.

Avec autant de langages de programmation fonctionnels, comment choisir celui qui convient le mieux à vos besoins?

Si vous connaissez .NET, je vous suggère fortement F #. Par contre, si vous connaissez mieux la machine virtuelle, il y a toujours Clojure . Si vous êtes plus académique que pratique, alors j'opterais pour Common Lisp ou Scheme. Si vous connaissez déjà Python, je pense qu’il existe déjà de nombreuses constructions fonctionnelles.

Scott Whitlock
la source
@ Scott Merci pour votre explication détaillée. J'imagine que ce que vous décrivez comme le plus gros écueil serait éliminé de l'équation en utilisant un langage de programmation purement fonctionnel, tel que Haskell. C'est pourquoi j'ai commencé avec cela, parce que j'ai été un programmeur impératif toute ma vie, et que je ne veux pas jouer avec un langage de programmation impur et que je risque de ne pas apprendre de la bonne façon. Si cela ne vous dérange pas que je pose une autre question: deux outils qui me préoccupent sont les outils et les bibliothèques. Quelle est la qualité de l'intégration de F # avec d'autres outils et bibliothèques .Net?
Edalorzo
Je ne comprends pas pourquoi vous regroupez le code lors de l'exécution et la génération et l'inspection de code d'exécution avec la programmation fonctionnelle. Les deux n'ont aucun rapport l'un avec l'autre. Les capacités de métaprogrammation que vous décrivez peuvent être ajoutées à presque toutes les langues, fonctionnelles ou non. Je pense que Lisp a commencé le code en tant que tendance de données, mais il est maintenant disponible en ruby ​​et dans d'autres langages non fonctionnels.
davidk01
1
L'intégration de @edalorzo-F # avec .NET est très bonne, à une exception près près: aucun concepteur d'interface graphique. Vous pouvez contourner ce problème en concevant votre interface graphique dans un assemblage C # et en le référençant à partir de F #, ou en générant l'interface graphique à l'intérieur de F # uniquement dans le code (pas avec un concepteur).
Scott Whitlock
@ davidk01 - bonne question sur la méta-programmation. Je trouve juste que la syntaxe lambda et la méta-programmation se construisent l'une sur l'autre, mais vous avez raison, elles pourraient être séparées. Il semble que vous ayez plus de chance de faire de la méta-programmation avec un langage fonctionnel.
Scott Whitlock
1
@Scott: À bien des égards, c'est plus facile - par exemple, lorsque vous n'avez pas à vous soucier des effets secondaires, vous pouvez modifier une section de code à la volée avec beaucoup plus de confiance - cela limite ce que vous devez changer.
Michael K
15

Et c'est le cas depuis assez longtemps. La programmation fonctionnelle n’est tout simplement pas devenue aussi populaire que d’autres modèles (c’est-à-dire la programmation orientée objet).

Cela est vrai si vous comptez les programmes développés par des programmeurs professionnels (ou au moins des personnes se considérant comme telles). Si vous étendez votre réseau pour inclure des programmes développés par des personnes qui ne se considèrent pas comme telles, la PF (ou du moins la programmation dans un style fonctionnel) est assez proche de OO (Excel, Mathematica, Matlab, R ... et même du JavaScript "moderne" ).

Dans quels scénarios devrais-je considérer un langage de programmation fonctionnel plus apte à effectuer une tâche donnée? Outre le problème de la programmation parallèle très populaire qui a récemment fait fureur.

Mon opinion personnelle est que le multicœur n’est pas la principale caractéristique de FP (du moins jusqu’à ce que les compilateurs Haskell, Scala, Clojure, F # résolvent le problème de la localisation du cache). La fonction tueur est map, filter, foldet les amis qui permettent une expression plus succincte d'un grand groupe d'algorithmes. À cela s’ajoute une syntaxe plus concise des langages de PF que les langages homologues les plus courants.

En outre, le fait que FP soit plus proche du modèle relationnel réduit le déséquilibre impédance avec le SGBDR ... ce qui est - encore une fois - du moins pour les non-programmeurs - très gentil.

Aussi, lorsque vous avez des difficultés particulières à satisfaire les exigences de "correction" - sous une forme difficile à tester (courante dans le calcul scientifique / l'analyse de données volumineuses, dans le but d'obtenir des résultats auparavant inconnus et en tant que tels, non spécifiables), la PF peut offrir avantages

Si je décidais de passer à un langage de programmation fonctionnel, quels sont selon vous les plus gros pièges à affronter?

  • manque de support d'outils (F # et quelques Lisps étant l'exception, Scala étant sur le chemin)
  • plus difficile de faire sortir le dernier bit de performance de votre matériel
  • les communautés se concentrent souvent sur des problèmes différents de ceux rencontrés par un grand nombre de projets de développement de logiciels commerciaux
  • très peu de développeurs expérimentés dans l'utilisation de la PF dans un contexte industriel et si vous pouvez les trouver, vous devrez probablement faire concurrence au salaire et aux avantages que le secteur financier peut offrir
  • le style de programmation fonctionnel a tendance à être plus difficile à déboguer; C'est-à-dire qu'observer entre les résultats dans une longue chaîne de fonctions composées n'est généralement pas possible dans la plupart des débogueurs (tous?)

Avec autant de langages de programmation fonctionnels, comment choisir celui qui convient le mieux à vos besoins?

  • Combien de vos problèmes peuvent être résolus en sortant déjà des bibliothèques / frameworks sur quelle plate-forme (par exemple, JVM ou .Net), combien sont nouveaux? Existe-t-il des constructions de langage capables d'exprimer ces problèmes directement?

  • De quel contrôle de bas niveau avez-vous besoin sur les performances d'espace et de temps de votre application?

  • Quelles sont les exigences de votre "exactitude"?

  • Pouvez-vous vous permettre de recycler des développeurs et / ou de concurrencer les avantages offerts par certaines niches très rentables du développement de logiciels?

Alexander Battisti
la source
+1 @Alexander, c’est certainement l’une des meilleures réponses à cette discussion. Vous avez apporté une nouvelle dimension à la discussion en introduisant le facteur humain, la difficulté de trouver des développeurs qualifiés et de les maintenir motivés. Je suis tout à fait d'accord avec votre vision des principales caractéristiques de FP langs, car chaque jour, je vois de plus en plus de langages impératifs les adopter. Mais votre message m'a ouvert les yeux pour me rendre compte qu'il y a beaucoup de choses que je ne connais pas encore sur la PF. Enfin, votre objectif de vous baser sur une plate-forme existante telle que .Net ou Java est certainement très valable et tout à fait sensé.
Edalorzo
9

Si je décidais de passer à un langage de programmation fonctionnel, quels sont selon vous les plus gros pièges à affronter? (Outre le changement de paradigme et la difficulté d'évaluer les performances en raison d'une évaluation paresseuse).

En supposant que vous soyez un développeur C ++ / C # / Java dans l'industrie ...

Soyez prêt pour les pairs grincheux qui ne veulent rien apprendre. Préparez-vous à ce que les patrons aux cheveux pointus imposent de mauvais choix linguistiques "parce qu'ils ont déjà codé". Préparez-vous à ce que les universitaires sur les forums vous encouragent à propos des monoïdes. Préparez-vous à des guerres de langage sans fin, car Scala n’a même pas l’élimination de la queue et Clojure a vraiment besoin de pédales pour tous les supports et ne me lancez pas sur Erlang.

Si vous êtes un programmeur Web, le plus gros piège sera probablement vos cheveux.

Avec autant de langages de programmation fonctionnels, comment choisir celui qui convient le mieux à vos besoins?

Je commencerais par plateforme:

  • OCaml est génial sous Linux et terrible sous Windows.
  • F # est excellent sous Windows et affreux sous Linux.
  • Scala et Clojure sont excellents sur la JVM.
Jon Harrop
la source
1
Quand je lis "Soyez prêts pour des camarades grincheux qui ne veulent rien apprendre." Je voulais crier: "Tellement vrai! Tellement vrai!" mais c'est vraiment triste.
Zelphir Kaltstahl le
3

Pour une perspective (certes biaisée) sur cette question, vous pouvez consulter le blog de Bob Harper, Existential Type . Carnegie Mellon a récemment retravaillé son cursus CS pour d'abord enseigner la programmation fonctionnelle, d'autres paradigmes n'étant enseignés qu'une fois que la programmation fonctionnelle est bien ancrée. Harper donne un coup de pouce au fil de la mise en pratique du nouveau curriculum. .

Harper est l’un des principaux développeurs du langage de programmation Standard ML, il est donc juste de dire que sa propre opinion sur la question peut être devinée à l’avance, et il ne craint certainement pas les déclarations controversées dans lesquelles il plaide pour cette position, mais il fait son cas bien.

jimwise
la source
1
+1 Cet article est certainement très intéressant et je le garderai désormais dans mes favoris. Je pense qu'enseigner la PF en premier est certainement une bonne approche, car il est vraiment difficile de se débarrasser de l'impératif de penser si on le fait autrement, et surtout si vous n'utilisez pas un langage de programmation purement fonctionnel, il est difficile de casser l'ancien des habitudes. Je constate également que les principaux langages POO intègrent des fonctionnalités et que l'acquisition des compétences et de l'état d'esprit d'un programmeur fonctionnel doit donc s'avérer très utile dans un proche avenir. Aperçu intéressant, merci!
Edalorzo
@jimwise: +1 pour l'article de Harper. Je trouve son approche très appropriée. @edalorzo: Lorsque vous commencez à penser de manière fonctionnelle, vous voyez le paradigme impératif comme un dernier recours que vous devez appliquer pour optimiser votre programme lorsqu'il n'est pas assez rapide. Récemment, j'ai écrit quelques petits outils dans Scala, pas très grands mais non triviaux et dotés de fonctionnalités réelles. À mon grand étonnement, je n'ai utilisé varaucune collection mutable ni une seule fois. Ainsi, la pensée impérative est à l’OMI une sorte d’optimisation prématurée qui, comme nous le savons tous, est la racine de tous les maux.
Giorgio
2

Dans quels scénarios devrais-je considérer un langage de programmation fonctionnel plus apte à effectuer une tâche donnée? Outre le problème de la programmation parallèle très populaire qui a récemment fait fureur.

Il n'y a pas de formule magique qui vous indique quand utiliser la programmation fonctionnelle. Ce n'est pas comme si la programmation orientée objet était mieux adaptée à nos situations de programmation actuelles. C'est juste une autre façon de structurer les programmes en termes d'un autre ensemble d'abstractions.

Si je décidais de passer à un langage de programmation fonctionnel, quels sont selon vous les plus gros pièges à affronter? (Outre le changement de paradigme et la difficulté d'évaluer les performances en raison d'une évaluation paresseuse).

La programmation fonctionnelle n'a rien à voir avec la paresse. ML et OCaml sont des langages fonctionnels et stricts. Le plus gros obstacle que vous aurez à surmonter est de structurer les choses en termes de valeurs immuables et de vous garder en tête, quelle que soit l’abstraction utilisée dans le système de types pour les effets secondaires. Les langages fonctionnels conviennent mieux à l'optimisation car ils rendent les effets secondaires très explicites dans le système de types. Haskell utilise des monades, mais il existe d'autres approches pour utiliser des effets dans des langages fonctionnels purs. Nettoyer a des types d'unicité et certains autres langages en développement ont d'autres choses.

Avec autant de langages de programmation fonctionnels, comment choisir celui qui convient le mieux à vos besoins?

Parmi les langages de programmation dont je suis au courant, je dirais que seuls Haskell et Clean peuvent être appelés langages fonctionnels. Tous les autres permettent des effets secondaires sans rendre ces effets explicites dans le système de types. Donc, si vous allez consacrer du temps à l’apprentissage de la programmation fonctionnelle, alors Haskell est probablement le seul qui convient à la facture. Tous les autres que je connais, Erlang, Scala, Clojure, etc., ne fournissent que des abstractions fonctionnelles au-dessus d’un langage impératif. Donc, si vous voulez aborder le paradigme fonctionnel par morceaux, alors je vous recommanderais Scala ou Erlang et si vous voulez tout aborder en même temps et éventuellement abandonner de frustration, alors vous devriez choisir Haskell.

davidk01
la source
@ Dadivk01 +1 J'aime le raisonnement selon lequel FP langs n'est qu'un outil concurrentiel comme un autre et peut être utilisé pour résoudre les mêmes problèmes que ceux résolus avec d'autres modèles. Pourquoi pensez-vous qu'ils sont moins populaires, alors? Et, seriez-vous toujours d’accord pour dire qu’ils sont mieux à même de résoudre le problème de l’informatique parallèle que, par exemple, la plupart des langs OOP? Diriez-vous que le type de données immuable a une influence sur l'empreinte mémoire et sur les performances par rapport aux langues impératives? Je donnais une chance à Haskell, pourquoi voudriez-vous dire "abandonne dans la frustration", tu me fais peur, mec :)
edalorzo
@edalorzo: Je ne pense pas que la programmation fonctionnelle soit meilleure pour les algorithmes parallèles. Les gens confondent la programmation déclarative avec la programmation fonctionnelle. Ce qui est utile à la programmation fonctionnelle, c'est son caractère déclaratif et un groupe de personnes très intelligentes écrivant d'excellents compilateurs pour traduire le code déclaratif en code machine. Tout autre langage qui miserait davantage sur la description de problèmes que sur la clarification explicite de détails mineurs serait tout aussi bon pour la programmation parallèle.
davidk01
@edalorzo: En ce qui concerne "abandonner dans la frustration", je le dis parce que si la programmation impérative est tout ce que vous savez, le système de typage de haskell et son approche monadique pour décrire les effets pourraient en faire un peu trop. Je pense qu'il est préférable de commencer avec un langage qui adopte une approche plus pragmatique des effets secondaires, comme Erlang et Scala.
davidk01
0

J'attribuerais la hausse actuelle des intérêts dans les langages fonctionnels au fait qu'ils sont idéaux pour l'informatique parallèle. Par exemple, toute l'idée de carte-réduction est basée sur le paradigme fonctionnel. Et il ne fait aucun doute que l'informatique parallèle augmentera, car il est clair qu'actuellement, la montée en gamme est beaucoup plus facile et moins chère que la mise à l'échelle. Même sur le marché grand public, les processeurs ont plus de cœurs, pas plus de GHz.

EDIT: puisque ce n'est pas évident pour tous.

En programmation fonctionnelle pure, une fonction prend une entrée, produit une sortie et n'a aucun effet secondaire. N'ayant aucun effet secondaire, cela signifie qu'il n'a pas d'état partagé, donc pas besoin de mécanismes de synchronisation, qui seraient sinon nécessaires lors de l'exécution simultanée. La synchronisation est la partie la plus difficile de tout logiciel concurrente / parallèle, ce qui la rend purement fonctionnelle, vous n'avez donc pas à vous occuper de la partie la plus difficile du tout.

Comme pour map-reduction, même le nom vient de la programmation fonctionnelle (la cartographie et la réduction sont des opérations typiques du paradigme fonctionnel). Les deux étapes de la réduction de la carte sont des fonctions qui s'exécutent en parallèle, prennent des entrées, produisent des sorties et n'ont aucun effet secondaire. Donc, c'est exactement l'idée de programmation fonctionnelle pure.

Quelques exemples de PF utilisés pour le parallélisme:

  • CouchDB - construit sur Erlang
  • Chat Facebook - construit sur Erlang
  • Twitter - grande partie construite sur Scala
vartec
la source
3
Tout le monde fait la demande de programmation parallèle, mais il y a très peu de données pour la sauvegarder. Si vous êtes au courant de telles sources, vous devriez les citer. Les calculs complexes ont souvent des dépendances de données complexes et si vous utilisez un paradigme de programmation fonctionnel, l'interdépendance de certains modèles en termes de données ne disparaît pas comme par magie. La programmation GPU est aussi parallèle que possible, mais ils utilisent bien des langages impératifs, car les modèles avec
lesquels
4
@vartec: Dans un souci d'objectivité, il serait toujours utile que vous fournissiez une référence qui sauvegarde vos revendications. Cela aiderait beaucoup plus les lecteurs ignorants qu'une contre-question ...
blubb
1
@vartec: En fait non, il ne m'est jamais venu à l'esprit qu'un grand nombre de personnes ayant formulé des affirmations avaient dit vrai. Je blâme ma formation en mathématiques, mais nous ne croyons pas tous en des faits tels que des faits concrets et des justifications concrètes de nos affirmations, et votre révision ne répond toujours pas à mon commentaire.
davidk01
1
@vartec Vous pourriez faire référence à une source crédible soutenant vos revendications.
quant_dev
1
+1 @ davidk01 "Tout le monde affirme ce qu'il est en programmation parallèle, mais il y a très peu de données pour la sauvegarder". Je suis au courant d'une énorme quantité de preuves du contraire. Par exemple, les articles Cilk décrivent l’importance primordiale de la mutation sur place si vous souhaitez une bonne complexité de la mémoire cache, qui est une exigence du parallélisme évolutif sur un multicœur.
Jon Harrop