• [^] # Re: go 2.0

    Posté par . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 1.

    Sur le fond, la réponse de gasche ci-dessus est suffisante : quand on documente une bibliothèque, on est obligé à faire des choix entre rester au niveau le plus général ou spécialiser (arbitrairement) la documentation.

    Je trouve que, pour une bibliothèque livrée avec le compilateur, spécialiser un concept général n'est pas optimal : on pourrait bien mettre du texte dans MonadIO expliquant comment dériver la classe pour créer des fonctions lisant/écrivant des fichiers sur le disque, mais quid des gens qui viendront lire la doc en ayant besoin de travailler plutôt avec des bases de données ? Serait-ce une adéquate utilisation de leur temps en les promenant sur des paragraphes ne traitant pas de leurs besoins ? La voie des tutoriels, conférences, et autres postes de blogs me paraît être la bonne dans ce cas.

    Par contre, quand les usages d'une bibliothèque sont presque totalement connus, illustrer la doc est tout à fait adéquat. Dans le cas des bibliothèques maintenues par GHC-HQ, on ne se prive pas de le faire.

    Ceci dit, il y a des contre-exemples de bibliothèques implémentant des concepts généralistes mais dont la doc est bourrée d'exemples pour quelques restrictions d'applications ; voir par exemple la fameuse lens.

    Et n'oublions pas que c'est du logiciel libre : je ne doute pas que tu as les compétences nécessaires pour rédiger un patch de la documentation que tu as potassée ; pourquoi ne pas contribuer ? Et ça tombe bien, l'outillage est en train d'être ripoliné pour faciliter les contributions.

    P.S. Pour maximiser le sous-hors-sujet Haskell dans un déjà hors-sujet Go, à propos des opérateurs qui seraient horribles comme tu l'écrivais ailleurs dans les commentaires: je trouve qu'utiliser une bibliothèque en explicitant tous les éléments qu'on en importe aide énormément à rendre le code intelligible même après des années d'abandon. Ceci vaut aussi pour Prelude. Concrètement :

    • Première itération d'écriture du code : mettre des import Foo dans l'en-tête, import Prelude comprise.
    • Deuxième itération: dire au compilateur de nous indiquer ce qu'on a utilisé, ghc -ddump-to-file -ddump-minimal-imports
    • Enfin, remplacer les imports manuels par ceux automatisés. Comme ça, des mois plus tard, quand on rencontrera un opérateur ésotérique, il suffira de voir où il se trouve dans l'en-tête et suivre la documentation du module correspondant.