Publicité
+ Répondre à la discussion
Page 1 sur 8 12345 ... DernièreDernière
Affichage des résultats 1 à 20 sur 153
  1. #1
    Rédacteur/Modérateur

    Avatar de millie
    Profil pro
    Inscrit en
    juin 2006
    Messages
    6 945
    Détails du profil
    Informations personnelles :
    Localisation : Luxembourg

    Informations forums :
    Inscription : juin 2006
    Messages : 6 945
    Points : 9 779
    Points
    9 779

    Par défaut [Débat] Langage Fonctionnel vs Langage impératif

    Même si les langages fonctionnels et impératifs sont équivalents dans leurs possibilités à résoudre des problèmes. De nombreuses personnes se demandent quel paradigme de langage de programmation ils peuvent utiliser.

    Pour quel type de problèmes avez vous préférer privilégier un paradigme plutôt qu'un autre ?
    Pensez-vous que pour certains problèmes, l'un des paradigmes n'est pas envisageable ?

    D'autres comparaisons sont ouvertes.
    Je ne répondrai à aucune question technique en privé

  2. #2
    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

    Dans certains domaines, les bénéfices du paradigme fonctionnel sont très clairs. Typiquement, pour tout ce qui est manipulations symboliques (calcul formel, certaines parties des compilateurs/interpréteurs, etc...), les langages fonctionnels (et plus encore ceux qui, dérivés de ML, apportent les types algébriques et le filtrage de motifs) sont supérieurs aux langages impératifs.

    La situation existe sans doute aussi dans l'autre sens, mais cela me semble nettement moins clair : on dit souvent par exemple que la programmation impérative est plus adaptée pour faire des GUI (et d'ailleurs c'est souvent de POO qu'on parle quand "on" dit ça), mais en pratique les approches fonctionnelles de la GUI semblent relativement crédible (mais pas extrêmement utilisables pour l'instant car bénéficiant d'une faible puissance de développement, etc...), et je me demande si, à popularité égale, elles ne feraient pas au moins aussi bien.

    Évidemment, on peut dire que dans l'autre sens, il est possible de développer des bibliothèques dans des langages impératifs pour simplifier les manipulations symboliques et Cie. C'est vrai, mais cela revient alors plus à mon avis à intégrer des aspects fonctionnels au langage (comme on peut le faire dans tous les langages, j'ai vu des gens coder utiliser des fold_left fold_right en C ...). L'INRIA développe d'ailleurs dans cette optique une solution pour intégrer des filtrages de motifs aux langages mainstream (C++ et Java je crois), mais ça n'a pas l'air si populaire que ça pour l'instant. À l'inverse, je pense que le code écrit en Haskell avec des monades ne doit pas forcément être considéré comme "du paradigme fonctionnel", s'il reproduit le comportent d'un langage impératif.

    Il se pose donc la question de la pureté/mixité : certains langages sont tout-fonctionnel ou tout-impératif, mais la plupart mélangent les deux. Cela a des inconvénients, mais ça permet de ne pas avoir de gros problèmes si justement le paradigme principal du langage se retrouve inadapté à une situation donnée. Je pense que c'est alors plus une question de style et de conception que du langage en lui-même : quelqu'un qui écrirait en C++ dans un style fonctionnel (je crois que Boost permet de faire ça) fait de la programmation fonctionnelle.

    PS : il paraît que ce forum est "réservé aux professionnels". Je ne suis pas un professionel. Je suis venu ici parce que le sujet, initialement dans un forum que je fréquente, a été déplacé. Je trouve la restriction aux "professionnels" un peu ridicule, mais il suffit que vous le demandiez et je ne posterai plus ici.

  3. #3
    Rédacteur/Modérateur

    Avatar de millie
    Profil pro
    Inscrit en
    juin 2006
    Messages
    6 945
    Détails du profil
    Informations personnelles :
    Localisation : Luxembourg

    Informations forums :
    Inscription : juin 2006
    Messages : 6 945
    Points : 9 779
    Points
    9 779

    Par défaut

    Citation Envoyé par bluestorm Voir le message
    PS : il paraît que ce forum est "réservé aux professionnels". Je ne suis pas un professionel. Je suis venu ici parce que le sujet, initialement dans un forum que je fréquente, a été déplacé. Je trouve la restriction aux "professionnels" un peu ridicule, mais il suffit que vous le demandiez et je ne posterai plus ici.


    Il faut avouer que les professionnels des langages fonctionnels courent moins les rues que les professionnels de langages objet/impératif. J'ai remarqué que la plupart des contributeurs/utilisateurs des langages fonctionnels sur ce forum sont des étudiants (et qui sont souvent très bon). Donc il n'y a pas de problème s'il n'y a pas que des professionnels.
    Je ne répondrai à aucune question technique en privé

  4. #4
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 183
    Détails du profil
    Informations personnelles :
    Âge : 57

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 183
    Points : 14 353
    Points
    14 353

    Par défaut

    millie t'as finalement lancé le sujet

    bravo

    Citation Envoyé par millie Voir le message
    Il faut avouer que les professionnels des langages fonctionnels courent moins les rues que les professionnels de langages objet/impératif. J'ai remarqué que la plupart des contributeurs/utilisateurs des langages fonctionnels sur ce forum sont des étudiants (et qui sont souvent très bon). Donc il n'y a pas de problème s'il n'y a pas que des professionnels.

    peut-être serait-ce justement parce que cela a un intérêt théorique, mais bien peu d'intérêt pratique ??

    Comme j'ai déjà eu l'occasion de le dire ailleurs, ce que j'en vois me semble complètement obscur comme notation (de ce que j'ai aperçu de Haskell sur ces forums). (et j'ai pourtant touché à pas mal de langages, et physicien à l'origine)..

    De même, le mélange de fonctionalités nécessaires dans un code "industriel" (accès aux fichiers, aux périphériques, manipulations d'images, de structures complexes en mémoire, calculs prolongés, voire itératifs, "événements et callbacks", sockets, accès BD, etc..., le tout au sein du même logiciel), facilement maintenable et débuggable par un technicien de maintenance niveau bac+2, ou au contraire par un scientifique raisonnant depuis belle lurette sur la FONCTIONALITE, les 2 éventuellement (et souvent) de cultures différentes (dans un autre pays par exemple), et pour un logiciel dont la durée de vie OPERATIONNELLE est supérieure à 2 ans, ne m'apparaît pas des plus évidents avec ce que je vois...

    Par exemple, je travaille en ce moment sur un code opérationnel depuis 30 ans... Il fut transfromé de Fortran en C il y a environ 18 ans. Mais là (et même si il passera sans doute à C++), le "portage" s'arrêtera.. Avec des gens de plus de la moitié du globe y travaillant, prendre un langage d'initiés serait du suicide...

    J'ai eu le même genre d'expérience avec Prolog : dans un projet sur lequel j'étais, un universitaire avait fait une partie en Prolog, trouvant que ça collait bien à l'esprit du problème (un système expert). Le mainteneur (scientifique) final avait appris le langage (déjà un investissement..). MAIS surtout le point qu'il avait négligé, c'est qu'opérationnelement, ça ne passait pas ...: temps de réponse de plus de 1000 fois supérieur à la traduction en C...


    Comme nous le répétons en permanence sur le forum C, un code utilisant toutes les astuces du langage (faire une fonction de 10 lignes en 1) peut-être le fun, mais est FORMELLEMENT DECONSEILLE pour un logiciel industriel..

    La "simplicité" d'écriture qu'on ma déjà répondue en Haskell sur d'autres posts (je ne peux parler des autres langages, ne les connaissant pas) est à mon avis du même style....

    Et dans le fond, je ne comprends pas bien en quoi on appelle cela des "langages fonctionnels" par opposition aux autres... Comme pour l'OO. Pour moi, c'est la PENSEE et l'ANALYSE qui doivent être fonctionnelles et OOs. Le code, comme les équations pour un physicien, n'est qu'un outil. Et dans la quasi-totalité des projets sur lesquels j'ai travaillé, les "programmeurs" (pour la plupart ingénieurs ou physiciens, ou sinon avec DEUG ou maîtise (ou doctorat) d'informatique) étaient plus à l'aise pour commnuiquer avec ce qu'ils utilisaient tous les jours.... (par exemple, les ingénieurs souvent interfaçaient leurs voltmètres numériques ou autres appareils de mesure avec des programmes en Pascal, ou en C. Et les NOTATIONS se ressemblent et entre eux, et avec les maths, ainsi que les paradigmes. Quasi aucun mot ou concept nouveau).

    Et je dois dire que, ayant toujours été physicien et travaillant sur des projets impliquant des maths et de la physique, les notations utilisées (j'y reviens) ressemblent beaucoup plus à ce que j'utilise d'autre part que ce à que j'ai vu des langages "fonctionnels.., et la fonctionnalité est parfaitement visible et décrite et compréhensible avec les langages dits "impératifs"...

    Je soupçonne donc fortement un courant de recherches universitaires dans le domaine..... (comme sur les sujets de la preuve formelle ou des modélisations de code diverses et variées)..

    Mais peut-être n'ai je vu que l'arbre qui cachait la forêt ??
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  5. #5
    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

    Comme j'ai déjà eu l'occasion de le dire ailleurs, ce que j'en vois me semble complètement obscur comme notation (de ce que j'ai aperçu de Haskell sur ces forums). (et j'ai pourtant touché à pas mal de langages, et physicien à l'origine)..
    C'est vrai, c'est particulier comme notation et comme vocabulaire.
    Pour un programmeur Fortran/Java/C, une phrase comme "la currification exprime le fait que la flèche est associative à droite" semble venue d'une autre planête.
    De ce côté là (purement syntaxique) il me semble qu'Anubis a fait un pas important, sa syntaxe est beaucoup plus commune.
    De même, le mélange de fonctionalités nécessaires dans un code "industriel" ... ne m'apparaît pas des plus évidents avec ce que je vois
    Quand c'est inutilisable il ne faut pas l'utiliser.
    temps de réponse de plus de 1000 fois supérieur à la traduction en C...
    C'est un fait anecdotique. De plus votre présentation est partiale: vous ne dites pas combien de temps de développement le prototypage en Prolog vous a fait gagné comparé à un devéloppement C partant de rien. Enfin, Prolog n'est pas un langage fonctionnel, ce qui bien entendu ne veut pas dire que Prolog ne "fonctionne" pas.
    Et dans le fond, je ne comprends pas bien en quoi on appelle cela des "langages fonctionnels" par opposition aux autres...
    Pas par opposition aux autres, uniquement pour des raisons historiques, c'est-à-dire l'enracinement dans la modélisation des fonctions (en 1920 Schönfinkel a défini les 3 combinateurs S, K et I qui suffisent à implémenter le lambda-calcul). Le mot "fonctionnel" n'a jamais été motivé par un argument publicitaire et n'a rien de dénigrant pour les autres langages. Vous pourriez les appeler des langages "fonctoriels" ça ne changerait pas grand chose au débat.
    Pour moi, c'est la PENSEE et l'ANALYSE qui doivent être fonctionnelles et OOs. Le code, comme les équations pour un physicien, n'est qu'un outil.
    En programmation fonctionnelle je n'ai jamais constaté cette distinction que vous faites entre analyse et implémentation. C'est justement cette scission qui devient obsolète en programmation fonctionnelle. Quant à la pensée elle restera toujours humaine, elle ne sera jamais OO ou fonctionnelle.

    La suite de votre message ne fait qu'affirmer combien les langages impératifs vous conviennent plus aisément, nul doute de ma part que vos choix soient les meilleurs pour vous, puisque vous en témoigner avec autant de sincérité.

    Il est dommage que votre intervention se termine sur une note un peu plus accusatrice.
    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.

  6. #6
    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 311
    Points
    8 311

    Par défaut

    Je ne suis pas sûr que l'avis de Souviron soit vraiment représentatif... Soyons clair : pour Souviron seul C et Fortran vaillent le coup et tous les autres langages sont des gadgets.

    Quand on est aussi enraciné dans ses habitudes, il est peu probable qu'on fasse le saut conceptuel nécessaire pour passer au fonctionnel. Il est bien connu que plus on a passé de temps à faire de l'impératif avant de toucher au fonctionnel plus le passage est rude, Souviron est un professionnel de grande qualité, mais il est parfaitement satisfait par ses outils actuels avec lesquels il a une très grande expérience et il n'est pas très curieux par ailleurs, en tant que tel, il ne représente pas une cible réaliste pour les langages fonctionnels.

    Adressons tout de même certaines des critiques :
    Comme j'ai déjà eu l'occasion de le dire ailleurs, ce que j'en vois me semble complètement obscur comme notation (de ce que j'ai aperçu de Haskell sur ces forums). (et j'ai pourtant touché à pas mal de langages, et physicien à l'origine)..
    Je ne vois pas ce que ces notations ont de "complètement obscures", tous les langages ont des particularités syntaxiques, les langages fonctionnels ne sont pas plus étrange que FORTH ou Smalltalk pour prendre des exemples un peu extrèmes... Au contraire et comme je l'ai déjà souligné dans d'autres réponses à Souviron, la notation fonctionnelle est très proche des mathématiques.

    De même, le mélange de fonctionalités nécessaires dans un code "industriel" (accès aux fichiers, aux périphériques, manipulations d'images, de structures complexes en mémoire, calculs prolongés, voire itératifs, "événements et callbacks", sockets, accès BD, etc..., le tout au sein du même logiciel), facilement maintenable et débuggable par un technicien de maintenance niveau bac+2, ou au contraire par un scientifique raisonnant depuis belle lurette sur la FONCTIONALITE, les 2 éventuellement (et souvent) de cultures différentes (dans un autre pays par exemple), et pour un logiciel dont la durée de vie OPERATIONNELLE est supérieure à 2 ans, ne m'apparaît pas des plus évidents avec ce que je vois...
    Les langages fonctionnels proposent des modèles de modularité excellent et permettent d'écrire des codes très complexes et très composés. Par contre il est vrai qu'ils manquent parfois de bibliothèques pour certaines tâches, mais ce n'est dû qu'à un manque de popularité des langages en question. Or justement ces langages semblent connaître un regain d'intérêt qui pourrait bien aider à combler ces lacunes.

    Pour adresser certains points, les accès aux fichiers ou aux périphériques ne sont pas plus difficiles avec un langage fonctionnel qu'avec tout autre langage (bien que les mots "monade IO" puissent vous effrayer, au final le code résultant vous semblera très très familier), les sockets et les accès à des BD sont tout aussi couverts, les structures de données complexes en mémoire sont bien plus aisément manipulables avec les langages fonctionnels (ça fait partie de leur spécialités), "évènement et callbacks" ça existe (la notion de callback est typiquement du fonctionnel), manipulation d'image est une question de librairie, etc...

    Comme nous le répétons en permanence sur le forum C, un code utilisant toutes les astuces du langage (faire une fonction de 10 lignes en 1) peut-être le fun, mais est FORMELLEMENT DECONSEILLE pour un logiciel industriel..

    La "simplicité" d'écriture qu'on ma déjà répondue en Haskell sur d'autres posts (je ne peux parler des autres langages, ne les connaissant pas) est à mon avis du même style....
    C'est là où vous faites une grosse erreur, passer de 10 à 1 lignes en C exige d'utiliser des constructions obscures et fondamentalement de rendre le code illisible, en Haskell le fait que la même opération ne prenne qu'une ligne traduit simplement le degré d'abstraction supérieur auquel opère le langage, la syntaxe employée est parfaitement ordinaire et la fonction reste parfaitement lisible par quelqu'un qui a déjà fait du Haskell (même s'il met autant de temps à la lire qu'il aurait lu 3 lignes en C, après tout c'est normal si elle en fait autant que 10 lignes de C).

    Et dans le fond, je ne comprends pas bien en quoi on appelle cela des "langages fonctionnels" par opposition aux autres...
    "fonctionnel" ici n'a aucun rapport avec "fonctionnalité" comme vous semblez le penser. Ainsi que l'a dit SpiceGuid, le nom "fonctionnel" se rapporte à un modèle de calcul, le lambda-calcul qui met en avant les fonctions, et seulement les fonctions, comme bloc de base de tout calcul.

    Pour en revenir au sujet, ces dernières années, Erlang, Haskell et d'autres ont commencé à percer un peu, il pourrait être intéressant de suivre cette tendance. Des initiatives comme la CUFP gagne en suivi chaque année, même s'ils restent pour l'instant minuscules.

    --
    Jedaï

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

    Pour quel type de problèmes avez vous préférer privilégier un paradigme plutôt qu'un autre ?
    Déjà, j'évite les langages qui m'enferment dans un paradigme précis. Je préfère avoir le choix. Au final, j'utilise le fonctionnel très souvent, mais parfois faire quelques effets de bord (modifier une variable ou utiliser une table de hachage) rend service. Quand je fais de l'impératif, j'essaie de limiter la portée au maximum.

    L'INRIA développe d'ailleurs dans cette optique une solution pour intégrer des filtrages de motifs aux langages mainstream (C++ et Java je crois), mais ça n'a pas l'air si populaire que ça pour l'instant.
    Dans la même idée, je recommande de se renseigner sur les active patterns de F#. C'est une extension du pattern matching et cela permet de filtrer sur toutes sortes de types (même ceux dont le type exact est caché). L'application courante est d'avoir du pattern matching sur les types de la bibliothèque .NET, ou déclarés dans du code C#. Par exemple, du pattern matching sur des regexp ou sur l'objet XML de .NET.

    PS : il paraît que ce forum est "réservé aux professionnels".
    Je crois qu'il faudrait lire "réservé aux personnes compétentes", mais ce serait une distinction un peu trop subjective.

    Comme nous le répétons en permanence sur le forum C, un code utilisant toutes les astuces du langage (faire une fonction de 10 lignes en 1) peut-être le fun, mais est FORMELLEMENT DECONSEILLE pour un logiciel industriel..
    Il ne s'agit pas du tout de la même chose. Le C permet parfois de remplacer 10 lignes d'assembleur par 1 ligne de code, est-ce mal ? Non, puisque très souvent, ça devient plus clair. En utilisant un langage de haut-niveau, on rencontre souvent le même phénomène. Utiliser un opérateur pour concaténer des chaines est souvent plus clair que son équivalent C. Je n'ai pas envie de développer plus, même si j'aurais beaucoup d'arguments, car ça change le débat : tes attaques ne visent pas le paradigme fonctionnel, mais plutôt les langages haut-niveau. Depuis que je ne code plus en C — et même si j'ai beaucoup codé en C il y a quelques années — j'ai augmenté ma productivité par un facteur 10. Par chance, mon code est aussi plus sûr (car vérifié par mon compilateur), et les différences de performances sont généralement négligeables.


    Parmi les fonctionnalités qui me manquent cruellement quand je dois utiliser un langage non fonctionnel, il y a surtout les types somme, le pattern matching, l'inférence de types et les fonctions d'ordre supérieur.

    Enfin, j'ai une très large préférence pour les langages expressifs (donc, concis) et sûrs (typage statique et fort). Étonnamment, dans cette catégorie, je n'ai trouvé que des langages à dominante fonctionnelle. Mon choix s'est finalement porté sur F#, pour bénéficier d'une large bibliothèque et de l'interopérabilité avec les langages plus populaires (C#, C++, etc.).

  8. #8
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 183
    Détails du profil
    Informations personnelles :
    Âge : 57

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 183
    Points : 14 353
    Points
    14 353

    Par défaut

    Citation Envoyé par SpiceGuid Voir le message
    Il est dommage que votre intervention se termine sur une note un peu plus accusatrice.

    Je ne vois pas en quoi le fait de parler de recherches universitaire est accusateur ??


    Citation Envoyé par Jedai Voir le message
    Je ne suis pas sûr que l'avis de Souviron soit vraiment représentatif... Soyons clair : pour Souviron seul C et Fortran vaillent le coup et tous les autres langages sont des gadgets.
    Non, c'est faux.

    Simplement, pour répondre à vous 2, ce que je disais répondait à la question et aux remarques de Millie, de ce qu'en j'en voit dans mon expérience (qui commence quand même à être assez vaste).

    Je "fréquente" le milieu industriel et informatique industriel depuis maintenant 28 ans..

    A part pour quelques petits projets subventionnés par le gouvernement où le financement vient A CAUSE d'une optique de recherche fondamentale "éventuellment aplliquée", je CONSTATE la réalité de ce que je dis, dans une grande variété de domaines, d'industries, et de pays.

    Que votre expérience soit différente, j'en conviens, c'est bien pour ça que j'ai dis "peut-être que je n'ai vu que l'arbre qui cache la forêt".

    Mais je maintiens que je suppose que la raison de la non-utilisation PEUT etre le fait que c'est plutôt orienté et utilisé Recherche

    Et je maintiens, Jedai, que la notation est ésotérique.

    Et je remercie SpiceGuid de m'avoir éclairé sur la définition.
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  9. #9
    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

    La syntaxe ne devrait pas être un obstacle majeure. En quelques semaines on peut se familiariser à une syntaxe différente. D'ailleurs la syntaxe du Fortran ne me semble pas très proche de celle du C.

    Il existe des utilisations de langages fonctionnels dans l'industrie, que ce soit en lien avec des instituts de recherche (le projet Astrée en aéronautique) ou pas (j'ai découvert tout récemment qu'Exalead, la boite (française) derrière le moteur de recherche du même nom, utilise OCaml en interne, et recrute un codeur OCaml). Les langages dérivés de ML (OCaml et Haskell en particulier) ont aussi des partisans dans la finance par exemple.

    Mais je maintiens que je suppose que la raison de la non-utilisation PEUT etre le fait que c'est plutôt orienté et utilisé Recherche
    . Je suis d'accord avec toi sur ce point, mais c'est une particularité de nature "sociologique" et pas fondamentale : le fait de savoir qu'historiquement les langagages fonctionnels ont été réservés aux milieux de recherche, et qu'ils ne sont acceptés dans l'industrie que lentement, et surtout dans les niches à "haute qualification" ne nous renseigne pas sur la question du fond, c'est à dire l'adaptation du paradigme fonctionnel (et donc des langages fonctionnels, actuels ou futurs) à l'industrie de la programmation dans son ensemble (ou au moins une partie plus large qu'actuellement).

    À ce sujet, on aime bien faire référence au discours de Tim Sweeney, célèbre programmeur du jeu vidéo (Unreal Engine...), qui expose les avantages qu'auraient une intégration de langages fonctionnels dans son industrie : The Next Mainstream Programming Language : A Game's Developper Perspective.

  10. #10
    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

    Et je maintiens, Jedai, que la notation est ésotérique.
    Elle est différente de la syntaxe du C. Beaucoup sont habitués aux langages descendant du C, ce qui peut déconcerter au début. Mais la syntaxe n'est pas moins accessible que celle du C. Il m'est arrivé d'enseigner Caml à des débutants, ils n'avaient aucune difficulté avec la syntaxe.

    Ce qui est dur, ce n'est pas d'apprendre une autre syntaxe, c'est de comprendre un autre paradigme.

    Mais je maintiens que je suppose que la raison de la non-utilisation PEUT etre le fait que c'est plutôt orienté et utilisé Recherche
    Je ne crois pas.

    La popularité du C s'est bâtie pour des raisons historiques, notamment avec Unix. Celle de C++ vient de sa compatibilité avec le C. La popularité de Java, puis celle de C#, vient de : la large bibliothèque intégrée, le soutien de grandes entreprises et la proximité avec le C++.

    Les langages fonctionnels n'ont pas bénéficié d'un tel soutien. L'apprentissage d'un nouveau paradigme étant plus compliqué que celui d'une nouvelle syntaxe, apprendre un langage fonctionnel demande un effort, pour ceux qui sont habitués aux C-like.

    Si les entreprises sont réticentes à utiliser un langage fonctionnel, c'est entre autres parce que :
    - ce ne sont pas toujours les personnes compétentes techniquement qui décident (et les décideurs ne connaissent pas Haskell)
    - il y a peu de développeurs disponibles (difficulté de recrutement, coût des formations, etc.)
    - la compatibilité avec le code existant n'est pas toujours possible
    - il y a souvent un manque de bibliothèques

    C'est problèmes ne sont pas spécifiques au fonctionnel, les autres langages les rencontrent aussi. Je dirais que le problème ne vient pas du paradigme en lui-même, mais plutôt que beaucoup de gens refusent de faire l'effort de changer.

    Cela dit, on peut trouver un certain d'utilisations professionnelles de la programmation fonctionnelle. Microsoft utilise et investit de plus en plus dans ce domaines, d'autres entreprises aussi ; de plus en plus d'étudiants apprennent ce paradigme. Je pense donc qu'il est amené à se développer, surtout qu'il possède de nombreuses propriétés intéressantes (pour la sûreté, pour la programmation concurrente, etc.).

    Mais surtout, il ne faut pas s'arrêter sur "les entreprises utilisent peu le fonctionnel, donc ça ne vaut pas le coup". En utilisant Caml ou F#, ma productivité a augmenté de façon considérable par rapport à l'époque où je devais coder en C ou C++. Ce n'est pas juste une constatation personnelle, tout le monde peut le remarquer : le code est 10 fois plus court, il est plus sûr (il n'y a jamais d'erreur de segmentation ou de NullPointerException) et bien plus lisible, pour quiconque connait le langage. Certains langages partagent cette concision (Python, Ruby...), d'autres cette sûreté (Ada, parait-il), mais je ne connais que des langages fonctionnels qui réussissent les deux.

  11. #11
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 183
    Détails du profil
    Informations personnelles :
    Âge : 57

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 183
    Points : 14 353
    Points
    14 353

    Par défaut

    Citation Envoyé par bluestorm Voir le message
    La syntaxe ne devrait pas être un obstacle majeure. En quelques semaines on peut se familiariser à une syntaxe différente. D'ailleurs la syntaxe du Fortran ne me semble pas très proche de celle du C.
    Ah bon ?

    FOR ou for, WHILE ou while, INTEGER ou int, REAL ou double, OPEN ou fopen, WRITE ou fwrite, READ ou fread, etc etc..

    ça se ressemble pas mal..

    Je suis d'accord qu'en quelques semaines on peut se familiariser avec quelque chose de nouveau.

    Mais c'est justement ces quelques semaines que je conteste par rapport aux arguments "mais non, c'est instantané si on a fait des maths"..
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  12. #12
    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

    j'ai mal interprété votre "forte suspicion", bien sûr que les langages fonctionnels tirent leurs origines des mathématiques et cela ralenti un peu leur diffusion à l'extérieur des domaines apparentés à la recherche.
    Mais je maintiens que je suppose que la raison de la non-utilisation PEUT etre le fait que c'est plutôt orienté et utilisé Recherche
    C'est en effet un des éléments importants qui expliquent pourquoi un paradigme aussi vieux ne s'est toujours pas démocratisé.
    Et je maintiens, Jedai, que la notation est ésotérique.
    Jedai fait l'autruche, la notation est ésotérique, le système de typage est ésotérique, et c'est encore pire si l'on s'oriente vers les systèmes de preuve. Mais c'est surtout une question d'apprentissage.
    Pour avoir utilisé un peu Anubis je peux garantir qu'il apporte une réponse satisfaisante à cette inquiétude (qu'il convienne ou non pour vos développements en informatique industrielle ne me regarde pas).
    je CONSTATE la réalité de ce que je dis, dans une grande variété de domaines, d'industries, et de pays.
    Nous ne sommes pas coupés du monde, moi aussi je constate que l'usage des langages fonctionnels dans le monde économique est plutôt confidentiel.
    Peut-être serait-ce justement parce que cela a un intérêt théorique, mais bien peu d'intérêt pratique ??
    Avec des initiatives comme F# ou Cafestérol il sera bientôt plus facile d'interfaçer avec les standards industriels, petit à petit les multiples obstacles pratiques que vous avez mentionnés vont s'aténuer ou disparaître.
    Mais c'est justement ces quelques semaines que je conteste par rapport aux arguments "mais non, c'est instantané si on a fait des maths"..
    Quelques semaines pour passer au paradigme fonctionnel ?
    Oui, mais alors pour un élève doué chapoté par un mentor expérimenté.
    Sinon mieux vaut poursuivre en C plutôt que d'aller droit à l'abattoir.

    En informatique comme ailleurs il n'y a aucune pratique qui soit "instantanée", "naturelle", "intuitive", "conviviale", ce ne sont que des slogans.
    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.

  13. #13
    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

    FOR ou for, WHILE ou while, INTEGER ou int, REAL ou double, OPEN ou fopen, WRITE ou fwrite, READ ou fread, etc etc..
    OCaml a des keywords "for" et "while" (assez rarement utilisé par rapport à du Fortran, mais quand même), des fonctions openfile, write et read (dans le module Unix), des types de donnée "int" et "float" (mais on ne les utilise pas dans les déclarations, car le type est inféré : on met simplement "let" : let x = 2).
    Ça ne montre pas grand chose.

    SpiceGuid : on parlait seulement de la syntaxe pour les "quelques semaines". Par ailleurs, pour ce qui est d'un langage fonctionnel C-friendly, je penserais plutôt à Nemerle, qui est quand même bien plus "décideur ready" qu'Anubis. (Même si boouh, c'est .NET )

  14. #14
    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 311
    Points
    8 311

    Par défaut

    Citation Envoyé par SpiceGuid Voir le message
    Jedai fait l'autruche, la notation est ésotérique, le système de typage est ésotérique, et c'est encore pire si l'on s'oriente vers les systèmes de preuve. Mais c'est surtout une question d'apprentissage.
    Je fais l'autruche ? Tu as déjà utilisé du Forth ou du Smalltalk ? Tu peux me dire les yeux dans les yeux que la syntaxe du Forth ou du Smalltalk est plus proche du C que celle de Haskell/OCaml ?
    Je n'ai pas dit que la syntaxe était identique à celle du C, elle ne l'est pas, mais globalement le truc le plus traumatisant pour un programmeur C c'est le fait qu'il n'y a pas de parenthèses et de virgules autour des paramètres de fonctions... Est-ce vraiment si dur ?
    La définition de fonction est un peu différente, mais c'est le cas de tous les langages, il n'y a que les gens qui n'ont fait que du C et dérivés (C++, Java, ...) pour croire qu'il y a un "standard" de définitions de fonctions.

    Le système de typage est ésotérique ? Ok, on remplace les "," par des "->", je comprend que ça soit un choc !
    Sinon voyons Int, Float, Double, Bool, ... Maybe Bool, je suis sûr que quelqu'un qui a des List<Iterator<...>, Matrix<double,double>> dans son code C++ ne peut pas comprendre ça : c'est manifestement trop complexe.

    Que la syntaxe soit différente, d'accord, qu'elle soit "ésotérique" ? C'est une qualification ridicule, moi aussi je peux dire que les "*" et les "&" du C sont "ésotériques" et effrayer les non-initiés.


    Citation Envoyé par SpiceGuid Voir le message
    Pour avoir utilisé un peu Anubis je peux garantir qu'il apporte une réponse satisfaisante à cette inquiétude (qu'il convienne ou non pour vos développements en informatique industrielle ne me regarde pas).
    Anubis n'est pas le seul langage à avoir une syntaxe un peu plus C-friendly, déjà Erlang a des parenthèses autour de ses arguments, et nul ne peut raisonnablement arguer qu'Erlang n'a pas fait ses preuves en tant que langage industriel.

    Citation Envoyé par SpiceGuid Voir le message
    Nous ne sommes pas coupés du monde, moi aussi je constate que l'usage des langages fonctionnels dans le monde économique est plutôt confidentiel.
    Je ne crois pas que personne ait jamais prétendu le contraire, c'est même l'une des raison d'être de ce thread, . Néanmoins ce n'est pas un argument, ce n'est pas parce qu'un paradigme n'est pas répandu qu'il est forcément inadapté. Il y a eu pas mal de problème technique à l'origine pour la compilation de langages fonctionnels, lesquels sont aujourd'hui en grande part résolus comme pourront l'attester tous les utilisateurs de OCaml et GHC. Par ailleurs le poids de l'histoire, des OS et des bibliothèques n'ont pas favorisé le fonctionnel, pendant une longue période. C'est là la vrai raison de leur faiblesse relative aujourd'hui.

    Citation Envoyé par Souviron34
    FOR ou for, WHILE ou while, INTEGER ou int, REAL ou double, OPEN ou fopen, WRITE ou fwrite, READ ou fread, etc etc..
    Il y a un for en Haskell. Il y a un until, il y a un openFile, il y a un writeFile (ou un hPrint, h pour handle), un readFile (ou hGetLine), etc... int s'appelle Int, double s'appelle Double... Cependant les différences entre syntaxes sont bien plus profondes que de simples problèmes de mots clés.

    Le vrai problème pour passer du C à un langage fonctionnel réside dans la compréhension du paradigme, pas dans une syntaxe soi-disant "ésotérique".

    Citation Envoyé par Souviron34
    Citation Envoyé par Jedai
    Je ne suis pas sûr que l'avis de Souviron soit vraiment représentatif... Soyons clair : pour Souviron seul C et Fortran vaillent le coup et tous les autres langages sont des gadgets.
    Non, c'est faux.
    Ah bon ? J'ai déjà participé à quelques débats avec vous, et j'en ai lu encore plus. L'impression que j'en ai retiré c'est que vous ne croyez pas aux langages de haut-niveau (quel que soit le paradigme), vous êtes persuadé qu'ils n'apportent rien, aurais-je mal interprété votre position ?

    --
    Jedaï

  15. #15
    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

    Le système de typage est ésotérique ? Ok, on remplace les "," par des "->", je comprend que ça soit un choc !
    Oui, enfin, je suis prêt à croire qu'on se sent un peu dépourvu quand on tombe sur un "existentially quantified type" (bon, ok, c'est pas dans le standard de 98).

    Je pense qu'ils n'ont pas totalement tort : en effet, les différences syntaxiques entre Haskell et C ne sont pas forcément plus renversantes qu'entre C et Smalltalk, mais... personne n'utilise le Smalltalk non plus !
    La syntaxe est vraiment différente (même moi, en venant de OCaml, j'ai du m'adapter à la syntaxe de Haskell, que je ne maîtrise toujours pas par manque de pratique (c'est sûrement pareil dans l'autre sens)).

    C'est encore plus flagrant pour le système de types. Je ne pense pas qu'on puisse comparer le typage du C et celui de ML en disant "c'est presque pareil". Il y a quand même un saut conceptuel à franchir (déjà, un type paramétré...). Évidemment, avec le C++ c'est un peu différent, puisqu'ils mangent des templates souvent. Bref, c'est quand même différent.

    Après, tu peux dire que ce n'est pas si difficile, et tu as raison. Il faut un temps d'adaptation, mais rien de surhumain (par contre, connaître assez profondément OCaml, ou plus encore le Haskell pratiqué actuellement, est beaucoup plus difficile, et demande de la pratique).

  16. #16
    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 311
    Points
    8 311

    Par défaut

    Citation Envoyé par bluestorm Voir le message
    Je pense qu'ils n'ont pas totalement tort : en effet, les différences syntaxiques entre Haskell et C ne sont pas forcément plus renversantes qu'entre C et Smalltalk, mais... personne n'utilise le Smalltalk non plus !
    La syntaxe est vraiment différente (même moi, en venant de OCaml, j'ai du m'adapter à la syntaxe de Haskell, que je ne maîtrise toujours pas par manque de pratique (c'est sûrement pareil dans l'autre sens)).

    Après, tu peux dire que ce n'est pas si difficile, et tu as raison. Il faut un temps d'adaptation, mais rien de surhumain (par contre, connaître assez profondément OCaml, ou plus encore le Haskell pratiqué actuellement, est beaucoup plus difficile, et demande de la pratique).
    Je ne dis pas qu'apprendre Haskell ou un quelconque langage fonctionnel est facile, je dis simplement que les problèmes d'apprentissage ne viennent pas de la syntaxe qui n'a rien d'"ésotérique", mais bien plutôt du paradigme fonctionnel, surtout administré complètement pur, sans aucune dilution, comme dans Haskell.

    Citation Envoyé par bluestorm Voir le message
    C'est encore plus flagrant pour le système de types. Je ne pense pas qu'on puisse comparer le typage du C et celui de ML en disant "c'est presque pareil". Il y a quand même un saut conceptuel à franchir (déjà, un type paramétré...). Évidemment, avec le C++ c'est un peu différent, puisqu'ils mangent des templates souvent. Bref, c'est quand même différent.
    Bien sûr, on espère bien que les types de Haskell sont plus avancés vu que l'un des objectifs c'est tout de même d'assurer plus de sécurité avec un système de type plus fort... D'un autre côté, en C tu as tout de même des struct, des unions, des enums, des pointeurs de fonctions... Le système de type n'est pas aussi simple que tu sembles l'impliquer, et ça m'étonnerait que beaucoup de débutants (même assez avancés) le maitrise sur le bout des doigts.

    Citation Envoyé par bluestorm Voir le message
    Oui, enfin, je suis prêt à croire qu'on se sent un peu dépourvu quand on tombe sur un "existentially quantified type" (bon, ok, c'est pas dans le standard de 98).
    Comme tu dis, ce n'est dans H98, et la plupart des gens, même des experts, ne l'utilise pas dans leur code (sauf parfois indirectement par le biais d'une librairie).

    Citation Envoyé par bluestorm Voir le message
    Je pense qu'ils n'ont pas totalement tort : en effet, les différences syntaxiques entre Haskell et C ne sont pas forcément plus renversantes qu'entre C et Smalltalk, mais... personne n'utilise le Smalltalk non plus !
    Exact, et c'est bien dommage... Enfin je pense tout de même que Smalltalk est encore plus utilisé que les langages fonctionnels, il y a plusieurs versions commerciales qui continuent d'exister à l'heure actuelle. Et je ne vois pas en quoi ça vient infirmer mon argument : la syntaxe de Smalltalk est tout sauf "ésotérique", elle peut s'enseigner en une petite heure et est bien plus simple que celle du C. "ésotérique" implique une complexité entourée de mystère, ni la syntaxe d'Haskell, ni celle de Smalltalk ne justifient ce qualificatif. Et elle n'est pas non plus ésotérique parce qu'elle serait très éloigné de tout autre modèle existant, elle ressemble beaucoup à la syntaxe des maths classiques après tout.

    Citation Envoyé par bluestorm Voir le message
    La syntaxe est vraiment différente (même moi, en venant de OCaml, j'ai du m'adapter à la syntaxe de Haskell, que je ne maîtrise toujours pas par manque de pratique (c'est sûrement pareil dans l'autre sens)).
    Qu'est-ce qui t'a posé problème principalement, et qu'est-ce qui te pose encore problème ? Personnellement je ne vois pas grande différence syntaxique entre les deux, sauf des points de détails, les différences "philosophiques" m'apparaissent bien plus importantes par comparaison.

    --
    Jedaï

  17. #17
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro Nicolas Vallée
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 217
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Vallée
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 217
    Points : 17 566
    Points
    17 566

    Par défaut

    Citation Envoyé par Jedai Voir le message
    Qu'est-ce qui t'a posé problème principalement, et qu'est-ce qui te pose encore problème ? Personnellement je ne vois pas grande différence syntaxique entre les deux, sauf des points de détails, les différences "philosophiques" m'apparaissent bien plus importantes par comparaison.


    personnellement, je suis également dans ce cas... je connais suffisamment OCaml pour faire à peu près ce que je souhaite avec, mais pour Haskell bien que j'ai traduit et testé tous les exemples du gentle introduction, je suis dans l'incapacité de sortir des cas d'école, car je maitrise pas du tout la libraire standard, et donc je dois passer mon temps à chercher ou à réinventer la roue

    le hic c'est aussi l'existence de différentes versions pas forcemment super compatibles entre elles (librairies communes)... perso, j'avais commencé avec hugs car c'est celle utilisée dans le gentle, puis je suis passé (sur tes conseils je crois ^^) à ghc, et y a parfois des trucs qui changent
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  18. #18
    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 311
    Points
    8 311

    Par défaut

    Citation Envoyé par gorgonite Voir le message
    personnellement, je suis également dans ce cas... je connais suffisamment OCaml pour faire à peu près ce que je souhaite avec, mais pour Haskell bien que j'ai traduit et testé tous les exemples du gentle introduction, je suis dans l'incapacité de sortir des cas d'école, car je maitrise pas du tout la libraire standard, et donc je dois passer mon temps à chercher ou à réinventer la roue
    D'un autre côté, maitriser la librairie standard de n'importe quel langage qu'on n'utilise pas très souvent n'est pas évident. Cependant entre les librairies de OCaml et celles de Haskell il y a beaucoup de similarité, tu peux également t'aider de Hoogle (qui te permet de chercher une fonction par nom ou par type, très pratique).

    Citation Envoyé par gorgonite Voir le message
    le hic c'est aussi l'existence de différentes versions pas forcemment super compatibles entre elles (librairies communes)... perso, j'avais commencé avec hugs car c'est celle utilisée dans le gentle, puis je suis passé (sur tes conseils je crois ^^) à ghc, et y a parfois des trucs qui changent
    Les fonctions du prélude restent identiques, les changements sont tout de même mineurs (si tu t'en tiens aux fonctions de base, je doute par exemple que ça fasse la moindre différence pour le Gentle). Néanmoins il est vrai que ça peut être déroutant, je conseillerais plutôt de s'en tenir à GHC sauf si on est intéressé par le développement d'un des autres compilateurs Haskell.

    --
    Jedaï

  19. #19
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro Nicolas Vallée
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 217
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Vallée
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 217
    Points : 17 566
    Points
    17 566

    Par défaut

    merci pour hoogle... mieux que google effectivement


    Citation Envoyé par Jedai Voir le message
    Les fonctions du prélude restent identiques, les changements sont tout de même mineurs (si tu t'en tiens aux fonctions de base, je doute par exemple que ça fasse la moindre différence pour le Gentle). Néanmoins il est vrai que ça peut être déroutant, je conseillerais plutôt de s'en tenir à GHC sauf si on est intéressé par le développement d'un des autres compilateurs Haskell.


    ben j'ai fini par criser au moment du défi fonctionnel sur le client/serveur tcp... parce que l'évaluation paresseuse de Haskell me semblait être un avantage (pas besoin de select & cie), mais j'ai jamais réussi à trouver de quoi jouer
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  20. #20
    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

    Qu'est-ce qui t'a posé problème principalement, et qu'est-ce qui te pose encore problème ?
    Visuellement, le plus étrange pour moi sont les gardes (enfin les tests de booléens bizarres de déclaration de fonction). Évidemment, ce n'est pas un point majeur (mais on parle de syntaxe, alors rien n'est vraiment "majeur").

    Le plus gênant pour écrire est que je ne comprend en gros rien aux règles de layout. Quand on lit du code, c'est évident, mais quand j'écris je me retrouve toujours à appuyer sur "tab" comme un con en attendant que mon mode emacs me trouve une position qui me semble crédible. Ça marche très bien, mais c'est assez mentalement déroutant
    ( je sais qu'il existe une syntaxe sans meaningful-indentation, mais on a envie de coder comme le reste des gens, en général )

    Par ailleurs, permet moi de te faire remarquer une petite larme de mauvaise foi : tu sautes sur l'excuse "c'est pas dans Haskell98", mais en cas de besoin tu sors la fonction "for", qui n'y est pas non plus, il me semble

    Sinon, pour conclure ma petite digression "Haskell et moi...", je trouve aussi que hoogle est un outil tout à fait fantastique.

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
  •