[Débutant] Langage fonctionnel à apprendre ?

[Garulfo]

Common LISP / Scheme : c'est quasiment la même chose.

[SpiceGuid]

Le plus Python/Ruby/Perl → Groovy (sur JVM)

[LLB]

En quoi Groovy est plus fonctionnel que Ruby ?

Un développeur Ruby n'a pas grand chose à gagner avec Groovy, de ce que j'ai vu. Alors qu'en passant à Lisp, il prendra plus conscience du paradigme fonctionnel. Il restera dans son monde à typage dynamique, mais il gagnera au niveau de la métaprogrammation.

[Garulfo]

Le plus ruby -> ruby.

C'est un langage fonctionnel. Un vrai avec toutes les possibilités des langages fonctionnels: fermeture, continuation, liaison lexicale, etc. Pourquoi en proposer un autre ?

[LLB]

Parce qu'il n'incite pas au style fonctionnel.

La déclaration de valeur se fait de façon automatique, il n'y a pas d'équivalent à notre "let". Du coup, il n'y a aucune différence entre une déclaration et une affectation. N'importe quel code Ruby fait des effets de bord à chaque ligne.

Ce n'est pas avec Ruby qu'il faut découvrir le fonctionnel.


Quant à Python, il incite encore moins au fonctionnel que Ruby (différenciation entre instruction et expression, les lambda sont très limitées, etc.). Je maintiens donc Python → Lisp.

[Garulfo]

Envoyé par LLB

[...]
Ce n'est pas avec Ruby qu'il faut découvrir le fonctionnel.[...]

ÉVentuellement, mais dans ce cas, est-ce que Scala ne risque pas le même genre de travers ? Il ne se définit comme Ruby comme un multiparadigme.
En tout cas, c'est vrai que c'est pas l'idéal. Mais pour idéal, Haskell devient un choix de maître. Par contre c'est faux que tout code Ruby possède des effets de bords. Les éléments sont correctement définis dans des champs lexicaux. En tout cas, je ne défend pas avec acharnement Ruby parce que je ne pense pas qu'il soit magnifique, mais on voit bien des gens qui font une masse de programmation impérative avec OCaml. C'est plus une question de cours que de langage.

Envoyé par LLB

[...]
Quant à Python, il incite encore moins au fonctionnel que Ruby (différenciation entre instruction et expression, les lambda sont très limitées, etc.). Je maintiens donc Python → Lisp.

Python n'est pas un langage vraiment fonctionnel. Il n'a pas de portée lexical aussi propre. Il n'a que deux ou trois niveaux (j'ai oublié exactement). La fermeture n'existe donc pas réellement.

En tout cas, c'est pas moi qui vait me plaindre de
Ruby/Python -> CLisp / Scheme

[gasche]

Puisque c'est la journée des critiques faciles, je trouve bon de préciser que Erlang ne permet pas correctement de déclarer des fonctions (récursives) imbriquées, ce qui est quand même un peu choquant pour un langage considéré comme fonctionnel.

D'ailleurs, si vous vous intéressez un peu à Erlang, je vous encourage à regarder aussi Reia ( http://wiki.reia-lang.org/wiki/Reia_...mming_Language ), une tentative de "Erlang plus Ruby-friendly" tournant sur la VM erlang, et qui fait des choses que je trouve très censées (et assez MLesques), par exemple au niveau des patterns. Il y avait aussi un projet de "Erlang sauce Lisp" mais je sais pas ce que ça a donné.

[SpiceGuid]

Scala est multiparadigme à la façon OCaml, soit il n'y a pas effet de bord soit ça renvoie unit.
C'est vraiment un bon langage pour faire du fonctionnel, et même si c'est un peu vrai que les débutants l'utilisent comme un Java++, Odersky a poussé la JVM aussi loin que possible vers le fonctionnel.
D'ailleurs le système de classes est ouvertement inspiré du système de modules de OCaml, avec imbrication et types abstraits à la OCaml.
Il y a aussi la do-notation, Scala va bien plus loin que par exemple Anubis où on se retrouve quand même très vite assez limité.

[InOCamlWeTrust]

Envoyé par Garulfo

ÉVentuellement, mais dans ce cas, est-ce que Scala ne risque pas le même genre de travers ? Il ne se définit comme Ruby comme un multiparadigme.
En tout cas, c'est vrai que c'est pas l'idéal. Mais pour idéal, Haskell devient un choix de maître. Par contre c'est faux que tout code Ruby possède des effets de bords. Les éléments sont correctement définis dans des champs lexicaux. En tout cas, je ne défend pas avec acharnement Ruby parce que je ne pense pas qu'il soit magnifique, mais on voit bien des gens qui font une masse de programmation impérative avec OCaml. C'est plus une question de cours que de langage.

Je pense qu'il faut prendre plus de recul.

Pour commencer, il n'y a pas de bonne façon de programmer. Il y a des codes plus élégants que d'autres, plus concis, plus clairs. Si on me demandait à moi ce qu'est un bon code, je dirais qu'il s'agit d'un code robuste à toutes les erreurs possibles et imaginables, comme on le voit dans les codes C bien faits et quasiment jamais dans les programmes écrits en fonctionnel. D'autres auraient des critères différents.

Ensuite, le problème des gens qui codent très impératif en OCaml vient essentiellement du fait qu'ils utilisent dans la majorité des cas des structures modifiables, très difficiles à manier dans un style fonctionnel plus pur. Cette façon de faire est la bonne dans ces cas-là. La seule chose que l'on peut alors reprocher est le choix de la structure, mais malheureusement l'efficacité asymptotique des algorithmes est inexorablement liée au type de structure utilisée... donc changer de style ne signifie pas toujours faire mieux, surtout si on doit changer de structure pour son équivalent fonctionnel, plus lourd à utiliser dans beaucoup de cas.

Ensuite, le style impératif, à l'inverse du style fonctionnel, permet de mieux suivre la progression de l'exécution, par nature. Etant donné que l'on exécute des instructions les unes après les autres, il devient facile de mettre des traces (va faire ça facilement en Haskell...), de stopper l'exécution à un point et de la reprendre, et de commenter.

Enfin, l'éternel débat du choix du langage me paraît chaque jour un peu plus stupide, étant donné qu'ils sont tous, OCaml mis à part, plus mauvais les uns que les autres en termes de performances et d'innovations. Trop de langages deviennent de vraies montagnes à merdes parce que l'on y incorpore tout un tas de daubes qui ne font que pourir le travail du programmeur. Il vaudrait mieux travailler sur un langage plus petit, mais dont le fonctionnement garantirait moins d'erreurs de programmation.

A quand un langage qui vérifie la taille des matrices à la compilation ?
a quand un langage qui vérifie la taille des listes ?

Bref, quel langage choisir ?

Celui qui te plaît le plus. De toute façon ils sont tous mauvais.

[SpiceGuid]

C'est bien vrai ça, la plupart des langages débutent en étant pas très bons, puis ils grossissent jusqu'à devenir franchement mauvais.

[LLB]

Envoyé par SpiceGuid

C'est bien vrai ça, la plupart des langages débutent en étant pas très bons, puis ils grossissent jusqu'à devenir franchement mauvais.

Tu as des exemples et des arguments ?

Presque tous les langages s'améliorent avec le temps. OCaml est meilleur que Caml light. De même pour tous les exemples qui me viennent à la tête. Un langage ne perd (presque) jamais de fonctionnalité, c'est le contraire qui se produit. Le problème, c'est quand un mauvais développeur utilise mal certaines fonctionnalités. Mais c'est le problème du développeur, et non du langage.

[Garulfo]

Envoyé par SpiceGuid

[...]C'est vraiment un bon langage pour faire du fonctionnel, et même si c'est un peu vrai que les débutants l'utilisent comme un Java++, Odersky a poussé la JVM aussi loin que possible vers le fonctionnel.[...]

C'est peut-être un bon langage à tes yeux, mais si tu regardes ce qui est produit en général, les exemples sur l'Internet, et ce que font les étudiants avec tu verras que ça ne semble pas être meilleur que Ruby pour enseigner le fonctionnel. Enfin, tu n'as pas dit le contraire remarque Et tu as même souligné que les débutants l'utilisent en Java++. C'était justement ça mon point ^_^

[Garulfo]

Envoyé par InOCamlWeTrust

[...]étant donné qu'ils sont tous, OCaml mis à part, plus mauvais les uns que les autres en termes de performances et d'innovations. [...]

Je suppose que c'est une boutade ?

[InOCamlWeTrust]

Je voulais juste parler des performances en termes de temps d'exécution. Les benchmarks Haskell sur le Great Computer Shoutout Language ne peuvent pas réellement être pris en tant que mesure fiable : les codes sont spécialement conçus pour, complètement anti-naturels... bref, pas le genre de truc que tout le monde serait capable de cracher.

[Garulfo]

Envoyé par InOCamlWeTrust

Je voulais juste parler des performances en termes de temps d'exécution. Les benchmarks Haskell sur le Great Computer Shoutout Language ne peuvent pas réellement être pris en tant que mesure fiable : les codes sont spécialement conçus pour, complètement anti-naturels... bref, pas le genre de truc que tout le monde serait capable de cracher.

Ça c'est bien possible. C'est d'ailleurs pas le seul langage soumis à ça. Mais dans ce cas, sur quoi te bases-tu ? Sur ton impression ? Je suis sûr qu'on pourrait trouver des spécialistes avec des impressions inverses non ?

En tout cas, globalement, je suis d'accord avec toi, si je t'ai bien compris: on se fout du langage au fond, c'est la méthode d'approche et la discipline de celui qui s'y met qui compte.

[gasche]

Je pense qu'il veut dire que les codes Haskell soumis au benchmark ne sont pas des codes "idiomatiques" ou "naturels" : ils permettent d'évaluer les (excellentes) performances d'un code Haskell adapté au petit oignons par des spécialistes de la question, mais ne donne pas une idée fiable des performances moyennes d'un bon code Haskell "normal", c'est à dire codé naturellement par un non-spécialiste de la micro-optimisation et/ou du compilateur.

Il faut dire pour la défense de Haskell que j'ai souvent entendu raconter que les règles du benchmark n'étaient particulièrement pas adaptées aux langages paresseux : certaines solutions Haskell particulièrement "bluffantes" (parce qu'utilisant la paresse pour court-circuiter une partie de l'énoncé) auraient été refusées. Ceci dit, je n'en sais pas plus que des rumeurs (et de toute façon les autres langages pourraient utiliser la paresse aussi si justifié, ça ne change fondamentalement rien).

[InOCamlWeTrust]

Envoyé par bluestorm

Je pense qu'il veut dire que les codes Haskell soumis au benchmark ne sont pas des codes "idiomatiques" ou "naturels" : ils permettent d'évaluer les (excellentes) performances d'un code Haskell adapté au petit oignons par des spécialistes de la question, mais ne donne pas une idée fiable des performances moyennes d'un bon code Haskell "normal", c'est à dire codé naturellement par un non-spécialiste de la micro-optimisation et/ou du compilateur.

Yes.

Envoyé par bluestorm

Il faut dire pour la défense de Haskell que j'ai souvent entendu raconter que les règles du benchmark n'étaient particulièrement pas adaptées aux langages paresseux : certaines solutions Haskell particulièrement "bluffantes" (parce qu'utilisant la paresse pour court-circuiter une partie de l'énoncé) auraient été refusées. Ceci dit, je n'en sais pas plus que des rumeurs (et de toute façon les autres langages pourraient utiliser la paresse aussi si justifié, ça ne change fondamentalement rien).

Oui, et tout comme on a refusé beaucoup d'autres codes très rapides pour quasiment tous les langages, y compris OCaml. On peut trouver les exemples sur le site. Il s'agit essentiellement des codes où le travail est complètement mâché par le compilateur, ou encore des solutions qui ne correspondent pas à l'énoncé : calcul de factorielle via des templates en C++, utilisation de fonctions au lieu de threads, etc...

Envoyé par Garulfo

En tout cas, globalement, je suis d'accord avec toi, si je t'ai bien compris: on se fout du langage au fond, c'est la méthode d'approche et la discipline de celui qui s'y met qui compte.

Oui, et si on est préoccupé par les performances, il faut aller voir ailleurs : C (pas le C++...), Fortran et Ada. Point.

[LLB]

Envoyé par InOCamlWeTrust

Oui, et si on est préoccupé par les performances, il faut aller voir ailleurs : C (pas le C++...), Fortran et Ada. Point.

Faut arrêter : si tu prends un code C, il a toutes les chances (les exceptions sont relativement rares) de compiler avec un compilateur C++ et il n'en sera pas plus lent. En bonus, tu pourras utiliser les références (je ne pense pas que ce soit lent...), les templates (ça peut améliorer la vitesse), la surcharge (ça n'enlève rien).

Et dès que tu codes une partie non critique en temps, tu gagnes la possibilité d'utiliser un langage plus expressif.


Après, on peut aussi débattre sur les performances de la STL...

[Jedai]

Envoyé par bluestorm

Je pense qu'il veut dire que les codes Haskell soumis au benchmark ne sont pas des codes "idiomatiques" ou "naturels" : ils permettent d'évaluer les (excellentes) performances d'un code Haskell adapté au petit oignons par des spécialistes de la question, mais ne donne pas une idée fiable des performances moyennes d'un bon code Haskell "normal", c'est à dire codé naturellement par un non-spécialiste de la micro-optimisation et/ou du compilateur.

Ca ne veut pas dire grand chose, tous les codes du shootout pourrait subir ce reproche à peu de chose près... De plus je pense que votre impression a été formé il y a un certain temps et que vous ne vous en êtes pas débarassé : il reste un certain nombre de solutions "non-idiomatique" parmi les codes Haskell, mais elles sont maintenant plutôt en minorité étant donné les progrès des librairies et de l'optimiseur.

Il est intéressant de constater les excellentes performances (parfois à vraiment peu de frais, regardez regex-dna par exemple) achevées par Haskell sur les plateformes parallèles.

--
Jedaï

[DISCLAMER]Attention, ce message est trollesque. Mais c'est vendredi soir, alors je me pardonne ;-)[/DISCLAMER]

Envoyé par InOCamlWeTrust

Si on me demandait à moi ce qu'est un bon code, je dirais qu'il s'agit d'un code robuste à toutes les erreurs possibles et imaginables, comme on le voit dans les codes C bien faits et quasiment jamais dans les programmes écrits en fonctionnel.

Les seuls tel codes que je connaissent sont justement écris dans des langages purement fonctionnels tel que le Calcul Inductif des Constructions :-)

Envoyé par InOCamlWeTrust

La seule chose que l'on peut alors reprocher est le choix de la structure, mais malheureusement l'efficacité asymptotique des algorithmes est inexorablement liée au type de structure utilisée... donc changer de style ne signifie pas toujours faire mieux, surtout si on doit changer de structure pour son équivalent fonctionnel, plus lourd à utiliser dans beaucoup de cas.

Sous-entends tu que la complexité des structures fonctionnelles est systématiquement moins bonne que celle des structures impératives ? Pour la constante, je ne dis pas, mais pour la complexité, c'est rarement le cas.
Et pour la lourdeur ? Ne jamais avoir à se demander s'il y a des problèmes d'aliasing quand on utilise une structure ne me semble pas être une lourdeur, au contraire.

Envoyé par InOCamlWeTrust

Enfin, l'éternel débat du choix du langage me paraît chaque jour un peu plus stupide, étant donné qu'ils sont tous, OCaml mis à part, plus mauvais les uns que les autres en termes de performances et d'innovations.

Ou peut être que les gens commencent à se dire que les super-méga-performances de la mort qui tue, on s'en fout de plus en plus, et que c'est la fiabilité qui est plus intéressante ? Nan, je rêve encore

Envoyé par InOCamlWeTrust

Trop de langages deviennent de vraies montagnes à merdes parce que l'on y incorpore tout un tas de daubes qui ne font que pourir le travail du programmeur. Il vaudrait mieux travailler sur un langage plus petit, mais dont le fonctionnement garantirait moins d'erreurs de programmation.

Le noyau de Coq n'est pas bien gros et apporte plein de sécurité :-)

Envoyé par InOCamlWeTrust

A quand un langage qui vérifie la taille des matrices à la compilation ?
a quand un langage qui vérifie la taille des listes ?

A quand des programmeurs tous munis d'un ou deux doctorats ?

Envoyé par Garulfo

En tout cas, globalement, je suis d'accord avec toi, si je t'ai bien compris: on se fout du langage au fond, c'est la méthode d'approche et la discipline de celui qui s'y met qui compte.

Certains langages incitent plus que d'autres à la discipline on va dire :-)

Envoyé par bluestorm

Je pense qu'il veut dire que les codes Haskell soumis au benchmark ne sont pas des codes "idiomatiques" ou "naturels" : ils permettent d'évaluer les (excellentes) performances d'un code Haskell adapté au petit oignons par des spécialistes de la question, mais ne donne pas une idée fiable des performances moyennes d'un bon code Haskell "normal", c'est à dire codé naturellement par un non-spécialiste de la micro-optimisation et/ou du compilateur.

C'est pareil pour les codes en C. La preuve, ils ne crashent pas :-)