Sur un autre topic (celui la https://www.jeuxvideo.com/forums/42-47-70265442-1-0-1-0-cette-licence-info-est-elle-assez-complete.htm ) on a eu une discussion interessante. Je voulais repondre mais je ne voulais pas polluer le topic d'a cote. Donc je reponds dans un topic a part.

Last time on programmation:

Apprendre la programmation fonctionnelle avant la programmation impérative c'est normal ça ?

Il y a plein de programme qui sont construit comme ca.

OK je savais pas
Point de vue pédagogique ça change quoi tu penses ?

Je pense que le debat du premier langage de programmation a tendance a etre sur discute. Mais il y a en effet differente classe d'approche pour apprendre la programmation.

Commencer par un langage fonctionel n'est pas commun mais c'est pas si rare que ca. En France, il y a plein de prepa qui enseigne la programmation en OCaml. J'avais un pote a la fac de lille et ils ont commencer la programmation en Scheme. Il y a des programmes aux USA qui commencent avec Haskell.

La question de fond est "quelle est la strategie pedagogique?" Et pour plein de gens, l'informatique ca sert a faire des maths ou des maths appliques. Du coup faire des trucs du genre "visualiser le champs magnetique d'un systeme a n paritcules" ca se fait super bien. Ou des trucs du genre "implementer la serie de taylor de telle fonction", ca se fait bien, ou encore "resoudre numeriquement l'EDP bidule". Et tout ce qui est de l'analyse de donne ca s'ecrit relativement bien.

Et du fait tu peux apprendre les concepts de variable, type, fonction, recursion, iteration, map-reduce, finalement assez facilement. Et une fois que tu sais ces trucs la, en gros tu es pret a apprendre n'importe quoi.

Bof, je trouve que ça se limite pas aux maths appliqués, les concepts de programmation fonctionnel sont universels.

Je trouve le paradigme particulièrement utile pour raisonner en "transformation de données" au niveau global et local.

Je trouve que le paradigme impératif classique a peu d'intérêt sauf dans certaines niches où on a des contraintes techniques qui l'imposent, comme avoir besoin que les performances (au sens large, mémoire et temps) du programme soient prédictibles, comme dans l'embarqué ou dans la cryptographie par exemple.

J'avais un pote a la fac de lille et ils ont commencer la programmation en Scheme.

J'ai un pote aussi qui a commencé par scheme, mais c'était sur une seule UE, c'est trop peu pour considérer ça comme son "premier langage" je pense.

Pour moi le premier langage, celui qui a un impact durable, c'est pas le premier que t'apprends, c'est le premier avec lequel tu es à l'aise.

Ou est ce que j'ai dit que la programmation fonctionelle se limitait au math applique?

Je dis juste que c'est raisonnable dans cette utilisation la. Le paradigme parle directement aux gens qui ont un esprit matheux. (Pas qu'ils sont incapable de faire autre chose ou que seulement les matheux peuvent l'apprendre.)

Commencer par OCaml/Haskell/Scheme peut être très bien mais je m'en doute si dans un prépa ou une licence de fac ça peut aller loin... Ça peut apporter des choses genre ADT, le pattern matching ou la récursivité mais bon.

Si on parle de la pédagogie, je pense qu'il y a deux aspects distincts pour les fonctionnelles:
- Les notions et patterns inventés par la FP, certes peuvent être étendu dans d'autres langages comme un langage objet
- Les idées exclusivement réservées aux langages de FP

Pour le premier on peut citer déjà pas mal des choses, comme map/filter/fold ou bien le pattern matching. On peut utiliser OCaml par exemple mais on peut aussi explorer ces trucs avec des langages OO moderns comme Kotlin ou C#. L'étudiant peut ainsi explorer un peu le système de typage, connaitre son succès et sa limitation dans un contexte de programmation objet et monter des connaissances petit-à-petit. Perso je suis plutôt pour apprendre programmer avec ces langages-là au lieu des fameux Java/Python/C car les derniers ont pas mal d'inconvénient ou n'apportent pas autant de sujets intéressants à traiter. Par exemple, difficile de parler des lambdas ou HOF aux gens de Java7, de l'inférence de type (un sujet aussi intéressant et peut aller très loin) aux bon vieux Java, et les gens de Python/C s'en branle de types ...

Pour le deuxième, on peut voir des trucs de type encore atypique comme la programmation monadique, le raisonnement des programmes (avec coq/agda par exemple), ou bien les techniques comme GADT ou rankNtype ... Peut être ce sont les features peu utilisable dans l'industrie, mais je crois ça vaut quand même la peine d'y explorer un peu parce que ça ouvre des possibilités alternatives. Mais, déjà si dans une fac la plupart des gens ne connaissent ni lambda ni linq c'est très dur d'aller plus loin ...

J'ai entendu parlé des cours dans les fac état-uniennes où on implémente un sous langage de scheme, un petit système de résolution de types, etc. Je pense que ça peut être plus intéressant et plus motivant pour les élèves que de faire des programmes de gestion de compte bidon.

Ma position sur le langage a utiliser en premier pour apprendre est que ca n'a pas d'importance.
Ce qui est important c'est la pedagogie sous jacente. Une fois que tu sais programmer dans un langage, tu apprends les autres relativement rapidement parceque les concepts sont les memes.

Du moment que la methode pedagogique est coherente et adapte a la population d'etudiant, ca va bien se passer. Dans la methode pedagogique, le langage que tu choisis pour apprendre n'est qu'un des aspect de l'apprentissage. Dans quel ordre tu apprends les concepts et comment tu les apprends sont aussi super important. Il y a certainement des combinaisons qui ne marchent pas bien, si tu essayes de suivre une methode "object first" en assembleur, ca va probablement mal se passer. Ca veut pas dire que commencer par assembleur c'est pas possible, c'est juste que la methode pedagogique n'est pas coherente en interne. Mais si tu enseigne une methode "electro, transitor, senseur" en assembleur, il y a des tonnes de programmes qui sont construit comme ca et qui se passe bien. Mais si tu essaye d'enseigner la meme methode "electro, transitor, senseur" en octave, c'est probablement pas une bonne idee.

On voit beaucoup sur les forums cette idee qu'il y a de bon langage pour commencer et de mauvais langage pour commencer. En vrai il faut regarder plus largement que juste le langage et regarder la coherence de l'approche pedagogique dans son ensemble.

Topic intéressant, merci Godrik pour la réponse

En fait de mon côté (c'est à dire que j'ai absolument jamais développé sur des vrais projets mais que je connais normalement pas trop mal les concepts), j'ai l'impression que l'impératif ça reste "la base" et que les autres paradigmes sont comme des "surcouches" ou des "méthodes" y'a toujours de l'impératif au fond.

je dis pas ça pejorativement, pas du tout, mais du coup ça me paraissait logique de commencer par là.
Après je suis très certainement influencé par le fait que c'est comme ça que j'ai appris.