Note que cette facilité s'accompagne d'une démonstration de ton code
Que le code soit impératif en python ou bien utilise des concepts plus avancés, il faut toujours expliquer ce qu'il fait non ? Ne serait-ce que parce que les gens qui le lisent ne sont pas forcément bien concentrés, ou juste pour éviter toute ambigüité possible sur le sens de ce qui est écrit.
En python, j'aurais donné certainement des explications très similaires, pour un code qui ferait la chose suivante :
Construire une matrice de la bonne taille initialisée à None
Définir les valeurs connues dans la matrice
Faire une ou plusieurs boucles (ici deux) pour remplir la matrice en utilisant une récurrence dont on doit prouver qu'elle n'utilisera jamais des valeurs non initialisées (ie: on ne tombe pas sur None).
Dans ce cas, la démonstration est la même en haskell si on résume de la même manière :
Construire une matrice de la bonne taille initialisée avec les fonctions de calculs
Définir la fonction de calcul d'une case en fonction des valeurs du tableau
Prouver que les valeurs utilisées pour calculer une case n'ont pas de dépendances cycliques, ce qui correspond à donner un ordre d’initialisation valide en python
La grosse différence est qu'une fois qu'on a une preuve, les détails de l'implémentation ne sont pas présents en haskell. Par exemple, on peut vouloir remplir la matrice diagonale par diagonale. Pour ce faire, il faut réfléchir à comment on fait les diagonales, ne pas se tromper sur les indices, bien parcourir tout le monde etc ... Alors que c'est totalement inutile en haskell. Et cela est d'autant plus vrai que la dimension du tableau augmente, et donc que les procédures de calculs font intervenir de plus en plus de boucles imbriquées avec des invariants de plus en plus complexes.
[^] # Re: Programmation Dynamique
Posté par Aluminium95 . En réponse au journal Haskell -- Évaluation paresseuse. Évalué à 3.
Que le code soit impératif en python ou bien utilise des concepts plus avancés, il faut toujours expliquer ce qu'il fait non ? Ne serait-ce que parce que les gens qui le lisent ne sont pas forcément bien concentrés, ou juste pour éviter toute ambigüité possible sur le sens de ce qui est écrit.
En python, j'aurais donné certainement des explications très similaires, pour un code qui ferait la chose suivante :
NoneNone).Dans ce cas, la démonstration est la même en haskell si on résume de la même manière :
La grosse différence est qu'une fois qu'on a une preuve, les détails de l'implémentation ne sont pas présents en haskell. Par exemple, on peut vouloir remplir la matrice diagonale par diagonale. Pour ce faire, il faut réfléchir à comment on fait les diagonales, ne pas se tromper sur les indices, bien parcourir tout le monde etc ... Alors que c'est totalement inutile en haskell. Et cela est d'autant plus vrai que la dimension du tableau augmente, et donc que les procédures de calculs font intervenir de plus en plus de boucles imbriquées avec des invariants de plus en plus complexes.