IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La programmation fonctionnelle est-elle le futur ?
Selon un adepte, « tous les langages modernes vont bientôt se baser sur ses principes »

Le , par Amine Horseman

238PARTAGES

2  0 
Un nouvel article sur Medium a attiré notre attention. Cette fois, il s’agit d’un article ayant pour titre « La programmation fonctionnelle devrait être la priorité n°1 en 2015 ».

L’auteur de cet article affirme que « les langages orientés objet ne peuvent pas nous sauver du monstre qu’est le Cloud », ceci parce que ces « langages sont basés sur des états mutables » et ne simplifient pas « les modèles concurrents et le parallélisme au sein des applications », à l’inverse de la programmation fonctionnelle.

Pour rappel, la programmation fonctionnelle est apparue il ya plus de 60 ans déjà avec Lisp. Selon la définition de Wikipédia, ce paradigme « considère le calcul en tant qu'évaluation de fonctions mathématiques et rejette le changement d'état et la mutation des données ». Pourtant, les langages impératifs comme le C avaient eu plus de succès dans le passé et même maintenant, surement à cause de leur efficacité en terme de temps d’exécution et de gestion de la mémoire.

Pourtant, l’auteur de l’article que nous avons cité plus haut croit profondément que ceci pourrait changer avec la rapidité des ordinateurs actuels et la démocratisation du Cloud et du parallélisme massif.

« Vous pouvez exécuter une fonction un millier de fois dans différents cores ou machines, vous n’allez pas obtenir des sorties différentes de ce que vous avez obtenu avant. Ainsi, vous pouvez utiliser le même code pour exécuter votre traitement dans un seul processeur aussi bien que dans 1000 processeurs. La vie peut être facile à nouveau ». Toutefois, ceci ne veut pas dire qu’il faut arrêter d’utiliser les états mutables. Au contraire, l’auteur assure que « l’idée principale de la programmation fonctionnelle est qu’il faut utiliser les états immutables seulement lorsqu’il est nécessaire ».

Ces états qui ne changent pas durant l’exécution sont fournis dans ce type de langages grâce a deux concepts : les fonctions pures qui ont des entrées et des sorties, mais ne changent aucune valeur, elles sont donc indépendantes de l’environnement ou de l’ordre d’exécution du thread. Le deuxième concept est celui de l’état immutable dont l’exemple OCaml suivant illustre le principe :

Code : Sélectionner tout
1
2
3
4
let x = 5;;
x = 6;;
 
print_int x;;  (* prints 5 *)
La programmation fonctionnelle pourra « nous sauver de la complexité de la synchronisation des threads », affirme l’auteur. « Elle peut nous aider à écrire de meilleurs programmes et réfléchir sur les problèmes que nous avons à résoudre […] Je peux dire que tous les langages modernes vont bientôt se baser sur ses principes » ceci parce que « le Java et le C++11 intègrent déjà les expressions lambda ».

Source : Medium, Wikipédia

Et vous ?

Êtes-vous d’accord avec l’avis de l’auteur cité ?

Pensez-vous que la programmation fonctionnelle est le futur avec le Cloud ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 07/01/2015 à 16:35
Citation Envoyé par imperio Voir le message
@tomlev: Il est vrai que beaucoup de langages récents implémentent des choses que l'on attribuerait plutôt à des langages fonctionnels. Du coup, à quel moment cesse-t-on de dire que ce sont des langages impératifs et les mettre dans la catégorie des langages fonctionnels ? Ça pourrait être un débat intéressant, non ?
Bah en fait, il me semble que les classifications habituelles des langages (impératif, fonctionnel, procédural, objet, etc) ne sont pas mutuellement exclusives, vu que la plupart des langages utilisent plusieurs paradigmes. Bien sûr il y a généralement un paradigme dominant, mais qui n'exclut pas forcément les autres. En fait, les langages modernes sont presque tous hybrides... D'ailleurs, voilà, d'après Wikipedia, les paradigmes utilisés par différents langages :

  • C# : multi-paradigm: structured, imperative, object-oriented, event-driven, task-driven, functional, generic, reflective, concurrent
  • Java : multi-paradigm: object-oriented, structured, imperative, functional, generic, reflective, concurrent
  • C++ : Multi-paradigm: procedural, functional, object-oriented, generic
  • Javascript : Multi-paradigm: scripting, object-oriented (prototype-based), imperative, functional
  • Swift : multi-paradigm (object-oriented, functional, imperative, block structured)
  • Perl : multi-paradigm: functional, imperative, object-oriented (class-based), reflective, procedural, Event-driven, generic
  • Ruby : multi-paradigm: object-oriented, imperative, functional, reflective
  • Python : Multi-paradigm: object-oriented, imperative, functional, procedural, reflective


Bref, y en a pas un qui soit pas multi-paradigme
5  0 
Avatar de kolodz
Modérateur https://www.developpez.com
Le 06/01/2015 à 18:06
J'ai beau avoir lu l'article et la source.... (Pas lu les 3 tutoriels à la fin de la source) Je ne vois toujours pas comment la programmation fonctionnelle et ou les lambdas vont m'aider à faire du merge de set de donnée ou de la synchronisation. Ce qui se trouve être les deux plus gros problème que je rencontre quand je fait du parallélisme...

Si vous savez, éclairez moi !

PS : (Java) Les lambda sont très pratique quand à leur utilisation, mais c'est du sucre syntaxique. Il n'y a rien que tu ne pouvais pas faire avant que tu peux faire maintenant. C'est juste beaucoup plus propre et simple à écrire avec l'option des lambdas.

Cordialement,
Patrick Kolodziejczyk.
4  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 06/01/2015 à 18:31
Bah c'est le principe. Tout comme on peut faire de l'objet en C, on peut faire depuis toujours de la programmation fonctionnelle en C ou Java.
C'est quand même mieux quand le langage fournit les bon outils.
4  0 
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 07/01/2015 à 9:54
At least for concurrency and parallelism, OOP cannot save you anymore. It's just because OOP relies directly on mutable state (in Imperative Languages, which are the most common OOP implementation)
Cette phrase résume bien l'ambiguité de l'article. On titre sur des phrases choc "l'OO ne peut plus nous sauver" et on met plein de bémols dans les paragraphes.

Comme l'a dit quelqu'un, on peut faire du fonctionnel et de l'immuable dans des langages orientés objet (certes au prix de quelques contorsions) et ce n'est pas le style OO qui est synonyme de mutabilité à l'origine. D'ailleurs, l'article ne parle pas d'un modèle de concurrence très intéressant et qui se rapproche beaucoup de ce qu'Alan Kay avait imaginé être l'orienté objet à ses débuts : Actor Model. Chaque acteur/objet communique avec les autres en leur passant des messages et tourne dans son process dédié. Les mutations n'ont lieu qu'à l'intérieur de cette bulle protégée et seul l'acteur peut décider de se modifier lui-même. Il n'y a aucune ressource partagée, ce qui facilite la programmation parallèle. Ce modèle est à la base de langages comme Erlang ou Elixir, mais il existe aussi des librairies pour Java (Akka), C# (Orleans).

Comme souvent, le dev qui ne va lire que les gros titres ressortira avec l'impression qu'il doit jeter son langage orienté objet à la poubelle et se jeter sur le premier langage fonctionnel qui vient pour suivre la tendance, au lieu d'examiner la question en profondeur.
4  1 
Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 06/01/2015 à 21:25
Citation Envoyé par kolodz Voir le message
J'ai beau avoir lu l'article et la source.... (Pas lu les 3 tutoriels à la fin de la source) Je ne vois toujours pas comment la programmation fonctionnelle et ou les lambdas vont m'aider à faire du merge de set de donnée ou de la synchronisation. Ce qui se trouve être les deux plus gros problème que je rencontre quand je fait du parallélisme...

Si vous savez, éclairez moi !

PS : (Java) Les lambda sont très pratique quand à leur utilisation, mais c'est du sucre syntaxique. Il n'y a rien que tu ne pouvais pas faire avant que tu peux faire maintenant. C'est juste beaucoup plus propre et simple à écrire avec l'option des lambdas.

Cordialement,
Patrick Kolodziejczyk.
Je pense que qu'avec un langage pure (comme Haskell) la programmation parallèle est plus facile car les fonctions n'ayant pas d'effet de bord (ou presque) peu importe comment sont parallélisés les traitements le résultat sera toujours exacte (du moins le même). Ceci dit, un langage fonctionnel n'est pas nécessairement pure. D'ailleurs la majorité des langages fonctionnels sont impure. Haskell peut aussi être impure mais il impose des restrictions qui vont délimités le code pure du code-impure et donc limité l'écriture de code impure. Finalement, ça revient à dire que si on n'a pas de données partagées entre plusieurs threads alors on n'a pas de problème d'accès concurrent.

Ensuite concernant le passage
Toutefois, ceci ne veut pas dire qu’il faut arrêter d’utiliser les états mutables. Au contraire, l’auteur assure que « l’idée principale de la programmation fonctionnelle est qu’il faut utiliser les états immutables seulement lorsqu’il est nécessaire ».

Je ne sais pas si c'est une erreur de traduction mais cela me parait complètement aberrant. Programmation fonctionnelle ou pas, C'est toujours mieux d'avoir le moins possible de changement d'états. Ça facilite énormément le raisonnement à propos du programme.
2  0 
Avatar de behel
Membre du Club https://www.developpez.com
Le 08/01/2015 à 10:12
Ça fait 20 ans que je connais les langages fonctionnels, ça fait donc 20 ans qu'ils ont une syntaxe "déplorable".
J'entends pas là qu'ils ne sont pas beaux à voir et pas facilement lisibles. Ce qui explique la prédominance des autres langages (C/C++, Java, Python ....).
Le jour ou un langage fonctionnel aura une meilleure "syntaxe" et ergonomie, alors il aura des chances de convaincre.
Ne jamais oublier que si l’équation qui résout un problème est belle, elle a de grandes chances d’être juste (dixit mon prof de math d'il y a 20 ans ;-).
2  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 06/01/2015 à 22:33
C'est sûr que les concepts de la programmation fonctionnelle prennent de plus en plus d'importance, y compris dans dans langages OO (de plus en plus supportent les expressions lambda et les closures, C# a Linq et les delegates, Java 8 a les streams et les interfaces fonctionnelles...). Et dans l'ensemble, je trouve que ça a tendance à beaucoup améliorer la qualité du code.

Citation Envoyé par Amine Horseman Voir le message
L’auteur de cet article affirme que « les langages orientés objet ne peuvent pas nous sauver du monstre qu’est le Cloud », ceci parce que ces « langages sont basés sur des états mutables »
Pas vraiment d'accord... Certes, la plupart des programmes OO utilisent des états mutables, mais ce n'est pas une caractéristique intrinsèque des langages OO. On pourrait tout à fait écrire du code dans un style fonctionnel en C#, en Java, en C++ (du moins les versions récentes) ou en Javascript. D'ailleurs, toutes les features des langages fonctionnels qui sont mentionnées dans l'article sont supportées (sous une forme ou une autre) dans des langages OO :

  1. First-Class Functions
  2. High-Order Functions
  3. Pure Functions
  4. Closures
  5. Immutable State
La deuxième ("higher-order functions", et non high-order) découlent directement de la première : du moment qu'une variable peut contenir une fonction, rien n'empêche de la passer en entrée ou en sortie d'une autre fonction.

Concernant les fonctions pures et l'état immuable, ce ne sont pas vraiment des features, mais plutôt des caractéristiques des programmes. Dans les langages OO, ce n'est pas vraiment géré par le langage proprement dit, mais rien n'empêche d'implémenter une fonction de façon à ce qu'elle soit pure, ou de créer des objets immuables (les types String ou DateTime en C# en sont des exemples).

La principale caractéristique des langages fonctionnels est qu'ils imposent (de façon plus ou moins stricte) ces caractéristiques. Par exemple, si je ne dis pas de bêtise, la seule façon en Haskell de faire des mutations d'état passe par l'utilisation de monades, un concept loin d'être facile à comprendre... D'autres langages fonctionnels comme F# permettent de le faire plus facilement, mais c'est toujours suffisamment explicite pour qu'on ne risque pas de le faire accidentellement.

Citation Envoyé par Amine Horseman Voir le message
Au contraire, l’auteur assure que « l’idée principale de la programmation fonctionnelle est qu’il faut utiliser les états immutables seulement lorsqu’il est nécessaire ».
Il dit le contraire : il ne faut utiliser des états mutables que lorsque c'est nécessaire
1  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 06/01/2015 à 22:39
Citation Envoyé par codec_abc Voir le message
Je ne sais pas si c'est une erreur de traduction mais cela me parait complètement aberrant. Programmation fonctionnelle ou pas, C'est toujours mieux d'avoir le moins possible de changement d'états. Ça facilite énormément le raisonnement à propos du programme.
C'est une erreur de traduction. La phrase d'origine est "The main idea FP provides is: use mutable state only when it's necessary."
1  0 
Avatar de imperio
Membre émérite https://www.developpez.com
Le 07/01/2015 à 12:24
Bah c'est le principe. Tout comme on peut faire de l'objet en C, on peut faire depuis toujours de la programmation fonctionnent en C ou Java. Le tout est d'avoir les outils qui facilitent cela.
Je ne suis pas d'accord. Rien que les expressions dans les langages fonctionnels permettent de beaucoup faciliter la vie, choses que ne permettent pas d'autres langages comme le C. Je ne parle pas non plus du pattern matching ni des closures qui sont justes géniales à mon humble avis.

Pour en revenir au sujet principal, je pense que le choix entre langage impératif et langage fonctionnel se doit d'être fait en fonction du besoin avant tout. Les langages fonctionnels sont très pratiques dans certains (parallélisation par-exemple) mais sont assez lourd à mettre en place dans d'autres cas où des langages impératifs se révèlent alors plus adaptés.
1  0 
Avatar de kolodz
Modérateur https://www.developpez.com
Le 07/01/2015 à 16:44
@tomlev : Merci !

Je reviens donc sur ce que j'ai dis :
Je ne vois toujours pas comment la programmation fonctionnelle et ou les lambdas vont m'aider à faire du merge de set de donnée ou de la synchronisation. Ce qui se trouve être les deux plus gros problème que je rencontre quand je fait du parallélisme...
Ce n'est pas magiquo-magique !

Cordialement,
Patrick Kolodziejczyk.
1  0