On est pas vendredi, mais remplacer du shell par du caml ... mis à part des améliorations purement techniques de performances, je ne comprend pas l'intérêt syntaxique
Le but est d'aboutir à une meilleur gestion des erreurs. Le shell est très efficace pour écrire des prototypes. Dans mon poste actuel, j'ai codé un environnement de test unitaires, des outils d'intégration continue et de déploiement, des outils de maintenance de serveur, de configuration de serveur, ... en quelques semaines à peine, en shell.
Mais ces programmes ne sont que des prototypes, qui mériteraient des versions plus robustes.
Pour l'approche monadique je pensais plutôt à l'autre côté: la description de la tâche et sa supervision plutôt que l'IO. Ce que je vais essayer dans les prochains jours c'est de programmer une monade dans laquelle on peut définir une commande complexe et faire tout le pipe-fitting qu'on veut, définir les options de supervision, etc.
Après, pour la monade, oui, c'est une solution élégante, mais en OCaml, on ne peut pas garantir la pureté des fonctions, du coup, des méthodes de type « retry » et autres pourraient avoir des comportements étranges ... (si on ne fait pas attention)
Quand on crée et efface des fichiers, qu'on compile des programmes ou qu'on installe des paquets sur un serveur, on est intéressé essentiellement par les effets de bord, et aucun langage ne va magiquement rendre le retry facile à implémenter!
[^] # Re: Gestion des erreurs
Posté par Michaël (site web personnel) . En réponse au journal chaintools, outils unix avec syntaxe pythonique. Évalué à 3.
Le but est d'aboutir à une meilleur gestion des erreurs. Le shell est très efficace pour écrire des prototypes. Dans mon poste actuel, j'ai codé un environnement de test unitaires, des outils d'intégration continue et de déploiement, des outils de maintenance de serveur, de configuration de serveur, ... en quelques semaines à peine, en shell.
Mais ces programmes ne sont que des prototypes, qui mériteraient des versions plus robustes.
Pour l'approche monadique je pensais plutôt à l'autre côté: la description de la tâche et sa supervision plutôt que l'IO. Ce que je vais essayer dans les prochains jours c'est de programmer une monade dans laquelle on peut définir une commande complexe et faire tout le pipe-fitting qu'on veut, définir les options de supervision, etc.
Quand on crée et efface des fichiers, qu'on compile des programmes ou qu'on installe des paquets sur un serveur, on est intéressé essentiellement par les effets de bord, et aucun langage ne va magiquement rendre le retry facile à implémenter!