> Sans troll inutile, je trouve que l'on peut faire plus ou moins la
> même chose dans les langages fonctionnels (lisp, ocaml, F#
> donc), les langages objets (Java, ruby,
> je-ne-citerai-pas-C++-qui-fait-bondir-les-fanas-de-l'objet...), et
> les langages impératifs (C...); c'est avant tout une question de
> goût, goût qui dépend de la façon de penser du programmeur,
> de sa manière d'aborder les problèmes.
Il me semble que l'on peut effectivement faire la même chose. La question c'est "comment" ?
Un if/then/else en ocaml ça n'a rien à voir avec un if {} else {} en C. Le principe est totalement différent (d'un côté on a une valeur/expression, de l'autre on a plus ou moins des instructions/statement) et pourtant on peut faire les mêmes choses.
C'est ce genre de différences qui est, à mon avis, vraiment fondamental. Effectivement, on a deux choses qui à la base sont faites pour correspondre à la même idée (programmer c'est à mon avis formuler sa pensée de manière à ce qu'un ordinateur la comprenne), et qui au final permettent de faire les mêmes choses (c'est pas le langage qui décide de ce qu'on fait, mais nous), mais la différence entre les deux reste importante/intéressante.
C'est vrai pour OCaml, et j'imagine que c'est encore plus vrai pour les langages purement fonctionnels; en tout cas OCaml incorpore de nombreux traits impératifs (et je pense que c'est un avantage), mais qui sont intégrés dans le mécanisme global du langage, fonctionnel.
C'est peut-être pour ça que les gens ont autant de mal avec les langages fonctionnels. Quand on met un codeur en C devant un cours de ocaml, pour ce que j'en ai observé, leur premier réflexe est de se dire "comment on fait une boucle for, comment on incrémente une variable, c'est quoi exactement la syntaxe de if/else, etc.". Forcément, si on retient "au lieu de if (prout) { foo(); } else { bar(); } on met if prout then foo() else bar()", on ne pourra pas comprendre pourquoi ça fait des trucs bizarres quand on met juste une valeur à la place des foo() et bar(), et on se dira "décidément, je n'arrive pas à comprendre les langages fonctionnels". Sans parler de la syntaxe de déclaration de fonction/valeurs qui a l'air complètement hallucinante.
Dans ce cas là j'aurais tendance à dire que ce n'est ni la faute du langage, ni celle du codeur, mais celle de la méthode. Il faut arrêter de commencer un nouveau langage par ce qu'on connaît déjà, quitte à fouler au pieds la logique de base du langage si elle est en contradiction avec les autres langages que l'on connait : il faudrait débuter par ce qui est fondamental, et différent.
[^] # Re: apprendre la programmation fonctionnelle
Posté par gasche . En réponse au journal Language F# - Du microsoft, mais il y a un rapport avec le libre !. Évalué à 5.
> même chose dans les langages fonctionnels (lisp, ocaml, F#
> donc), les langages objets (Java, ruby,
> je-ne-citerai-pas-C++-qui-fait-bondir-les-fanas-de-l'objet...), et
> les langages impératifs (C...); c'est avant tout une question de
> goût, goût qui dépend de la façon de penser du programmeur,
> de sa manière d'aborder les problèmes.
Il me semble que l'on peut effectivement faire la même chose. La question c'est "comment" ?
Un if/then/else en ocaml ça n'a rien à voir avec un if {} else {} en C. Le principe est totalement différent (d'un côté on a une valeur/expression, de l'autre on a plus ou moins des instructions/statement) et pourtant on peut faire les mêmes choses.
C'est ce genre de différences qui est, à mon avis, vraiment fondamental. Effectivement, on a deux choses qui à la base sont faites pour correspondre à la même idée (programmer c'est à mon avis formuler sa pensée de manière à ce qu'un ordinateur la comprenne), et qui au final permettent de faire les mêmes choses (c'est pas le langage qui décide de ce qu'on fait, mais nous), mais la différence entre les deux reste importante/intéressante.
C'est vrai pour OCaml, et j'imagine que c'est encore plus vrai pour les langages purement fonctionnels; en tout cas OCaml incorpore de nombreux traits impératifs (et je pense que c'est un avantage), mais qui sont intégrés dans le mécanisme global du langage, fonctionnel.
C'est peut-être pour ça que les gens ont autant de mal avec les langages fonctionnels. Quand on met un codeur en C devant un cours de ocaml, pour ce que j'en ai observé, leur premier réflexe est de se dire "comment on fait une boucle for, comment on incrémente une variable, c'est quoi exactement la syntaxe de if/else, etc.". Forcément, si on retient "au lieu de if (prout) { foo(); } else { bar(); } on met if prout then foo() else bar()", on ne pourra pas comprendre pourquoi ça fait des trucs bizarres quand on met juste une valeur à la place des foo() et bar(), et on se dira "décidément, je n'arrive pas à comprendre les langages fonctionnels". Sans parler de la syntaxe de déclaration de fonction/valeurs qui a l'air complètement hallucinante.
Dans ce cas là j'aurais tendance à dire que ce n'est ni la faute du langage, ni celle du codeur, mais celle de la méthode. Il faut arrêter de commencer un nouveau langage par ce qu'on connaît déjà, quitte à fouler au pieds la logique de base du langage si elle est en contradiction avec les autres langages que l'on connait : il faudrait débuter par ce qui est fondamental, et différent.