Merci beaucoup pour ce retour, il me donne pas mal d’idées pour la suite ! Avec le commentaire précédent, je comprends qu’il manque sans doute un texte d’introduction, entre préambule et FAQ, pour présenter le projet, le corpus, le choix de Haskell et les prérequis.
Ces choix viennent en partie de mon parcours : je collectionne les jeux vidéo depuis plus de 20 ans, j’adore les jeux FromSoftware et j’ai toujours aimé le bas niveau, de l’assembleur au VHDL en passant par la Game Boy. Haskell se trouve un peu au croisement de tout cela : j’aime son système de types, la composition des fonctions et la façon dont on peut y construire des parseurs. Ce n’est pas forcément « le meilleur langage » pour la rétro-ingénierie, mais c’est celui que j’ai envie d’approfondir. L’introduction sera justement l’occasion d’expliquer ce choix et les alternatives possibles.
Je suis très content que le code t’ait paru lisible sans pratiquer (pour le moment :p) Haskell. :-) Je comprends aussi ta remarque sur les commentaires : je me suis beaucoup appuyé sur les explications autour du code et sur les signatures des fonctions, mais cela ne suffit pas toujours à faire comprendre leur rôle ni les raisons du découpage. Ajouter quelques commentaires directement aux endroits importants permettrait de mieux relier le code au raisonnement de l’article, sans pour autant le surcharger.
Pour ECMA-119, je ne cherche pas à couvrir toute la norme ni à garantir la conformité de toutes les images. J’applique plutôt un design par soustraction : implémenter le minimum nécessaire pour atteindre un objectif précis. Les références normatives permettent ensuite à ceux qui le souhaitent de partir du code pour aller plus loin. Une structure qui sort du sous-ensemble reconnu devra simplement être signalée comme absente, incorrecte ou non prise en charge. Mais je prends en compte cette remarque :-)
Nous sommes également d’accord sur les fixtures et l’intégration continue. Je compte développer le projet en TDD, car les tests peuvent aussi servir de documentation exécutable de l’API. Les parties générales pourront ainsi utiliser des données libres ou synthétiques que chacun pourra rejouer dans la CI.
Merci aussi d’avoir soulevé la question juridique. Je n’ai aucune intention de diffuser du contenu protégé et je veillerai à respecter le cadre applicable, mais je n’ai pas encore suffisamment approfondi cet aspect pour en dire davantage.
Merci encore pour toutes ces pistes. Je comprends qu’il ne manque pas forcément plus de contenu au premier article, mais plutôt une vraie porte d’entrée avant de mettre les mains dans le cambouis. :-)
[^] # Re: intro
Posté par s[e]th & h[o]lth (site web personnel) . En réponse au journal D’une image nommée .iso à un premier probe en Haskell. Évalué à 2 (+1/-0).
Merci beaucoup pour ce retour, il me donne pas mal d’idées pour la suite ! Avec le commentaire précédent, je comprends qu’il manque sans doute un texte d’introduction, entre préambule et FAQ, pour présenter le projet, le corpus, le choix de Haskell et les prérequis.
Ces choix viennent en partie de mon parcours : je collectionne les jeux vidéo depuis plus de 20 ans, j’adore les jeux FromSoftware et j’ai toujours aimé le bas niveau, de l’assembleur au VHDL en passant par la Game Boy. Haskell se trouve un peu au croisement de tout cela : j’aime son système de types, la composition des fonctions et la façon dont on peut y construire des parseurs. Ce n’est pas forcément « le meilleur langage » pour la rétro-ingénierie, mais c’est celui que j’ai envie d’approfondir. L’introduction sera justement l’occasion d’expliquer ce choix et les alternatives possibles.
Je suis très content que le code t’ait paru lisible sans pratiquer (pour le moment :p) Haskell. :-) Je comprends aussi ta remarque sur les commentaires : je me suis beaucoup appuyé sur les explications autour du code et sur les signatures des fonctions, mais cela ne suffit pas toujours à faire comprendre leur rôle ni les raisons du découpage. Ajouter quelques commentaires directement aux endroits importants permettrait de mieux relier le code au raisonnement de l’article, sans pour autant le surcharger.
Pour ECMA-119, je ne cherche pas à couvrir toute la norme ni à garantir la conformité de toutes les images. J’applique plutôt un design par soustraction : implémenter le minimum nécessaire pour atteindre un objectif précis. Les références normatives permettent ensuite à ceux qui le souhaitent de partir du code pour aller plus loin. Une structure qui sort du sous-ensemble reconnu devra simplement être signalée comme absente, incorrecte ou non prise en charge. Mais je prends en compte cette remarque :-)
Nous sommes également d’accord sur les fixtures et l’intégration continue. Je compte développer le projet en TDD, car les tests peuvent aussi servir de documentation exécutable de l’API. Les parties générales pourront ainsi utiliser des données libres ou synthétiques que chacun pourra rejouer dans la CI.
Merci aussi d’avoir soulevé la question juridique. Je n’ai aucune intention de diffuser du contenu protégé et je veillerai à respecter le cadre applicable, mais je n’ai pas encore suffisamment approfondi cet aspect pour en dire davantage.
Merci encore pour toutes ces pistes. Je comprends qu’il ne manque pas forcément plus de contenu au premier article, mais plutôt une vraie porte d’entrée avant de mettre les mains dans le cambouis. :-)