février
2010
Un article de SpiceGuid
Définition
C’est comme pour un langage à objets, étant un paradigme riche il y a plusieurs définitions possibles pour un langage fonctionnel.
Une définition possible: c’est un langage qui offre les fermetures (une fonction liée à un environnement d’évaluation).
Avantage de cette définition: elle est tolérante.
Inconvénient de cette définition: elle perd de sa pertinence au fur et à mesure que la plupart des langages à objets intègrent plus ou moins cette fonctionnalité.
Une autre définition possible: c’est un langage avec un sytème de typage riche, riche au point qu’il devienne insupportable de ne pas être assisté par une forme d’inférence de type.
Avantage: c’est plus représentatif de la spécificité des langages fonctionnels modernes.
Inconvénient: ça exclut les assembleurs de langages (macro-langages) que sont les vénérables Lisp et Scheme.
Autres définitions (plus techniques et plus ou moins équivalentes entre elles) :
- c’est un langage inspiré du lambda calcul
- c’est un langage inspiré des catégories bi-cartésiennes fermées
- c’est un langage où Hom(A × B, C) = Hom(A, Hom(B,C))
Utilisation
Typiquement les macro-langages font des merveilles pour prototyper la conception de nouveaux paradigmes (réflection, AOP et autre POO étendue ou exotique).
Typiquement les langages à inférence de type font des merveilles pour implémenter les spécification algébriques et les algorithmes avancés.
Historiquement les langages à inférence de type sont très liés à la preuve de programme, ce qui les rends très lisibles dès lors qu’on est familier avec leurs concepts exotiques (du point de vue d’un programmeur POO) et la syntaxe particulière qui va avec.
Mais aujourd’hui la programmation fonctionnelle s’est élargie et démocratisée et on peut quasiment tout faire avec, y compris des jeux SDL, Allegro ou SFML, de la 3D OpenGL, de la programmation système, du web et bien d’autres choses encore.
Avenir académique
Au niveau académique la programmation par objets n’est plus un domaine vraiment actif, pour plusieurs raisons :
- la recherche sur la POO avait beaucoup exploré toutes sortes de variantes exotiques de la sémantique de l’envoi de messages, en pratique aucune variante n’a été assez convaincante pour éclipser le fait que le modèle d’exécution de C++ est le plus performant
- il est plus fructueux d’associer une extension objets à un langage fonctionnel que le contraire
- même si en lui-même le paradigme fonctionnel n’apporte pas la solution à la question du parallélisme, au moins il repose sur un modèle théorique plus simple qui permet de se concentrer sur le coeur de la difficulté
- le modèle du lambda-calcul est tellement simple qu’il se prête à d’infinies variantes / extensions, potentiellement porteuses de nouveaux paradigmes (voir Bondi par exemple), éventuellement ces expérimentations connaîtront le même sort que les expérimentations sur l’envoi de message mais il est trop tôt pour l’affirmer aujourd’hui
Avenir industriel
La programmation fonctionnelle a déjà réussi dans le sens où la plupart des langages à objets sont dotés (ou envisagent de se doter) d’une extension offrant les fermetures. Cependant l’influence de la programmation fonctionnelle va déjà bien au delà et les nouveaux langages à objets (Scala,F#,Clojure,Groovy,Go) sont ouvertement influencés par les langages fonctionnels. L’industrie a plébiscité l’objet et continuera de le faire mais d’une façon moins dogmatique qui ouvre la voie aux approches mixtes objet / fonctionnel.
[…] Qu’est-ce qu’un langage fonctionnel ? […]