Discussion :

[Chatbour]

Bonjour à tous et à toutes

je viens de m'informer un peu sur le paradigme fonctionnel et je voudrais vous poser ces questions :

les langages fonctionnels sont-ils utilisés hors cadre universitaire et académique ?
quels sont les "situations" où on doit opter pour un langage fonctionnel ?

Merci d'avance..

[Garulfo]

les langages fonctionnels sont-ils utilisés hors cadre universitaire et académique ?

Oui. Emacs, Autocad, les premières version de Maple, Coq, etc. Si les langages ne le sont pas forcément les techniques peuvent l'être : ainsi Google a été célèbre pour ses algorithmes de recherches de nature fonctionnelle (mais implémenté en C si je me rappelle bien). Ce n'est pas les langages qui sont important, mais les notions sous-jacentes (les paradigmes). Le langage est secondaire ; mais pas inutile ni négligeable cependant.

De toute façon dis toi que tous les langages ont maintenant des saveurs fonctionnelles (sauf éventuellement les plus vieux).

quels sont les "situations" où on doit opter pour un langage fonctionnel ?

C'est difficile de donner une réponse générale. Il faudrait que j'y réfléchisse plus. Tous ce qui fait appel à du traitement symbolique est bien sûr bénéficiaire directement du paradigme fonctionnel (ce qui inclus la compilation). C'est d'ailleurs pourquoi les langages comme Scheme ou Ocaml on des faits d'armes dans de tels actes. Les situations d'autoréécriture (voire autopoétique), de réflexivité, de traitements du signal (plus généralement de flot), sont aussi des situations où les algorithmes fonctionnels apparaissent aisément. Et de plus en plus, les besoins d'efficacités. Car contrairement à la légende, les langages fonctionnelles sont de plus en plus efficace une fois compilé (raison pour laquelle on voit des saveurs fonctionnelles dans tous les langages modernes). Ainsi les compilateurs ocaml, Haskell et Scheme se classe toujours très bien dans les performances, certes derrière C, C++, D, Fortran et Pascal; mais devant Java, Ruby, Python, Perl et autre langage « classique ».

Je suppose que Gorgonite va faire une entrée FAQ avec cette question. On aura le temps de mieux y réfléchir.

[kevinDotNet]

bonjour,

J'aurai voulu savoir concrètement , à quoi servent les langages fonctionnels ? Je pense pas qu'on puisse développer des applications avec ça , sachant qu'on a de très bon langages tel que vb.net , c# ou java .

Pour quels types d'utilisations sont-ils utilisés ?

merci

[HanLee]

J'aurais bien envie de rajouter les problèmes ou les situations où on se retrouve à manipuler des structures de données arborescentes et des algorithmes complexes dessus...

Mais bon, je sais pas si c'est structurel (par la nature fonctionnelle des langages) ou bien de fait (la plupart des langages fonctionnels type ML/Haskell).

[GnuVince]

La programmation fonctionnelle est une façon différente d'aborder des problèmes. Si on prend un exemple simple, calculer la somme d'une liste, la plupart des gens habitués aux langages impératifs vont utiliser une boucle:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
def sum(numbers):
    result = 0
    for number in numbers:
        result += number
    return result

Dans le code ci-haut, on code explicitement notre boucle et result est constament changé. Dans le paradigme fonctionnel, les variables sont immutables (la plupart du temps), donc on ne pourrait pas résoudre ce problème de cette façon. Si j'utilise le langage Scheme comme exemple, voici comment écrire la fonction sum:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
(define (sum numbers)
  (reduce + 0 numbers))

C'est tout. reduce (appelé fold dans d'autres langages) est une abstraction de l'idiome d'accumulation avec la boucle for. Le premier paramètre, +, est la fonction à utiliser pour joindre un élément de la liste avec le total courant, 0 est la valeur de départ du total et numbers est la liste de nombres. Et reduce est écrit de telle sorte que le total n'est jamais modifié.

C'est particulièrement intéressant avec l'arrivée des processeurs multi-coeurs, car le paradigme fonctionnel est mieux adapté pour la programmation concurentielle que le paradigme impératif. Jedaï, l'expert résident va pouvoir te donner plus de détails.

[alex_pi]

Attention, je préviens de suite, je suis un théoricien, ce qui suit risque de faire mal à la tête :-)

Dans un premier temps, qu'appel-t-on langage fonctionnel ? Au sens strict, un langage est fonctionnel lorsque les fonctions y sont des "objets de premier type", ou, dit plus clairement, quand les fonctions sont des trucs comme les entiers ou les caractères. Dans un langage fonctionnel, on peut passer une fonction en argument d'une autre, on peut définir une fonction dans le corps d'une fonction, on peut créer des tableaux de fonction, mettre une fonction dans une variable, etc.

Il y a une autre approche qui consiste à parler du "paradigme fonctionnel". Tu as sans doute déjà entendu parler du paradigme impératif ou du paradigme objet. Pour la petite note historique, il y a bien longtemps de ça (dans les années 30), deux personnes, Alonso Church et Alan Turing ont étudié la notion de "calculabilité". Ils ont inventé deux modèles de "calculs". Turing a inventé la "machine de Turing", qui est grossièrement une bande sur laquelle sont inscrite des instructions et que parcours une tête de lecture/écriture, tout en modifiant la bande. Church, lui, a inventé le lambda calcul, où tout est fonction, et les seuls choses que l'on puisse faire sont de créer une fonction et d'appliquer une fonction. Et chose assez surprenante (si si...), il a été montré que les deux modèles, pourtant totalement différents, représentent exactement le même ensemble de ce qui est "calculable".
On peut alors dire que le paradigme impératif est une évolution de la machine de Turing. C'est à dire que pour programmer, on donne un ensemble d'instruction pour modifier directement la mémoire de la machine, et l'execution du programme dépend du contenu de cette mémoire.
D'un autre coté, le paradigme fonctionnel est une évolution du lambda calcul. On y décrit les caluls que l'on veut faire à l'aide de fonctions et d'application de fonctions, sans se préocuper de la mémoire.
Ces visions sont bien sûr caricaturales et la frontière n'est pas si nette, mais c'est pour expliquer :-)

Dans cette vision "lambda calculesque", un langage fonctionnel est alors aussi un langage qui ne modifie pas explicitement la mémoire. C'est à dire qu'une fois que l'on a mis une valeur dans une "variable" (nom assez mal choisi), cette variable n'est plus mutable. On ne peut plus modifier la valeur qu'elle contient. C'est ce que l'on appelle les langages fonctionnels "purs". Dans ces langages, (le plus connu étant Haskell), il n'y a pas de tableau par exemple. Quel intéret ? Comme le dit GnuVince, dans le cadre de la programmation multithread, sur plusieurs processeur, cette approche réduit considérablement tous les problèmes de synchronisation ! Plus de problème d'accès concurent à une variable puisque personne ne peut en changer la valeur. La programmation parallèle s'en trouve grandement simplifiée.

Pour répondre plus directement à ta question, théoriquement, les langages fonctionnels peuvent servir à tout faire. Dans la pratique, ils sont principalement utilisé dans les milieux académique, je pense principalement parce qu'avant F#, aucun langage fonctionnel "main stream" (bien supporté) n'existait. Les supporters de Lisp et Scheme vont me sauter à la gorge, mais ce sont deux langages interprétés et au typage purement dynamique, ce qui pose quand même certain problème sur des "gros" projets (attention, troll inside).

Maintenant, on peut tout de même citer mldonkey, client pair à pair écrit en Caml, ou encore un gestionnaire de fenetre écrit en Haskell, un vérificateur de code source, Astree, qui vérifie tout le code de l'A380, quasiment toute l'infrastructure logiciel de Jane St Capital, une boite de trading américaine est faite en OCaml (et ils brassent un paquet de pognon !), etc. Ca existe quand même !

Bref, je pense que l'absence d'un grand nombre d'application en langage fonctionnels est plus historique et politique que pragmatique. Dit autrement, il est parfaitement possible de faire des applis grand public dans des langages fonctionnels, mais il y a une certaine rupture entre les gens qui codent des applis grand public et ceux qui font les langages fonctionnels. Espérons que F# changera la donne !

Pour des exemples de code, je t'invite à jeter un oeil aux sous forum de Autre langages/langages fonctionnels.

[Garulfo]

J'aurais bien envie de rajouter les problèmes ou les situations où on se retrouve à manipuler des structures de données arborescentes et des algorithmes complexes dessus...

Mais bon, je sais pas si c'est structurel (par la nature fonctionnelle des langages) ou bien de fait (la plupart des langages fonctionnels type ML/Haskell).

Les structures de données arborescentes sont souvent les structures par excellence en fonctionnel. Mais même si elles sont employés dans des langages impératif les algorithmes (naïf) pour les explorer sont fonctionnels. C'est peut-être pour ça que tu fais cette association.

[Garulfo]

Attention, je préviens de suite, je suis un théoricien, ce qui suit risque de faire mal à la tête :-)
[...]

Alonso Church et Alan Turing ont étudié la notion de "calculabilité". Ils ont inventé deux modèles de "calculs". [...]

Les supporters de Lisp et Scheme vont me sauter à la gorge, mais ce sont deux langages interprétés et au typage purement dynamique, ce qui pose quand même certain problème sur des "gros" projets (attention, troll inside). [...]

Petite précision : l'objectif de Church et de Kleene (merci de ne pas l'oublier... les deux sont à associer à la naissance du λ-calcul ) était surtout de créer une autre base au fondement des mathématiques. Cet objectif a été un échec puisque le lambda-calcul pur s'est avéré être incohérent (paradoxe de Kleene-Rosser). Mais de cet échec est quand même sorti le modèle sur la calculabilité ^_^ Rien n'était faux dans ce que tu as dis... mais je préférais précisé.

Pour la troisième partie que j'ai cité par contre, heureusement que tu as dit être théoricien: ça te sauve Lisp et Scheme ont de nombreux compilateurs efficaces qui n'ont rien, a priori, à envier à ocamlopt ou à GHC. De fait donc, tu as effectivement trollé

Maintenant je suis aussi d'un certain côté, théoricien, si on entend par là que j'en ai étudié la théorie. Reste que je suis aussi praticien.

[Garulfo]

de très bon langages tel que vb.net , c# ou java .

Enfin... dire que Java et VB.NET sont très bons... ça me fait mal.
Ce sont des mauvais langages, mais portés par une excellente publicité, des conférences soutenues et une riche industrie. La popularité n'est pas la qualité. C'est aussi vrai en programmation.

C# je connais mal. Alors je ne me prononce pas.

---

Il y a ce sujet qui s'est ouvert :
Quand-est ce qu'on doit utiliser un langage fonctionnel ?
http://www.developpez.net/forums/sho...d.php?t=578347

Peut-être qu'un modérateur sympatique pourrait fusionner les deux pour en faire une question pour la FAQ ? N'est-il pas ?

[kevinDotNet]

OK , donc en faite , la programmation fonctionnelle est plutôt destinée à des logiciels de calcul pour avoir une meilleure complexité des algorithmes .

est-ce que au niveau entreprise , ce type de programmation est utilisé ? car je ne vois pas une entreprise réalisée un logiciel de gestion de stock en scheme .

[smatador]

OK , donc en faite , la programmation fonctionnelle est plutôt destinée à des logiciels de calcul pour avoir une meilleure complexité des algorithmes .

Ça veut dire quoi "une meilleure complexité des algorithmes" ?

est-ce que au niveau entreprise , ce type de programmation est utilisé ? car je ne vois pas une entreprise réalisée un logiciel de gestion de stock en scheme .

Et pourquoi pas ? Les langages fonctionnels me semblent tout à fait capable de réaliser de telles applications. Le problème serait plutôt un manque d'outils et de compétences de la part des développeurs.

[wiztricks]

Dans le milieu financier tu as pas mal d'algorithmes de calcul de risques sur des portefeuilles d'actions qui sont construits sur des langages fonctionnels.

Pour compléter ce a été déjà dit, les langages fonctionnels sont à la base de ce qui tourne autour de la calculabilité... Et ils sont très intéressants lorsqu'il s'agit de démontrer formellement que des algorithmes sont "justes".

Personnellement, j'ai débuté en informatique avec des langages tels que PROLOG ou LISP.
Lorsque je m'amuse à spécifier, je préfère utiliser le lamba-calcul car c'est quand même plus naturel.
Pour vérifier, on peut implanter rapidement un prototype.

Je recode le proto en langage C++ ou C si çà apporte quelque chose côté performances.
- W

[kevinDotNet]

Ça veut dire quoi "une meilleure complexité des algorithmes" ?

tiens voila une explication de la complexité.
http://fr.wikipedia.org/wiki/Complex..._algorithmique

Peut-etre qu'il en sont capable mais les entreprises qui font un logiciel de gestion de stock en scheme doivent être très minoritaire .

[kevinDotNet]

Dans le milieu financier tu as pas mal d'algorithmes de calcul de risques sur des portefeuilles d'actions qui sont construits sur des langages fonctionnels.

Pour compléter ce a été déjà dit, les langages fonctionnels sont à la base de ce qui tourne autour de la calculabilité... Et ils sont très intéressants lorsqu'il s'agit de démontrer formellement que des algorithmes sont "justes".

Personnellement, j'ai débuté en informatique avec des langages tels que PROLOG ou LISP.
Lorsque je m'amuse à spécifier, je préfère utiliser le lamba-calcul car c'est quand même plus naturel.
Pour vérifier, on peut implanter rapidement un prototype.

Je recode le proto en langage C++ ou C si çà apporte quelque chose côté performances.
- W

ok merci pour l'exemple

[kevinDotNet]

si vous avez d'autres exemples d'utilisations des langages fonctionnelles , donner-les. car c'est toujours intéressant de connaitre les possibilités d'un langage .

[smatador]

tiens voila une explication de la complexité.
http://fr.wikipedia.org/wiki/Complex..._algorithmique

Je te remercie mais je sais ce qu'est la complexité Ceci dit je ne vois toujours pas le rapport entre un paradigme de programmation et la complexité d'un algorithme.

Peut-etre qu'il en sont capable mais les entreprises qui font un logiciel de gestion de stock en scheme doivent être très minoritaire .

C'est vrai mais cette situation n'a rien à voir avec les capacités de ces langages comme tu l'as laissé entendre dans ton premier message.

[Jedai]

Peut-etre qu'il en sont capable mais les entreprises qui font un logiciel de gestion de stock en scheme doivent être très minoritaire .

Certes, mais comme on te l'a dit, ce n'est pas tant une question pratique qu'historique, les outils, les bibliothèques et les formations des programmeurs des PME concernés sont majoritairement impératives.

On peut trouver beaucoup de raisons à cela, entre autre un problème de performances dans le passé : le modèle de Turing (plus proche des langages impératifs) est beaucoup plus proche du matériel qu'on retrouve dans les ordinateurs réels et les jeux d'instructions du processeur sont plus adaptés aux langages impératifs (ce n'est pas une fatalité mais il est peu probable que ça change dans le futur proche). Les premiers langages fonctionnels étaient globalement bien plus lent et gourmand que les langages impératifs de la même époque (et vu la lenteur des ordinateurs de cette période, la vitesse d'exécution et la consommation de ressources étaient vitales).
Heureusement, aujourd'hui cette objection ne tient plus : les compilateurs pour langages fonctionnels ont fait des progrès gigantesques et sont maintenant excellent, à tel point que Haskell (GHC) ou OCaml (ocamlopt) peuvent avoir des performances très proches du C ou du C++ et bien meilleures que certains langages mainstream actuels.

Les langages fonctionnels présentent beaucoup d'avantages en retour, ils sont généralement plus expressifs que les langages mainstream (qui incorporent de plus en plus d'aspects fonctionnels pour rattraper leur retard ces derniers temps), ils sont généralement plus sûr et beaucoup plus facile à prouver correct. Pour ceux qui sont habitués des deux paradigmes, il est souvent plus facile de comprendre un programme fonctionnel localement (grâce à l'absence d'effets de bord globaux) qu'un programme impératif... Un autre aspect intéressant est que le paradigme fonctionnel tend à créer beaucoup plus de parallélisme potentiel que le paradigme impératif (autrement dit, il y a beaucoup plus de code qu'on pourrait exécuter en parallèle dans un programme fonctionnel que dans un programme impératif (écrit sans penser à la parallélisation)), ce qui dans un monde où la multiplication des cores a plus ou moins remplacé l'accélération de la fréquence des processeurs représente un sérieux avantage potentiel.

--
Jedaï

[Jedai]

Il faut dire que les structures de données arborescentes sont par nature récursives et que la récursion est beaucoup mieux supportée et encouragée dans les langages fonctionnels.


--
Jedaï

[HanLee]

Scoop : Dassault Systemes utilise aussi pour certaines parties OCaml !

Dans un code type compilation/interprétation de langage évidemment .

[Garulfo]

Scoop : Dassault Systemes utilise aussi pour certaines parties OCaml !

Dans un code type compilation/interprétation de langage évidemment .

C'est pas vraiment un scoop.
Les entreprises comme Dassault n'ont aucun préjugé en général : ils prennent ce qu'ils faut pour avoir de la qualité et de la rentabilité, même si cela nécessite un investissement pour commencer. Leurs clients ne leur pardonneront aucune erreur. Donc des langages comme Ada ou Ocaml, qui assurent une certaine fiabilité a priori, et l'utilisation de méthode formelle sont souvent utilisées sur toute partie sensible.