Juste pour te répondre concernant le fait que
<des étudiants ne cessaient d'avoir à la bouche "mais bon sang, pourquoi on peut pas mettre une boucle for ici, ca rait vachement plus simple"> :
Il faut bien avouer qu'il y a des problèmes qui se modélisent et se résolvent de manière algorithmique plus facilement avec un paradigme qu'avec un autre.
Bien souvent, dans des cours d'initiation à la programmation fonctionnelle, on impose à n'utiliser que les traits fonctionnels des langages choisis comme support, de manière à forcer la réflexion de cette manière là.
C'est juste à but "éducatif".
C'est après, à tout à chacun, d'apprendre à reconnaitre des problèmes et de choisir une voie pour les résoudre.
Si je dois faire des modifications de coordonnées de vertex pour des faces de polygones dans un espace 3D, je choisirais certainement plus la voie impérative et algorithmiquement itérative, plutôt que la voie fonctionnelle et la récursivité.
Bien souvent, les gens, à mon grand regret, ne gardent dans la bouche qu'un "holala, c'était la misère les cours d'ocaml, on ne pouvait jamais faire des choses simplement".
Alors que justement, la manière de penser fonctionnel est très simple.
A deux conditions :
-1/ Que le problème se prête à une démarche fonctionnelle (ce qui n'est pas systématique, mais bien plus fréquent que ce que les gens imaginent)
-2/ Que l'on ai une parfaite compréhension de ce que l'on code.
Et c'est sur ce deuxième point que je rejoins totalement Godrik : l'approche impérative/objet permet aux gens de "bricoler", là où c'est totalement impossible sur une langage fonctionnel.
En impératif, ils mettent des boucles là où il sentent qu'il faut parcourir quelque chose, avec des bornes de boucle douteuses, et puis ils testent, ça crash, ça segfault, ça trie leurs entiers dans le mauvais sens, ils change l'opérateur ">" en "<" et ça finit par marcher (partiellement, souvent) au bout d'un long moment.
Sur un langage fonctionnel, l'activité intellectuelle est bien plus soutenue, et chaque ligne est sensé être pleinement pensée.
il est juste impossible d'écrire soi même du code fonctionnel pour un problème que l'on ne comprend pas parfaitement.
Un exemple très simple : je ne peux pas coder en Haskell, ou Ocaml si il y a du bruit autour de moi.
Alors qu'en Java, ça ne pose quasimment aucun problème.
Pire : dans des langages impératifs/objets, de nombreux programmeurs que je connais, en plus de ne comprendre que partiellement leur problème, se lancent dans le codage d'un truc orible du genre "void trucmuche()" sans même savoir précisemment ce qu'ils attendent de leur fonction.
Ma conclusion : les gens n'aiment pas trop réflechir. Et c'est pour cette raison qu'ils n'aiment pas les langages fonctionnels.
Ils préfèrent tester et déboguer pendant des heures.
C'est triste mais notre pauvre domaine est ainsi fait...
Quand j'ai lu un post un peu plus haut de quelqu'un qui disait "quand je mentionnais sur mon CV que je connais bien Ocaml, les recruteurs souriaient souvent".
Personnellement, à ta place, je sourirais en les voyant sourire. Et si ils méprisent réellement ce langage, je n'accepterais pas de travailler pour eux.
Je ne crois pas un instant qu'ils n'aiment pas.
Je crois qu'ils n'ont soit jamais vraiment essayé, soit rien compris, et qu'ils sont ainsi retourner bricoler en Java.
PS : Désolé pour ce post trollesque mais sincèrement pensé.
ces gens méritent de bouffer de la callback en C, encore, encore et encore.
