<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Le 21 mars 2014 13:15, Stéphane Payrard <span dir="ltr"><<a href="mailto:cognominal@gmail.com" target="_blank">cognominal@gmail.com</a>></span> a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Etant autodidacte, je n'ai pas d'autorité particulière pour parler<br>
d'un sujet d'origine académique. :)<br>
De plus ma réponse est biaisée par mon intérêt pour les langages elm et idris .<br>
<br>
La programmation fonctionnelle moderne tourne autour de deux thèmes, celui de la<br>
référence transparentielle et celui de type.<br>
<br>
Le premier est déjà mentionné implicitement sans indiquer le bénéfice<br>
espéré : l'absence d'états permettrait aux compilateur de paralléliser<br>
et d'utiliser au mieux les architectures multiprocesseurs.<br>
En pratique, sauf dans des cas spécialisés (grosses matrices, rendu<br>
graphique), ce bénéfice ne s'est guère matérialisé.<br>
Pourtant, c'est cette perspective qui a motivé le développement des<br>
langages fonctionnels pour résoudre le goulot d'étranglement de<br>
l'architecture de Von Neumann. Voir le papier de Backus en 1977 :<br>
<a href="https://www.cs.ucf.edu/~dcm/Teaching/COT4810-Fall%202012/Literature/Backus.pdf" target="_blank">https://www.cs.ucf.edu/~dcm/Teaching/COT4810-Fall%202012/Literature/Backus.pdf</a><br>
<br>
<br>
La notion de type permet pour les langages les moins "riches"<br>
(polymorphiques de niveau<br>
1) d'offrir l'inférence de type. Tandis des langages langages comme<br>
idris proposent des types paramétrés par des valeurs ce qui permet un<br>
système plus riche mais oblige à beaucoup d'annotations de type. C'est<br>
pourquoi ces langages étaient jusqu'à maintenant spécialisés dans des<br>
domaines comme la création de prevues formels.<br>
Le domaine est encore revitalisé par la découverte des similarités<br>
entre un champ de la topologie et la théorie des types. Mais je ne<br>
sais pas si (ou quand) cela aura un impact en dehors des milieux<br>
académiques. Voir <a href="http://homotopytypetheory.org/" target="_blank">http://homotopytypetheory.org/</a><br>
<br>
Il est intéressant de noter que la syntaxe de beaucoup de langages<br>
fonctionnels est héritée d'ISWIM, un langage hypothétique présenté par<br>
Landin dans un papier de 1966.<br>
<a href="http://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf" target="_blank">http://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf</a><br>
<br>
Finalement, un sujet connexe est la programmation réactive<br>
fonctionnelle. Un des intérêts est de permettre<br>
le type de programmation interactive prônée par Bret Victor mais<br>
probablement impossible dans tout autre contexte. Bret Victor semble<br>
délibérément ignorer cette contrainte en proposant des démos qui la<br>
cachent.<br>
Dans ce domaine un langage est particulièrement prometteur :  elm.<br>
La société Prezi entend utiliser elm pour les prochaines versions de<br>
son produit et a embauché le créateur<br>
du langage, ce qui pourrait garantir sa pérennité. Même si la<br>
programmation réactive fonctionnelle est un sous champ de la<br>
programmation fonctionnelle, un programme généré par elm a le mérite<br>
de tourner dans un browser et de permettre des démos interactives ce<br>
qui rend le sujet moins aride.<br>
<br>
<a href="http://elm-lang.org/blog/Interactive-Programming.elm" target="_blank">http://elm-lang.org/blog/Interactive-Programming.elm</a><br>
<a href="http://worrydream.com/LearnableProgramming/" target="_blank">http://worrydream.com/LearnableProgramming/</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
On 3/21/14, Laurent Pierron <<a href="mailto:Laurent.Pierron@inria.fr">Laurent.Pierron@inria.fr</a>> wrote:<br>
> Bonjour,<br>
><br>
> Récemment je me suis posé la question avec un collègue pour introduire un<br>
> séminaire interne sur les langages fonctionnels, et on n'a pas réussi à<br>
> trouver une réponse satisfaisante, on s'est heurté aux différents types de<br>
> langage fonctionnel (Lisp, ML famille, Haskell, etc.), qui peuvent inclure<br>
> des éléments de langages impératifs, des objets, des types algébriques ou<br>
> uniquement des types simples et qui ont des stratégies d'évaluation<br>
> différentes.<br>
><br>
> Personnellement, je dirais que dans un langage de fonctionnel l'exécution<br>
> d'un programme se fait uniquement par substitution d'expression sans<br>
> modification de l'état d'une machine alors que dans un langage impératif<br>
> l'exécution se fait par évaluation d'expression et modification de l'état de<br>
> la machine.<br>
><br>
> On peut aussi dire que les langages fonctionnels sont basés sur le<br>
> lambda-calcul de Church, alors que les langages impératifs sont basés sur la<br>
> machine de Turing, mais il faut expliquer ce qu'est le lambda-calcul.<br>
><br>
><br>
> Laurent Pierron<br>
><br>
> Le 20 mars 2014 à 11:26, Gautier DI FOLCO <<a href="mailto:gautier.difolco@gmail.com">gautier.difolco@gmail.com</a>> a<br>
> écrit :<br>
><br>
> Bonjour,<br>
><br>
> Je vais peut-être poser une question très générale, mais qu'est-ce qui<br>
> caractérise un langage de programmation fonctionnel ?<br>
> Je m'explique :<br>
>  - je sais qu'un LPF se base sur des expressions<br>
>  - je sais en reconnaître un quand j'en vois un<br>
><br>
> mais chaque fois qu'on me pose la question, je ne suis pas foutu de donner<br>
> des éléments caractéristiques clairs.<br>
><br>
> Est-ce que vous auriez une "phrase toute faite" ou quelque chose qui me<br>
> permette de l'expliquer simplement/clairement de manière juste ?<br>
><br>
> Merci par avance.<br>
> _______________________________________________<br>
> Haskell-fr mailing list<br>
> <a href="mailto:Haskell-fr@haskell.org">Haskell-fr@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-fr" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-fr</a><br>
><br>
> _______________________________________________<br>
> Haskell-fr mailing list<br>
> <a href="mailto:Haskell-fr@haskell.org">Haskell-fr@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-fr" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-fr</a><br>
><br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
cognominal stef<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Haskell-fr mailing list<br>
<a href="mailto:Haskell-fr@haskell.org">Haskell-fr@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-fr" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-fr</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">Je suis un peu dans le même cas, mais comme dans mes cercles je suis "le plus calé en FP" et qu'en plus je tente "d’évangéliser", j'ai de gros efforts pédagogiques à fournir (ce qui n'est pas mon point fort).<br>
</div><div class="gmail_extra">Le soucis avec ces critères, transparence référentielle et typage fort/statique, c'est que du coup tu sors Scala et Clojure par exemple.<br><br></div><div class="gmail_extra">PS : je suis sur du Data-flow en ce moment du coup je connais un peu le FRP, mais j'avoue ne pas avoir fait le lien avec Bret Victor.<br>
</div></div>