Faisant de l'OCaml tout les jours, je ne peux que approuver ce conseil.
Il faut bien le dire avant toute chose, OCaml est un langage qui brille dans le domaine de l'analyse statique et la compilation. Il y a plusieurs raisons à cela.
La première concerne la programmation fonctionnel. Le principe de la programmation fonctionnel est que tout est fonction. Mais en disant cela, on a rien dit. En vérité, la programmation fonctionnel offre une manière de penser qui, justement, est parfaite pour ce qui est de l'analyse et de la transformation. Un langage impératif offre une vision d'états de la machine (un nombre d'état qui peut devenir exponentielle dès qu'il s'agit de faire de multi-threads) de manière séquentielle comme la recette de cuisine qu'on nous ressort à chaque fois qu'on souhaite apprendre l'informatique. Mais dans une problématique de recherche et de transformation, cette notion d'état n'a pas grande importance. Ce qui est important dans un compilateur par exemple, ce n'est pas l'état de celui-ci, c'est les règles de transformations qu'il va appliquer, et c'est bien là la nature d'un compilateur, c'est les règles lexicales, syntaxiques et sémantiques de transformation qui nous intéresse. C'est en ce premier point qu'OCaml (mais tout langage fonctionnel de manière général) est plus propice au travail de compilation et d'analyse du code.
La deuxième concerne le milieu d'OCaml. OCaml est un langage qui vient de l'Inria et qui est encore maintenu par pas mal de chercheur (notamment le laboratoire Gallium). Il est au final très plaisant de travailler avec où l'important n'est pas la date de la prochaine release d'OCaml mais l'intégration d'un travail qui correspond à l'état de l'art de toutes leurs recherche. Ceci donne alors un compilateur associé à pas mal de papiers de recherches (pas si difficile à lire que ça) qui offre un aspect qui va bien au delà du simple hype au langage. En somme, je considère que tout travail dans OCaml fait objet d'une confiance difficile à rétorquer sous le coup de l'humeur - comme par exemple, pourquoi on a l'opérateur (+.) pour les flottants - car chaque choix est argumenté en prenant compte un point de vu de recherche mais aussi, il y a peu, d'industrie. Et c'est bien un des rares langages à pouvoir mélanger les deux.
La troisième raison concerne bien entendu son système de type qui fait qu'OCaml est OCaml. Dans un domaine comme celui de la compilation, le premier point le plus important est que le compilateur ne produise pas quelque chose qui ne fonctionne pas. Ce serait bête de faire un "Hello World!" en C et que gcc nous produise un "Hello Toto!". Sur ce point qui parait bête, les problématiques de la compilation vont bien plus loin que de simplement produire ce qu'on nous demande. On doit aussi vérifier ce que nous produisons. Une des solutions aujourd'hui est le test unitaire qui permet à fortiori de savoir si le comportement de notre programme correspond à nos attentes. Bien que cette manière est très bien, elle n'est pas exhaustive, elle se limite à l'imagination que peut avoir le développeur sur les cas d'utilisations possibles de son logiciel. Ainsi, les chercheurs ont cherché (c'est leurs jobs il parait) une solution permettant de vérifier statiquement la validité d'un programme. Bien entendu, ce n'est pas possible de vérifier qu'un programme ne plantera jamais mais on a déjà pas mal de piste qui permettent d'élaguer le plus de bugs possibles et l'une de ces solutions est le système de type. C'est bien pour cette raison qu'on dit qu'un programme OCaml qui compile à 90% de chance de ne pas planter.
Au final, au travers de ces trois points, et de manière simplifié, on comprends pourquoi OCaml brille dans ces domaines là mais le mieux reste de le pratiquer pour s'en rendre compte. J'ai vraiment l'intime conviction qu'OCaml peut être une très bonne solution pour ton logiciel bien qu'il faut ré-apprendre un nouveau langage et surtout ré-implémenter le moteur dans ce langage. Cela peut paraître chiant (et ça l'est je pense) mais le gain que tu gagneras est juste énorme. Un vieux fou m'a demandé de faire mon petit interpréteur de Scheme en OCaml alors que je le faisais en C, il reste fou mais il avait raison de me demander ça et c'est bien un des meilleurs conseils qu'on m'ai donné. J'ai perdu alors pas mal de temps à ré-implémenter mais force est de constater que je suis allé beaucoup plus loin qu'un simple interpréteur de Scheme aujourd'hui et c'est bien grâce à OCaml.
[^] # Re: Inférence de type, ou preuve automatique ?
Posté par Dinosaure (site web personnel) . En réponse à la dépêche Grammalecte, correcteur grammatical. Évalué à 2.
Faisant de l'OCaml tout les jours, je ne peux que approuver ce conseil.
Il faut bien le dire avant toute chose, OCaml est un langage qui brille dans le domaine de l'analyse statique et la compilation. Il y a plusieurs raisons à cela.
La première concerne la programmation fonctionnel. Le principe de la programmation fonctionnel est que tout est fonction. Mais en disant cela, on a rien dit. En vérité, la programmation fonctionnel offre une manière de penser qui, justement, est parfaite pour ce qui est de l'analyse et de la transformation. Un langage impératif offre une vision d'états de la machine (un nombre d'état qui peut devenir exponentielle dès qu'il s'agit de faire de multi-threads) de manière séquentielle comme la recette de cuisine qu'on nous ressort à chaque fois qu'on souhaite apprendre l'informatique. Mais dans une problématique de recherche et de transformation, cette notion d'état n'a pas grande importance. Ce qui est important dans un compilateur par exemple, ce n'est pas l'état de celui-ci, c'est les règles de transformations qu'il va appliquer, et c'est bien là la nature d'un compilateur, c'est les règles lexicales, syntaxiques et sémantiques de transformation qui nous intéresse. C'est en ce premier point qu'OCaml (mais tout langage fonctionnel de manière général) est plus propice au travail de compilation et d'analyse du code.
La deuxième concerne le milieu d'OCaml. OCaml est un langage qui vient de l'Inria et qui est encore maintenu par pas mal de chercheur (notamment le laboratoire Gallium). Il est au final très plaisant de travailler avec où l'important n'est pas la date de la prochaine release d'OCaml mais l'intégration d'un travail qui correspond à l'état de l'art de toutes leurs recherche. Ceci donne alors un compilateur associé à pas mal de papiers de recherches (pas si difficile à lire que ça) qui offre un aspect qui va bien au delà du simple hype au langage. En somme, je considère que tout travail dans OCaml fait objet d'une confiance difficile à rétorquer sous le coup de l'humeur - comme par exemple, pourquoi on a l'opérateur
(+.)pour les flottants - car chaque choix est argumenté en prenant compte un point de vu de recherche mais aussi, il y a peu, d'industrie. Et c'est bien un des rares langages à pouvoir mélanger les deux.La troisième raison concerne bien entendu son système de type qui fait qu'OCaml est OCaml. Dans un domaine comme celui de la compilation, le premier point le plus important est que le compilateur ne produise pas quelque chose qui ne fonctionne pas. Ce serait bête de faire un "Hello World!" en C et que gcc nous produise un "Hello Toto!". Sur ce point qui parait bête, les problématiques de la compilation vont bien plus loin que de simplement produire ce qu'on nous demande. On doit aussi vérifier ce que nous produisons. Une des solutions aujourd'hui est le test unitaire qui permet à fortiori de savoir si le comportement de notre programme correspond à nos attentes. Bien que cette manière est très bien, elle n'est pas exhaustive, elle se limite à l'imagination que peut avoir le développeur sur les cas d'utilisations possibles de son logiciel. Ainsi, les chercheurs ont cherché (c'est leurs jobs il parait) une solution permettant de vérifier statiquement la validité d'un programme. Bien entendu, ce n'est pas possible de vérifier qu'un programme ne plantera jamais mais on a déjà pas mal de piste qui permettent d'élaguer le plus de bugs possibles et l'une de ces solutions est le système de type. C'est bien pour cette raison qu'on dit qu'un programme OCaml qui compile à 90% de chance de ne pas planter.
Au final, au travers de ces trois points, et de manière simplifié, on comprends pourquoi OCaml brille dans ces domaines là mais le mieux reste de le pratiquer pour s'en rendre compte. J'ai vraiment l'intime conviction qu'OCaml peut être une très bonne solution pour ton logiciel bien qu'il faut ré-apprendre un nouveau langage et surtout ré-implémenter le moteur dans ce langage. Cela peut paraître chiant (et ça l'est je pense) mais le gain que tu gagneras est juste énorme. Un vieux fou m'a demandé de faire mon petit interpréteur de Scheme en OCaml alors que je le faisais en C, il reste fou mais il avait raison de me demander ça et c'est bien un des meilleurs conseils qu'on m'ai donné. J'ai perdu alors pas mal de temps à ré-implémenter mais force est de constater que je suis allé beaucoup plus loin qu'un simple interpréteur de Scheme aujourd'hui et c'est bien grâce à OCaml.