Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
[Débat] Langage Fonctionnel vs Langage impératif
Même si les langages fonctionnels et impératifs sont équivalents dans leurs possibilités à résoudre des problèmes. De nombreuses personnes se demandent quel paradigme de langage de programmation ils peuvent utiliser.
Pour quel type de problèmes avez vous préférer privilégier un paradigme plutôt qu'un autre ?
Pensez-vous que pour certains problèmes, l'un des paradigmes n'est pas envisageable ?
D'autres comparaisons sont ouvertes.
Dans certains domaines, les bénéfices du paradigme fonctionnel sont très clairs. Typiquement, pour tout ce qui est manipulations symboliques (calcul formel, certaines parties des compilateurs/interpréteurs, etc...), les langages fonctionnels (et plus encore ceux qui, dérivés de ML, apportent les types algébriques et le filtrage de motifs) sont supérieurs aux langages impératifs.
La situation existe sans doute aussi dans l'autre sens, mais cela me semble nettement moins clair : on dit souvent par exemple que la programmation impérative est plus adaptée pour faire des GUI (et d'ailleurs c'est souvent de POO qu'on parle quand "on" dit ça), mais en pratique les approches fonctionnelles de la GUI semblent relativement crédible (mais pas extrêmement utilisables pour l'instant car bénéficiant d'une faible puissance de développement, etc...), et je me demande si, à popularité égale, elles ne feraient pas au moins aussi bien.
Évidemment, on peut dire que dans l'autre sens, il est possible de développer des bibliothèques dans des langages impératifs pour simplifier les manipulations symboliques et Cie. C'est vrai, mais cela revient alors plus à mon avis à intégrer des aspects fonctionnels au langage (comme on peut le faire dans tous les langages, j'ai vu des gens coder utiliser des fold_left fold_right en C ...). L'INRIA développe d'ailleurs dans cette optique une solution pour intégrer des filtrages de motifs aux langages mainstream (C++ et Java je crois), mais ça n'a pas l'air si populaire que ça pour l'instant. À l'inverse, je pense que le code écrit en Haskell avec des monades ne doit pas forcément être considéré comme "du paradigme fonctionnel", s'il reproduit le comportent d'un langage impératif.
Il se pose donc la question de la pureté/mixité : certains langages sont tout-fonctionnel ou tout-impératif, mais la plupart mélangent les deux. Cela a des inconvénients, mais ça permet de ne pas avoir de gros problèmes si justement le paradigme principal du langage se retrouve inadapté à une situation donnée. Je pense que c'est alors plus une question de style et de conception que du langage en lui-même : quelqu'un qui écrirait en C++ dans un style fonctionnel (je crois que Boost permet de faire ça) fait de la programmation fonctionnelle.
PS : il paraît que ce forum est "réservé aux professionnels". Je ne suis pas un professionel. Je suis venu ici parce que le sujet, initialement dans un forum que je fréquente, a été déplacé. Je trouve la restriction aux "professionnels" un peu ridicule, mais il suffit que vous le demandiez et je ne posterai plus ici.
Envoyé par bluestorm
Il faut avouer que les professionnels des langages fonctionnels courent moins les rues que les professionnels de langages objet/impératif. J'ai remarqué que la plupart des contributeurs/utilisateurs des langages fonctionnels sur ce forum sont des étudiants (et qui sont souvent très bon). Donc il n'y a pas de problème s'il n'y a pas que des professionnels.
millie t'as finalement lancé le sujet
bravo
peut-être serait-ce justement parce que cela a un intérêt théorique, mais bien peu d'intérêt pratique ??
Comme j'ai déjà eu l'occasion de le dire ailleurs, ce que j'en vois me semble complètement obscur comme notation (de ce que j'ai aperçu de Haskell sur ces forums). (et j'ai pourtant touché à pas mal de langages, et physicien à l'origine)..
De même, le mélange de fonctionalités nécessaires dans un code "industriel" (accès aux fichiers, aux périphériques, manipulations d'images, de structures complexes en mémoire, calculs prolongés, voire itératifs, "événements et callbacks", sockets, accès BD, etc..., le tout au sein du même logiciel), facilement maintenable et débuggable par un technicien de maintenance niveau bac+2, ou au contraire par un scientifique raisonnant depuis belle lurette sur la FONCTIONALITE, les 2 éventuellement (et souvent) de cultures différentes (dans un autre pays par exemple), et pour un logiciel dont la durée de vie OPERATIONNELLE est supérieure à 2 ans, ne m'apparaît pas des plus évidents avec ce que je vois...
Par exemple, je travaille en ce moment sur un code opérationnel depuis 30 ans... Il fut transfromé de Fortran en C il y a environ 18 ans. Mais là (et même si il passera sans doute à C++), le "portage" s'arrêtera.. Avec des gens de plus de la moitié du globe y travaillant, prendre un langage d'initiés serait du suicide...
J'ai eu le même genre d'expérience avec Prolog : dans un projet sur lequel j'étais, un universitaire avait fait une partie en Prolog, trouvant que ça collait bien à l'esprit du problème (un système expert). Le mainteneur (scientifique) final avait appris le langage (déjà un investissement..). MAIS surtout le point qu'il avait négligé, c'est qu'opérationnelement, ça ne passait pas ...: temps de réponse de plus de 1000 fois supérieur à la traduction en C...
Comme nous le répétons en permanence sur le forum C, un code utilisant toutes les astuces du langage (faire une fonction de 10 lignes en 1) peut-être le fun, mais est FORMELLEMENT DECONSEILLE pour un logiciel industriel..
La "simplicité" d'écriture qu'on ma déjà répondue en Haskell sur d'autres posts (je ne peux parler des autres langages, ne les connaissant pas) est à mon avis du même style....
Et dans le fond, je ne comprends pas bien en quoi on appelle cela des "langages fonctionnels" par opposition aux autres... Comme pour l'OO. Pour moi, c'est la PENSEE et l'ANALYSE qui doivent être fonctionnelles et OOs. Le code, comme les équations pour un physicien, n'est qu'un outil. Et dans la quasi-totalité des projets sur lesquels j'ai travaillé, les "programmeurs" (pour la plupart ingénieurs ou physiciens, ou sinon avec DEUG ou maîtise (ou doctorat) d'informatique) étaient plus à l'aise pour commnuiquer avec ce qu'ils utilisaient tous les jours.... (par exemple, les ingénieurs souvent interfaçaient leurs voltmètres numériques ou autres appareils de mesure avec des programmes en Pascal, ou en C. Et les NOTATIONS se ressemblent et entre eux, et avec les maths, ainsi que les paradigmes. Quasi aucun mot ou concept nouveau).
Et je dois dire que, ayant toujours été physicien et travaillant sur des projets impliquant des maths et de la physique, les notations utilisées (j'y reviens) ressemblent beaucoup plus à ce que j'utilise d'autre part que ce à que j'ai vu des langages "fonctionnels.., et la fonctionnalité est parfaitement visible et décrite et compréhensible avec les langages dits "impératifs"...
Je soupçonne donc fortement un courant de recherches universitaires dans le domaine..... (comme sur les sujets de la preuve formelle ou des modélisations de code diverses et variées)..
Mais peut-être n'ai je vu que l'arbre qui cachait la forêt ??
C'est vrai, c'est particulier comme notation et comme vocabulaire.Comme j'ai déjà eu l'occasion de le dire ailleurs, ce que j'en vois me semble complètement obscur comme notation (de ce que j'ai aperçu de Haskell sur ces forums). (et j'ai pourtant touché à pas mal de langages, et physicien à l'origine)..
Pour un programmeur Fortran/Java/C, une phrase comme "la currification exprime le fait que la flèche est associative à droite" semble venue d'une autre planête.
De ce côté là (purement syntaxique) il me semble qu'Anubis a fait un pas important, sa syntaxe est beaucoup plus commune.
Quand c'est inutilisable il ne faut pas l'utiliser.De même, le mélange de fonctionalités nécessaires dans un code "industriel" ... ne m'apparaît pas des plus évidents avec ce que je vois
C'est un fait anecdotique. De plus votre présentation est partiale: vous ne dites pas combien de temps de développement le prototypage en Prolog vous a fait gagné comparé à un devéloppement C partant de rien. Enfin, Prolog n'est pas un langage fonctionnel, ce qui bien entendu ne veut pas dire que Prolog ne "fonctionne" pas.temps de réponse de plus de 1000 fois supérieur à la traduction en C...
Pas par opposition aux autres, uniquement pour des raisons historiques, c'est-à-dire l'enracinement dans la modélisation des fonctions (en 1920 Schönfinkel a défini les 3 combinateurs S, K et I qui suffisent à implémenter le lambda-calcul). Le mot "fonctionnel" n'a jamais été motivé par un argument publicitaire et n'a rien de dénigrant pour les autres langages. Vous pourriez les appeler des langages "fonctoriels" ça ne changerait pas grand chose au débat.Et dans le fond, je ne comprends pas bien en quoi on appelle cela des "langages fonctionnels" par opposition aux autres...
En programmation fonctionnelle je n'ai jamais constaté cette distinction que vous faites entre analyse et implémentation. C'est justement cette scission qui devient obsolète en programmation fonctionnelle. Quant à la pensée elle restera toujours humaine, elle ne sera jamais OO ou fonctionnelle.Pour moi, c'est la PENSEE et l'ANALYSE qui doivent être fonctionnelles et OOs. Le code, comme les équations pour un physicien, n'est qu'un outil.
La suite de votre message ne fait qu'affirmer combien les langages impératifs vous conviennent plus aisément, nul doute de ma part que vos choix soient les meilleurs pour vous, puisque vous en témoigner avec autant de sincérité.
Il est dommage que votre intervention se termine sur une note un peu plus accusatrice.
Je ne suis pas sûr que l'avis de Souviron soit vraiment représentatif... Soyons clair : pour Souviron seul C et Fortran vaillent le coup et tous les autres langages sont des gadgets.
Quand on est aussi enraciné dans ses habitudes, il est peu probable qu'on fasse le saut conceptuel nécessaire pour passer au fonctionnel. Il est bien connu que plus on a passé de temps à faire de l'impératif avant de toucher au fonctionnel plus le passage est rude, Souviron est un professionnel de grande qualité, mais il est parfaitement satisfait par ses outils actuels avec lesquels il a une très grande expérience et il n'est pas très curieux par ailleurs, en tant que tel, il ne représente pas une cible réaliste pour les langages fonctionnels.
Adressons tout de même certaines des critiques :
Je ne vois pas ce que ces notations ont de "complètement obscures", tous les langages ont des particularités syntaxiques, les langages fonctionnels ne sont pas plus étrange que FORTH ou Smalltalk pour prendre des exemples un peu extrèmes... Au contraire et comme je l'ai déjà souligné dans d'autres réponses à Souviron, la notation fonctionnelle est très proche des mathématiques.Comme j'ai déjà eu l'occasion de le dire ailleurs, ce que j'en vois me semble complètement obscur comme notation (de ce que j'ai aperçu de Haskell sur ces forums). (et j'ai pourtant touché à pas mal de langages, et physicien à l'origine)..
Les langages fonctionnels proposent des modèles de modularité excellent et permettent d'écrire des codes très complexes et très composés. Par contre il est vrai qu'ils manquent parfois de bibliothèques pour certaines tâches, mais ce n'est dû qu'à un manque de popularité des langages en question. Or justement ces langages semblent connaître un regain d'intérêt qui pourrait bien aider à combler ces lacunes.De même, le mélange de fonctionalités nécessaires dans un code "industriel" (accès aux fichiers, aux périphériques, manipulations d'images, de structures complexes en mémoire, calculs prolongés, voire itératifs, "événements et callbacks", sockets, accès BD, etc..., le tout au sein du même logiciel), facilement maintenable et débuggable par un technicien de maintenance niveau bac+2, ou au contraire par un scientifique raisonnant depuis belle lurette sur la FONCTIONALITE, les 2 éventuellement (et souvent) de cultures différentes (dans un autre pays par exemple), et pour un logiciel dont la durée de vie OPERATIONNELLE est supérieure à 2 ans, ne m'apparaît pas des plus évidents avec ce que je vois...
Pour adresser certains points, les accès aux fichiers ou aux périphériques ne sont pas plus difficiles avec un langage fonctionnel qu'avec tout autre langage (bien que les mots "monade IO" puissent vous effrayer, au final le code résultant vous semblera très très familier), les sockets et les accès à des BD sont tout aussi couverts, les structures de données complexes en mémoire sont bien plus aisément manipulables avec les langages fonctionnels (ça fait partie de leur spécialités), "évènement et callbacks" ça existe (la notion de callback est typiquement du fonctionnel), manipulation d'image est une question de librairie, etc...
C'est là où vous faites une grosse erreur, passer de 10 à 1 lignes en C exige d'utiliser des constructions obscures et fondamentalement de rendre le code illisible, en Haskell le fait que la même opération ne prenne qu'une ligne traduit simplement le degré d'abstraction supérieur auquel opère le langage, la syntaxe employée est parfaitement ordinaire et la fonction reste parfaitement lisible par quelqu'un qui a déjà fait du Haskell (même s'il met autant de temps à la lire qu'il aurait lu 3 lignes en C, après tout c'est normal si elle en fait autant que 10 lignes de C).Comme nous le répétons en permanence sur le forum C, un code utilisant toutes les astuces du langage (faire une fonction de 10 lignes en 1) peut-être le fun, mais est FORMELLEMENT DECONSEILLE pour un logiciel industriel..
La "simplicité" d'écriture qu'on ma déjà répondue en Haskell sur d'autres posts (je ne peux parler des autres langages, ne les connaissant pas) est à mon avis du même style....
"fonctionnel" ici n'a aucun rapport avec "fonctionnalité" comme vous semblez le penser. Ainsi que l'a dit SpiceGuid, le nom "fonctionnel" se rapporte à un modèle de calcul, le lambda-calcul qui met en avant les fonctions, et seulement les fonctions, comme bloc de base de tout calcul.Et dans le fond, je ne comprends pas bien en quoi on appelle cela des "langages fonctionnels" par opposition aux autres...
Pour en revenir au sujet, ces dernières années, Erlang, Haskell et d'autres ont commencé à percer un peu, il pourrait être intéressant de suivre cette tendance. Des initiatives comme la CUFP gagne en suivi chaque année, même s'ils restent pour l'instant minuscules.
--
Jedaï
Les deux aspects principaux d'une approche fonctionnelle sont, à mon avis, l'absence d'état implicite et la possibilité de manipuler les fonctions comme des valeurs.
En ce qui concerne l'absence d'état implicite, c'est quelque chose qui facilite le raisonnement et donc une technique que j'utilise quand elle me semble applicable, mais j'aurais beaucoup de mal à ne jamais avoir d'état implicite. D'une part parce que les problèmes que je traite sont spécifié comme cela, d'autre part parce qu'expliciter l'état me semble avoir nécessairement un cout important en mémoire et en performance dans certains cas (on se retrouve à avoir l'état initial et l'état final accessible en même temps, et donc duplication de tout ce qui est commun).
Quant à la possibilité de manipuler les fonctions comme des valeurs, en pratique la plupart des usages que j'en fait quand j'utilise des langages fonctionnels sont accessibles au prix de quelques lourdeurs dans les autres langages que j'utilise. Ces lourdeurs sont suffisantes pour diminuer le nombre de leurs utilisations, mais pas pour rendre impraticable la technique quand elle offre un avantage.
Ne voulais-tu pas dire explicite ? Parce qu'il y a toujours un état implicite.
Problème de perspective. Une technique en programmation fonctionnelle est de passer explicitement l'état qu'on aurait passé implicitement dans un programme impératif et de retourner le nouvel état de manière explicite également (Et si j'ai bien compris -- je n'en suis pas certains --, les monades d'Haskell ne sont que du sucre syntaxique autour de cette technique). D'où mon utilisation d'"état implicite", mais j'admets sans peine qu'on doit pouvoir trouver une perspective dans lequel on inverse les mots.
Seule la monade State d'Haskell correspond à cette définition, ainsi que ST et IO d'une façon moins directe. Maybe ou List par contre ne correspondent pas du tout à cette description. Les monades sont une notion beaucoup plus générale qu'une simple simulation du paradigme impératif.
Ce n'est pas si lourd que ça dans la plupart des cas, d'une part le Garbage Collector supprime les états anciens devenus inutiles, d'autre part le paradigme fonctionnel favorise les structures de données "partageables" dont une grande partie reste valable d'une mise à jour à l'autre et est donc partagée entre les différentes versions d'une donnée.En ce qui concerne l'absence d'état implicite, c'est quelque chose qui facilite le raisonnement et donc une technique que j'utilise quand elle me semble applicable, mais j'aurais beaucoup de mal à ne jamais avoir d'état implicite. D'une part parce que les problèmes que je traite sont spécifié comme cela, d'autre part parce qu'expliciter l'état me semble avoir nécessairement un cout important en mémoire et en performance dans certains cas (on se retrouve à avoir l'état initial et l'état final accessible en même temps, et donc duplication de tout ce qui est commun).
Dernièrement, tous les langages fonctionnels décents offrent la possibilité d'avoir un état implicite, par exemple en Haskell dans les monades IO ou ST (la monade ST permettant même de s'assurer que de l'extérieur la fonction est bien transparente référentiellement), toute l'astuce étant de restreindre au maximum mécaniquement la portée de cet état, et de garder les manipulations de données les plus pures possibles pour conserver au mieux les avantages du fonctionnel.
La question devient donc : Vaut-il mieux utiliser un langage fondamentalement sûr dans lequel on peut introduire de façon contrôlée des éléments non sécurisé (excepté par les preuves qu'on peut faire nous-même), ou un langage fondamentalement non-sûr où on peut programmer de façon sûre avec une attention de tous les instants...Quant à la possibilité de manipuler les fonctions comme des valeurs, en pratique la plupart des usages que j'en fait quand j'utilise des langages fonctionnels sont accessibles au prix de quelques lourdeurs dans les autres langages que j'utilise. Ces lourdeurs sont suffisantes pour diminuer le nombre de leurs utilisations, mais pas pour rendre impraticable la technique quand elle offre un avantage.
C'est un peu caricatural bien sûr, mais bien que le paradigme impératif ait tout à fait sa place, pour ma part j'ai fait le choix de la première option.
--
Jedaï
tu oublies de signaler que les implémentations efficaces des langages fonctionnelles (ocaml et ghc) ont un garbage collector digne de ce nom... pour éviter qu'on ne les compare aux piètres performances de leurs cousins de chez Java & cie
Donc il va falloir que je replonge la dedans pour voir exactement ce que ça offre d'autre. Mais dans cet usage, on est d'accord que ce n'est que du sucre syntaxique ou bien même cela je ne l'ai pas compris?
Si le GC entre en jeu, il y a eu duplication... et c'est trop tard pour nous.Ce n'est pas si lourd que ça dans la plupart des cas, d'une part le Garbage Collector supprime les états anciens devenus inutiles,
Les structures sur lesquelles je travaille sont des graphes (peu dense) qu'on modifie et qu'on parcour avec une vision très locale. De plus les noeuds sont placés dans un espace à 3 dimensions et il faut aussi faire des recherches spaciales. Tu connais une structure partageable et efficace qui le permette? J'ai des collègues que ça intéresseraient vraissemblablement.d'autre part le paradigme fonctionnel favorise les structures de données "partageables" dont une grande partie reste valable d'une mise à jour à l'autre et est donc partagée entre les différentes versions d'une donnée.
Non, ce n'est pas la question. C'est une des questions. Si c'était le seul facteur, j'utiliserais aussi un autre langage que le C++.La question devient donc : Vaut-il mieux utiliser un langage fondamentalement sûr dans lequel on peut introduire de façon contrôlée des éléments non sécurisé (excepté par les preuves qu'on peut faire nous-même), ou un langage fondamentalement non-sûr où on peut programmer de façon sûre avec une attention de tous les instants...
C'est un peu caricatural bien sûr, mais bien que le paradigme impératif ait tout à fait sa place, pour ma part j'ai fait le choix de la première option.
Et alors ?
Je plussoie, c'est très rarement une bonne idée même quand tu les aimes bien, une dose de scepticisme ne fait jamais de mal... Surtout que tes cours sur le fonctionnel n'ont pas l'air de t'avoir enthousiasmé plus que ça.c'est rarement une bonne idée...
D'autant que la source que je t'ai donné est directement sur le Wiki officiel d'Haskell et est plutôt substantielle, il y a une différence entre une phrase entraperçue au détour d'un slide et une documentation complète et vérifiable sur l'usage des tableaux en Haskell.
--
Jedaï
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager