Journal Après le MOOC OCaml

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
11
28
déc.
2016

J’ai participé au MOOC Ocaml qui s’est terminé le 18 décembre 2016. Tous les exercices du MOOC Ocaml pouvaient être faits dans un environnement du type de celui de Try OCaml

Pour continuer d’apprendre OCaml et développer des projets en Ocaml sur son poste, il faut se frotter aux outils gravitant autour du langage Ocaml, principalement ceux de build.

Dans ce journal je parlerais de la solution qui me semble la plus simple pour démarrer un projet OCaml et ensuite des autres outils que j’ai testés.

Prélude

Les essais ont été faits sur une Debian stable.

L’exemple d’application que je souhaite compiler est de la forme suivante:

src
├── main.ml
└── utils.ml
  • main utilise utils et utils utilise une lib externe.
  • la lib externe est installée avec opam.

OCaml et Opam

OPAM (OCaml Package Manager) est à la fois le dépôt de paquets OCaml et l’outil en ligne de commande pour les gérer.

Opam sait aussi gérer l’installation de plusieurs versions d’Ocaml.

On l’installe avec le gestionnaire de paquet :

apt install opam

Cela installe aussi Ocaml qui est une dépendance d’Opam.

On peut passer à une version plus récente d’OCaml avec :

opam switch 4.03.0

Note aux utilisateurs de fish : opam init ne fonctionne pas avec fish, les scripts sont corrigés, mais il n’y a pas eu de release d’Opam depuis, voir #2255

Outils

Il existe un paquet starterkit qui facilite l’installation d’un grand nombre d’outils de développement OCaml, on l’installe avec :

opam install starterkit

C’est un meta-paquet qui installe les paquets suivants : lambda-term, ocp-indent, stringext, utop, ocp-index, merlin, ocamlfind, oasis, ocamlbuild.

Démarrer un projet

On démarre un projet géré par Oasis en créant un fichier _oasis, exemple ci-dessous:

OASISFormat: 0.4
BuildTools: ocamlbuild
Plugins: META (0.4), DevFiles (0.4)
Name:        prog
License: MIT
Authors: xxx
Synopsis: yyy
Version:     1.1.0
Executable prog
  Path:       src
  MainIs:     main.ml
  CompiledObject: best
  BuildDepends: 
    pcre

Le projet est ensuite initialisé avec la commande :

oasis setup -setup-update dynamic

Le projet se compile alors en lançant make

Le démarrage et la gestion d’un projet avec Oasis est simple et semble assez standard.

Il manque malgré tout la génération des fichiers pour opam avec l’intégration d’oasis2opam et la génération du fichier .merlin pour Merlin.

Autres tests

ocamlbuild

On peut aussi utiliser directement ocamlbuild en suivant les exemples pour écrire un fichier _tags et un Makefile personnalisés.

ocp-build

Il faut créer un fichier en .ocp dont la syntaxe est relativement simple.

Le projet s’initialise et se compile avec les commandes suivantes:

ocp-build init
ocp-build build

Il ne génère pas plus de fichier qu’Oasis et nécessite de déclarer tous ses fichiers.

Voir ocp-build, a build system for OCaml applications

topkg & carcass

Je n’ai pas réussi à installer carcass qui est un outil pour créer des canvas d’application compilé par topkg.

Voir topkg

Solvuu-build

solvuu-build semblait prometteur, mais je n’ai pas réussi à le faire fonctionner.

Conclusion

Merci à l’auteur de starterkit qui est aussi l’auteur de l’article So you're learning OCaml! écrit à l’occasion du premier MOOC OCaml en 2015.

Cet article a été repris sur le site ocaml.org sous le titre Crash course on the OCaml ecosystem

Et vous ? Débutant dans ce langage ou non, comment abordez-vous le développement avec OCaml et son écosystème ?

  • # Sympa

    Posté par  . Évalué à 4.

    Merci pour ton journal (et désolé pour le plombage de moral dans la dépêche). Je ne connaissais pas starterkit, c'est un bon conseil à donner aux débutants, et sa doc est agréable pour se lancer aussi.

    Pour répondre à ta question, moi je suis un vieux OCamleux donc j'ai grandi avec les choses d'avants et je me mets aux nouveaux trucs seulement petit à petit. En général pour un nouveau projet je me fais un .merlin et opam à la main (pro tip pour installer les dépendances d'un projet qui vient avec son opam local: opam pin leprojet . --no-action ; opam install --deps-only leprojet), et j'écris mon propre Makefile qui appelle OCamlbuild en dessus.

    Les gens plus modernes commencent avec OASIS directement, et c'est un chouette outil, mais j'ai toujours un peu peur d'avoir à travers trois niveaux d'abstractions: make (pour diriger la fête, par habitude et convention), oasis derrière, et enfin ocamlbuild (ou omake pour les gens qui préfèrent).

    Un truc dont je suis bien conscient et, je pense, tout le monde dans la communauté OCaml, c'est que ce n'est pas vraiment agréable comme expérience pour les débutants. Pour chaque besoin il y a trois outils différents, aucun qui ne fait vraiment le consensus (à part opam pour le package management), et des couches de trucs les uns par-dessus les autres. Tout le monde essaie d'améliorer ça et de rendre l'environnement plus agréable pour les nouveaux (et pour les autres aussi), mais ça demande un travail énorme, vraiment considérable, de progresser juste un peu là-dessus. On ne s'en rend pas forcément compte de l'extérieur mais, de base, créer des outils agréables c'est vraiment difficile, et en plus, créer des outils agréables et qui s'intègrent bien à l'existant que les habitués connaissent déjà, c'est encore plus dur.

    (Je comprends les gens de Reason qui ont décidé de repartir de zéro au niveau de l'écosystème, même si je pense qu'un effort équivalent pour travailler avec les gens existants peut avoir au final plus d'impact.)

    • [^] # Re: Sympa

      Posté par  . Évalué à 1. Dernière modification le 29 décembre 2016 à 10:57.

      Un truc dont je suis bien conscient et, je pense, tout le monde dans la communauté OCaml, c'est que ce n'est pas vraiment agréable comme expérience pour les débutants.

      Pas plus que d'utiliser gcc ou clang avec un makefile et les autotools. Je pense que ce qui est le plus pénible pour un débutant c'est la librairie standard : d'un côté elle existe et répond à certain besoins, d'un autre côté elle est assez mal faite. Le problème, c'est qu'elle n'est pas assez mal faite pour l'abandonner totalement, parce qu'elle répond au moins partiellement à certaines attentes basiques. Un choix plus raisonnable aurait été de ne pas avoir de librairie standard du tout (pas de Map, HashMap, etc …).

      Ici, le développeur qui vient d'un langage avec une lib correcte (comme python pour citer le lien so you're learning ocaml) se retrouve avec une lib bancale, et soit recode ses fonctions à la main dans un fichier perso qu'il trimballe du genre utils.ml (ce que je fais pour le moment), soit il apprend une autre librairie standard, avec ses conventions. Le problème c'est que dans tous les cas, il y a un choix (Core vs Batteries vs truc perso) et que le code devient moins « portable » : quand on arrive sur un truc basique qui devient dur à comprendre parce qu'on ne connait pas la lib, et bah c'est lourd. À la fin, un mec qui lit du code finira par connaître les habitudes des gens qui écrivent leurs propres fonctions, Core et Batteries.

      Un deuxième point est la syntaxe qui est parfois très pénible, notamment la priorité des opérateurs, en particulier du if qui est super chiant. Et le fait d'utiliser des begin ... end pour corriger toutes les priorités alors que les constructions standard pourraient facilement l'éviter.

      • [^] # Re: Sympa

        Posté par  . Évalué à 5.

        Pas plus que d'utiliser gcc ou clang avec un makefile et les autotools.

        Je dirais que justement, c'est bien ça le problème.

        Le fonctionnement du compilateur OCaml a été calqué sur celui des compilateurs C, donc des gens qui sont à l'aise avec C ne voient pas forcément le problème—mais la plupart des autres langages ont des outils plus agréables. Quand on est à l'aise avec autotools on n'est pas forcément représentatif de la population des développeurs et développeuses.

        • [^] # Re: Sympa

          Posté par  . Évalué à 1.

          En effet, pour reprendre un lien ajouté par Benoît Laurent dans un autre commentaire, voici ce qu'on lit ici

          A build system that is so obviously superior to the other alternatives that everyone switches to it instantly. Or a stdlib replacement/extension that is so obviously superior that everyone switches to it (ahah). Imho the big problem with the ecosystem is not really that it lacks critical features, it's more that everything is fragmented, incompatible, complicated to the beginner

          Cela rejoint mon expérience sur la librairie standard, et ajoute que le problème est exactement le même pour le système de build : le problème c'est que ça marche assez bien pour ne pas avoir envie de tout changer. Cela incite fortement les gens à construire des surcouches pour éviter d'avoir à casser l'existant (d'où les 3 niveau de build).

          Après, il faut faire attention avec les outils plus agréables, parce que la gestion des librairies c'est pas toujours super. Le système de type NPM/Hackage/OPAM incite à des évolutions rapides et potentiellement incompatibles qui font que parfois, il devient impossible de compiler un projet (en tout cas pour Haskell). De plus ce genre de système ne remplace pas un gestionnaire de paquets, et pourtant il est tentant d'utiliser OPAM comme seul moyen de distribution.

    • [^] # Re: Sympa

      Posté par  (site web personnel) . Évalué à 3.

      A l'époque où je faisais du Lisaac (que ceux qui s'en souviennent s'esclaffent une seconde), on avait énormément discuté de ces problèmes de make, d'autotools et de la boucle sans fin où on créé un outil pour générer la conf de l'outil précédent qui avait lui-même été écrit pour automatiser son précédent…

      Le produit de nos cogitations nous avaient amené à créer le LIP (LIsaacProject) qui est une sorte de Lisaac simplifié (on avait pas de tableaux si je me souviens bien) pour gérer des projets.
      Il y avait toutes les primitives qu'il fallait pour chercher des fichiers, des paths, des version de librairie, des dépendances, etc…

      Je pense que ça serait pas bête de faire ça en OCaml : il y a tout ce qu'il faut pour faire un interpréteur (avec ocamlrun), il n'y a qu'à (YaKaFoKon) implem une lib pour de la gestion de projet, tout est écris en ocaml, et zou on ferait un 

      ocamlopt -build myProject.mlp

      Ça serait tellement plus simple…

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Sympa

        Posté par  . Évalué à 2.

        Des choses comme ça ont quand même été bien explorées : ocamlbuild se configure en OCaml (mais pas seulement) et apporte des concepts pour décrire le build, solvuu repose sur ocamlbuild mais la description de projet se fait totalement en OCaml, et omake est justement un outil de build avec son langage à part.

        Tu parles de ocamlopt -build ..., mais ça suppose faire rentrer une notion de "build" complexe dans le compilateur, qui aujourd'hui ne fait que des builds simples, de supposer qu'il va distinguer ce qui a déjà été buildé et ce qu'il faut rebuilder, etc. C'est une possibilité, et ça pourrait simplifier beaucoup les choses (en limitant les "couches" différentes), mais pour l'instant les gens ont toujours voulu garder la séparation des responsabilités, et avoir un outil de build séparé du compilateur.

    • [^] # Re: Sympa

      Posté par  (site web personnel) . Évalué à 3.

      Un truc dont je suis bien conscient et, je pense, tout le monde dans la communauté OCaml, c'est que ce n'est pas vraiment agréable comme expérience pour les débutants.

      Oui ça n'est pas facile, mais ça ne me choque pas pour un langage de cet age.

      Par contre les langages les plus récents mettent la barre assez haut maintenant, notamment Rust avec Cargo.

      Opam est une réussite et à l'air de faire l'unanimité. 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 ?

      Merci à tous pour vos retours d'expériences et vos astuces.

      • [^] # Re: Sympa

        Posté par  . É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é.

        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.

      • [^] # Re: Sympa

        Posté par  . Évalué à 4.

        Par ailleurs, un truc à garder en tête en regardant Cargo par exemple (ou la commande go), c'est que ça propose une expérience plus agréable en enlevant souvent des fonctionnalités. Par exemple, faire du préprocessing de sources Rust avec Cargo, c'est très difficile.

        La communauté compense en mettant le plus de méta-programmation possible directement dans le langage, ce qui est une bonne chose pour certaines fonctionnalités (les macros propres, c'est utile et puissant, les tests unitaires bien intégrés, etc.) mais reste beaucoup moins flexible qu'un langage utilisant un outil de build "généraliste" (qui permet de rajouter des règles localement) comme Make ou ocamlbuild.

        Par exemple, je ne crois pas qu'il y ait un générateur de parseur en Rust qui s'intègre bien avec le système de Build. lalrop recode la gestion des timestamps etc. de son côté, et copie les fichiers générés dans le répertoire de développement.

        Ça va sûrement s'améliorer avec le temps, mais il faut aussi voir que l'approche monolithique a aussi des coûts qu'on ne voit pas forcément tout de suite.

  • # Qualité du-dit MOOC

    Posté par  . Évalué à 2.

    Bonjour,
    J'ai moi aussi suivi ce MOOC, presque jusqu'à la fin, et je suis, dirai-je poliment, très réservé sur sa qualité. Étant donné que tu as l'air plus enthousiaste que moi, je me demandais ce que tu (ou d'autres personnes l'ayant suivi) en pensait. Ce que tu y as apprécié, ou contraire ce qui t'as rebuté.

    • [^] # Re: Qualité du-dit MOOC

      Posté par  (site web personnel) . Évalué à 4.

      Ça faisait longtemps que je voulais essayer OCaml, ça m'en a donné la possibilité et m'a forcé à maintenir mon l’intérêt sur plusieurs semaines. J'espère avoir passé un premier cap où il me serra plus facile de m'y remettre.

      J'ai aimé l'environnement et ainsi pouvoir continuer sur plusieurs machines sans installer quoi que ce soit. Les supports sont bien.

      On sent un certain style universitaire dans les choix d'exercice et d'énoncé, j'ai d'ailleurs trouvé ceux-ci plusieurs fois incomplet ou difficilement compréhensible, les messages laissés dans les forums mon parfois débloqué, merci à ceux qui ont en laissé.

      Après 3 ou 4 semaines j'ai réduit ma participation par manque de temps/fatigue j'ai alors joué sur la notation et n'ai pas cherché à tout finir.

      Note que c'était le premier MOOC auquel je participais.

      • [^] # Re: Qualité du-dit MOOC

        Posté par  . Évalué à 2.

        De manière amusante, ma situation est très proche de la tienne : ça faisait longtemps que je voulais essayer OCaml, ça m'en a donné la possibilité et m'a forcé à maintenir mon l’intérêt sur plusieurs semaines. Et c'était mon premier MOOC. ;)

        Après, j'ai profondément détesté l'environnement. Pour le reste, je te rejoint globalement, plutôt universitaire, exercices parfois (trop souvent) difficilement compréhensibles. Je rajouterai juste une mésestimation du temps nécessaire, d'où un retard progressif, ce qui finalement fait que je n'ai pas touché au projet.

        Reste que mon ressenti final est plutôt négatif (alors que tu te focalise plus sur le bon côté—c'est une bonne philosophie), et que je finis plutôt déçu par ce MOOC (et par OCaml, un peu par ricochet).

    • [^] # Re: Qualité du-dit MOOC

      Posté par  . Évalué à 3.

      Je connais les gens qui ont conçus le MOOC et je serait content de leur faire un retour utile sur ce qui t'a posé problème, si tu ne l'as pas déjà fait par d'autres canaux. N'hésite pas à donner plus de détails en réponse ou à m'envoyer un mail si tu préfères (gasche dot dylc chez gmail).

      • [^] # Re: Qualité du-dit MOOC

        Posté par  . Évalué à 3.

        Je leur est fait un (très) long retour détaillé dans le formulaire dédié.

        En substance, les problèmes sont liés aux exercices qui sont parfois très compliqués (ne serait-ce que comprendre l'énoncé de certain), un manque de détail sur la récurrence, des outils en ligne très désagréables (l'éditeur de texte qui bouge la position du curseur comme bon lui chante, l'absence d'annuler (Ctrl-Z) sur plus de quelques modifications, le clic milieu qui ne marche pas…), et la troisième semaine (je n'ai littéralement rien retenu de cette semaine, dédiée aux types récursifs et aux structures en arbre — une semaine et demi après avoir vu la récurrence, c'est violent).

    • [^] # Re: Qualité du-dit MOOC

      Posté par  (site web personnel) . Évalué à 2.

      J'avais résumé mon retour d'expérience sur ce fil :
      http://linuxfr.org/nodes/110032/comments/1681475
      Je le copie/colle

      Suite à ce billet, je me suis inscrit à ce MOOC OCaml 2016 qui touche à sa fin en ce qui me concerne.

      J'ai trouvé cela très intéressant (sachant que je fais de la programmation comme loisir, je ne suis pas très averti et j'ignorais tout de la programmation fonctionnelle). Donc je ne regrette pas cet effort (qui pour moi a représenté entre trois et huit heures suivant les semaines).

      Par contre, j'ai été assez frustré par le manque de retours de l'équipe pédagogique dans les forums associés. J'ai suivi d'autres MOOC sur edX ou Coursera où les échanges étaient bien plus nombreux et instructifs.

      Ils ont fait le choix de laisser les inscriptions ouvertes jusqu'à la fin de la session (ce qui est louable) et il n'y a donc pas de date limite hebdomadaire pour les exercices. La contrepartie, c'est qu'il n'y a donc pas de corrigés officiels publiés au fur et à mesure de l'avancement. Même si j'ai obtenu des scores honorables, j'aurais vraiment apprécié de voir ensuite une approche éventuellement différente et plus fonctionnnelle. En plus, ça paralyse un peu les échanges entre étudiants tant la crainte est grande de spoiler les exercices.

      Pratiquement, j'ai réussi à peu près tous les exercices hebdomadaires mais j'ai échoué à achever les problèmes de fin de session.

      Et je ne vais pas immédiatement aller plus loin sur ce langage.

  • # Liens supplémentaires

    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 29 décembre 2016 à 22:13.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.