Je vois très souvent des gens dire que le langage de programmation avec lequel on apprends la programmation n'a pas réellement une si grande importance. Je suis tous a fais d'accord, mais en général en parle alors des langages impératifs. Pour être bien avancé dans le livre «Learn You a Haskell for Great Good!» je dois dire que je suis vraiment impressioner et j'adore ce langage.

La question que je me pose c'est est-ce que sa serais une bonne idée de commencer la programmation par un langage fonctionnelle telle que celui-ci. J'imagine que sans base en math sa peut être difficile, mais disons qu'on ai une base en math, mais pas en informatique. Aussi au vue des grands avantages des langages fonctionnelles je suis surpris que l'on en parle aussi peu. Y a-t-il une raison qui explique par exemple qu'on ne les enseignes pas plus tôt à défaut de commencer par eux, car les rares mentions que j'ai vue parlant d'eux arrive assez tard dans les études. (Pour préciser je suis un Québecois).

P.S. : Désolé pour les fautes d'orthographes. Je fais un effort, mais ce n'est pas super facile.

Il s'agit pour la plupart de langages de chercheurs j'ai envie de dire même si les langages objets reprennent de plus en plus les concepts genre Swift , Java... Quand tu vois un langage comme Ur/web qui est issu de Haskell et bien ça percera pas malgré les avantages évidents qu'il peut y avoir. La difficulté de mise en place de certains environnements et la documentation parfois floue décourage . Pour ma part j'ai voulu tester Elixir sur mon mac essentiellement pour le framework Phoenix jamais réussi à avoir un truc fonctionnel idem avec Js_of_Ocaml là j'arrive à l'installer et compiler mais jamais obtenu de programme JS fonctionnel et vu le peu de doc sur le web j'ai laissé tombé ce qui est peut être dommage. Après les gens pensent à manger et donc ils ne miseront pas sur le fonctionnel comme plan de carrière. J'ai déjà rencontré un fan de Scala bah il fait ça chez lui mais en dehors ...:-(

Dans les classes prépa MP option informatique, le langage qu'on apprend est (dans la majorité des prépas) le Caml Light, comme son nom l'indique une version allégée de OCaml. Dans l'idée c'est plutôt bien, mais en pratique perso mon prof avait pas trop l'air de savoir ce qu'était de la programmation fonctionnelle et il codait en caml comme si c'était du C, à grands coups de tableaux, références et boucles for

Les arguments contre le fonctionnel sont principalement que c'est souvent moins rapide que l'impératif, et que les gens ont l'habitude des langages impératifs et ont la flemme de changer.
Comme l'a dit boyd, c'est principalement dans le monde académique que les langages fonctionnels sont utilisés. Dans l'industrie, dès qu'on veut faire un gros projet, il faut recruter des gens qui maitrisent le même langage, il faut que le langage dispose des libs adéquates, etc. C'est pour ça que la transition vers le fonctionnel se fait lentement.

Dans la théorie ça à l'air chouette, dans la pratique il y à presque pas de débouchés au niveau professionnel, et beaucoup d'étudiants n'y comprennent rien et ça ne fait que de les dégouter de la programmation. C'est pour cette raison que pas mal d'écoles généraliste enseignent le Python pour son apparente simplicité, ne serais ce que pour donner le gout de la programmation aux étudiants et leur donner envie d'en apprendre plus.

Ça fait partie parfois du programme de certaines écoles d'informatique spécialisée, mais combien d'étudiants vont en retenir quelque chose, d'après ce que j'ai pu en voir pas tant que ça, et au final en entreprise ils vont coder de toute façon en Java, C# ou PHP le plus souvent, donc ce passage souvent ne profite qu'à une minorité.

Ca fait un bout de temps que les gens regarde la programmation fonctionnelle comme une solution a plein de vrai probleme important (comme le calcul parallele). Mais industriellement on en est pas encore la.

Justement. On parle de problème de rapidité, mais de ce que j'ai vue quand on rentre dans les système massivement parralèle les langages fonctionnelles gagnent au là mains. Je pens entre autre a l'Erlang qui a réussis à tenir avec un programme contenant 20 millions de processus. Les langages fonctionnelle ont d'ailleur comme avantage un parallèlisme beaucoup plus simple non? Aussi, les optimisations particulière dû au fonctionnelle (Transparence référentiel, Tail call optimisation) doive quand même bien aidé. Selon certaint un programme Haskell bien écris peut atteindre les performences du C.

Bon pour ce qui est de trouver un travail c'est vrai que le fonctionnelle c'est pas là où il y en à le plus. Quoique j'ai crû voir qu'il commencait à y avoir des demandes d'emplois pour du Scala. Pour les bibliothèques j'imagine que c'est vrai que pas grand langage peux se reprocher de la taille des librairies Java ou C++.

H.S.: Étant Québecois je ne comprends rien du tous quand vous faite des références au système d'éducation Francais, car chez nous c'est complètement différent. Je ne vous demande pas d'expliquer je précise juste.

Chez nous Scala c'est minoritaire après c'est une question de ressource comme je fais un peu de Ruby j'ai voulu tester Elixir sur mon mac et bien je n'ai jamais réussi à le faire marcher ni trouvé de solution sur le net.
Je tape iex que j'ai un message d'erreur

Au niveau des études, faut aussi prendre en compte le fait que la programmation impérative et objet sont des paradigmes super intuitifs pour des débutants. En impératif, au plus simple, on réalise séquentiellement des actions prédécoupées. En objet, on réalise des simulations plus ou moins réaliste du monde. Quand on apprends, ça semble logique.
À côté, on a la programmation fonctionnelle, où, suivant le degré de pureté, on doit se taper des interfaces monadiques pour faire un Hello World, et abstraire ses structures de données et ses contrôles pour avoir le moindre début de résultat. Y'a pas photo.

Bien évidemment, je suis loin de dire que "impératif = simple et idiot" et "fonctionnel = complexe et intelligent" ; un programme qui n'est pas un minimum pensé et modélisé en amont ne sera jamais efficient, peu importe le paradigme. Simplement, quand on oblige les utilisateurs à faire de la gymnastique cérébrale dès leurs débuts pour comprendre, lire et écrire du code en fonctionnel, c'est contre-productif. Quand on explique des concepts nouveaux dans un domaine où un langage n'est qu'un outil comme un autre, surcharger l'outil de concepts ésotériques à apprendre en plus est une perte de temps monumentale et une déviation du sujet original.

Alors oui, je suis un grand fan de programmation fonctionnelle, et je pense que c'est une discipline très enrichissante quand elle est utilisée pour elle-même dans des cours. Par contre l'utiliser pour présenter d'autres concepts qui n'ont rien à voir directement ça n'a pas de sens si l'impératif/objet permet une introduction transparente à ces domaines.

c'est clair que le paradigme fonctionnel c'est sympa, mais perso, dans des projets d'industrie, je vois pas en quoi tu aurais avantage à utiliser Scala plutôt que Java/C# par exemple.

Après pour le parallèle, j'en ai jamais fait en scala j'ai un cours ce semestre mais si tu veux pas te péter le cul OpenMP est parfait et si tu veux utiliser la puissance de GPU (genre 3000 coeurs), tu peux faire du CUDA.

Des contre-exemples ? Je serais intéressé.

Perso, ce que j'ai aimé dans scala (enfin dans le paradigme):

- pattern matching
- générateur
- map/flat/reduce/filter/flatmap/exists etc
- Les streams/lazy
- Les blocks

Les moins
- Avec ces structures immutables, tu peux perdre énormément de temps
- Débuguer c'est une catastrophe (où je m'y suis mal pris mais qvec eclipse biofe quoi)
- Les mises à jour de scala qui pète toutes les compatibilités

Le 12 février 2015 à 21:37:59 vive_cod4 a écrit :
Les moins
- Débuguer c'est une catastrophe (où je m'y suis mal pris mais qvec eclipse biofe quoi)

Je ne connais pas le Scala en particulier, mais un des gros soulagements quand on fait de la programmation fonctionnelle après avoir fait du C ou autre joyeuseté, c'est qu'on n'a bien souvent (presque) rien à débugguer, et quand c'est le cas, 90% du temps le compilateur nous indique directement où se trouve le problème !

caletlog Je suis pas vraiment d'accord avec l'idée que "l'impératif, c'est intuitif". Je comprends ce que tu veux dire, mais je pense que c'est surtout lié au fait qu'on enseigne en général la programmation (et plus généralement l'algorithmique) en ayant en tête le paradigme impératif. On t'explique qu'un programme c'est une suite d'instructions qu'on va exécuter les unes après les autres, dans l'ordre, pour manipuler des cases mémoires en y rangeant des entiers. On retrouve l'influence de Turing et plus généralement le besoin de se rattacher à l'aspect matériel qu'il y a derrière.
Au contraire, pour comprendre le fonctionnel, il faut un niveau d'abstraction au-dessus. Mais là où je ne suis pas d'accord avec toi, c'est qu'il n'y a pas besoin de fournir un effort pour "s'élever" à ce niveau-là, il suffisait dès le début de ne pas descendre dans les tréfonds du processeur. Si, dès le début, on se mettait à voir un programme plus comme une fonction mathématique que comme des suites d'instructions, on aurait bien moins de mal à concevoir le fonctionnel. Quant au bagage mathématique nécessaire, il n'est pas si énorme : pas besoin de parler de monades dès le début, il suffit d'avoir compris le principe de récurrence, et on peut à peu près tout faire.
Pour revenir au côté intuitif, dès qu'on veut implémenter un tri sur un tableau, on se met bien vite à se battre contre les indices i, i-1, i+1. Dès qu'on prend une liste et qu'on fait un algo récursif, ça devient presque tautologique : "je trie la moitié, je trie l'autre moitié, je merge". Un autre exemple rigolo c'est de coder la résolution des tours de Hanoï en impératif et en fonctionnel

Le 13 février 2015 à 20:47:08 Lowenheim a écrit :

Le 12 février 2015 à 21:37:59 vive_cod4 a écrit :
Les moins
- Débuguer c'est une catastrophe (où je m'y suis mal pris mais qvec eclipse biofe quoi)

Je ne connais pas le Scala en particulier, mais un des gros soulagements quand on fait de la programmation fonctionnelle après avoir fait du C ou autre joyeuseté, c'est qu'on n'a bien souvent (presque) rien à débugguer, et quand c'est le cas, 90% du temps le compilateur nous indique directement où se trouve le problème !

En effet l'inférence de type et autres trucs ça semble costaud maintenant le fonctionnel j'ai un peu de mal à m'y mettre ne serait ce que par manque de doc et de bugs que je rencontre (si certains font de l'Elixir ou de l'Ocaml je pourrais détailler , venez en MP si vous voulez donner de l'aide )

Sinon y en a ici qui font du Clojure Ca m'intéresserait pour ClojureScript , j'aimerais en saisir l'intérêt .

Le 13 février 2015 à 20:47:08 Lowenheim a écrit :

Le 12 février 2015 à 21:37:59 > caletlog Je suis pas vraiment d'accord avec l'idée que "l'impératif, c'est intuitif".

D'ailleurs, pour parler d'histoire un peu rigolote, c'est que j'ai un de mes amis qui a commencé la programmation avec du Lisp.
Quand il est passé en école, il en chiait pour passer du fonctionnel -> impérative.

Boyd -> j'ai réalisé (enfin, suis toujours en train) mon projet tuteuré de fin de DUT MMI en Clojure. Je ne connaissais absolument rien au Clojure en septembre, et avait à peine quelques notions de Lisp. Résultat ? Génial. Mon projet était essentiellement un parseur + transcompilateur pour un langage que j'ai développé, alors c'était vraiment parfait pour profiter des structures de données immuables et de l'homoïconicité des Lisp. Le développement était un vrai plaisir, après 2 mois de lecture intensives sur le sujet. C'est plaisant, rapide, performant, et l'écosystème Clojure, parfaitement intégré à celui de Java, est un vrai avantage. Et Leiningen est un don des dieux, ce truc est absolument monstrueux, vraiment génial pour le développement, et rend le déploiement aussi simple que possible.

Sinon, oui, le fonctionnel serait sans doute plus intuitif si on l'apprenait avant l'impératif. Mais quand même. Pour reprendre le cas de l'objet : si c'est aussi populaire, c'est aussi parce que ça modélise/simule plus ou moins bien le monde réel. Quand on réfléchit à un projet, on peut le modéliser par des entités concrètes. Avant même de savoir comment structurer mon programme et ses flux de contrôle, je peux savoir quelles entités existantes je vais manipuler. Si je bloque sur une partie "machine", je peux basculer sur une partie "réelle", et inversement.
En fonctionnel, c'est plus délicat. En Lisps et dérivés, on a généralement une approche orientée sur les structures de données du programme. Pas forcément "naturel" à modéliser. En Haskell, on approche généralement un type-driven development. C'est encore autre chose.

Bon bah j'essayerais de creuser , moi c'est ClojureScript qui m'intéresse un tant sois peu on verra si j'accroche.