Admettre que la programmation fonctionnelle peut être maladroite

Mon intérêt initial pour la programmation fonctionnelle était parce qu’elle semblait si perverse.

À l’époque, j’étais le programmeur autodidacte classique, ayant appris le BASIC puis le langage assembleur 6502 afin de pouvoir implémenter mes propres conceptions de jeux. J’ai pris le numéro d’août 1985 du magazine Byte pour en savoir plus sur le nouvel Amiga de l’époque. C’était aussi le numéro sur les langages déclaratifs, avec une réimpression de la célèbre

Tout cela était assez fou pour un codeur de jeu Atari 800 à lire. J’ai compris certaines parties, complètement raté de vastes pans d’autres, mais un point clé a attiré mon imagination : la programmation sans variables modifiables. Comment cela pourrait-il fonctionner ? Je ne pouvais même pas écrire le plus petit jeu sans stocker des valeurs en mémoire. Cela me plaisait pour son impossibilité, de la même manière que j’avais entendu dire que le langage machine était trop difficile à aborder pour la plupart des gens. Mais alors que je m’étais penché sur les listes de jeux en langage assembleur dans les magazines et que j’avais appris à écrire le mien en conséquence, il n’y avait pas une telle applicabilité directe pour la programmation fonctionnelle. Cela m’a fait réfléchir, mais je ne l’ai pas utilisé.

De nombreuses années plus tard, lorsque j’ai travaillé pour la première fois sur des didacticiels pour Haskell, Standard ML et finalement Erlang, c’était pour comprendre comment la programmation sans modification de variables pouvait fonctionner. Dans le petit, c’est assez facile. Une grande partie de ce qui semblait étrange en 1985 était devenu banal : le ramasse-miettes, utilisant des structures de données complexes sans se soucier de la disposition de la mémoire, des langages avec beaucoup moins de comptabilité que C ou Pascal. Mais cette chose “pas de mises à jour destructrices” était - et est toujours - délicate.

Je suppose qu’il est tout à fait évident de souligner qu’il y a eu des dizaines de milliers de jeux vidéo écrits en utilisant un style de programmation impératif, et peut-être une poignée - peut-être même quelques doigts - de jeux écrits de manière purement fonctionnelle. Bien sûr, il y a eu des jeux écrits en Lisp et quelques jeux écrits par des dilettantes du langage friands d’Objective Caml, mais ils ne se sont jamais avérés être programmés dans un style fonctionnel. Vous pouvez écrire du code impératif dans ces langages assez facilement. Et la raison de s’engager dans cette voie est simple : il n’est pas du tout clair comment écrire de nombreux types d’applications complexes dans des langages fonctionnels.

Habituellement, je peux travailler sur les dépendances des données, et souvent je trouve qu’il y a une simplicité sous-jacente à l’approche fonctionnelle. Mais pour d’autres applications… eh bien, elles peuvent se transformer en énigmes. Là où je peux généralement parcourir une solution désordonnée en C, la
solution purement fonctionnelle m’échappe ou me demande un peu de perplexité. Dans ces cas, j’ai l’impression de lutter contre le système, et je comprends pourquoi c’est la route la moins fréquentée. Vous ne le croyez pas ? Vous pensez que la pureté fonctionnelle est toujours le chemin de la droiture ? Voici un exemple simple.

La suite  ici