Journal The Future of Functional Programming Languages

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
27
18
oct.
2012

Juste un journal bookmark pour signaler cette très intéressante discussion entre un groupe de personnes qu’il est assez unique de voir ensemble : Xavier Leroy (OCaml), David MacQueen (un des concepteur de ML), Martin Odersky (Scala), Simon Peyton‐Jones(Haskell) et Don Syme (F#).

La discussion est intitulée « The Future of Functional Programming Languages ». Y sont abordés les succès et insuccès de l’approche fonctionnelle, comment elle infuse ailleurs, quelles sont les perspectives, etc.

Cela se passe ici, et c’est disponible en divers formats.

  • # Il manque...

    Posté par  . Évalué à 5.

    …le chanteur de Green Day, dommage.

    • [^] # Re: Il manque...

      Posté par  . Évalué à 1.

      Les gens n'ont pas d'humour. Je parlais bien évidemment du créateur de Erlang, vous savez, le premier homme qui a marché sur la lune.

      • [^] # Re: Il manque...

        Posté par  (site web personnel) . Évalué à 3.

        Comme je comprenais pas la blague, effectivement le créateur d'Erlang est Joe Armstrong
        et le chanteur de Green Day s'appelle Billie Joe Armstrong
        Bien vu ;-)

        Non, c'est vrai que ça aurait été intéressant d'avoir le créateur d'Erlang, ça aurait été intéressant d'explorer ces problèmes de SMP.

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # F#

    Posté par  (site web personnel) . Évalué à -7.

    Le F# ?
    Je m'étais arrêté au C#… Ils vont aller jusqu'où ?

    • [^] # Re: F#

      Posté par  . Évalué à 4.

      Z# ?

      • [^] # Re: F#

        Posté par  . Évalué à 2.

        j'aurais plutôt dit G#, les H n'étant pas une note ;)

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: F#

      Posté par  . Évalué à 0.

      Mais c'est trop intéressant, ça, comme commentaire ! Merci de participer de façon constructive à un débat de fond !

      • [^] # Re: F#

        Posté par  . Évalué à 5.

        Tu as écrit une réponse récursive : elle se répond à elle-même.

        • [^] # Re: F#

          Posté par  . Évalué à 2.

          Moi je suis la philosophie Unix et je sépare mon propos en deux réponses différentes qui font chacun une seule chose. D'un côté j'apporte un complément d'information sur le sujet du journal, de l'autre (ici) je râle un peu en espérant que ça améliore la qualité des commentaires pour les prochains journaux. Mais merci pour ta participation.

    • [^] # Re: F#

      Posté par  (site web personnel) . Évalué à 2.

      En même temps on entend parler de F# depuis 2007 et c'est sous Apache 2 depuis 2010…

  • # dommage

    Posté par  . Évalué à 3.

    Ca commençait bien, avec tous ces formats, ce sujet prometteur, et la haute résolution.

    Quel dommage que ces saccades se présentent aux plus mauvais endroits (comment reconnaitre un mauvais endroit ? Facile : quelqu'un parle).
    Franchement, j'ai énormément de mal a comprendre M. Haskell, qui en plus de parler vite, bénéficie de nombreux bullet times…

    • [^] # Re: dommage

      Posté par  (site web personnel) . Évalué à 9.

      Effectivement c'est assez pénible, il faudrait essayer un autre format moins libre :-(

      Je note deux interventions intéressantes (j'ai pas encore tout vu) :

      • Leroy qui est en train de se demander s'il ne faudrait pas voir ailleurs que faire des système de type hyper strict car à force ça risque de gaver les utilisateurs. Après j'ai pas compris ce qu'il propose
      • McQueen qui pose le problème des exceptions, pour lui les exceptions sont un core dump. C'est un peu extrême comme point de vue, mais je me souviens m'être rendu compte au sein du projet Lisaac, après âpres discussions, que c'est un champ de recherche sous exploité (je peux me tromper). En fait c'est un problème essentiellement humain : dans un logiciel de E-Commerce, une exception pour disque plein peut provoquer un blocage de l'appli, alors que dans un airbus, c'est inimaginable. Donc ça dépend de la tolérance à la panne.

      Plus généralement, ils se posent beaucoup la question de pourquoi un langage marche ou pas. Or, cette question pourrait être une problématique universitaire en… science de gestion. On a au mieux une question d'amateur éclairés (comme si je donnais mon avis sur le système de type de OCaml).

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: dommage

        Posté par  . Évalué à 7.

        Leroy qui est en train de se demander s'il ne faudrait pas voir ailleurs que faire des système de type hyper strict car à force ça risque de gaver les utilisateurs. Après j'ai pas compris ce qu'il propose

        Python est pas mal, mais assez confidentiel par rapport à Haskell, F# et OCaml.

      • [^] # Re: dommage

        Posté par  (site web personnel) . Évalué à 1.

        Pour le point 1), c'est un peu casse gueule de remplacer la vérification de type par des testes. Etre plus sympa sur le typage n'est pas un cadeau à long terme.

        Pour le point 2), il n'a pas tort. Il me semble que pour lisaac ont voulait un système qui retourne un doublet avec le status d'erreur, il me semble que go propose la même chose. Je pense aussi que le problème serait bien moindre si Ocaml proposait de typer les exceptions pour voir ce qui remonte jusqu'au "main".

        "La première sécurité est la liberté"

        • [^] # Re: dommage

          Posté par  . Évalué à 3.

          Je pense aussi que le problème serait bien moindre si Ocaml proposait de typer les exceptions pour voir ce qui remonte jusqu'au "main".

          Hum, ce que tu propose ressemble fortement à Java qui indique(indiquait?) dans le prototype des fonctions les exceptions potentiellement levée ce qui causé pas mal de protestations car c'est pénible à gérer..

          Bref, pour la gestion d'erreur il n'y a pas de solution miracle..
          Les 3 points que je trouve intéressant:
          - les scopes (*) qui remplacent en mieux le try .. finally
          - les références non-nullable par défaut et le type Maybe.
          - la gestion d'exception "à la Lisp" qui semble un peu différente des autres, mais je ne comprends pas bien si c'est vraiment un avantage en pratique..

          *: http://digitalmars.com/d/1.0/exception-safe.html

          • [^] # Re: dommage

            Posté par  (site web personnel) . Évalué à 3.

            Pour le point 2 (je dois étudier le 1 et je connais pas le 3), j'écris une grosse appli de GED en Ocaml (10 klignes) en ce moment, et j'utilise massivement les None/Some (le type Maybe) et franchement ça ne m'empêche pas d'avoir plein d'exception : j'interagit avec pas mal de services extérieurs et ils peuvent merder eux aussi (ou alors je leur envoie les mauvais params, une ressource qui n'existe plus, etc…), donc certes ça me limite mes exceptions à des cas "fonctionnels", mais ça n'empêche pas que j'ai plein d'exception quand mon traitement est bloqué car le service extérieur n'as pas réagit correctement.
            Et un jour falloir que je réfléchisse à gérer sérieusement un certain nombre d'entre elles.
            Et là les problèmes vont commencer avec le try catch…

            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

            • [^] # Re: dommage

              Posté par  . Évalué à 2.

              Et là les problèmes vont commencer avec le try catch…

              Je ne pense pas que retarder le problème soit une bonne façon de gérer les try catch. Personnellement en même temps que je réfléchis aux paramètres et au retour d'une fonction, je me pose la question des exceptions (de quoi à besoin ma fonction ? à quoi elle sert/qu'est ce qu'elle retourne ? pourquoi/comment elle peut planter ?). Il me semble que c'est comme ça que ça reste logique. Ensuite l'architecture d'une application peut beaucoup aider (dans une archi à composant les composants ne doivent pas se vautrer salement déjà).

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: dommage

            Posté par  . Évalué à 2.

            Hum, ce que tu propose ressemble fortement à Java qui indique(indiquait?) dans le prototype des fonctions les exceptions potentiellement levée ce qui causé pas mal de protestations car c'est pénible à gérer..

            Il y a plusieurs choses à voir.

            D'une part il n'y a qu'une partie des exceptions qui doivent être gérées (soit en étant attrapées soit en étant déclarée plus haut). Les Error et les RuntimeException ne sont pas obligatoirement gérées (en fait d'un point de vu pratique c'est des choses qui peuvent arriver n'importe quand. Ce sont les CheckedException qui doivent être gérées.

            Pour ce qui est des problèmes de contamination que ça entraine. De mon point de vu une méthode cliente doit gérer l'exception (ou l'encapsuler) et je ne pense que que c'est un problème que la méthode cliente ai un couplage fort avec la classe appelée.

            D'autre part même si c'est plus verbeux, je ne trouve pas ça plus contraignant que le pattern matching qu'on trouve avec l'inférence de type.

            les scopes (*) qui remplacent en mieux le try .. finally

            Si j'ai bien compris. Dans un bloc d'instruction on place une instruction du type :

            scope(failure) foo(m);

            et si on sort de ce bloc en erreur (pour le cas en exemple), la méthode foo est appelée. Par contre la documentation semble dire que la détection des erreurs se fait encore via des exceptions (ou alors je n'ai pas compris « scope(failure) executes NonEmptyOrScopeBlockStatement when the scope exits due to exception unwinding. »). Donc ça ne remplace pas vraiment les exceptions.

            Je ne vois pas non plus comment tu peut gérer certains cas avec. Pour libérer des ressources c'est super (les exemples le montre), mais quand il s'agit de gérer une erreur par exemple pour écrire dans un log ou remonter une information à l'utilisateur, tu es obligé d'utiliser une variable globale qui va contenir l'information alors dans quand les cas « classiques » (qu'on trouve en Java ou C++ par exemple) c'est l'exception qui contient cette information. Ça me semble plus propre.

            • les références non-nullable par défaut et le type Maybe.

            Les valeurs null sont une plaie. D'ailleurs on vois en Java avec common lang, guava ou la dernière version de Java SE qu'une partie des aides sont en faites des helpers pour gérer les valeurs null. J'aime bien l'approche patern matching qu'on trouve dans les langages fonctionnels pour ça (on est obligé de gérer la valeur null (ou plutôt le type null quand celui-ci peut se présenter)). Les types nullables de C# sont plutôt pas mal je trouve, ils obligent les développeurs à gérer les cas de valeurs null.

            • la gestion d'exception "à la Lisp" qui semble un peu différente des autres, mais je ne comprends pas bien si c'est vraiment un avantage en pratique..

            Tu parle du fait de pouvoir corriger et rejouer la partie incriminées ? J'ai encore jamais utilisé un tel système, je ne peux pas en dire beaucoup plus que toi.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: dommage

              Posté par  . Évalué à 2.

              scope [coupé] Donc ça ne remplace pas vraiment les exceptions.[coupé]Je ne vois pas non plus comment tu peut gérer certains cas avec.

              Oh, ça ne remplace en aucun cas les exceptions, c'est juste une syntaxe en complément bien plus lisible que le try .. finally, qui est beaucoup lisible quand elle est applicable.

              Donc on peut dire que c'est juste de la syntaxe et juste pour certains cas, mais de mon point de vue la gestion des ressources lors d'une transaction est un cas assez courant pour mériter un support particulier.

              • [^] # Re: dommage

                Posté par  . Évalué à 2.

                Donc on peut dire que c'est juste de la syntaxe et juste pour certains cas, mais de mon point de vue la gestion des ressources lors d'une transaction est un cas assez courant pour mériter un support particulier.

                A mais j'ai pas dis le contraire :)

                Ça me paraît un peu moins agréable mais beaucoup plus souple que le mot clef with de python ou java (qui sont intéressants avec une ressource unique).

                Quel langage implémente cette fonctionnalité ?

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: dommage

                  Posté par  . Évalué à 3.

                  D: http://dlang.org/
                  Un langage principalement développé par des "vieux chibab" en C++..

                  • [^] # Re: dommage

                    Posté par  (site web personnel) . Évalué à 1.

                    Le D c'est bien :-)

                    allie agréablement performance, productivité, maintenance

                    approche du paradigme fonctionnelle plus que convenable ce n'est pas pour autant un langage fonctionnelle pur car le développeur pioche dans le paradigme le plus approprié pour effectué son travail.

                    Donc si vous voulez du fonctionnelle pur et dur passez votre chemin pour tous les autres ce langage mérite le coup d’œil.

                    Je me permet de mettre la présentation du D lors du FUDcon Paris 2012 FUDCon_D_programming.pdf

                    • [^] # Re: dommage

                      Posté par  (site web personnel) . Évalué à 2.

                      Quid niveau perf, car pour un langage de ce type, qui est salutaire, il ne peut percer que s'il fait mieux que C++. Or ce n'est pas le cas, et c'est essentiellement un problème de moyens.

                      Cela dit, D devrait générer du C facile à optimiser pour le compilateur, bénéficiant ainsi de toutes les optimisations implémentés dans les compilateurs C avancés (GCC, Intel C).

                      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                      • [^] # Re: dommage

                        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 22 octobre 2012 à 15:36.

                        D n'est pas vala

                        de plus D à toutes les optimisation de gcc ou llvm je ne sais pas ce qu'il en est de intel.

                        De surcroit avoir une performance équivalente au c++ sans ça complexité en fait un langage très intéressant. Réussir une telle performance avec un garbage collector je dis chapeau. Pas la peine de troller sur le gc si vous n'avez pas essayé hein (je commence à avoir l'habitude des troll d'idée toutes faites erronées).

                        A part le typage des données il n'est pas plus complexe que ces langage de script homologues .

                        Bref le D est très séduisant avis d'une personne qui l'utilise régulièrement ( ce qui est censé avoir plus de valeur que n'importe quel troll ou celui qui a testé en l'an 40) .

                        Je précise pour les indécis ;-) ce langage a de forte chance de vous plaire.

                        • [^] # Re: dommage

                          Posté par  (site web personnel) . Évalué à 2.

                          Alors, disclaimer : je ne dis pas ça pour troller, j'ai horreur des langages impératifs, donc je risque pas de l'utiliser. Seulement un langage qui fait la même chose en moins bloat que C++, c'est forcément intéressant.

                          Je pense seulement que cela ne sert à rien de chercher à générer de l'assembleur soit même quand tu dois intégrer des centaines de règles d'optimisation du code (en asm), qui change en fonction de la révision du processeur en question. Tu ne pas gérer ça à quelques personnes. GCC et Intel C compiler ont des équipes entières dédiées à cela, elles ont l'infrastructure pour, l'expérience, les libs d'analyse, etc…

                          Donc on s'en fout que D soit Vala ou pas, la question, c'est que ça ne sert à rien de générer soit même de l'assembleur (à moins qu'on soit un langage fonctionnel et que générer du C soit trop problématique) alors qu'il suffit d'utiliser C comme un assembleur portable.

                          Il se trouve que D a un front-end GCC, mais ont-ils les ressources nécessaires pour que le code soit totalement optimisé par le back-end (normalement oui) ?

                          Pas sûr.

                          Est-il possible de désactiver le GC.

                          Bref, D pourrait décoller, s'il avait vraiment des perfs équivalente à C++. Autrement j'imagine mal qu'il est possible de convaincre des développeurs près à s'investir.

                          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                          • [^] # Re: dommage

                            Posté par  . Évalué à 3.

                            Il se trouve que D a un front-end GCC, mais ont-ils les ressources nécessaires pour que le code soit totalement optimisé par le back-end (normalement oui) ?

                            Qu'est ce qui te fait dire que le langage intermédiaire de GCC est plus compliqué à optimisé que le C ?

                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                          • [^] # Re: dommage

                            Posté par  (site web personnel) . Évalué à 1. Dernière modification le 23 octobre 2012 à 00:26.

                            j'ai testé le code cpp et le temps est quasi identique

                            D:

                            allocation: 19 ms, 216 μs, and 6 hnsecs 
random: 17 ms, 274 μs, and 4 hnsecs

                            CPP:

                            allocation: 18 ms
random generation: 15 ms
result: 29248300000
time: 42128 ms

                            de plus faire un bench sur quelques ms a aucun sens

                            • [^] # Re: dommage

                              Posté par  (site web personnel) . Évalué à 1. Dernière modification le 23 octobre 2012 à 00:36.

                              Edit mauvais copier / coller

                              j'ai testé le code cpp et le temps est quasi identique

                              D:

                              ./bench 
allocation: 14 ms, 773 μs, and 4 hnsecs 
random: 15 ms, 373 μs, and 3 hnsecs 
result: 90239760000
scalar products: 24 secs, 57 ms, 317 μs, and 4 hnsecs

                              CPP:

                              ./bench 
allocation: 10 ms
random generation: 14 ms
result: 29248300000
time: 42272 ms

                              J'ai pas touché au programme donnée (donc pas d'optimisation) et en D on met entre 24-28 sec alors que le cpp met environ 40 sec.

                              • [^] # Re: dommage

                                Posté par  (site web personnel) . Évalué à 1. Dernière modification le 23 octobre 2012 à 01:24.

                                avec les options d'optimisations:
                                D:

                                allocation: 16 ms, 768 μs, and 5 hnsecs 
random: 11 ms, 765 μs, and 4 hnsecs 
result: 46654920000
scalar products: 5 secs, 358 ms, 999 μs, and 7 hnsecs

                                CPP:

                                allocation: 3 ms
random generation: 8 ms
result: 29248300000
time: 3489 ms

                                le programme cpp est légèrement plus rapide toutefois le code est stricto sensu le code cpp ce qui introduit un biais car le code D fournit :

                                • réalloue à chaque tour de bloc la taille du tableau!!
                                • Le tableau pourrait être statique afin de pouvoir utiliser les instructions SSE4
                                • l'approche fonctionnelle avec notamment map aiderait sensiblement les performances
                                • N devrait être immutable
                                • size_type devrait être size_t pour supporter 32 et 64 bits
                                • les param de scalar_product :
                                  • changer const ref en in
                                  • mettre la fonction comme pure

                                et j'en passe
                                Un même code peut être transcrit presque litterralement dans plusieurs langage cependant il y a des subtilités qui vont produire des différences significatives

                                • [^] # Re: dommage

                                  Posté par  (site web personnel) . Évalué à 2.

                                  Cela fait 30% de perf, c'est assez important. Il faudrait voir si tes propositions de changement change la donne, mais il faut faire les mêmes en cpp aussi.

                                  Le plus propre est de faire les benchs du langage shoutout, même si il devrait augmenter la taille des "workloads", il y a parfois des surprises énormes avec l'augmentation de la taille des données.

                                  "La première sécurité est la liberté"

                    • [^] # Re: dommage

                      Posté par  . Évalué à 1.

                      Merci pour le lien mais lire un gros PDF avec GoogleDoc c'est pour les masochistes!

                      • [^] # Re: dommage

                        Posté par  . Évalué à 3.

                        Fichier > Télécharger

                        On a le droit de te balancer un RTFM ?

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: dommage

                  Posté par  (site web personnel) . Évalué à 1.

                  C :) https://bitbucket.org/jmb/cseh (désolé pour la pub).

          • [^] # Re: dommage

            Posté par  (site web personnel) . Évalué à 2.

            N'oublie pas que les types sont inférés en Ocaml, donc il n'y a absolument rien à déclarer. Il suffit de lire la signature de "main" par le compilo pour voir les exceptions qui seront levé.

            "La première sécurité est la liberté"

          • [^] # Re: dommage

            Posté par  (site web personnel) . Évalué à 2.

            J'ai eu plusieurs fois un pattern de code problématiques avec les exceptions : une fonction de recherche qui utilise List.find et donc retourne une exception si elle ne trouve rien. La fonction de recherche est utilisé dans plusieurs cas : trouver une information pour générer d'autre donnés, l'absence de l'information est un bug (failwith "internal error"), faire une validation des entrées dans ce cas l'exception génère un log d'erreur. Il peut aussi exister des fonctions qui génèrent normalement l'absence d'une donnée (cas par défaut).

            Il existe aussi les fonction de recherche qui utilise la fonction précédente, or on peut oublier ou ce situe la génération de log d'erreur ou pas. On ne sait plus si la fonction appelé remonte tout ses exceptions ou essaye de les gérer (log d'erreur mais pas au bon niveau, cas par défaut qui n'a pas de sens, etc…).

            Bref, je ne trouve pas que les exceptions passent à l'échelle. Après un certain nombre de couche, on ne sait plus ce qui passe au travers, ce qui a un comportement par défaut et ce qui génère un log d'erreur.

            Il me semble que la lib de janestreet n'utilise pas d'exception mais des types sommes.

            "La première sécurité est la liberté"

            • [^] # Re: dommage

              Posté par  (site web personnel) . Évalué à 6.

              Pour prendre une grosse application en OCaml que je connais pas trop mal, Coq, qui tape dans les 230 kloc, je peux témoigner que les exceptions, ça ne passe vraiment pas du tout à l'échelle.

              Quant tu reçois une exception à toplevel, elle est passée par trois ou quatre phases de rattrapage-puis-relançage, rendant le parcours du flot de contrôle aussi aisée que du trekking dans les Andes avec l'association française des tétraplégiques. Sans compter le fait que c'est une vraie horreur de repérer les fonctions qui peuvent lever des exceptions, et que certains usages font songer que les développeurs de Coq doivent avoir des personnalités multiples pour arriver à créer un langage aussi pur et écrire des gorkeries d'un niveau inégalé. Je peux citer l'exemple d'une fonction de cinquante lignes qui utilisait récursions, références et exceptions dans un gloubiboulga de contrôle, alors que ça se réduisait à un bête fold sur une liste avec une fonction pure, sans perte d'efficacité…

              • [^] # Re: dommage

                Posté par  (site web personnel) . Évalué à 3.

                Les êtres inférieurs comme moi ou d'autres n'ont que rarement la capacité à voir qu'un fold répond au problème que l'on cherche à résoudre.

                « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                • [^] # Re: dommage

                  Posté par  (site web personnel) . Évalué à 3.

                  Il y a pire : 2 fold imbriqué. Parfois, je préfère faire plusieurs map pour sauver des neurones, mais si c'est sous optimal (mais cela ne le serait pas si le compilo faisait son boulot de déforestation)

                  "La première sécurité est la liberté"

        • [^] # Re: dommage

          Posté par  . Évalué à 2.

          Il y a un outil qui fait de l'analyse statique du code OCaml pour propager les exceptions :
          Ocamlexc.

          Ne pas surcharger les annotations de types avec les effets mais conserver une gestion fiable des exceptions est un bon compromis.
          Attention à lire le readme au sujet des constructions récentes. (J'ai un patch quick'n'dirty pour le compiler avec Labltk, je pourrai le mettre quelque part si ça intéresse des gens :)).

          • [^] # Re: dommage

            Posté par  (site web personnel) . Évalué à 3.

            C'est une vrai maladie de ocaml de faire des outils complémentaire en forkant le compilateur ? :) Le pire que j'ai vu est l'outil d'instanciation de functor pour des raisons de performances, au lieu de le faire directement par le compilateur.

            "La première sécurité est la liberté"

            • [^] # Re: dommage

              Posté par  . Évalué à 3.

              Tu recommanderais plutôt que tous les développeurs d'outils soient donnés des droits de commit sur le compilateur, ou bien qu'ils récrivent leur propre version du frontend et du typeur au lieu de réutiliser les sources du compilateur ?

              C'est une question un peu rhétorique puisque depuis la dernière version les bibliothèques internes du compilateur sont exportées et on peut donc écrire des outils qui les utilisent pour parser/typer/compiler sans devoir reprendre directement le source. Ceci dit je ne vois toujours pas le problème avec le fait de forker un compilateur pour faire une expérience (surtout si c'est du code un peu poubelle que les gens n'ont pas les ressources pour maintenir), et au contraire j'aurais tendance à trouver ça plutôt sain que des gens le fassent au lieu de réinventer la roue.

              • [^] # Re: dommage

                Posté par  (site web personnel) . Évalué à 2.

                Les patchs peuvent être envoyer au mainteneur du compilo pour inclusion, comme pour Linux. C'est dommage qu'un tel code finisse à la poubelle, par absence de maintenance.

                Dans le cas de l'instanciation de functior, on est clairement dans le gros hack complexe au lieu d'ajouter une fonctionnalité au compilo.

                "La première sécurité est la liberté"

                • [^] # Re: dommage

                  Posté par  (site web personnel) . Évalué à 2.

                  N'oublie pas que l'INRIA alloue gentillement 2 jour.homme par mois à OCaml…

                  « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                • [^] # Re: dommage

                  Posté par  . Évalué à 2.

                  Tu donnes Linux comme exemple, mais dans le développement du noyau Linux il y a aussi des dizaines de prototypes qui sont développés et puis jetés à la poubelle (ou alors proposé à l'intégration upstream, rejetés et jetés à la poubelle; il y aussi quelques cas de proposés, rejetés et maintenus sur le côté mais c'est plus rare en proportion). Pour que l'intégration upstream se fasse il faut que le code soit de bonne qualité et clairement utile, et les gens qui développent le prototype ne sont pas si souvent prêt à faire ce travail.

  • # Mouais

    Posté par  . Évalué à 8. Dernière modification le 19 octobre 2012 à 10:18.

    Franchement je n'ai pas trouvé ce panel très intéressant, et ça a contribué à me faire penser que les panels, sauf quand c'est vraiment très très bien fait, sont toujours un peu ratés. Ce que j'ai retiré de cette présentation c'est que Simon Peyton-Jones a trop la classe, et que Martin Odersky et Don Syme auraient aimé travaillé ensemble plutôt que faire deux langages séparés (idée qui m'a surpris et intéressé).

    J'ai écrit un commentaire reddit sur les exposés intéressants du Milner Symposium d'un point de vue langages de programmation. À mon avis dépenser son temps en lisant les slides des présentations citées sera beaucoup plus productif et intéressant que regarder la vidéo de ce débat.

    Je profite du fait que LinuxFR et reddit utilisent tous les deux markdown pour citer le commentaire en plein ci-dessous. En espérant que ça motivera les gens à comprendre l'anglais.

    The most programming-related talks of the symposium were probably Xavier Leroy's The continuation of functional programming by other means and Martin Odersky's Objects and modules: two sides of the same coin?. For more foundational aspects of language and type systems, Benjamin Pierce's Types à la Milner and Robert Harper's Defining a programming language were also very interesting.

    If you like pi-calculus and concurrent communication calculi, I personally enjoyed Davide Sangiorgi's Some remarks on bisimulation and coinduction and Jean Krivine's Jobbers, sentient buildings and lions: a short walk into Robin Milner's tower. Finally, if you're into weird little mathematics puzzles (I think notfancy might enjoy this for example), Jan Rutten's Coalgebraic bisimulation felt to me like a possibly anecdotic, but nice and interesting presentation.

    • [^] # Re: Mouais

      Posté par  (site web personnel) . Évalué à 3.

      Le problème c'est qu'ils se posent beaucoup la question des raisons du succès/insuccès des langages fonctionnels dans l'industrie. Or (je me répète), c'est une question à poser aux profs de la fac de gestion : comprendre pourquoi un langage marche, c'est à peu près la même question que de se demander pourquoi une techno (les fraiseuses numériques au hasard) marche dans un champ industriel.

      C'est donc une question de science humaine qui devrait être traité comme tel. Or là on a une discussion d'amateurs éclairés, sans plus, comme si j'allais moi sur le plateau donner mon avis sur les GADT.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Mouais

      Posté par  (site web personnel) . Évalué à 2.

      Et tiens d'ailleurs, Gérard Berry expliquait dans son cours au collège de France que le lambda-calcul était impropre au SMP. qu'en est-il des autres recherches sur la question ?

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Mouais

        Posté par  . Évalué à 3.

        Pour faire du calcul concurrent distribué, il y a les formalismes basés sur le pi-calcul. Si tu parles de SMP (Symmetric Multiprocessing) en parlant spécifiquement de la mémoire partagée, il y a peu de formalismes spécialisés (enfin les travaux sur les modèles mémoire faibles s'en approchent le plus), mais de toute façon les gens ne sont pas convaincus qu'il y a de bons modèles de programmation qui exploitent la mémoire partagée. Ce qu'on sait faire c'est utiliser des types linéaires pour garder trace de "qui possède" les données, et donc permettre des passages de message zéro-copie dans un cadre SMP (en très gros c'est ce que vise Rust, et il y a aussi des langages de recherche plus formalisés sur le sujet). Enfin tu as les logiques de séparation (en) concurrentes, qui sont des extensions de la logique de Hoare à des raisonnements avec accès concurrent à des ressources partagées qui garantissent l'absence de race.

        Si tu parles spécifiquement des spécificités des programmes bas-niveau faisant de la concurrence par mémoire partagée, la situation est en fait "meilleure" qu'avec les langages fonctionnels: la seule façon de coder un truc correct sans se tirer une balle est de comprendre ces sémantiques formelles et de prouver la correction du programme avec. À côté le lambda-calcul est délicieusement haut niveau et explicite, on n'a presque pas besoin de savoir comment ça marche pour coder correctement dans un langage fonctionnel… lambda.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.