Langage fonctionnel

Bonjour,

Je vois souvent des personnes avec un bon niveau informatique utiliser des langages avec un paradigme fonctionnel pour implémenter leurs algorithmes. Je souhaiterais donc avoir le ressenti des personnes utilisant ces langages via les questions qui vont suivre.

1. Avez-vous commencé à utiliser les langages fonctionnels durant votre cursus scolaire ? (Si oui n’hésitez pas à préciser le nom et l’année de votre formation)
2. Quel langage fonctionnel utilisez-vous principalement (votre favori) ? Quels sont les autres langages fonctionnels que vous utilisez (mis à part le favori) ?
3. Utilisez-vous votre langage fonctionnel favori pour des projets professionnels, personnels ou les deux ?
4. Généralement, préférez-vous utiliser les langages avec un paradigme procédural ou fonctionnel ?
5. Quels sont les langages procéduraux utilisez principalement ? Si vous en utilisez, l’utilisez-vous parce que vous l’appréciez (n’hésitez pas à citer les qualités) ou bien est-ce plus par obligation (pour gagner sa vie) ?
6. Dans quel cas (type de projet) éviteriez-vous d'utiliser votre langage fonctionnel ?
7. Conseilleriez-vous aux gens qui ne connaissent que le paradigme procédural d’apprendre au moins un langage fonctionnel ? Si oui pourquoi et lequel ?

Cordialement,

EDIT : Résultat du sondage (20/09/2015)

Suite aux avis donnés (11 avis), je publie quelques stats :

PS: N'hésitez pas à répondre à donner vos avis, je prendrais en compte

Avis de : Ksass`Peuk, Dominus Carnufex, gbdivers, olzd, Dinosaure, Grimur, nohar, artragis, QuentinC, katana, lmghs

Lu'!

1. Depuis le début de mes travaux de thèse en 2013. Mais en fait le fonctionnel, tu fais déjà des choses qui s'en rapprochent sur certains points dans pas mal de langages multi-paradigmes. C'est juste que pour certains problèmes c'est la manière la plus simple de faire.

2. OCaml, Coq et Why3, mais c'est pas ce que j'appellerai des langages "favoris".

3. Pro et plus récemment pour deux trois trucs persos.

4. Généralement, j'aime bien avoir accès à un maximum de paradigmes différents pour choisir celui qui est adapté sur le moment.

5. C++. Parce que d'une part je commence à bien le connaître et que j'aime vraiment bien ce langage. Et d'autres part parce que ça m'amuse jouer avec le système de type pour générer des trucs improbables au compile-time. Je dirai qu'un des avantages de ce langage par rapport à OCaml par exemple, c'est l'existence de putain d'outils d'analyse de code et de programmes. Ne pas avoir un debugger bien foutu pour OCaml m'handicape pas mal au quotidien et c'est assez gavant de debugger à coups d'affichages et de logs. Les désavantages de C++ sont évidents : syntaxe lourde, compilation longue, etc.

6. Quand j'ai 50 000 libs qui font déjà le job demandé dans un autre langage. Déjà. Quand j'ai besoin d'avoir un vrai contrôle sur la gueule des données en mémoire et sur leur modification. Pour la réalisation d'interface graphique c'est globalement peu adapté mais bon les procéduraux ne le sont pas non plus directement.

7. Clairement. N'importe lequel je pense. Simplement parce la forme de programmation qui vient naturellement avec et l'usage massif de données non-mutables sont des notions qui sont aussi utiles dans les autres langages et qu'on en vient à améliorer la robustesse de ce qu'on réalise en apportant ces idées.

1. Ayant fait des études histoire, tu te doutes que ce n'est pas dans mes études que j'ai découvert la prog fonctionnelle.
2. Haskell, sans la moindre hésitation. J'ai une certaine tendresse intellectuelle pour des Lisp minimalistes, comme Scheme, et Erlang permet de faire des choses pas dégueu en programmation concurrente. Idris est très proche de Haskell, mais permet d'utiliser beaucoup plus facilement les types dépendants, ce qui peut s'avérer pratique dans certaines circonstances. En revanche, je n'aime pas OCaml, qui m'apparaît comme un Haskell du pauvre.
3. Personnels, je ne bosse pas dans l'informatique.
4. Fonctionnel. Depuis que j'ai découvert ce paradigme, je suis tombé amoureux, et je trouve le procédural et la POO lourds et inélégants.
5. Ça doit bien faire un an et demi que je n'ai pas touché à un langage procédural, à part un peu de JavaScript pour plier une page Web à ma volonté. Avant cela, j'avais essentiellement touché à PHP et JS, pour le dev Web, et au C pour le reste. J'ai testé d'autres langages, mais de manière plus anecdotique.
6. Dans un projet où les performances sont cruciales. Il est possible d'obtenir des performances excellentes avec Haskell, mais ça demande un niveau de maîtrise du langage que je n'ai pas, et au final, je pense qu'on perd dans la partie optimisation le temps qu'on avait gagné à coder grâce au paradigme fonctionnel.
7. Non. De ce que j'ai pu voir, une part non négligeable des gens qui sont familiers avec la programmation procédurale ont énormément de mal à se plier au fonctionnement du fonctionnel, et c'est toujours pour eux un mauvais moment à passer. Donc s'ils ont un réel besoin d'un langage fonctionnel, ou s'ils sont simplement curieux, OK, mais je ne pousserais pas quelqu'un qui n'en a ni le besoin ni particulièrement l'envie.

1. pas d’étude dinfo non plus, donc pas vu en cours
2. Haskell, sans hésiter non plus. Choisit a pile ou face… (ok, pas que, j'ai un peu regardé, mais globalement, je n'ai pas choisis avec d'autres argument plus solide que "pourquoi pas")
3. perso (je suis en phase d'apprentissage. Je n'ai pas encore assez de recul avec Haskell - et surtout le C++ - pour voir comment je peux utiliser Haskell en pro)
4. Multi-paradigme (avec une utilisation plus poussée de la POO)
5. C++. Parce que j'aime bien faire comme Ksass`Peuk
6. pas assez de recul
7. Oui. Même si je suis partisan de ne pas trop se disperser (je ne comprend pas très bien l’intérêt de survoler 20 langages pendant ses études, je trouve plus pertinent d'en apprendre 4-5 et de se spécialiser dans 1 ou 2), je pense qu'un étudiant doit voir des choses différentes : langages mainstream, langage web, prog systeme, reseau, POO…et fonctionnel. Tout simplement pour elargir sa vision des choses.

1. OCaml, en L2 info si je me souviens bien. J'avais déjà touché à Haskell par moi-même avant.
2. Pas vraiment de favori. Je trouve juste OCaml plus pratique que Haskell. Erlang est à part.
3. OCaml pour du pro et du perso.
4. Je préfère avoir le choix si possible donc multi-paradigme (j'aime bien Common Lisp). Si je devais en choisir un ce serais du fonctionnel.
5. Python parce qu'il y a une lib pour tout, surtout en machine learning. C'est aussi un langage assez simple à manipuler.
6. Ca dépend du projet et des libs disponibles qui répondent aux besoins.
7. Oui, question de culture. Au niveau du choix du langage, Haskell, OCaml ou même Scheme. J'ai pas vraiment d'avis tranché sur la question.

1. J'ai utilisé OCaml dès ma première année à EPITECH de manière personnel lorsque j'ai essayé de faire mon propre langage informatique. Ensuite, j'avais un module OCaml en deuxième année que j'ai supervisé auprès de mes élèves de ma promotion puisque j'avais un niveau suffisant pour faire les cours.

2. J'utilise exclusivement OCaml. Je n'ai soit pas assez d'expérience pour utiliser les autres langages (c'est le cas d'Erlang) ou l'intérêt me semble très/trop limité pour que je puisse m'y mettre à fond (c'est le cas d'Haskell).

3. J'utilise OCaml dans le milieu du travail (actuellement je suis à OCamlPro - un peu obligé de faire de l'OCaml dans ce contexte) sinon je fais des petits projets toujours en OCaml pour aider la communauté.

4. Tout dépends du contexte. En général, dès que j'ai besoin d'un haut niveau d'abstraction, j'utilise OCaml. Il m'arrive de coder en C dès que je veux gérer plus finement les performances et la mémoire. Il m'arrive d'utiliser OCaml pour une programmation bas niveau ou même de mixer OCaml et C quand il le faut. Mais en général, je suis plus enclin à OCaml qui m'assure pas mal d'axiomes contrairement à C.

Sur la programmation objet en OCaml, je l'ai utilisé mais ça reste hyper spécifique. Je préfère m'amuser avec la programmation fonctionnel et les foncteurs d'OCaml que de me casser les dents avec le compilateur et les objets.

1. Je n'utilise que le C en dehors d'OCaml. C'est surtout, comme dit plus haut, pour mieux maîtriser les performances et la mémoire. Cela reste donc très spécifique.

2. La question peut être assez difficile. De mon expérience, la programmation de jeux reste pour pas mal incompatible avec la programmation fonctionnel pour des raisons techniques de l'ordre de la latence à cause du garbage collector. Après, j'ai toujours pas vu de domaine d'application là dedans donc ça se trouve, les gens se trompe - John Carmack, une icône de ce monde là pense plutôt que la P.F. est exactement fait pour les jeux (c'est pour ça que je parlais plus d'un point de vue technique) et c'est vrai que les concepts tel que la programmation par continuation, la F.R.P. ou encore les effets algébriques vont dans la facilitation de la gestion des interactions (qui reste le centre d'un jeu). Maintenant, on en est encore loin donc bon, je déconseille tout de même pour éviter des faux espoirs.

3. Il faut apprendre un langage fonctionnel et de préférence OCaml, pour moi c'est un prédicat pour être un bon programmeur (cela ne veut pas dire qu'il faut faire de la programmation fonctionnel). Je dis spécifiquement OCaml puisque les ressources sont vraiment bien pour commencer et ils sont assez exhaustifs sur ce qu'est réellement la programmation fonctionnel (ce qui n'est pas le cas de JavaScript par exemple, longtemps les gens ne savaient pas que c'était un langage fonctionnel …). Ce genre de ressource se retrouve aussi avec Haskell mais j'aime pas Haskell pour plusieurs raisons (dont la lazy-evaluation qui est difficile à cerner même pour des experts).

1. J'ai commencé avant de rentrer en première pour le fun, mais je fais du Caml Light depuis l'année dernière (prépa MPSI puis MP toussa), ce magnifique langage pas maintenu depuis un bout de temps avec l'IDE windows qui pue bien violemment.

2. Pour moi c'est OCaml, mais j'aime bien Haskell aussi. OCaml a ces derniers temps tendance à me soûler avec les +. bien moches quand on fait de l'arithmétique de flottants, et avec sa lib' standard pas terrible (je sais, y'a Batteries pour quand j'en ai besoin). Malgré ce coup de gueule, j'aime bien ce langage quand même. Je vais probablement tenter de faire du Haskell pour mes prochains projets

3. Projets personnels, et pour la prépa

4. Ca dépend de ce que je fais en fait. Si je dois bosser sur des arbres, des listes ou que ça sent bon la récursivité, je sors OCaml de son holster. Sinon ça sera pour Python ou C

5. Je fais du C et du Python aussi. J'apprécie beaucoup le côté minimaliste du C, et pour Python, c'est parce que je peux coder très vite avec, que dans une certaine mesure on retrouve des outils fonctionnels (salut map et les compréhensions de listes). L'OO de Python me rebute un peu par contre, je trouve Ruby plus propre de ce point de vue, même si je dois manquer de recul.

6. Quand j'ai besoin de coder en impératif j'évite OCaml, je n'aime pas coder en impératif avec. De même, quand j'ai besoin d'éviter de réinventer la roue je l'évite aussi. Exemple: mon TIPE. J'ai utilisé Python parce que les algorithmes que j'utilise sont assez orientés impératif et que la lib' standard est bien fournie.

7. Le fonctionnel apporte une nouvelle vision des choses, qui peut être très bénéfique. Par exemple, j'ai l'impression que les gens qui codent en fonctionnel sont très à l'aise avec la récursivité et les structures de données récursives de style arbre. Donc oui, je suis d'accord avec Dinosaure, c'est un atout pour être un bon programmeur. Je ne sais pas trop quoi conseiller entre Haskell et OCaml, mais il y a de très bonnes documentations pour Haskell. Pour quelqu'un qui s'intéresse aux maths, ça peut être sympa. Les articles de Bartosz Milewski sont très bons pour illustrer le côté maths d'Haskell.

1. J'ai appris Caml en prépa MPSI/MP (2002 à Orléans), c'était mon premier vrai langage de programmation (j'avais fait des merdouilles en recopiant des tutos PHP avant, comme tout le monde, mais j'avais jamais vraiment appris à programmer).

2. Alors aujourd'hui c'est quand même rare que je code avec un langage fonctionnel, mais de temps en temps, j'aime bien faire un peu de Haskell.

3. Uniquement pour des projets persos.

4. J'utilise les deux, ça dépend vraiment du type de code. J'essaye de reproduire des patterns un peu sympa du fonctionnel en Python, donc je suppose que j'aime bien mélanger les deux selon le problème à résoudre.

5. Python, c'est parce que je l'apprécie vraiment que je le pratique au boulot, pas l'inverse.

6. Dans tous mes projets pros, parce que personne ne connait Haskell.

7. Oui, Haskell. C'est le langage qui m'a fait reprendre goût au fonctionnel après le traumatisme du Caml en prépa. Après, sincèrement, même si ce n'est pas pour en faire ton langage principal, je trouve qu'il fait comprendre la programmation d'une façon complètement différente, complémentaire avec le paradigme impératif, et (mais c'est vraiment purement subjectif) je trouve que ça t'aide à penser un peu outside of the box, surtout quand tu pratiques un langage impératif mais souple comme Python.

Pour répondre à 7 plus ou moins.

Je crois que tu connais bien Java si je me souviens bien. Du coup, une piste de transition "souple" vers le fonctionnel pourrait être Scala.

J'ai toujours eu du mal à m'y mettre (au fonctionnel), et la lecture d'un livre sur Scala m'a bien aidé à mieux appréhender les concepts. Essentiellement parce que tout bon bouquin/cours sur Scala va présenter les avantages du multi-paradigme, et donc bien t'aider à te représenter, sur un exemple concret, ce que le paradigme fonctionnel va apporter comme solution.

hth comme disent les anglo-saxons.

Puis-je te demander quel livre tu as lu ?

1. C'est un peu compliqué. J'ai casi fait que du impératif OO mais mon projet de fin d'année était si merdique que pour lui donner une vraie valeur, j'ai codé la partie la plus complexe de la lib de base du projet en F#. Soyons clair c'était moche. Mais au moins j'ai pris contact avec ce type de langage
2. J'ai utilisé F# sporadiquement, je pense que je vais activement m'y remettre pour mes projets .NET mais a priori je n'en ai pas d'autres et j'ai pas forcément envie de passer ce paradigme en paradigme principal, peut-être suis-je trop pollué pour cela.
3. Si je le réutilise d'ici peu, ça sera pour des projets perso et uniquement pour faire les coeurs de lib. Pour tout ce qui concerne l'événementiel et la séparation en couches de données, la POO est largement plus facile à mettre en place.
4. Procédural par habitude
5. Au début, PHP, maintenant j'utilise principalement python et C#, par extension je sais coder en java et en C with classes (j'attends avec impatience le tuto C++ de zds pour me reformer à ce langage dont je risque d'avoir besoin professionnellement). Globalement le python c'set super pour prototyper et C# pour faire un truc qui a une GUI sympa portative.
6. Un projet web, un projet où la valeur ajoutée est dans la GUI (un client léger qui utilise principalement des API pour communiquer avec les serveurs). Après c'est surtout parce que je n'ai aps une expérience des programmes complets en fonctionnels. A part pandoc, je sais pas s'il en existe énormément.
7. Oui, clairement! Je suis dans ce cas et je sais que ça apporte une ouverture d'esprit non négligeable et quand on sait combien le développement est une activité créative, c'est une nécessité. Etant plutôt fan du framework .NET, je vous conseille le F# qui vous permettra de profiter de ce framework/lib ultra fourni avec moins de douleur.

Je t'invite à te renseigner sur Haste, un petit bijou de programmation fonctionnelle qui compile du Haskell vers du Javascript pour faire précisément ce type d'applis.

donc en gros il prend un langage utilisé par personne pour générer un langage de merde.

blague à part, je met ça dans ma todolist.

Puis-je te demander quel livre tu as lu ?

Scala In Action. Très bon livre.

Je t'invite à te renseigner sur Haste, un petit bijou de programmation fonctionnelle qui compile du Haskell vers du Javascript pour faire précisément ce type d'applis.

Ca pourrait m'intéresser.

Comment ça fonctionne pour manipuler des API tierces (Angular, React, JQuery, Backbone, ou peu importe) qui elles, sont écrites en Javascript ?

Je n'ai pas les détails (je maîtrise pas vraiment la technologie, je sais juste qu'elle est mieux foutue et plus complète que Elm, un autre dérivé du Haskell qui fait du JavaScript), mais il y a un système assez transparent de FFI.

Il y en a peu de vraiment populaires dans la réalité (on pourrait citer Xmonad, qui est un gestionnaire de fenêtres dans la même veine que AwesomeWM mais en Haskell, ou encore darcs, qui est un gestionnaire de versions à-la-git, toujours en Haskell…).

Par contre dès que tu vas vouloir faire un parseur ou un compilateur, les langages fonctionnels deviennent franchement brillants. Le simple fait de pouvoir définir des types algébriques complets et touffus en quelques lignes, et de pouvoir filtrer les entrées par motif permet d'exprimer des opérations complexes sur un arbre syntaxique de façon hyper-élégante, là où il faut ruser dans un langage impératif et/ou OO pour définir un pattern visitor.

Le contre-balancement de ça, c'est que l'extension de ce genre de types entraîne souvent la modification de code existant (les matching des fonctions qui traitent ce type), qui peuvent progressivement donner un nombre excessif de chemin d'exécution au sein de ces fonctions (augmentation des risques d'erreurs, difficulté de lecture, etc), et un grossissement assez méchant des fichiers qui contiennent ces fonctions du coup. Là où en objet, l'extension de type sera un nouveau comportement créé par héritage et isolé des comportements déjà présents (Open-Closed Principle).

Je dirai du coup que c'est hyper utile pour le multiple-dispatch (donc excellent quand on a besoin d'un visiteur puissant, typiquement le cas d'un AST), mais que pour le simple-dispatch, ça aura plutôt tendance à nuire à l'évolutivité, la modularité et la maintenance.

A ce propos, j'avais bien aimé la présentation de Yuriy Solodkyy à la CppCon 2014 qui montrait des expérimentation pour une implémentation de multiple dispatch en C++. Dans les propositions, il y avait une forme de pattern-matching (avec un syntaxe lourdingue, on est en C++ quand même, non mais). La présentation s'appelle "Accept no visitors" et est disponible sur YT. Elle résume bien les avantages et inconvénients de chacun des techniques de dispatch.

Je dirai du coup que c'est hyper utile pour le multiple-dispatch (donc excellent quand on a besoin d'un visiteur puissant

artragis parlait du web un peu plus haut. Dans les "single page webapp" d'aujourd'hui j'ai l'impression que ce "multi-dispatch" ou "visiteur puissant" ça me parle beaucoup.

Aujourd'hui certaines de ces applications sont construites sur le modèle "flux". En gros on a une approche plutôt descriptive pour décrire le layout de la page en fonction de l'état des données. (tel bouton sera là si telle propriété existe, bon c'est pas une révolution), une approche objet, voire presque "dictionnaire" pour l'état de l'application (ce qu'ils appellent un "store" : y'a 4 commandes dans le panier, …) et pour orchestrer tout ça, j'ai l'impression que c'est là qu'on aurait besoin d'un langage fonctionnel. Il s'agit d'agréger des événements provenant de différents flux (résultat d'une requête API, événement provenant du serveur type "push", SSE ou websocket, action utilisateur, …).

Autant de trucs pour lesquels une approche fonctionnelle (au sens fonction mathématique presque) me paraît adaptée. Y'a des ensembles de départ (l'ensemble des actions utilisateurs, des messages reçus, des requêtes HTTP, …) des ensembles d'arrivée (les fameux "store"). Et on a simplement envie d'écrire les transformations qui permettent de passer de l'un à l'autre, et potentiellement en cascade.

Bonjour,

Q1: Oui. J'ai eu une petite intro à Haskell, et très très vaguement touché à Scala pendant les études (Scala c'était à l'EPFL, bastion originel du Scala).

Q2: Aucun; mais si je devais reprendre du fonctionel, vu que mon langage n°1 est le Java, ce serait à priori plutôt vers Scala que je me tournerais. Ceci dit, honnêtement j'ai quasiment tout oublié vu que je ne m'en sers pas pour des projets concrets, je devrais quasiment repartir de zéro.

Q3: Ni l'un ni l'autre. J'ai trouvé la prog fonctionnelle très sympathique, mais de là à architecturée un projet concret de A à Z, il y a un pas que je n'ai pas encore osé franchir. Au niveau professionel, je n'ai pas l'impression que ce soit très demandé, il semblerait que la grosse majorité soit partagée entre Java et la plateforme C#/VB.net.

Q4: Full POO et procédural, clairement. JE ne sais pas si c'est parce que je suis trop formaté étant donné que j'ai commencé la prog en autodidacte bien avant de faire des études en informatique (j'ai commencé le C/C++ à 11 ans), ou si c'est simplement parce que je n'ai pas pris la peine de creuser dans ce domaine plus que ça en-dehors des obligations scolaires

Il n'empêche que la tendance est de plus en plus à vouloir intégrer des concepts typiquement fonctionels dans les langages OO classiques, parce que ça apporte un plus extrêmement intéressant, pratique et efficace pour régler certains problèmes de manière très élégante. Le meilleur serait donc dans la souplesse et la mixité des paradygmes ?

En tout cas, on se demande bien ce que serait le JavaScript, le python et le lua sans concepts fonctionels. Mème Java s'y met un peu avec Java 8.

Q5: J'ai terminé mes études mais ne travaille pas encore (je cherche, j'ai terminé les études cette année), donc pour le moment je n'utilise pas de langage que je n'apprécie pas du tout au moins un minimum. Mon quatuor de tête est Java, PHP, JavaScript et C++ et je suis en train de me mettre à python. Après le reste c'est très anecdotique, j'ai touché un peu de lua, j'ai vaguement voulu essayer ruby mais n'ai pas été séduit, pareil pour C# à cause de la lourdeur de VS, j'ai eu un petit aperçu de perl mais ça m'a paru exceptionnellement bordélique, …etc… J'ai rangé Nodes dans un coin, je serais bien tenté d'essayer un coup mais je n'ai pas encore eu le temps…

Maintenant pourquoi ceux-là, eh bien PHP et JavaScript sont probablement des incontournables dans leurs domaines de prédilection respectifs (web back-end et front-end), bien qu'en fait je ne les apprécie pas tant que ça, je considère que lua a les mêmes qualités de base que JavaScript mais est beaucoup plus élégant, et PHP a toujours un peu cet aspect langage du petit bricoleur (même si le tir a été largement corrigé avec PHP 5.3+).

Java est souvent critiqué pour être lourd et verbeux mais il a l'avantage d'avoir une communauté énorme et d'être très polyvalent, tout en gardant un rapport performance/simplicité assez bon. ET j'aime bien C++ parce qu'on peut vraiment tout faire avec (très bas niveau comme très haut niveau), qu'il produit des programmes performants et compacts (en taille d'exécutable pas en code), l'ennui c'est évidemment qu'il est très vite complexe même pour faire les plus petits trucs idiots et certaines choses restent toujours aussi impénétrables (les tarés qui font des programmes complet en template).

Q6: Je ne répondrai pas, je ne suis pas assez fan des langages fonctionels pour cela

Q7: Oui. Ca me semble important parce que ça permet de voir autre chose, d'élargir sa culture, et d'être plus efficace en POO/procédural étant donné que le fonctionel a largement débarqué dans les langages OO classiques. La compréhension de liste en python c'est typiquement du fonctionel et c'est redoutable; tout comme les algorithmes basés sur map/reduce/filter et l'élégance de manipulation des collections associées, les closures, ou les itérateurs et générateurs, que ce soit en Java, JS, PHP, C++ ou n'importe quoi d'autre, qui implémentent tous à leur manière tout ou partie de ces concepts aujourd'hui. ON utilise encore peu le case matching dans les langages traditionels mais c'est aussi très très puissant, ça permet d'exprimer bien des choses plus facilement et plus clairement qu'avec des chaînes de if.

Après, en ce qui me concerne, je n'ai plus utilisé les langages fonctionels au-delà des cours; c'est pas grave je pense. L'intérêt de passer par un langage fonctionel même si on l'oublie à peu près complètement après, c'est qu'on garde une idée générale des concepts que ça a apporté et qu'on reste capable globalement de les utiliser quand on les retrouve ailleurs. Si je vous dis que j'ai fait un an de latin en secondaire, que j'ai depuis tout oublié et que je serais bien incapable de construire ou comprendre une phrase toute simple en latin aujourd'hui, mais que c'est ce qui m'a véritablement donné le déclic pour comprendre ce que sont et comment fonctionnent les cas et les déclinaisons en allemand, je pense que vous voyez où je veux en venir avec cet argument.

Le contre-balancement de ça, c'est que l'extension de ce genre de types entraîne souvent la modification de code existant (les matching des fonctions qui traitent ce type), qui peuvent progressivement donner un nombre excessif de chemin d'exécution au sein de ces fonctions (augmentation des risques d'erreurs, difficulté de lecture, etc), et un grossissement assez méchant des fichiers qui contiennent ces fonctions du coup. Là où en objet, l'extension de type sera un nouveau comportement créé par héritage et isolé des comportements déjà présents (Open-Closed Principle).

http://c2.com/cgi/wiki?ExpressionProblem

Par contre dès que tu vas vouloir faire un parseur ou un compilateur, les langages fonctionnels deviennent franchement brillants. Le simple fait de pouvoir définir des types algébriques complets et touffus en quelques lignes, et de pouvoir filtrer les entrées par motif permet d'exprimer des opérations complexes sur un arbre syntaxique de façon hyper-élégante, là où il faut ruser dans un langage impératif et/ou OO pour définir un pattern visitor.

Ça n'est pas spécifique aux langages fonctionnels. C'est juste que les gens qui ont fait ML et qui réfléchissaient aux langages de programmation dans les années 70 en général avaient un peu de jugeote, contrairement aux comités/dictateurs bénévoles qui ont suivi.

1. Avez-vous commencé à utiliser les langages fonctionnels durant votre cursus scolaire ? (Si oui n’hésitez pas à préciser le nom et l’année de votre formation)

1. Non.

2. OCaml.

3. Je l'utilisais dans mon précédent boulot. Je fais plutôt du Python aujourd'hui.

4. Fonctionnel.

5. Python, à cause de mon boulot actuel. Je ne l'apprécie pas beaucoup, mais heureusement le langage est relativement souple, et fait un bon "poor man's Lisp".

6. Quand les bibliothèques nécessaires sont trop grosses pour être réimplémentées.

7. Oui, mais pas n'importe lesquels. Je pense que des langages comme OCaml ou Haskell sont bien conçus et reposent sur une poignée de concepts clairs et orthogonaux qui peuvent être facilement expliqués (à condition d'éviter toute analogie avec les langages impératifs), et qu'ils permettent de découvrir de nouvelles choses, voire de mieux comprendre les langages impératifs (personnellement, OCaml m'a permis de comprendre le système de types de Java, par exemple). En revanche, des langages comme Lisp ou Erlang me semblent moins intéressants pour le débutant.

Je crois que ce qui est vraiment intéressant dans ces langages, c'est le fait qu'ils soient bien conçus et de haut niveau, davantage que le fait que ça soit des langages fonctionnels - ce dernier point est quasiment un "effet de bord" (haha, haha).

Edit : OP, tu pourras résumer/synthétiser les réponses quelque part s'il te plaît ?

OCaml intègre depuis la 4.02.0 l'extension d'un type algébrique qui était déjà présente avec le type exception notamment.

Maintenant, que le compilateur te signale que si tu changes un type algébrique, il faut changer tout le code qui en dépends est, selon mon expérience, un bienfait qu'une contrainte.

L'isolation d'extensions d'une AST (qui s'apparente forcément à des extensions du langage) en omettant arbitrairement ses dépendances (puisque tu parles d'isolation) permet juste de te tirer une balle dans le pied car tu casses la cohérence d'un pan de tes règles sémantiques dans ton langage. Et c'est pour cette raison qu'OCaml et Haskell auront toujours de l'avance dans ce domaine d'application par rapport à tout les autres langages - ils sont fait pour vérifier l'homogénéité de se qui reste être de la transformation d'un type à un autre et donc assure non seulement l'exhaustivité du traitement et la cohérence en interdisant le patch hack et l'ajout brutal d'informations sans prendre en compte l'ensemble.

Concernant la multitude de branchement conditionnel, si tu regardes bien le travaille qui a été fait sur le pattern matching et son optimisation et si tu regardes la sémantique du C++ et sa compilation, il est raisonnable de dire qu'OCaml ou Haskell (je ne sais pas trop ce dernier ne sachant pas comment il compile réellement le pattern matching) serait plus rapide sur ce point pour une seule raison, il n'est pas possible de faire du polymorphique ad-hoc (le simple fait que tu mettes les visiteurs en virtual plombe la vitesse puisque la décision est calculé au runtime avec la vtable, non plus par le compilateur) qui facilite le travail de décision du compilateur. En somme, il y aurait au temps de branchement conditionnel en C++ qu'en OCaml (dans le meilleur des cas), la seule différence c'est que l'un est déporter de manière implicite sur son modèle objet, tandis que l'autre est déporter de manière implicite sur son pattern-matching.

Enfin l'aspect objet et l'héritage dans ce genre de conception n'est pas un bienfait selon moi. Dans ce domaine, on assure que les éléments qui forment le langage sont définis de manière atomique et une extension de son comportement reviendrait souvent à être du sucre syntaxique si on parle de non-dépendance ou a une désambiguïsation des règles sémantiques qui nous amène souvent à re-atomiser l'élément en question (ce qui permet alors d'assurer l'application de manière exhaustive à nos nouvelles règles sémantique). Si on évite cette aspect là, on se retrouve alors avec un traitement in-décisionnel puisqu'il est humain d'oublier certains détails dans la conception - et c'est là où la contrainte qu'amène un compilateur comme celui d'OCaml devient intéressante.