Journal Un compte rendu de la conf sur isaac/lisaac

Posté par .
Tags : aucun
0
23
mar.
2006
Comme annoncé dans l'article http://linuxfr.org/2006/03/09/20473.html la conférence donnée par Benoit Sonntag c'est déroulée aujourd'hui.

Je tient d'abord remercier B. Sonntag qui est une personne très sympatique et qui nous a fait un exposé intéressant et synthétique durant les trois heures de la présentation publique. Petit detail sympa la présentation a été affichée avec un portable tournant sous Isaac.

Nous avons pu ensuite essayer en pratique le compilateur qu'il a écrit et ainsi constater la qualité du travail fournie de nos propres yeux (et doigts). Et ceci malgré la grande jeunesse du projet. A noter qu'une autre session sera probablement organisée.

Personellement j'était plutot sceptique sur quelques point du projet (qui ont d'ailleur été discuté ici) que je trouvais choquant comme :

- l'intéret d'un langage ne proposant pas de condition (if then else) ou d'itérateur (for while) dans la syntaxe du langage.

- la capacité d'un langage objet a se plier aux exigences de la programmation système

- l'utilitée de passer d'un langage objet à classe (le standard pour plus au moins tout le monde) a un langage objet à prototype (que je ne connaissais pas)

Finalement j'ai été très impressionné pas les réponses qui m'on été donnée ! J'aurai aimé que ce ne soit pas moi qui les exposes ici (on aurait du faire une video, l'exposé était très clair).

Malheureusement le projet en est à ses tout début d'ouverture au public et je me rend compte qu'il n'existe pas de document écrit syntétisant ce qui a été dit oralement. Les slides de la présentation sont disponibles mais présentent uniquement des figures illustratives. (figures a haut pouvoir trollifere d'ailleurs, surtout le début avec en apothéose le slide 7 de project_st_overview.pdf :)) cf site)

Pour essayer d'expliquer les choses quand même, je dirais que le modèle objet à prototype ajoute un réel pouvoir expressif à la programmation objet. Et contrairement à la plupart des extensions récentes des langages, cela rend le langage plus simple et plus cohérent. Et cela en conservant les avantages déjà acquis avec les langage à classes.

Une fois qu'on a posé les bases de la syntaxe on se rend compte que les structures de controles définies dans la bibliothèque sont la seul manière de faire logique dans ce contexte.

Finalement les quelques extension nécessaire à la programmation système (les interruptions et la gestion des masques de bits principalement) se fondent totalement dans le modèle à prototypes. De plus ces méchanismes ont montré leur efficacité lors du développement par B. Sonntag d'un système sur un nouveau processeur qui a été réalisé plus rapidement que les ingénieurs de la société travaillant en C.



En conclusion je voudrai ajouter que loin de sortir de nulle part ce projet propose une synthèse du meilleur que l'on peut trouver dans le domaine objet avec des inspiration comme smarteiffel, self et smalltalk.

(malheusement assez peu connu, quoique smarteiffel est réputé pour la rapidité de son code produit, d'ailleurs l'encadrant de thèse de B. Sonntag est le principal développeur de smarteiffel, et smalltalk possède une machine virtuelle libre qui fait régulierement l'objet de depèches enthousiastes ici).

Et plus de cela, le projet possède, à mon humble avis, deux principales innovation :

- Un compilateur extrement performant associé a un langage très expressif (je ne pense pas avoir déjà vu mieux). On a vraiment l'impression d'avoir affaire à la souplesse d'un langage de script alors qu'on a la performance des langage compilé.

- Réussir a faire le grand écart entre un langage de haut-niveau et les préoccupations matériels des ordinateurs et des système d'exploitation. Pour ce rendre compte de ca il faut surtout regarder le travail accompli sur le (prototype) de système d'exploitation isaac.

PS : Désolé pour les fautes, je me désespère moi même :) C'est loin d'être exaustif de la présentation, je voulais surtout présenter un point de vue personnel.

PS2 : la disponibilité de la totalité des sources sous licence libre est apparement bien engagée.
  • # Autres langages à prototype

    Posté par (page perso) . Évalué à 3.

    À noter que parmis les nombreux langages objet à prototype, il y a Javascript.

    Sinon pour plus de détails, je vous recommande la lecture de l'article sur wikipedia http://en.wikipedia.org/wiki/Prototype-based_programming (la version française est plutôt maigre..)
    • [^] # Re: Autres langages à prototype

      Posté par . Évalué à 3.

      C'est intéressant car parmi les critiques relevées par l'articles il y a
      dynamic type systems (...) correctness, safety, predictability and efficiency
      .

      Mais lisaac est typé statiquement et compilé, il est donc plutot sur et efficace. Donc il répond à la plupart des critiques.

      A part la dernière sur le fait que les developpeur ne sont pas familier avec cette technique. Mais bon ca c'est comme n'importe quel innovation. Genre y'a plein de gens qui sont boulonné au C et qui ne veulent surtout pas changer, quelque soit les arguments qu'on leur donne. A mon avis c'est le peur de quitter un environnement familier où ils exercent un position privilégiée ... surtout quand la nouvelle technique rend caduque un travail autrefois fait à la main !

      Mais bon y'a pas de gens comme ça ici ! non ? :)
      • [^] # Re: Autres langages à prototype

        Posté par (page perso) . Évalué à 2.

        Mais bon y'a pas de gens comme ça ici ! non ? :)
        Non, juste 95 % ;-*)

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

  • # Pffff...

    Posté par . Évalué à -5.

    Merci à l'INRIA de nous pondre encore un langage inutile comme le OCaml qui va permettra à tous les champions de l'informatique théorique de croire qu'ils savent programmer...

    Oui, je sais, je suis amer, mais quand ça fait 1 an qu'on se bouffe cette daube de Caml à la fac, on finit par devenir méchant.

    Quand je vois que le Caml, prétendumment très à l'aise avec le typage, pas foutu de faire la différence entre un entier et un flottant si on ne rajoute pas un point à l'opérateur, ça me fait plus pitié qu'autre chose...

    Allez, je sais, je vais encore me faire moinser, mais bon, cpas grave...
    • [^] # Re: Pffff...

      Posté par (page perso) . Évalué à 1.

      C'est dommage ton opinion de OCaml
    • [^] # Re: Pffff...

      Posté par . Évalué à 8.

      Quand je vois que le Caml, prétendumment très à l'aise avec le typage, pas foutu de faire la différence entre un entier et un flottant si on ne rajoute pas un point à l'opérateur, ça me fait plus pitié qu'autre chose...


      mdr, c'est sur que faire la différence entre (je veux un entier) 3+4 et (je veux un flottant) 3+4 c'est réalisé par tout les compilo du monde.

      C'est exactement pareil pour tout les langage a un moment donné il faut que tu dise au compilo quel type tu veux utiliser. Or il n'y a pas de déclaration de type en Caml donc ils utilisent des opérateur différent "+" et "+.". Dans le contexte c'est la seul manière de faire.

      Apparement tu a encore des progres a faire en prog fonctionnelle :)

      Sérieusement ce qui est vraiment dommage c'est qu'ils n'ont pas utilisé l'extension objet de OCaml pour définir un type Nombre et uniffier l'interface des opérateurs entre les entiers et les flottants.

      Pour en revenir au sujet : ce point la est traité correctement en Lisaac. On manipule les différentes type de nombres (entiers ...) suivant la même interface.
      • [^] # Re: Pffff...

        Posté par . Évalué à -3.

        Il y a un truc génial qui s'appelle l'analyse syntaxique.
        Quand tu écris 3 + 4, ce sont des entiers. Quand le nombre contient un ".", c'est un flottant, et puis c'est tout.

        Donc un compilo qui lit 3 + 4, il conclut binop(+, int(3), int(4)), et quand il lit 3.5 + 4.3, il conclut binop(+, float(3.5), float(4.3)), c'est pourtant pas compliqué...
        • [^] # Re: Pffff...

          Posté par (page perso) . Évalué à 2.

          et quand le compilo ne connait pas la valeur ? entrée utilisateur, sonde, etc..

          3 + entrée = ??? entier ou flottant
          • [^] # Re: Pffff...

            Posté par . Évalué à 1.

            Ton entrée est une température , c'est un float.
            Ton entrée est un nombre de touches frappées ? c'est un int.
            Ton entrée est "quelqu'un a cliqué ?" c'est un bool.
        • [^] # Re: Pffff...

          Posté par . Évalué à 4.

          Sans blague ca existe ? tu crois vraiment que les gens qui ont fait le compilo ocaml ne savent pas ce que c'est ?

          Mais ce n'est pas suffisant ici :

          exemple :
          let add x y = x + y ;;

          Dis moi quelle est le type des paramètres formels x et y suivant ta méthode ? int ou float ?
          • [^] # Re: Pffff...

            Posté par . Évalué à 2.

            + est un opérateur qui doit s'appliquer aux entiers, comme aux flottants, donc on s'en tape joyeusement que l'utilisateur passe des entiers ou des flottants à add.
            Et si ce n'est ni des entiers, ni des flottants ? Et bien soit l'opérateur + a été redéfinis pour le type correspondant, soit on lance une exception.
            • [^] # Re: Pffff...

              Posté par (page perso) . Évalué à 4.

              + est un opérateur qui doit s'appliquer aux entiers, comme aux flottants, donc on s'en tape joyeusement que l'utilisateur passe des entiers ou des flottants à add.

              Tu me montreras ton compilateur qui "s'en tape joyeusement".

              Et si ce n'est ni des entiers, ni des flottants ? Et bien soit l'opérateur + a été redéfinis pour le type correspondant, soit on lance une exception.

              Comme tu dis: "pour le type correspondant".

              Alors le nombre 1, dis moi, c'est un entier ou un flottant ?

              Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

            • [^] # Re: Pffff...

              Posté par (page perso) . Évalué à 4.

              Non, il faut arrêter de croire que entiers, flottants tout ça c'est interchangeable. C'est tout simplement faux et ce sont justement les langages qui convertissent joyeusement entre les deux qui entretienent la confusion.

              En OCaml les types entiers ont une arithmétique d'anneau, modulo 2^31 (ou 2^63). Mais les flottants suivent l'arithmétique IEEE 754 avec tous ses comportements bizarres (valeur NaN non comparable aux autres valeurs, non-associativité a priori des opérations, etc.)

              Et ça évite ce genre d'erreur facile à faire en C: double x = a / b; où a et b sont des entiers.
            • [^] # Re: Pffff...

              Posté par . Évalué à 6.

              + est un opérateur qui doit s'appliquer aux entiers, comme aux flottants

              Tu pas du principe que la surcharge d'opérateurs est quelque chose qui va de soi, malgré le fait que l'opération "addition" est très différente selon le type des données. La surcharge d'opérateur, c'est du sucre syntaxique pour faire plaisir au développeur, rien de plus.

              OCaml a fait le choix de renoncer à ce sucre syntaxique pour proposer autre chose qui fait plaisir au programmeur: l'inférence de type. L'inférence de type permet de supprimer la plupart des erreurs de typage à la compilation, donc c'est quelque chose qui apporte un bénéfice évident.

              Or toi, au lieu de reconnaître que c'est un choix, avec lequel tu peux être d'accord ou non, tu prétends que c'est de l'incompétence. Il y a des moments où on préfère que son code soit garanti valide, et il y a des moments où on préfère que son code soit facile à écrire. En particulier, il y a des moments où on voudrait se rendre compte à la compilation que l'opérateur "+" n'existe pas pour l'objet manipulé, et pas à l'exécution quand l'exception est levée.
      • [^] # Re: Pffff...

        Posté par (page perso) . Évalué à 1.

        Sérieusement ce qui est vraiment dommage c'est qu'ils n'ont pas utilisé l'extension objet de OCaml pour définir un type Nombre et uniffier l'interface des opérateurs entre les entiers et les flottants.

        hmm non, pour ça les langages fonctionnels utilisent plutôt des type classes cf. http://en.wikipedia.org/wiki/Type_class .
        Mais ça n'existe pas en OCaml.
    • [^] # Re: Pffff...

      Posté par (page perso) . Évalué à 6.

      Quand je vois que le Caml, prétendumment très à l'aise avec le typage, pas foutu de faire la différence entre un entier et un flottant si on ne rajoute pas un point à l'opérateur, ça me fait plus pitié qu'autre chose...

      Peux-tu m'indiquer le langage qui sait deviner l'intention du codeur?

      Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

    • [^] # Re: Pffff...

      Posté par . Évalué à 7.

      Mouarf, l'avis d'un étudiant :)

      Non pas pour te dénigrer, mais en tant qu'étudiant qui fait du Ocaml depuis un an, qui est énervé par les contraintes de typages, t'as pas forcément beaucoup de recul sur ce qui est bien ou mal dans un typage si fort. Surtout si t'as fait du PHP avant. C'est bien, c'est facile, peu de contraintes, mais une horreur à debugger (c'est que mon avis, mais j'ai pratiqué, et je le partage).
    • [^] # Re: Pffff...

      Posté par . Évalué à 5.

      Je serai toujours étonné sur LinuxFr par les commentaires de gens inexpérimentés. Voyons les gens de INRIA, ils sont plus balaises que toi en informatique. Par contre, en communication et en marketing ils ont tout à apprendre de MS ... Ocaml est un langage très intéressant. Mais il doit ABSOLUMENT sortir et évoluer hors de la sphère académique. D'ailleurs Dominique de Villepin ferait mieux de s'acharner sur la valorisation au CNRS/INRIA. C'est un vrai scandale en France. Si on regarde dans le temps. L'innovation en matière de langage, on a

      - Pays-bas avec Python, un succès

      - La France avec Ocaml et Lissac, marginal

      - Japon avec Ruby, qui est encore peu utilisé

      Au USA, il n'y a rien eu depuis l'innommable C++, et Java, toujours empêtré avec Sun ... C# étant un ramassis du reste (C et Perl existant depuis des lustres)

      Je ne saurai conseiller d'organiser des VRAIS conférences, avec TOUTES les composantes du CNRS utilisant massivement l'outil informatique, les industrielles, et ouverte sur l'international. Un peu comme "International Conference on High Energy Physics". Montrer des transparents en Français devant une cinquantaine d'étudiant en informatique, c'est pas de la com ...
      • [^] # Re: Pffff...

        Posté par (page perso) . Évalué à 2.

        Je crois que le Perl est plus récent que le C++ ;-)

        Quitte a parler du java et du C#, t'aurais pu évoquer le petit frère du C++, l'ObjectiveC, qui en ai la grande source d'inspiration.
        • [^] # Re: Pffff...

          Posté par . Évalué à 3.

          Perl 1.0 was released to usenet's alt.comp.sources in 1987.
          Bjarne Stroustrup at Bell Labs initially developed C++ during the early 1980's.

          Exacte, mais ça fait un baille.

          ObjectiveC est postérieur à C++, et fortement inspiré de smaltalk. Je n'en est pas parlé, car il est trop marginal. Et un peu boiteux: une couche oo très couteuse en cpu sur un dérivé de l'assembleur.
      • [^] # Re: Pffff...

        Posté par . Évalué à 2.

        Tu es gentil, mais d'une part, je ne suis qu'un étudiant, mais je n'ai pas fait "que du PHP" (et je partage ton avis là dessus). J'ai également fait du C, un paquet de C++, du perl, du python, un poil de java...
        Chaque langage a ses avantages et ses inconvénients ; pour l'instant, le seul intérêt que j'ai trouvé au caml, c'est de permettre aux matheux/théoriciens d'écrire du code comme des maths, on croyant que voui madame ça marchera aussi bien que du C...

        Et quand je vois les algos qu'utilisent certains mes profs (pas tous, hein), dès fois, je me pose des questions... Dire qu'un prof est compétent parce qu'il est prof, c'est typiquement français, l'expression "l'habit ne fait pas le moine" étant systématiquement ignorée dans notre pays.

        Quand au C/C++, tu juges ça inommable, mais c'est eux qui composent 95% des gros programmes, et ce n'est pas pour rien.
        • [^] # Re: Pffff...

          Posté par . Évalué à 2.

          Quand au C/C++, tu juges ça inommable, mais c'est eux qui composent 95% des gros programmes, et ce n'est pas pour rien.


          C'est de moins en moins vrai, pour les appli utilisateur desktop oui mais en entreprise ca a beaucoup évolué vers Java. Et cela évoluera encore, c lent mais ca bouge qd même
        • [^] # Re: Pffff...

          Posté par . Évalué à 3.

          Quand au C/C++, tu juges ça inommable, mais c'est eux qui composent 95% des gros programmes, et ce n'est pas pour rien.
          C++ est inommable. La STL en particulier. C'est un plaisir pour touver la source d'un bug. Les infos du compilateur et de gdb sont absolument incompréhensible pour un humain. Expanser 2000 lignes de code à chaque usage, c'est du délire. D'ailleurs chez ATT, ils ne sont pas tous d'accord http://www.research.att.com/sw/tools/cdt
          • [^] # Re: Pffff...

            Posté par . Évalué à 1.


            C++ est inommable. La STL en particulier. C'est un plaisir pour touver la source d'un bug. Les infos du compilateur et de gdb sont absolument incompréhensible pour un humain.

            Est-ce que ca ne met pas en lumiere les manques du compilo et du debugguer plutot que la STL ?
            Parce qu'a mon avis, si tu te plains de la STL et des erreurs a la compilation que l'on peut rencontrer au cours de son utilisation... ne va _jamais_ voir du cote de Boost ;)

            Expanser 2000 lignes de code à chaque usage, c'est du délire.
            Je suppose que la encore c'est un manque provenant du compilateur et, supposition encore, ca devrait_etre/est resolu avec les headers precompiles.

            En fait j'ai l'impression que ce que tu n'aimes pas dans le C++ ce sont les templates.
            Serais-tu le fils cache a Rene Brun (HEP private joke inside) ?
            Il me semble que C++0x devrait resoudre la plupart de tes griefs a l'encontre des templates[*].
            Cela se resume a: "make templates a first class citizen".

            [*] encore faut-il que les compilos suivent derriere, je le concede volontiers.
            • [^] # Re: Pffff...

              Posté par . Évalué à 2.

              Il me semble que C++0x devrait resoudre la plupart de tes griefs a l'encontre des templates[*].
              Cela se resume a: "make templates a first class citizen".

              [*] encore faut-il que les compilos suivent derriere, je le concede volontiers.


              Comme dans lisaac quoi ? :)
              • [^] # Re: Pffff...

                Posté par . Évalué à 2.

                Yep.
                Mais bon, lisaac c'est combien de personnes ?

                GCC c'est quand meme a base de vachement plus de monde [1] meme s'il faut bien sur retrancher toutes les personnes qui ne contribuent pas directement a G++.

                [1] : http://gcc.gnu.org/onlinedocs/gcc/Contributors.html
                • [^] # Re: Pffff...

                  Posté par . Évalué à 3.

                  Lisaac c'est 1 ou 2 personnes.

                  Et il se repose compltement sur gcc puisque il génére du C avec quelques extension de gcc.

                  Et quand je disais que c'était comme dans Lisaac, c'est parcque les templates sont réellement des citoyen de premiere classe et que le compilo est déjà efficace.

                  Et la syntaxe et la sémantique de C++ ne permettront jamais d'avoir un compilo qui génére du code aussi performant que celui de lisaac. t'aura beau mettre 400 personnes dans le projet g++ ca ira pas

                  Parceque justement un bon paquet d'optimisation automatique dans lisaac sont prévue pour être fait à la main en C++. Et que le langage est trop complexe
        • [^] # Re: Pffff...

          Posté par . Évalué à 4.

          juste comme ca :

          "Quand au C/C++, tu juges ça inommable, mais c'est eux qui composent 95% des gros programmes, et ce n'est pas pour rien."

          je modifie 2/3 truc :

          Quand à Windows, tu juges ça inommable, mais c'est eux qui equipe 95% des ordinateur, et ce n'est pas pour rien.

          enfin j dit ca comme ca hein, faut pas y voir une attaque personelle
          • [^] # Re: Pffff...

            Posté par . Évalué à 2.

            Windows est sur 95% des ordinateurs parce que même ceux qui ne connaissent rien à l'informatique peuve avoir un ordinateur: du coup, battage médiatique, OS imposé, toussa...

            Quand un codeur choisit un langage pour son prochain programme, généralement, il choisit un poil plus en connaissance de cause.
            Je pense par exemple que les développeurs d'apache ont de vraies raisons de prendre le C...

            D'ailleurs, tu ne t'es jamais demandé pourquoi on ne voit jamais de vrais programmes utilisés en dehors de l'INRIA, écris en Caml ?
            (oui, je sais, je connais mldonkey, le prog qui se fait virer des server p2p (parenthèse, je viens de me prendre 3 ans de prison et 300k euros d'amende...) parce qu'il envoit des requêtes en série comme un porc).

            Code apache en caml, on a pas fini de rigoler...
            • [^] # Re: Pffff...

              Posté par . Évalué à 6.

              >Quand un codeur choisit un langage pour son prochain programme,
              >généralement, il choisit un poil plus en connaissance de cause.

              Bof, moi j'aurais plutôt dit qu'il choisissait souvent le plus connu/répandu/éprouvé avec de nombreuses bibliothèques, mais pas forcément le plus adapté.

              >Je pense par exemple que les développeurs d'apache ont de vraies
              >raisons de prendre le C..

              Parce qu'Erlang n'a été disponible sous licence libre qu'à partir de 1998 ?

              >D'ailleurs, tu ne t'es jamais demandé pourquoi on ne voit jamais de
              >vrais programmes utilisés en dehors de l'INRIA, écris en Caml ?
              >(oui, je sais, je connais mldonkey, le prog qui se fait virer des server
              >p2p (parenthèse, je viens de me prendre 3 ans de prison et 300k
              >euros d'amende...) parce qu'il envoit des requêtes en série comme
              >un porc).

              Y a Unison aussi http://www.cis.upenn.edu/~bcpierce/unison/ Il me semble qu'il est assez utilisé, et de l'avis général assez "malin".
              Dans les projets de recherche également (bien sur tu vas me dire que ça ne compte pas) : le fameux Coq, ASTRÉE...
              Si OCaml est aussi médiocre que tu sembles l'inférer (ahah), je me demande pourquoi il est utilisé par Microsoft dans certains projets de recherche (appliquée, tu peux le remarquer) comme http://research.microsoft.com/terminator/ . La même entreprise qui a d'ailleurs conçu un clone^Wcousin sur .NET, F# : http://research.microsoft.com/fsharp/fsharp.aspx

              >Code apache en caml, on a pas fini de rigoler...
              Ça manque singulièrement d'arguments, donc en effet, je rigole. Je ne dis pas que tu peux tout faire en OCaml, ni que ce soit intéressant/utile, mais je doute de l'impossibilité de la tâche (sans prétendre qu'OCaml soit la panacée universelle).

              Sinon, un petit aparté. La réaction de certaines personnes dès qu'on évoque (O)Caml ou Lisaac ("ah, c'est ça la recherche française ? Encore un langage inutile de l'INRIA, qui finira inconnu et mort") me choque, d'autant plus qu'il est rare de voir des projets aussi pratiques... Surtout quand ces réflexions viennent de gens qui seraient les premiers à hurler à la publication de travaux théoriques, exigeant des résultats immédiats qui ne sont de toute évidence pas le but de la recherche fondamentale scientifique.
            • [^] # Re: Pffff...

              Posté par . Évalué à 4.

              Quand un codeur choisit un langage pour son prochain programme, généralement, il choisit un poil plus en connaissance de cause.

              C'est comme pour tout, il y a une minorité de gens qui maîtrisent plusieurs langages et qui sont capables de choisir le plus adapté à la tâche à effectuer, et puis il y a les autres, qui ont appris un ou deux langages et qui partent du principe que c'est la panacée.
      • [^] # Re: Pffff...

        Posté par . Évalué à 3.

        La France avec Ocaml et Lissac, marginal


        Lisaac (avec deux a) est beaucoup plus jeune que Ocaml.

        Ca ne fait que très recement qu'il y a une version utilisable de Lisaac. En plus le développement a été réalisé par une seule personne (+un ingé pendant 2 ans).

        On est au tout début pour Lisaac alors que Ocaml a déjà une longue histoire et est mature.

        Perso je trouve que Caml a un bon succes ...pour un langage fonctionel, je ne pense pas qu'on puisse attendre beaucoup plus.

        Alors que Lisaac est impératif objet et bien adapté pour faire des choses efficaces.
        • [^] # Re: Pffff...

          Posté par . Évalué à 3.

          Caml a un bon succes ...pour un langage fonctionel, je ne pense pas qu'on puisse attendre beaucoup plus.

          Mais OCaml est un langage qui permet de code à la fois en fonctionnel, en impératif et en objet (tout comme Common Lisp, d'ailleurs).
          • [^] # Re: Pffff...

            Posté par . Évalué à 2.

            Oui c'est vrai mais bon ca reste qd même du ML avec en bonus l'impératif et l'objet.

            D'un point de vue syntaxe et sémantique on marie des choses par la force. Et au final on se retrouve avec un langage tres tres gros (ML + impératif + classe + module). Perso j'aurai préféré qu'ils gardent la simplicité du langague d'origine, bon ce n'était pas forcement possible

            C'est tout a fait l'opposé de la philosophie de lisaac. cf la grammaire http://isaacos.loria.fr/li_docs.html qui est très courte mais le langage reste quand même tres expressif.

            Par exemple voici la définition de la boucle for. En fait c'est très proche d'un itérateur sur les entier tel que l'on aurait pus le définir en Caml.

            to limit_up:SELF do blc:BLOCK <-
            (
            (self<=limit_up).if {
            blc.value self;
            (self+1).to limit_up do blc;
            };
            );

            en caml (pas objet) ca aurait fait un truc du style
            let rec for i limit_up blc=
            if i<limit_up
            then blc i;for (i+1) blc
            else blc i
            ;;
            du type int -> int -> (int -> ()) ->() (a vue de nez)
            (mon caml est rouillé donc ca doit être faux, mais j'ai pas envie d'installer le compilo)

            Je trouve que c'est un exemple très réussit d'intégration de concept plutot fonctionnel à l'intérieur d'un langage objet mais sans rajouter des construction plus ou moins étrangère dans la syntaxe de base. En fait ce qu'il ont eu besoin de rajouter c'est le type BLOCK correspondant a un suite d'instruction séquentielles. Comme ca on peut passer des blocs a itérer au la commande for (enfin to do : on peut définir plusieur mot clef).
            • [^] # Re: Pffff...

              Posté par (page perso) . Évalué à 1.

              ML a toujours eu un aspect impératif, ce n'est absolument pas quelque chose qui a été rajouté "en bonus".
              • [^] # Re: Pffff...

                Posté par . Évalué à 2.

                ah oui j'avais oublié que ML aussi était impur, ca change rien au fait que l'impératif et le fonctionel ne vont pas naturelement ensemble.
                • [^] # Re: Pffff...

                  Posté par (page perso) . Évalué à 2.

                  t'as "oublié" que ML est impur ? Mouarf, tu dois pas en faire beaucoup ; c'est pas un reproche évidemment mais alors épargne nous tes jugements avec les "c'est pas naturel" (sous-entendu, lisaac l'est).

                  L'impératif et le fonctionel sont trés bien intégré, tant au niveau de la syntaxe que de la sémantique. C'est vraiment un aspect fondamental dans la conception des langages de la famille ML. D'ailleurs le logo des anciens langages caml était un symbole ying-yang avec un lambda dans une case et l'opérateur d'affectation en caml (:=) dans l'autre [1].

                  Pour la boucle, ça s'écrit comme ça:
                  for i = 0 to limit_up do f i done

                  Voilà il faut vraiment être d'une mauvaise foi noire pour prétendre que c'est moins naturel que la version utilisant une fonction récursive ou que le gloubiboulga syntaxique de lisaac.

                  [1] http://cristal.inria.fr/~weis/books-fra.html
                  • [^] # Re: Pffff...

                    Posté par . Évalué à 3.

                    Non effectivement je ne fais plus de ML. Mais j'ai déjà lu les livres que tu cite.

                    D'un autre coté je me souviens pas d'avoir été aussi agressif avec toi !

                    Cette syntaxe est effectivement tres naturelle.

                    Mais ceci n'est pas une definition du for mais une utilisation du for comme définie dans la grammaire de caml. Donc ca n'a rien a voir avec mon discours.
            • [^] # Re: Pffff...

              Posté par (page perso) . Évalué à 3.

              C'est la aussi ou on voit toute la puissance des itérator de Sather. En Sather, les classes ont des attributs, des méthodes et des itérators. Le gros avantage est de pouvoir itérer sur plusieurs iétrateurs dans une même boucle et le compilateur peux optimiser en mettant toute la partie initialisation en dehors de la boucle. L'autre gros avantage, il n'y a plus de structure for, while until ! Inutile, dépassé. for devient l'iterator upto! sur les entiers
              for (i=1, 1000) {....} 
              
              devient
              loop
                1.upto!(1000)
                ....
              end
              
              Idem pour while
              while (test) {....}
              
              qui devient
              loop
                while!(test)
               ...
              end
              
              L'itérator while! est appellé sur aucun objet. En fait, on pourrait le mettre sur un objet booléen #BOOL, true ou false et considérer que cette notation n'est que du "syntatic sugar". Bref, tout un tas de structure devienne bien plus simple avec cette notion d'itérator. La contruction de l'itérator while! est très simple (les autres aussi), en voici un exemple d'implémentation
              while!(pred:BOOL) is
                 -- Yields as long as 'pred' is true
                 loop
                    if pred then
                       yield;
                    else
                       quit;
                    end;
                 end;
              end;
              
              Si on s'authorise l'opérateur ? : du C, cela raccourci carrément le code
              while!(pred:BOOL) is
                 loop
                    pred ? yield : quit;
                 end;
              end;
              
              • [^] # Re: Pffff...

                Posté par (page perso) . Évalué à 3.


                Lire pour la derniere URL

                http://www.gnu.org/software/sather/docs-1.2/tutorial/iterators1034.html
      • [^] # Re: Pffff...

        Posté par . Évalué à 10.

        C'est sympa de faire un journal là-dessus, j'avais déjà vu passer le nom mais sans m'y attarder. C'est un projet colossal et très intéressant. Par exemple, les quelques petites phrases qu'il donne sur la parallélisation de l'exécution des programmes écrits en Lisaac se jettent dans de vastes domaines de recherche grand ouverts. Le mien, entre autres.

        En ce qui me concerne, Lisaac prend tout son sens en tant que langage évolué pour la programmation système. Actuellement, je n'en connais pas. C'est un domaine qui nécessite de pouvoir mettre le clavier dans le cambouis plus que ne le permet normalement un langage de haut niveau : par exemple, alors qu'un ramasse-miettes est très pratique en temps normal, il est catastrophique pour écrire un pilote de périphérique. Il reste à voir comment ça se passe dans la pratique, ce qui signifie lire la doc, le code, etc. Du temps à passer dessus en perspective...

        Puisque je passe par là, j'en profite pour quelques mises au point. J'ai failli prendre un troll sur la tête en arrivant : vous pourriez ranger vos affaires, quand même...

        Sur l'INRIA : c'est un très grand institut, assez disparate. J'ai eu l'occasion de voir que les chercheurs étrangers ont parfois du mal à en comprendre l'organisation, ce qui leur donne un point commun avec les Français. Notamment, elle contient de grands théoriciens et... de grands praticiens. En gros, dans mon projet, lorsque les gens ne codent pas en C, c'est qu'ils codent en Fortran. Ou qu'ils ne codent pas.

        Sur la valorisation de la recherche, comme dit plus haut, les développeurs d'Objective Caml, par exemple, s'en occupent en compagnie de quelques très grosses entreprises. Cela ne doit pas faire oublier que c'est avant tout un langage expérimental, donc qui change souvent et profondément. Les chercheurs ont besoin de tels langages. Pour expérimenter, pas pour vendre.

        Sur les nouveaux langages et nouveaux paradigmes, je me demande bien ce qui peut pousser à croire qu'il n'y en a pas, aux États-Unis ou ailleurs. Pict, fondé sur le pi-calcul, est l'exemple qui me vient là tout de suite, mais c'en est juste un. Il en apparaît tout le temps de nouveaux, ce qui est une excellente chose pour l'informatique en général.

        Sur les anciens, il faut comprendre qu'un langage donné, plus largement un paradigme donné a son champ d'application. Par exemple, la programmation fonctionnelle s'applique très bien au traitement de données structurées, en particulier les langages de programmation. Ce n'est pas pour rien que les développeurs de gcc se sont donné tant de mal pour implanter tree-ssa dans la version 4 : cette traduction du code impératif et spaghetteux en une forme fonctionnelle favorise l'analyse et la transformation du code, et particulièrement son optimisation. Il est tentant de croire qu'un langage donné va sauver le monde, mais c'est illusoire. Écrire un serveur http en Caml, par exemple, serait possible mais difficile, du moins avec de bonnes performances.

        Ah tiens, les performances. En voilà un domaine où les idées reçues ont la vie dure, sans doute en grande partie en raison d'une méconnaissance des architectures actuelles. En écrivant des boucles et des affectations plutôt que des fonctions récursives et des liaisons, on a l'impression d'être plus proche de la machine : on envoie une instruction, on enregistre le résultat, on passe à la suivante. Sans le dire comme ça, les gens ont en tête une machine de von Neumann. C'était vrai, en gros, jusqu'à l'arrivée du Pentium. Maintenant, on est passé à l'autre modèle : celui du flot de données. Les instructions sont exécutées dans le désordre, en parallèle tant que c'est possible, et le facteur limitant est généralement la latence de la mémoire : dès qu'une donnée arrive, elle réveille les instructions qui l'attendaient. Ainsi, le modèle le mieux adapté est la description du calcul en fonction de la disponibilité des données, en séparant autant que possible le code en morceaux indépendants. C'est ce qu'on fait, entre autres, en programmation fonctionnelle, où une évaluation est possible quand on a les résultats d'autres évaluations dont elle dépend, et pas en programmation impérative où on impose un ordre sur l'exécution des lignes du code (généralement du haut vers le bas, mais on trouve de tout dans le folklore).

        C'est pour ce genre de raisons que, paradoxalement, on arrive très bien à convaincre des matheux du bien-fondé de la programmation fonctionnelle, mais on a plus de mal avec des informaticiens (ou plutôt des "informatheux", comme dirait une de mes connaissances) - sauf, comme c'est le cas dans certains établissements, quand on commence par là avec des étudiants ne sachant pas programmer (entendu dans un amphi brestois, deuxième semestre de MIAS : "les boucles c'est nul, la récursivité c'est vachement plus facile"). Les étudiants arrivent avec des idées qui reposent sur leur expérience et leurs connaissances, et un nouveau paradigme les bouscule plutôt violemment. Or, on ne peut guère parler d'analyse de langages de programmation à des gens qui n'ont pas encore les bases de la compilation, ou d'architectures parallèles alors qu'ils ne sont même pas initiés aux architectures séquentielles. En gros, les principaux avantages du paradigme fonctionnel ne leur sont pas encore accessibles, et il faut bien reconnaître que la fonction factorielle, fût-elle récursive terminale, montre assez vite ses limites. Alors on trouve toutes sortes de réactions, d'opinions qui peuvent durer ou changer. En tous cas rien de bien inquiétant.

        Bon je vous laisse, j'ai comme l'impression que ma propension à écrire des pavés a encore frappé. Je vais donc aller exécuter un script : logout ; shutdown ; sleep.
        • [^] # Re: Pffff...

          Posté par . Évalué à 3.

          Merci pour le commentaire.

          Mais concernant le troll, je pense qu'au contraire la prochaine fois que j'écrit un journal je vais en inclure 2-3 dedans :) . Regarde, sans le troll sur Ocaml on aurait jamais eu ton commentaire ! Ici ca marche au troll...

Suivre le flux des commentaires

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