Posté par anaseto .
En réponse au journal Haskell et le tri.
Évalué à 6.
Dernière modification le 20 février 2016 à 15:14.
Ça reviens à ce que je disais, les langages fonctionnels sont complexes, peu naturels. Dire à quelqu'un qu'il va apprendre la programmation pour écrire des programmes qui n'interagissent avec rien, ça me semble difficilement motivant.
D'un autre côté, Haskell n'est pas le langage fonctionnel le plus simple pour commencer. OCaml est par exemple bien plus accessible (afficher un "Hello world" ne fait pas apparaître des concepts compliqués, contrairement à Haskell avec la monade IO). Haskell ne vise pas à être un langage facile à apprendre, c'est un peu comme C++ (ou Rust), mais dans un genre plus mathématique, ce qui fait que les interactions avec le monde extérieur ne sont pas la première chose mise en avant.
Le fait qu'un langage soit fonctionnel ne le rend pas complexe ou peu naturel en soi. En fait, je trouve par exemple que l'utilisation de fonctions courantes d'ordre supérieur sur les listes est plutôt sain, et je ne m'en prive pas non plus lorsque j'écris dans un langage non particulièrement fonctionnel qui les propose (même si c'est toujours une question de limite : par exemple, autant map et filter me semblent vraiment apporter quelque chose, je n'ai pas toujours l'impression que les fold_left apportent beaucoup par rapport à une boucle). Dans le cas de Haskell, c'est aussi un peu un terrain de prototypage pour plein d'idées sur les système de types, du coup il y a plein d'extensions, c'est complexe et on se cogne à un moment ou à un autre avec des concepts théoriques. D'autres langages comme OCaml sont un peu plus conservateurs (ça veut pas dire que tout code OCaml va être compréhensible pour un néophyte non plus, et ces derniers temps il y a pas mal de nouveautés).
Ceci dit, ce qui en pratique freine le plus sont des choses pas vraiment liées aux langages en soi : le fait que le langage offre des possibilités complexes ne veut pas dire que faire des choses simples va devenir compliqué. Mais en prenant un livre un peu au hasard sur Lisp ou Haskell, il y a de bonnes chances qu'une bonne partie du livre, surtout l'introduction, soit dédiée à expliquer pourquoi le langage est si génial (super macros ou super système de types), ce qui a de bonnes chances d'arrêter quelqu'un qui n'a pas assez de patience ou de temps pour arriver au stade où il peut écrire des choses utiles de base avant de faire des choses géniales. Et puis même une fois les bases du langage maîtrisées, c'est facile de tomber sur un package documenté à l'aide seul de la signature de ses fonctions et une ligne de description pour chacune (ou zéro), et c'est pas souvent que l'on trouve des exemples tout prêts qui permettent d'emblée de se faire une idée de comment on va utiliser le truc : on attend souvent de l'utilisateur qu'il étudie l'API et réfléchisse lui-même à la bonne façon d'agencer les types, et ça fait perdre du temps.
Il y a aussi le fait que ce n'est pas parce qu'on commence à comprendre Haskell et faire des choses utiles facilement que l'on va être capable de lire le code des autres (si ça se trouve, ils utilisent des Lens ou des Arrows ou autre nouveauté, et il faut potasser un peu de théorie avant de pouvoir faire quelque chose :) ). Et ça peut parfois être un inconvénient. On reproche souvent quand quelqu'un fait des choses « trop intelligentes ». Eh bien avec Haskell ça arrive assez souvent (moins avec OCaml, je pense), ce qui a du bon comme du mauvais, mais peut être déroutant et faire perdre du temps en pratique suivant l'utilisation que l'on en fait (c'est pour ça qu'après avoir utilisé un serveur web Haskell faisant usage des Lens un moment, j'étais passé ensuite à du Perl pour reposer les neurones et être sûr qu'au bout d'un an j'ai pas oublié la théorie).
[^] # Re: Moi == pas doué, je suppose....
Posté par anaseto . En réponse au journal Haskell et le tri. Évalué à 6. Dernière modification le 20 février 2016 à 15:14.
D'un autre côté, Haskell n'est pas le langage fonctionnel le plus simple pour commencer. OCaml est par exemple bien plus accessible (afficher un "Hello world" ne fait pas apparaître des concepts compliqués, contrairement à Haskell avec la monade IO). Haskell ne vise pas à être un langage facile à apprendre, c'est un peu comme C++ (ou Rust), mais dans un genre plus mathématique, ce qui fait que les interactions avec le monde extérieur ne sont pas la première chose mise en avant.
Le fait qu'un langage soit fonctionnel ne le rend pas complexe ou peu naturel en soi. En fait, je trouve par exemple que l'utilisation de fonctions courantes d'ordre supérieur sur les listes est plutôt sain, et je ne m'en prive pas non plus lorsque j'écris dans un langage non particulièrement fonctionnel qui les propose (même si c'est toujours une question de limite : par exemple, autant
mapetfilterme semblent vraiment apporter quelque chose, je n'ai pas toujours l'impression que lesfold_leftapportent beaucoup par rapport à une boucle). Dans le cas de Haskell, c'est aussi un peu un terrain de prototypage pour plein d'idées sur les système de types, du coup il y a plein d'extensions, c'est complexe et on se cogne à un moment ou à un autre avec des concepts théoriques. D'autres langages comme OCaml sont un peu plus conservateurs (ça veut pas dire que tout code OCaml va être compréhensible pour un néophyte non plus, et ces derniers temps il y a pas mal de nouveautés).Ceci dit, ce qui en pratique freine le plus sont des choses pas vraiment liées aux langages en soi : le fait que le langage offre des possibilités complexes ne veut pas dire que faire des choses simples va devenir compliqué. Mais en prenant un livre un peu au hasard sur Lisp ou Haskell, il y a de bonnes chances qu'une bonne partie du livre, surtout l'introduction, soit dédiée à expliquer pourquoi le langage est si génial (super macros ou super système de types), ce qui a de bonnes chances d'arrêter quelqu'un qui n'a pas assez de patience ou de temps pour arriver au stade où il peut écrire des choses utiles de base avant de faire des choses géniales. Et puis même une fois les bases du langage maîtrisées, c'est facile de tomber sur un package documenté à l'aide seul de la signature de ses fonctions et une ligne de description pour chacune (ou zéro), et c'est pas souvent que l'on trouve des exemples tout prêts qui permettent d'emblée de se faire une idée de comment on va utiliser le truc : on attend souvent de l'utilisateur qu'il étudie l'API et réfléchisse lui-même à la bonne façon d'agencer les types, et ça fait perdre du temps.
Il y a aussi le fait que ce n'est pas parce qu'on commence à comprendre Haskell et faire des choses utiles facilement que l'on va être capable de lire le code des autres (si ça se trouve, ils utilisent des Lens ou des Arrows ou autre nouveauté, et il faut potasser un peu de théorie avant de pouvoir faire quelque chose :) ). Et ça peut parfois être un inconvénient. On reproche souvent quand quelqu'un fait des choses « trop intelligentes ». Eh bien avec Haskell ça arrive assez souvent (moins avec OCaml, je pense), ce qui a du bon comme du mauvais, mais peut être déroutant et faire perdre du temps en pratique suivant l'utilisation que l'on en fait (c'est pour ça qu'après avoir utilisé un serveur web Haskell faisant usage des Lens un moment, j'étais passé ensuite à du Perl pour reposer les neurones et être sûr qu'au bout d'un an j'ai pas oublié la théorie).