Posté par gasche .
En réponse au journal Après le MOOC OCaml.
Évalué à 4.
Dernière modification le 30 décembre 2016 à 01:57.
Qu'est-ce qui empêcherait de reproduire cet effort pour y ajouter l'outil de build ? Le support financier de JaneStreet ? Un consensus technique ?
Ce n'est pas clair, pour moi, que l'outil de build soit la source du problème. En supposant par exemple que OASIS permette de faire parfaitement abstraction du build (ce qui est au moins vrai pour les programmes "simples" que peuvent écrire les débutants qui découvrent le langage), il te reste à faire au moins un _oasis, un opam et un .merlin pour te lancer dans ton projet, et sans doute (ce n'est pas forcément indispensable) un Makefile par-dessus tout ça.
Il y a des langages qui ont un système monolithique qui fait tout : l'installation des dépendances, la configuration, le build, la discussion avec les IDEs, le packaging, etc. Mais d'une part, ça fait un goulot d'étranglement sur le langage (plus difficile d'étudier des alternatives etc.), d'autre part en suivant le principe Unix on aurait envie de comprendre comment découper ce mastodonte en des outils plus simples et indépendants, qui collaborent de façon flexible mais sans ajouter trop de complexité. Mais quelles frontières tracer, comment partager les responsabilités ? Aujourd'hui on n'a sans doute pas trouvé les bons contours en OCaml, parce que le mélange ajoute trop de complexité.
[^] # Re: Sympa
Posté par gasche . En réponse au journal Après le MOOC OCaml. Évalué à 4. Dernière modification le 30 décembre 2016 à 01:57.
Ce n'est pas clair, pour moi, que l'outil de build soit la source du problème. En supposant par exemple que OASIS permette de faire parfaitement abstraction du build (ce qui est au moins vrai pour les programmes "simples" que peuvent écrire les débutants qui découvrent le langage), il te reste à faire au moins un
_oasis, unopamet un.merlinpour te lancer dans ton projet, et sans doute (ce n'est pas forcément indispensable) unMakefilepar-dessus tout ça.Il y a des langages qui ont un système monolithique qui fait tout : l'installation des dépendances, la configuration, le build, la discussion avec les IDEs, le packaging, etc. Mais d'une part, ça fait un goulot d'étranglement sur le langage (plus difficile d'étudier des alternatives etc.), d'autre part en suivant le principe Unix on aurait envie de comprendre comment découper ce mastodonte en des outils plus simples et indépendants, qui collaborent de façon flexible mais sans ajouter trop de complexité. Mais quelles frontières tracer, comment partager les responsabilités ? Aujourd'hui on n'a sans doute pas trouvé les bons contours en OCaml, parce que le mélange ajoute trop de complexité.
Edward Yang, un membre actif de la communauté Haskell, s'est aussi intéressé à cette question dans son billet The convergence of compilers, build systems and package managers.