Pourquoi j’aime OCaml (2023)

• Un développeur attaché à la programmation fonctionnelle et aux garanties statiques en vient à apprécier tout particulièrement la conception équilibrée d’OCaml après avoir pratiqué plusieurs langages
• Par rapport à Haskell, avec son système de types complexe et sa compilation lente, OCaml offre à la fois simplicité et pragmatisme
• Il rappelle Go par sa compilation rapide et son runtime épuré, tout en conservant les atouts d’un langage fonctionnel comme le pattern matching et les types somme
• Grâce à des builds rapides, des binaires statiques et de riches outils de documentation (odig, utop), il offre une bonne productivité et reste accessible
• Son principal attrait réside dans l’équilibre entre simplicité et expressivité, ainsi que dans une conception du langage particulièrement soignée

---

Expérience et comparaison des langages de programmation

• À partir de son expérience du développement de logiciels amateurs et professionnels dans divers langages, l’auteur dégage les caractéristiques d’un bon langage
  • Il met en avant comme critères importants la rapidité de compilation, un runtime simple, de fortes garanties statiques, des composants fonctionnels, de bonnes performances et la qualité de la documentation
• Haskell lui a appris la manière de penser propre à la programmation fonctionnelle, mais sa syntaxe complexe et sa compilation lente sont pointées comme des problèmes
  • La tendance de la communauté à rechercher la complexité et des problèmes d’exécution comme les space leaks rendent aussi la maintenance difficile
• Go permet simplicité, compilation rapide, bon outillage et compréhension aisée d’un code concis
  • Mais sa conception conservatrice, sa gestion verbeuse des erreurs et l’absence de vérification explicite de null le rendent peu confortable et augmentent le risque de bugs
  • L’absence de REPL et son attitude négative envers les idées fonctionnelles sont également citées comme des limites

Principaux points forts d’OCaml

• OCaml est présenté comme un langage qui remplit la plupart des critères ci-dessus
  • Fortes garanties statiques : prise en charge des types somme, des variantes polymorphes et du pattern matching
  • Runtime simple : utilise un garbage collector tout en fonctionnant comme un langage de niveau système
  • Compilation rapide : plus rapide que Haskell ou Rust grâce au système de build Dune
  • Génération d’un binaire unique lié statiquement, ce qui facilite le déploiement
  • Excellents outils de documentation : odig (navigation hors ligne dans la documentation), utop (REPL), et séparation entre fichiers d’interface et d’implémentation
• La déduction automatique des types améliore l’efficacité de l’écriture du code
  • La structure qui définit les types dans des fichiers d’interface aide à explorer le code plus clairement

Conception du langage et impression générale

• OCaml est un langage ancien, mais il conserve une grande élégance de conception
  • Certaines fonctionnalités orientées objet ou bibliothèques complexes sont jugées inutiles
• Globalement, l’équilibre entre simplicité et expressivité, ainsi qu’une bonne documentation et un bon écosystème d’outils, constituent les principaux attraits d’OCaml
• L’auteur fait l’éloge d’OCaml comme d’un « langage simple mais expressif » et évoque une satisfaction difficile à retrouver dans d’autres langages

[GN⁺]

Avis Hacker News

• J’ai un peu utilisé OCaml, et j’ai rencontré plusieurs problèmes
  Le support de Windows est médiocre, et ce n’est qu’avec OCaml 5 qu’il est devenu « simplement assez mauvais »
  La syntaxe est difficile à lire pour un humain, et en cas d’erreur de syntaxe, un seul caractère mal placé peut produire un message d’erreur de 1000 lignes
  Ocamlfmt transforme même des expressions match complexes en une seule ligne, ce qui nuit à la lisibilité
  La documentation est aussi excessivement concise, avec très peu d’exemples
  OPAM a l’air bien en théorie, mais en pratique il est plein de bugs, et il y a même eu un bug empêchant de trouver curl si l’on appartenait à plus de 32 groupes Unix
  Comme les annotations de type dans les signatures de fonctions sont facultatives, cela réduit les avantages du typage statique
  L’écosystème est aussi petit, et il n’y a même pas de fonction intégrée pour copier un fichier
  Cette obsession pour les listes simplement chaînées est également inefficace
  Malgré tout, c’est mieux que le C ou Python, mais je ne le choisirais probablement pas plutôt que Rust

  • Pour utiliser OCaml sous Windows, je recommanderais plutôt F#
    Comme il cible le CLR, le déploiement est bien plus simple, et on peut profiter directement de l’écosystème .NET
    On peut utiliser presque tel quel les bibliothèques NuGet pour C# ou VB.NET, donc l’écosystème est immense
    La documentation F# est bien plus riche et les exemples bien plus nombreux
    Liens utiles : Référence du langage F#, F# Core Docs, F# Cheatsheet
  • Je me demandais si le bug curl d’OPAM existait vraiment, alors j’ai vérifié, et il est bien confirmé dans l’issue #5373
    En réalité, c’est un problème lié à musl, causé par le fait qu’OPAM a été compilé avec ce binaire
  • La plupart des points relèvent de la courbe d’apprentissage, mais même une fois habitué, la fragmentation de l’écosystème reste réelle
    ocamlformat est bien meilleur avec le profil janestreet que dans sa configuration par défaut
    Le problème des annotations de type dans les signatures de fonctions se résout en fournissant un fichier .mli, mais la plupart des gens ne le font pas
    En revanche, le plugin OCaml pour VS Code offre la meilleure expérience pour les débutants
  • Je partage ce point de vue sur l’obsession des listes simplement chaînées
    Sur le matériel moderne, je pense que la collection par défaut devrait être un vector
  • Je suis entièrement d’accord sur la faiblesse du support Windows
    Autrefois, on ne pouvait même pas installer directement depuis ocaml.org, et il fallait passer par mingw ou wsl
    En pratique, c’était comme s’il n’y avait pas d’OCaml pour Windows

• La raison pour laquelle les concepteurs de Go n’ont presque pas repris les idées de la programmation fonctionnelle est claire
  Comme l’a dit Rob Pike, la plupart des développeurs chez Google étaient jeunes et habitués aux langages de la famille C, donc il leur fallait un langage facile à apprendre
  Comme le changement de manière de penser exigé par les langages fonctionnels prend beaucoup de temps, Go a cherché à éviter ce coût

  • En réalité, beaucoup de Googlers sont aussi mécontents des choix de l’équipe Go

• Chaque fois que je vois le mot « ML », mon cœur s’emballe encore un instant, avant que je réalise qu’il ne s’agit pas de Meta Language, mais de Machine Learning, ce qui me déçoit

  • ML signifie Meta Language, et LLM désigne le groupe de recherche Languages and Logic Montreal
  • À tout prendre, je préfère encore cette confusion
    Ce qui m’agace davantage aujourd’hui, c’est l’abus du mot « AI »
    J’aimerais qu’on n’utilise pas le terme AI tant qu’une vraie AGI n’existe pas
  • La première fois que j’ai utilisé ML, à la fin des années 1980 sur une machine 80286, j’ai été réellement bouleversé
  • J’avais déjà posté un commentaire similaire autrefois et reçu une pluie de downvotes ; je suis ravi de voir qu’il est mieux accueilli cette fois

• Si l’on regarde la conférence de Richard Feldman, elle explique bien pourquoi les langages fonctionnels ne se sont pas imposés
  Il faut soit être le langage propriétaire d’une plateforme, soit avoir une killer app, soit disposer d’un énorme budget marketing
  Si Python a connu une telle explosion, c’est aussi parce qu’il est devenu le langage central de l’écosystème IA
  J’ai moi-même appris la programmation fonctionnelle avec OCaml et mené des projets en Haskell et en Zig, mais au final on revient à la réalité : « on utilise les outils qu’on peut utiliser »
  OCaml, Rust et Haskell sont populaires comme « langages qu’on veut apprendre », mais pas comme « langages réellement très utilisés »

  • Je ne suis pas d’accord avec l’idée que la popularité de Python viendrait de l’IA
    Torch était à l’origine basé sur Lua, puis a migré vers Python, qui était déjà très populaire
  • Je pense que si la programmation fonctionnelle n’est pas devenue dominante, c’est à cause d’une attitude élitiste
    Le camp FP s’est montré indifférent aux évolutions techniques du monde réel, pendant que des langages comme C, Pascal, Perl, Tcl occupaient le terrain
    Au final, la FP est restée « un clergé enfermé dans sa cathédrale », pendant que les langages impératifs gagnaient le grand public

• J’ai utilisé F#, et la concurrence fondée sur les acteurs m’a paru facile à comprendre
  En revanche, dès qu’on introduisait des Array mutables, tout devenait plus complexe
  Je me demande pourquoi on préférerait OCaml à F# en pratique

  • F# perd progressivement en compatibilité à cause des évolutions du CLR, et son compilateur est lent avec un outillage instable
    À l’inverse, OCaml offre la suppression du verrou global, une compilation rapide, et des fonctionnalités puissantes comme les modules, GADT et effets
    F# garde encore l’avantage sur le support Windows, le SIMD et les types non boxés, mais OCaml rattrape peu à peu son retard
  • L’intégration de F# à .NET est une arme à double tranchant
    Il y a beaucoup de bibliothèques, mais la plupart ne sont pas idiomatiques en F#
    OCaml dispose d’un écosystème natif plus important
  • Dans mon entreprise, nous avons développé les parties intensives en calcul en F#
    L’interopérabilité avec C# est bonne, mais utiliser des bibliothèques F# depuis C# était un cauchemar
    On finit donc par garder une couche externe en C#, et la base de code devient hybride
    L’écosystème .NET est riche, mais il reste fortement marqué par une pensée centrée sur l’OOP, qui entre en conflit avec le style FP
    Visual Studio est pratique, mais peu confortable pour des workflows basés sur la CLI
    Les temps de compilation ne cessent de s’allonger, et les tests sont maladroits
    Après avoir utilisé OCaml, j’ai trouvé son ergonomie de langage bien plus naturelle
  • OCaml est bien plus puissant que F# avec ses functors, modules de première classe, GADT, système objet, etc.
    F# est souvent présenté comme « OCaml pour .NET », mais en réalité ce n’est guère plus qu’un langage de la famille ML ; ce sont presque deux langages différents

• OCaml est un vieux langage, donc on pourrait croire que ses fonctions OOP sont dispensables, mais je pense que Standard ML est plus abouti

  • J’aime aussi SML, mais le système objet d’OCaml est sous-estimé
    Il est utile pour les records à typage structurel, l’open recursion ou les bindings JS comme Js_of_ocaml
  • Je suis en train d’écrire un compilateur en SML, et je me heurte à d’étranges contraintes comme la surcharge int/real ou la value restriction
    L’absence de mise à jour des records est aussi pénible
  • Autrefois, je préférais SML, mais à l’époque les « langages en O » étaient à la mode, et OCaml a davantage attiré l’attention

• Depuis le début des années 2000, OCaml a toujours été « presque parfait »
  Mais au moment où ses frictions se résolvent, d’autres langages ont déjà absorbé ses idées

  • OCaml est un langage comme le Velvet Underground
    Peu de gens l’apprennent, mais chacun de ceux qui l’apprennent crée un nouveau langage
    Source
  • Malgré cela, OCaml fait réellement tourner des systèmes de trading de plusieurs milliards de dollars
  • Je ne vois pas bien ce qu’on entend par « friction »
    Beaucoup de projets tournent déjà très bien en OCaml, et avec l’ajout d’un système d’effets, il est même plutôt en avance

• La popularité et la qualité sont deux choses différentes
  popularité ≠ excellence, et c’est pareil en musique
  Ce sont surtout les tendances et l’inertie qui décident

  • Popularité et appréciation sont même plutôt inversement corrélées
    Plus un langage est utilisé, plus il y a de gens pour le détester,
    tandis qu’un langage peu connu est plus facilement surestimé
  • La « qualité » d’une musique est subjective, mais celle d’un langage peut être objectivée par l’efficacité avec laquelle il résout des problèmes
    Si OCaml est moins populaire, c’est parce que le public capable d’en percevoir l’efficacité est restreint
    Et l’attitude dogmatique du camp FP y contribue aussi

• Je pense que Elixir est un langage proche d’OCaml, mais avec un vrai potentiel de démocratisation
  Il combine des atouts de la FP comme l’immuabilité, le pattern matching et le modèle d’acteurs,
  et fonctionne de manière stable sur la runtime BEAM
  Il n’a pas de typage statique, mais il introduit progressivement une vérification de types

  • En réalité, ce qui m’intrigue davantage, c’est pourquoi F# n’est pas plus populaire
    Il peut pourtant utiliser tout l’écosystème .NET, et reste moins connu qu’OCaml
  • Elixir a un écosystème et un outillage excellents, et sa syntaxe est plus familière qu’Erlang
    De nombreuses entreprises l’utilisent réellement pour des backends SaaS
  • Mais la plupart des organisations considèrent encore le paradigme fonctionnel (centré sur la récursion) comme une contrainte
    C’est pourquoi les langages FP restent minoritaires
  • Personnellement, je trouve Elixir moins exigeant mentalement et plus flexible qu’OCaml
  • Gleam est intéressant lui aussi, mais un langage qui ne compile pas ne convient pas à mon travail

• OCaml ressemble à Go en tant que langage système avec GC
  Je préfère un GC à la gestion mémoire manuelle ou au borrow checking
  Le GC du langage D était lui aussi excellent, mais le vrai problème était que le simple mot « GC » suffisait à faire peur aux gens