De son côté OCaml a 20 ans. Et même si il a un succès relatif, c'est resté un langage de niche.
Arguer que parce qu'il a 20 ans, OCaml a raté le coche, je pense que c'est s'avancer un peu vite.
Pendant des années, on a considéré les langages fonctionnels comme élégants mais pas adaptés à un environnement de production. Depuis ~10 ans, on voit pulluler les « extensions fonctionnelles » aux langages OO (Java et C++ entre autres), et on s'entend rappeler que pas mal de langages de haut niveau (de type Perl) ont presque toujours eu une partie des constructions habituellement attribuées aux langages fonctionnels.
Mais depuis que les architectures multicœur sont arrivées, tout à coup, les langages fonctionnels, et en particulier les langages fortement typés reviennent à la mode. Entre autres, Scala est sans doute le plus populaire (pour le big data on a SPARK qui l'utilise, et sinon Twitter est bien connu dans le genre). Scala est pour moi un langage « multi-paradigme » qui fonctionne et est relativement populaire car (tout comme F# avec .Net) il s'appuie sur les bibliothèques standard (et moins standard) de Java, tout en proposant une syntaxe principalement fonctionnelle (et qui je trouve est quand même proche de celle de OCaml par bien des aspects).
OCaml a réellement souffert du manque de bibliothèques utiles pour permettre autre chose que des machins académiques. Mais tout comme les langages fonctionnels ont été proposés il y a plus de 50 ans et n'ont commencé à percer qu'il y a 5-10 ans pour des choses plus « grand public », il n'est pas complètement improbable que OCaml trouve un public plus large à mesure que sa bibliothèque « standard » s'agrandit.
J'aime bien Scala, mais on paie le prix qu'on paie aussi avec Clojure et ... Java : on paie le prix de la JVM qui est lente à charger, et RAMophage. De plus, bien que le typage soit fort en Java/Scala/blah, il reste dynamique, ce qui pour des applis haute-performance est assez gênant. Par exemple, avec SPARK ça va car on part de loin : Hadoop fait bien trop de copies des données intermédiaires sur HDFS, et du coup SPARK semble 1000 fois plus rapide en comparaison simplement parce qu'il cherche à garder les données le plus possible en mémoire. De plus, on pense généralement au big data en termes de quantité de données avec un traitement simple dessus : on paie plus le prix des communications qu'autre chose.
Les gros labos de recherche (DOE/DOD aux USA, CEA, INRIA, etc., en France) commencent à sérieusement se pencher sur le « big compute » qui rajoute de gros traitements par-dessus des environnements « big data », et là je pense qu'on va commencer à voir fleurir des solutions à base de langages avec un typage statique, et en règle générale une capacité d'exploiter le matériel de façon plus efficace. Ça veut très certainement dire que pour les couches les plus basses on va se servir de C/C++, mais je n'exclus pas la possibilité d'utiliser un langage de type OCaml, surtout si les utilisateurs ont déjà pris l'habitude d'utiliser Scala...
[^] # Re: Logiciels libres
Posté par lasher . En réponse à la dépêche Agrégation et logiciels libres. Évalué à 5.
Arguer que parce qu'il a 20 ans, OCaml a raté le coche, je pense que c'est s'avancer un peu vite.
Pendant des années, on a considéré les langages fonctionnels comme élégants mais pas adaptés à un environnement de production. Depuis ~10 ans, on voit pulluler les « extensions fonctionnelles » aux langages OO (Java et C++ entre autres), et on s'entend rappeler que pas mal de langages de haut niveau (de type Perl) ont presque toujours eu une partie des constructions habituellement attribuées aux langages fonctionnels.
Mais depuis que les architectures multicœur sont arrivées, tout à coup, les langages fonctionnels, et en particulier les langages fortement typés reviennent à la mode. Entre autres, Scala est sans doute le plus populaire (pour le big data on a SPARK qui l'utilise, et sinon Twitter est bien connu dans le genre). Scala est pour moi un langage « multi-paradigme » qui fonctionne et est relativement populaire car (tout comme F# avec .Net) il s'appuie sur les bibliothèques standard (et moins standard) de Java, tout en proposant une syntaxe principalement fonctionnelle (et qui je trouve est quand même proche de celle de OCaml par bien des aspects).
OCaml a réellement souffert du manque de bibliothèques utiles pour permettre autre chose que des machins académiques. Mais tout comme les langages fonctionnels ont été proposés il y a plus de 50 ans et n'ont commencé à percer qu'il y a 5-10 ans pour des choses plus « grand public », il n'est pas complètement improbable que OCaml trouve un public plus large à mesure que sa bibliothèque « standard » s'agrandit.
J'aime bien Scala, mais on paie le prix qu'on paie aussi avec Clojure et ... Java : on paie le prix de la JVM qui est lente à charger, et RAMophage. De plus, bien que le typage soit fort en Java/Scala/blah, il reste dynamique, ce qui pour des applis haute-performance est assez gênant. Par exemple, avec SPARK ça va car on part de loin : Hadoop fait bien trop de copies des données intermédiaires sur HDFS, et du coup SPARK semble 1000 fois plus rapide en comparaison simplement parce qu'il cherche à garder les données le plus possible en mémoire. De plus, on pense généralement au big data en termes de quantité de données avec un traitement simple dessus : on paie plus le prix des communications qu'autre chose.
Les gros labos de recherche (DOE/DOD aux USA, CEA, INRIA, etc., en France) commencent à sérieusement se pencher sur le « big compute » qui rajoute de gros traitements par-dessus des environnements « big data », et là je pense qu'on va commencer à voir fleurir des solutions à base de langages avec un typage statique, et en règle générale une capacité d'exploiter le matériel de façon plus efficace. Ça veut très certainement dire que pour les couches les plus basses on va se servir de C/C++, mais je n'exclus pas la possibilité d'utiliser un langage de type OCaml, surtout si les utilisateurs ont déjà pris l'habitude d'utiliser Scala...