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
Quels projets réalise t-on avec la prog. fonctionnelle ?
bonjour ,
ne connaissant rien à la programmation fonctionnelle et justement étant intéressé par ça, je vous demande vous professionnels de la programmation fonctionnelle :
Quels sont les type de projets utiles et utilisables qu'on peut réaliser avec des langages fonctionnels ?
Je pense que l'on peut globalement tout faire en fonctionnel (je parle d'un point de vue pratique, pas théorique, où c'est évident). S'il y a au final si peu de gros projet écris en fonctionnel (pas nécessairement pur), je pense que c'est plus une question d'inertie et d'habitude que pour des raisons intrinsèques.Envoyé par bassim
Mais à part ça, dans le domaine grand publique, il y a MLdonkey écrit en OCaml. Pour ce langage en particulier, tu trouveras quelques exemples par ici.
Haskell est un langage encore plus théorique et "orienté chercheur" que Caml, donc il sera encore plus dur de trouver des tas de choses faites en Haskell. Mais pour la petite histoire, quand la norme de Perl6 est sortie, a interpréteur a été écris en Haskell beaucoup plus rapidement qu'en C.
Il y a aussi erlang comme langage "en gros" fonctionnel (je ne connais vraiment pas), qui est très utilisé chez Ericson.
Bref, on peut faire énormément de chose en fonctionnel, et même si tu retournes après à des langages impératifs, tu ne perdras pas ton temps à étudier ce nouveau paradigme.
Enjoy
Bienvenue sur le forum Langages fonctionnels.
Il y a des utilisations 'cachées' (ou plus confidentielles) dans des domaines très grand public, par exemple:
SCOL a servi de langage de script dans la plupart des jeux-vidéos Cryo en ligne.SCOL (Standard Cryo On-line Language) est un langage de programmation fonctionnelle créé par Sylvain Huet au sein de feu Cryo-Networks.
Ceci dit je pense qu'il ne faut pas se voiler la face: la programmation fonctionnelle est globalement marginale et elle demande un goût plus prononcé pour les mathématiques.
Il y a quand même une contrepartie: les gains en qualité du code sont incontestables, en particulier la phase de déboguage est très réduite, dans les cas "fonctionnellements purs" elle est souvent inexistante.
Théoriquement parlant, on peut tout faire avec des langages fonctionnels ; dans la pratique, les langages fonctionnels sont utilisés dans les domaines où ils sont bons, c'est-à-dire dans les projets demandant une grande abstraction comme le calcul formel, la preuve de programmes assistée ou la compilation (tous les compilateurs de langages fonctionnels qui se respectent sont boot-strappés).
Dans d'autres domaines, utiliser un langage fonctionnel alourdirait énormément les choses et n'apporterait rien : le calcul numérique en est un exemple, mais les systèmes d'exploitation également. Il s'agit essentiellement de domaines exigeants en termes de performances et possédant beaucoup de fois des algorithmes aux branchements si complexes qu'il est difficile de se passer de choses telles le goto.
De façon générale, on peut dire que les langages fonctionnels sont l'archétype même des langages de programmation faits par des informaticiens pour des informaticiens, destinés à produire des programmes d'applications informaticiennes. Des langages impératifs comme le FORTRAN ont été faits pour des non-informaticiens réalisant des applications non-informaticiennes : c'est une autre philosophie.
Quant au fait qu'il faille un goût prononcé pour les maths avant de faire de la programmation fonctionnelle, je dirais que c'est faux : il ne s'agit que d'un délire de matheux aigris qui voient trop souvent dans ce genre de langages un quelque chose de magique, ésotérique... un peu de l'ordre du mystique... C'est ainsi qu'un jour, en colle de Math Sup avec un colleur notoirement à l'Ouest, je me suis vu dire (le mot est trop faible, il faudrait dire crier) : "Ce n'est pas la peine de me parler de Caml si vous ne savez pas faire cet exercice correctement !". La personne en question n'avait jamais écrit plus de trois lignes de code sous l'interprète de Caml Light.
Pour ce qui est du côté mathématique en programmation fonctionnelle, il y a un merveilleux torchon jaune (oui, vous savez, de la même couleur que...) paru chez un éditeur Français je crois, écrit par une personne qui visiblement n'a jamais touché un ordinateur de sa vie, ou tout au plus à joué une fois au M$olitaire, n'a jamais écrit autre chose qu'une fonction map et qui, comble des combles, ne sait même pas se servir d'un correcteur orthographique et ne sait pas parler dans son langage naturel : le Français. Un merveilleux lien est ici :
http://www.amazon.fr/Programmation-f.../dp/2854286081
Si vous voulez faire un cadeau à votre pire ennemi, c'est le moment ou jamais de claquer 56 euros !
Ce serait bien d'ouvrir un topic ou autre (pourquoi pas un article ?) avec des références solides et sérieuses sur les langages fonctionnels. Pour commencer, tu as celui-ci : avec ce livre, tu n'apprendras pas seulement énormément de choses sur la programmation fonctionnelle, mais aussi sur les systèmes d'exploitation, les systèmes de récupération de la mémoire, etc... Un vrai must !
http://www.pps.jussieu.fr/Livres/ora/DA-OCAML/
En plus, tu l'as en version électronique gratuite.
@InOCamlWeTrust: je compatis avec ta souffrance... au passage, il me rappelle quelque chose ce prof
à mon avis, la situation est bien résumée... peut-être de manière peu diplomate, mais tout à fait justifiable
au passage, si tu veux un projet de taille industriel en OCaml, je pense que Astree est un bon exemple : ça sert pour les industriels, mais il faut garder à l'esprit qu'il faut de gros fondements théoriques, et les plus gros problèmes sont "algorithmiques" et non d'implémentation
Mauvais exemple : http://www.ffconsultancy.com/product...sts/index.html
Un langage fonctionnel peut être très performant, tant au niveau conception qu'au niveau exécution, pour du calcul lourd.
Cette comparaison pour un raytracer (gourmand en calcul) est intéressante:
http://www.ffconsultancy.com/languag...omparison.html
De même d'autres domaines comme la bioinformatique, où la puissance de calcul est primordiale, voit parfois les langages fonctionnels d'un bon oeil (le pattern matching d'ocaml est un must dans ce cas).
Cependant, le ton général de ton message est très vrai et je suis en accord avec celui-ci.
Je parlais essentiellement du calcul numérique, domaine dans lequel seul le C peut rivaliser avec les performances et la simplicité du FORTRAN. Programmer une banale multiplication matricielle en FORTRAN, c'est du gâteau... en Haskell, ou Scheme, c'est déjà autre chose. De plus, pour reprendre le cas du C, tu as la possibilité de contrôler très finement les erreurs se produisant lors de calculs, ce qui est primordial lorsque tu dois faire des programmes robustes (je parle de programmes industriels utilisés dans le monde entier, pas d'un vulgaire ray tracer de cent lignes de code). Je sais bien que la littérature regorge de livres vantant les mérites des langages fonctionnels dans le domaine du numérique, mais une fois de plus, ce n'est pas parce qu'une idée est figée dans le marbre au moyen d'un livre qu'elle est vraie.
Crois-moi, pour avoir programmé des algorithmes numériques dans les deux paradigmes, je suis aujourd'hui convaincu que seuls le C et FORTRAN sont réellement adaptés à ce genre de choses.
Exemple en Haskell : xmonad (gestionnaire de fenêtre en Haskell, le coeur du code tient en 500 LOC et il y a déjà beaucoup d'extensions, pas mal de gens ne pratiquant même pas le Haskell s'y sont déjà mis (alors que le projet est très récent)), darcs (gestion de versions, utilisé bien au-delà de la communauté Haskell), ..
Quelques autres exemples dans l'industrie.
Il est vrai que les langages fonctionnels sont encore très très minoritaires en informatique en général, mais ces derniers temps on assiste à un fort regain d'intérêt pour eux, et certains langages "mainstream" commencent à incorporer des idées venues de ces petits joueurs, témoins les closures en Java, et le très fort intérêt de Microsoft pour ce type de langage (C# s'en inspire fortement).
--
Jedaï
Et puis si on en fait, c'est aussi parce que c'est marrant.
« A language that doesn't affect the way you think about programming, is not worth knowing. » Alan J. Perlis
Les langages fonctionnels valent le coup. Si tu apprends et t'y intéresses, ça changera forcément ton point de vue sur la programmation, améliorera tes programmes, même si tu ne les fait pas forcément¹ dans un de ces langages.
¹ : pour une raison ou une autre, le plus souvent c'est le manque de telle bibliothèque 'essentielle'
Des projets utiles et utilisables (et utilisés) écrits dans des langages fonctionnels, il y en a certes moins qu'en C/C++/C#/Java mais il y en a !
Pour ce qui est d'Erlang :
- Ejabberd : un serveur jabber (XMPP) capable d'endurer une charge de connexions monstrueuse.
- Yaws : un serveur HTTP, qui bat à plate couture Apache en terme de montée en charge et qui bénéficie d'un framework à la Ruby on Rails, Erlyweb
- Wings3D : un modeleur 3D
Ca, c'est pour les projets open-source. C'est sans compter qu'en passant un coup de fil ou en transmettant des données en GPRS/EDGE avec son mobile (commutateurs/SGSN/GGSN Ericsson) il y a pas mal de chance qu'on utilise Erlang sans s'en rendre compteLes applications en sont trés pragmatiques et concrètes !
De manière plus générale, je crois que c'est surtout le fait que les langages fonctionnels soient moins connus, moins répandus qui fait qu'on trouve moins de projets dans ces langages. Mais à l'heure actuelle, ils sont en plein boom ! Il est frappant de voir comme Haskell, Erlang et d'autres sont sortis de l'anonymat ces derniers mois et commencent à susciter un large intérêt !
Je crois qu'un programmeur qui travaille dans des langages impératifs a tout intérêt à apprendre un langage fonctionnel, pas nécessairement pour s'y convertir, mais pour améliorer son style et sa discipline de programmation.
Adopter un style fonctionnel dans ses développements, y compris dans des langage impératifs, ça peut avoir du bon : en écrivant un maximum de fonctions dont le résultat ne dépends que des arguments, la refactorisation du code est plus facile, le code mieux organisé, plus modulaire, les test unitaires et le débogage facilités.
En bref, comme ça a été dit, les langages fonctionnels sont en train de sortir du domaine académique/mathématique (pour Haskell, OCaml, ...) et des salles télécoms (en ce qui concerne Erlang) de plus en plus et ça ne fait que commencer !
Répondre avec citation
Partager