Programmation

N.B : Ce billet est largement inspiré de l’article de John Hugues : Why functional programming matters.

Madame la Marquise m’a foutu les morpions…
Dans un précédent billet, je promettais une courte série sur une A.I. simple et modulaire pour jeux de plateaux, sous la forme d’un hommage aux morpions. Cette A.I. met à profit les possibilités de composition de fonctions et d’évaluation paresseuse introduites dans les précédents billets.

Un plateau de morpions ...

Les joies de la procrastination
Je voudrais introduire ici l’évaluation paresseuse (« lazy evaluation ») caractéristique de certains langages fonctionnels, au premier rang desquels Haskell, qui faisait l’objet des deux précédents billets (1 2). Elle consiste, en deux mots, à reporter l’évaluation d’une valeur au moment où elle est devenue nécessaire.

L’évaluation paresseuse n’est pas l’apanage des langages fonctionnels –bon nombre d’entre eux reposent d’ailleurs au contraire ...

L’imagination au pouvoir
L’Origami, art du pliage, permet de transformer une simple feuille en une grue, un canard ou un brontosaure –art poétique, donc, qui fait émerger de la virginité d’une page un monstre depuis longtemps disparu ou le vol d’un oiseau. Peut-être que notre activité –à nous autres programmeurs- n’a pas pour le grand public l’attrait oriental de cette discipline épurée et pourtant ! ne consiste-t-elle pas à faire émerger du chaos d’interminables séquences de bits des structures ...

- vous prendrez bien une petite cuillère de Haskell ?
Dans le précédent billet, j’ai utilisé LISP pour montrer ce que pouvait être une approche bottom-up fondée sur la modularité qu’apporte la composition de fonction. Pourtant, LISP n’est pas –et de loin- le langage qui favorise le plus cette approche. Dans ce billet et le suivant, je voudrais introduire certaines tournures syntaxiques des langages plus fonctionnels –j’utiliserai Haskell, mais vous pourriez trouver des choses équivalentes ...

Une question de cartes
Dans son billet Misères de l’analyse objet, un cas pratique, François (j’ai décidé une bonne fois pour toute de l’appeler par son prénom) montre les travers d’une approche objet naïve qui tenterait de refléter le réel dans les classes du programme. Elle mène à un code difficile à factoriser et difficile à maintenir. Le billet montre comment raffiner le concept initial, de façon itérative, jusqu’à arriver à la représentation adaptée au meilleur algorithme. François en ...