Dans l'absolu, ce n’est pas une mauvaise pratique de mettre les signatures car, pour moi au moins, elles font partie de la documentation.
Cependant, selon le code sur lequel l’on travaille et pendant la phase « brouillon » du code, mettre systématiquement des signatures reviendrait à toujours rouler sur un vélo la tête dans le guidon. En effet, les besoins immédiats ont tendance à faire écrire des signatures (et implémentations) mono-morphiques même là où cela ne comporte aucun avantage. Et plus tard, par exemple, il n’est pas rare de se rendre compte que des implémentations « obtuses » respectivement de type Foo et Bar ont beaucoup de ressemblances ; on se mettra alors à faire du refactoring a posteriori alors qu’il aurait été inutile si l’on avait écrit une implémentation plus générale du premier coup. Il y a d’autres cas plus gênants, voire limitants, qui peuvent arriver quand on met systématiquement les signatures mais c’est presque toujours lors d’usages avancés de Haskell (donc à un stade où l’on n'a plus besoin des recommandations d’un quidam sur DLFP).
En gros, je trouve plus efficace de se défaire des signatures pendant la phase « brouillon » du cycle de vie d’un code et de les mettre au moment où le code passe en mode release. Mes 2$.
[^] # Re: Oui mais
Posté par gipoisson . En réponse au journal Non, l'inférence de types n'est pas du typage faible. Oui, elle rend les programmes plus lisibles. Évalué à 5. Dernière modification le 21 novembre 2018 à 23:10.
Dans l'absolu, ce n’est pas une mauvaise pratique de mettre les signatures car, pour moi au moins, elles font partie de la documentation.
Cependant, selon le code sur lequel l’on travaille et pendant la phase « brouillon » du code, mettre systématiquement des signatures reviendrait à toujours rouler sur un vélo la tête dans le guidon. En effet, les besoins immédiats ont tendance à faire écrire des signatures (et implémentations) mono-morphiques même là où cela ne comporte aucun avantage. Et plus tard, par exemple, il n’est pas rare de se rendre compte que des implémentations « obtuses » respectivement de type
FooetBaront beaucoup de ressemblances ; on se mettra alors à faire du refactoring a posteriori alors qu’il aurait été inutile si l’on avait écrit une implémentation plus générale du premier coup. Il y a d’autres cas plus gênants, voire limitants, qui peuvent arriver quand on met systématiquement les signatures mais c’est presque toujours lors d’usages avancés de Haskell (donc à un stade où l’on n'a plus besoin des recommandations d’un quidam sur DLFP).En gros, je trouve plus efficace de se défaire des signatures pendant la phase « brouillon » du cycle de vie d’un code et de les mettre au moment où le code passe en mode release. Mes 2$.