Publicité
+ Répondre à la discussion
Page 3 sur 5 PremièrePremière 12345 DernièreDernière
Affichage des résultats 41 à 60 sur 84
  1. #41
    Inactif
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 49

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 331
    Points
    2 331

    Par défaut

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

  2. #42
    Rédacteur
    Avatar de SpiceGuid
    Homme Profil pro Damien Guichard
    Inscrit en
    juin 2007
    Messages
    1 574
    Détails du profil
    Informations personnelles :
    Nom : Homme Damien Guichard
    Localisation : France, Loire (Rhône Alpes)

    Informations forums :
    Inscription : juin 2007
    Messages : 1 574
    Points : 2 707
    Points
    2 707

    Par défaut

    Le plus Python/Ruby/Perl → Groovy (sur JVM)
    Du même auteur: le cours OCaml, le dernier article publié, le blog dvp et le jeu vidéo.
    Avant de poser une question je lis les règles du forum.

  3. #43
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 263
    Points
    1 263

    Par défaut

    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.

  4. #44
    Inactif
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 49

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 331
    Points
    2 331

    Par défaut

    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 ?

  5. #45
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 263
    Points
    1 263

    Par défaut

    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.

  6. #46
    Inactif
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 49

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 331
    Points
    2 331

    Par défaut

    Citation Envoyé par LLB Voir le message
    [...]
    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.

    Citation Envoyé par LLB Voir le message
    [...]
    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

  7. #47
    Membre Expert
    Inscrit en
    avril 2007
    Messages
    831
    Détails du profil
    Informations forums :
    Inscription : avril 2007
    Messages : 831
    Points : 1 130
    Points
    1 130

    Par défaut

    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é.

  8. #48
    Rédacteur
    Avatar de SpiceGuid
    Homme Profil pro Damien Guichard
    Inscrit en
    juin 2007
    Messages
    1 574
    Détails du profil
    Informations personnelles :
    Nom : Homme Damien Guichard
    Localisation : France, Loire (Rhône Alpes)

    Informations forums :
    Inscription : juin 2007
    Messages : 1 574
    Points : 2 707
    Points
    2 707

    Par défaut

    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é.
    Du même auteur: le cours OCaml, le dernier article publié, le blog dvp et le jeu vidéo.
    Avant de poser une question je lis les règles du forum.

  9. #49
    Membre Expert
    Avatar de InOCamlWeTrust
    Inscrit en
    septembre 2006
    Messages
    1 036
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 1 036
    Points : 1 265
    Points
    1 265

    Par défaut

    Citation Envoyé par Garulfo Voir le message
    É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.
    When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.

  10. #50
    Rédacteur
    Avatar de SpiceGuid
    Homme Profil pro Damien Guichard
    Inscrit en
    juin 2007
    Messages
    1 574
    Détails du profil
    Informations personnelles :
    Nom : Homme Damien Guichard
    Localisation : France, Loire (Rhône Alpes)

    Informations forums :
    Inscription : juin 2007
    Messages : 1 574
    Points : 2 707
    Points
    2 707

    Par défaut

    C'est bien vrai ça, la plupart des langages débutent en étant pas très bons, puis ils grossissent jusqu'à devenir franchement mauvais.
    Du même auteur: le cours OCaml, le dernier article publié, le blog dvp et le jeu vidéo.
    Avant de poser une question je lis les règles du forum.

  11. #51
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 263
    Points
    1 263

    Par défaut

    Citation Envoyé par SpiceGuid Voir le message
    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.

  12. #52
    Inactif
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 49

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 331
    Points
    2 331

    Par défaut

    Citation Envoyé par SpiceGuid Voir le message
    [...]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 ^_^

  13. #53
    Inactif
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 49

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 331
    Points
    2 331

    Par défaut

    Citation Envoyé par InOCamlWeTrust Voir le message
    [...]é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 ?

  14. #54
    Membre Expert
    Avatar de InOCamlWeTrust
    Inscrit en
    septembre 2006
    Messages
    1 036
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 1 036
    Points : 1 265
    Points
    1 265

    Par défaut

    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.
    When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.

  15. #55
    Inactif
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 49

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 331
    Points
    2 331

    Par défaut

    Citation Envoyé par InOCamlWeTrust Voir le message
    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.

  16. #56
    Membre Expert
    Inscrit en
    avril 2007
    Messages
    831
    Détails du profil
    Informations forums :
    Inscription : avril 2007
    Messages : 831
    Points : 1 130
    Points
    1 130

    Par défaut

    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).

  17. #57
    Membre Expert
    Avatar de InOCamlWeTrust
    Inscrit en
    septembre 2006
    Messages
    1 036
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 1 036
    Points : 1 265
    Points
    1 265

    Par défaut

    Citation Envoyé par bluestorm Voir le message
    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.

    Citation Envoyé par bluestorm Voir le message
    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...

    Citation 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.
    When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.

  18. #58
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 263
    Points
    1 263

    Par défaut

    Citation Envoyé par InOCamlWeTrust Voir le message
    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...

  19. #59
    Expert Confirmé Sénior
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    avril 2003
    Messages
    6 175
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : avril 2003
    Messages : 6 175
    Points : 8 313
    Points
    8 313

    Par défaut

    Citation Envoyé par bluestorm Voir le message
    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ï

  20. #60
    alex_pi
    Invité(e)

    Par défaut

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




    Citation Envoyé par InOCamlWeTrust Voir le message
    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 :-)

    Citation Envoyé par InOCamlWeTrust Voir le message
    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.

    Citation Envoyé par InOCamlWeTrust Voir le message
    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


    Citation Envoyé par InOCamlWeTrust Voir le message
    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é :-)

    Citation Envoyé par InOCamlWeTrust Voir le message
    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 ?

    Citation Envoyé par Garulfo Voir le message
    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 :-)

    Citation Envoyé par bluestorm Voir le message
    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 :-)

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •