OCaml 3.10.0 est sorti

Posté par  . Modéré par Nÿco.
Étiquettes :
0
23
mai
2007
Technologie
Le 16 mai est sorti la version 3.10.0 de Objective Caml, implémentation du langage Caml (Categorical Abstract Machine Language) créé par l'INRIA.

Objective Caml est la principale variante du langage Caml. Du point de vue du langage, elle étend le noyau du langage Caml avec une couche orientée objets complète, ainsi qu'un système de modules puissant. Un système de types polymorphe avec inférence automatique des types assure la cohérence de ces traits. Le langage est entièrement développé et maintenu par l'INRIA. Il est distribué sous licence QPL 1.0 tandis que les bibliothèques sont sous licence LGPL 2.

En plus des sources, des binaires sont proposés pour GNU/Linux (format RPM, deb ou Gentoo) et pour Win32. Les binaires Mac OS X ne sont pas encore disponibles.

NdR: Merci à benja pour son journal. Les nouveautés principales de cette version (tirées du changelog) :
  • Les variables d'instances dans les classes peuvent maintenant être déclarées virtual et implémentées dans des sous-classes.
  • L'impression d'un historique de la pile d'appel lorsque le programme s'arrête sur une exception non rattrapée, auparavant disponible uniquement pour les programmes compilés en bytecode, est maintenant disponible pour les programmes compilés en code natif (fonctionne sur Intel/AMD et sur PPC, en 32 bits et en 64 bits).
  • Nouveaux portages : Mac OS X, PowerPC, 64 bits; Microsoft Windows 64 bits (x64) utilisant les outils Microsoft PSDK; Microsoft Windows 32 bits utilisant les outils Visual Studio 2005.
  • Le préprocesseur Camlp4 a été réimplémenté en grande partie et offre une nouvelle API pour les extensions de syntaxe, plus modulaire que l'ancienne.
  • Un nouvel outil expérimental, ocamlbuild: c'est un gestionnaire de compilation qui automatise la construction d'applications et de bibliothèques OCaml.
  • Référencer une interface compilée avec -rectypes depuis un module non compilé avec cette option est maintenant une erreur.
  • Modification du "fragile matching" warning.
  • Détection de dépassement de pile sur MS Windows 32 bits, Mac OSX PC et Intel.

Aller plus loin

  • # Dommage...

    Posté par  . Évalué à 9.

    Que ce langage soit si peu utilisé !
    J'ai appris le Caml Light en prépa, les 3 premières heures j'ai détesté, impossible de comprendre la syntaxe, la façon d'exprimer les choses (quand le cours commence par "pas de boucles" * , ça fait étrange).

    Puis on découvre une autre façon de concevoir les choses, et finalement le retour à un autre langage est bien douloureux. En tout cas je pense que c'est une excellent idée de l'enseigner, ça permet de programmer de façon intelligente, mais pour le reste, c'est vrai qu'à chaque fois que j'ai voulu faire des "vraies" choses avec, j'étais mal à l'aise. En revanche pour prototyper un algorithme complexe, c'est idéal...

    Pourquoi ce ne sont pas les meilleurs langages qui sont utilisés ?
    :-(


    * Oui je sais les boucles existent, mais ce n'est pas l'esprit du langage
    • [^] # Re: Dommage...

      Posté par  . Évalué à 5.

      Pourquoi ce ne sont pas les meilleurs langages qui sont utilisés ?

      Ca me rappelle un petit texte que j'ai bien aimé, _The rise of "worse is better"_

      Un essai de Richard P. Gabriel:
      http://www.jwz.org/doc/worse-is-better.html

      L'histoire par l'auteur:
      http://www.dreamsongs.com/WorseIsBetter.html

      On trouve même un article sur Wikipedia:
      http://en.wikipedia.org/wiki/Worse_is_Better

      Ca n'a pas trop de rapport avec la dépêche elle-même mais c'est intéressant pour ceux qui ne connaissent pas.
    • [^] # Re: Dommage...

      Posté par  . Évalué à 3.

      Dans ce que tu dis, je vois deux choses :
      1. Le problème programmation impérative <-> programmation fonctionnelle
      2. Les autres trais du langages.

      Pour le premier point, c'est clair que quand on dis à un étudiant qui sait déjà programmer (par exemple en C) qu'on va programmer sans variables et sans boucles, ça lui fait bizarre.

      En fait, je pense qu'un bon programmeur devrait maîtriser les deux styles de programmation car les deux ne sont pas adaptés à toutes les situations: écrire un produit de matrice de façon fonctionnelle, c'est ridicule et écrire un algo de résolution des tours de Hanoï impérativement, c'est l'horreur. De façon plus générale, je pense que pour manipuler des structures de données un peu complexes, l'approche fonctionnelle est supérieure et que pour beaucoup de choses plus basique l'approche impérative se justifie bien.

      Pour ce qui est du second point, je trouve que
      - la programmation par filtrage,
      - avoir un système de modules paramètriques ,
      - avoir un vrai typage fort,
      - avoir un ramasse miettes pour la mémoire,
      - ...
      est vraiment très agréable.

      Au final, je trouve dommage que les langages ayant du succès soient des langages assez basiques. Ceci dit, cela reste compréhensible car pour qu'un langage ait du succès, il faut qu'il possède une grosse communauté pour développer plein de bibliothèques. Or un langage trop évolué fait souvent appel à des concepts et des façons de programmer inhabituels et peu de développeurs vont s'y intéresser. Comme peut de développeurs s'y intéressent, la communauté reste réduite et le cercle vertueux de promotion du langage ne s'amorce pas.

      Bref.

      Je suis d'accord qu'OCAML est un bon langage sous utilisé.
      • [^] # Re: Dommage...

        Posté par  . Évalué à 6.

        écrire un produit de matrice de façon fonctionnelle, c'est ridicule

        open Array

        let ( @@ ) f g x = f (g x)

        let produit mata matb =
        ....let coeff li col =
        ........fold_left ( + ) 0
        ............(init (length matb) (fun k -> mata.(li).(k) * matb.(k).(col)))
        ....in
        ....init (length mata) (init (try length matb.(0) with _ -> 0) @@ coeff)

        100% tableaux non mutables (non mutés, en tout cas).
        • [^] # Re: Dommage...

          Posté par  . Évalué à 9.

          Et après on dit que Perl est illisible...

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

          • [^] # Re: Dommage...

            Posté par  . Évalué à 3.

            Dans l'exemple donné, le principal problème est l'utilisation du fold_left. Les personnes qui ne programment que de façon impérative sont très destabilisées pas l'utilisation d'itérateurs fonctionnels.

            Et ne me dites pas que les boucles for ou while sont plus naturelles. J'ai assuré un TP d'algorithmique de base et au vu des problèmes de mes étudiants, je peux vous assurer que ce n'est pas le cas.
            • [^] # Re: Dommage...

              Posté par  . Évalué à 2.

              Je suis désolé mais en "lisant" ton code. Je ne comprends absolument pas ce qui est fait.

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

              • [^] # Re: Dommage...

                Posté par  . Évalué à 4.

                Je n'ai plus écris d'OCAML depuis longtemps, je vais donc peut-être dire des bêtises.
                Mais je me lance

                > open Array
                >
                > let ( @@ ) f g x = f (g x)
                >
                > let produit mata matb =
                > ....let coeff li col =
                > ........fold_left ( + ) 0
                > ............(init (length matb) (fun k -> mata.(li).(k) * matb.(k).(col)))
                > ....in
                > ....init (length mata) (init (try length matb.(0) with _ -> 0) @@ coeff)

                On fait le produit des matrices mata et matb.
                pour cela, on définit une fonction coeff li col qui donne le coefficient li,col de la matrice produit. Pour rappel, c'est mata(li,0)*matb(0,col)+...+mata(li,n)*mat(n,col)

                Pour calculer ce coefficient, on utilise un fold_left qui prend en argument plein de trucs.

                On voit entre autre apparaître (fun k->mata.(li).(k)*matb.(k).(col)). Si on appelle f cette fonction, le coefficient est donc f(0)+f(1)+f(2)+...+f(n).

                Passons maintenant au fold_left. cette fonction prend en argument une fonction f, une valeur et une liste. Par exemple,
                fold_left f 0 [1;2;3] = f (f (f (0 1) 2) 3

                La fonction (+) est l'operateur + préfixé, c'est à dire (+) 1 2=1+2.
                Pour additionner tous les éléments d'une liste, il suffit de faire un
                fold_left (+) 0 l.

                Si on recolle les morceaux, pour que la fonction coef retourne ce qu'il faut, il suffit que init n f tourne une la liste [f(0);f(1);...;f(n)]. Dans ce cas,

                1. init (length matb) (fun k -> mata.(li).(k) * matb.(k).(col)) retourne la liste
                [mata(li,0)*matb(0,col),...,mata(li,n)*mat(n,col)]
                2. le fold_left (+) 0 ... rend la somme des éléments de la liste soit, le coefficient de li,col de la matrice.


                Maintenant qu'on a une fonction coeff qui marche, il suffit d'utiliser init pour faire une jolie matrice. Si on part du principe qu'une matrice, c'est une famille de vecteurs, on construire un vecteur ligne, il suffit de faire un
                init n k->coef li k.

                On remarque que cette fonction a un paramètre (li). La fonction
                li -> (init n k->coef li k) est donc la fonction qui rend le li-ème vecteur ligne de la matrice. En l'itérant à coup de init, on obtient une matrice.

                Je passe l'utilisation du try with.

                Bref, que d'explications pour un code de 6 lignes.
                • [^] # Re: Dommage...

                  Posté par  . Évalué à 1.

                  Je comprends mieux pourquoi OCaml ne sortira jamais de l'université :)

                  Sois un code pareil existe en lib, sois il n'est jamais écris comme ça.

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

                  • [^] # Re: Dommage...

                    Posté par  . Évalué à 2.

                    C'est pas propre à ocaml, c'est propre au fonctionnel.
                    Et c'està mon avis bien plus facile à comprendre qu'un gros truc en impératif où faut pister les effets de bord.
                    • [^] # Re: Dommage...

                      Posté par  . Évalué à 5.

                      Sur cet exemple précis ?!

                      Tu veux me faire croire que cette exemple est plus clair que l'algo avec les 3 boucles embriqués ?

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

                      • [^] # Re: Dommage...

                        Posté par  . Évalué à 3.

                        D'accord avec toi, je me souviens d'un livre sur Ocaml en Francais qui pousse vraiment l'aspect fonctionnel même quand le code impératif est plus simple (et c'est souvent le cas!)ce que je trouve idiot car Ocam supporte les deux styles..

                        Ceci dit je me souviens d'un article sur une manière d'optimiser le 'jeu de la vie' au lieu de représenter le jeu classiquement par une matrice, on passe a une représentation "récursive" (transformation type 'divide and conquer' loin d'être triviale d'ailleurs).
                        Bon le resultat n'est pas plus lisible mais il y a un gros gain de perfomance.
                        • [^] # Re: Dommage...

                          Posté par  . Évalué à 2.

                          Donc, on parle d'optimisation de sioux et pas vraiment de code "normal" (qui doit rester simple et lisible par un codeur moyen).

                          Moi aussi, j'ai écris un code méga optimiser en C complètement illisible :

                          for(ii=0; ii<n ;ii=ii+K)
                          .for(kk=0; kk<n ;kk=kk+K)
                          ..for(i=ii;i<ii+K;i=i+1)
                          ...for(k=kk; k<kk+K ;k=k+1)
                          ....tmp = A[i][k];
                          ....for(j=0;j<n;j=j+1)
                          ......C[i][j] = C[i][j] + tmp*B[k][j];

                          Et encore je suis gentil, j'ai viré du code asembleur x86 pour le prefetch.

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

                          • [^] # Re: Dommage...

                            Posté par  . Évalué à 2.

                            En fait, il y a pire :

                            for(ii=0; ii<n ;ii=ii+K)
                            .for(kk=0; kk<n ;kk=kk+K)
                            ..for(i=ii;i<ii+K;i=i+1)
                            ...for(kkk=kk;kkk<kk+K;kkk+=4){
                            ....tmp6 = A[i][kkk];
                            ....tmp7 = A[i][kkk+1];
                            ....tmp8 = A[i][kkk+2];
                            ....tmp9 = A[i][kkk+3];
                            ....for(j=0;j<n;j=j+128){
                            .....for(jjj=j;jjj<j+128;jjj+=2){
                            ......C[i][jjj] += tmp6*B[kkk][jjj]+tmp7*B[kkk+1][jjj] + tmp8*B[kkk+2][jjj]+tmp9*B[kkk+3][jjj];
                            .....C[i][jjj+1] += tmp6*B[kkk][jjj+1]+tmp7*B[kkk+1][jjj+1]
                            + tmp8*B[kkk+2][jjj+1]+tmp9*B[kkk+3][jjj+1];
                            }

                            Toutes ces boucles embriquées et ces indices dans tous les sens, c'est beau non ?! :)

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

                          • [^] # Re: Dommage...

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

                            je pense qu'une grande partie de la non lisibilité n'a pas a voir avec l'optimisation, mais avec un mauvais choix de noms de variables.

                            bon choix de noms de variables, de fonctions, indentation et style logiques et constants, egale grands progres (j'appelle ca l'autodocumentation)
                      • [^] # Re: Dommage...

                        Posté par  . Évalué à 2.

                        Tu n'as jamais codé en fonctionnel, et ça se sent...

                        Personnellement je comprend ce code sans problème, pratiquement en le lisant. Ce n'est pas parce que j'ai un cerveau d'extraterrestre, c'est parce que j'ai déjà programmé en fonctionnel et j'ai l'habitude de raisonner avec des combinateurs de fonctions et des fonctions d'ordre supérieur.

                        Si tu n'as jamais fait que de l'impératif il n'y a rien d'étonnant à ce que tu ne comprenne pas ce code, mais es-tu véritablement certain que si on t'avait présenté le code impératif à trois boucle avant que tu ais commencé la programmation tu l'aurais mieux compris que ce code fonctionnel ?

                        Franchement je ne vois pas la difficulté, fold_left est une opération parfaitement naturelle, surtout avec un opérateur binaire comme ici, s'il avait appelé sa fonction coef 'coefficient_produit ligne colonne', tu aurais tout de suite compris de quoi il parlait...

                        --
                        Jedaï
                        • [^] # Re: Dommage...

                          Posté par  . Évalué à 3.

                          Sauf que l'algo avec boucle est celui que l'on t'apprend en classe pour définir la multiplication matriciel.

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

                          • [^] # Re: Dommage...

                            Posté par  . Évalué à 1.

                            Ah non !
                            En classe, on apprend que pour A = B.C la valeur de A[i][j] est égale à la somme de B[i][k].C[k][j] pour k=1 à n.

                            Qui a parlé de boucle là ?
                            Soit, à la limite, on peu considérer que le "somme pour k de ... à ..." ressemble à une boucle, mais il n'y a pas de notion d'ordre contrairement à une boucle !

                            Par contre, les deux autres boucles, tu les as ajouté parce que c'est ta manière de penser en impératif.

                            ----------

                            En fonctionnel, tu peux faire ca de la manière suivante (je prend pas la syntaxe CAML puisqu'elle fait peur)

                            soit les deux fonction B et C de [[1,n]]^2 dans R qui représentent les deux matrices du même nom (une fonction, une matrice, c'est la même chose finalement ...)

                            // calcule B[i][k].C[k][j] (on aurait pu en faire une fonction anonyme, mais ça fait peur ...
                            prod(B,C,i,j,k) := B(i,k)*C(k,j)

                            // la fonction A qui représente la matrice du même nom
                            // sum qui est classiquement fourni par une bibliothèque prend en paramètre deux entier (les bornes) et une fonction à un paramètre (prod dont on a fixé tous les paramètres sauf un)
                            A(i,j) := sum(1,n,prod(B,C,i,j))
                            • [^] # Re: Dommage...

                              Posté par  . Évalué à 2.

                              (une fonction, une matrice, c'est la même chose finalement ...)


                              Héhé, ouais, si tu généralise la matrice pour qu'elle puisse être indicée par un ensemble quelquonque.

                              Genre soit la matrice Mij avec i,j ¤ {vert, bleu, rouge}

                              ou ... Mij avec i,j ¤ {R inter [0,1]}

                              dans ces cas là j'ai pas vraiment entendu parler de matrice ;)
                              • [^] # Re: Dommage...

                                Posté par  . Évalué à 2.

                                oui, sauf que j'ai pris le cas particulier d'une fonction de [[1,n]]² -> R ...
              • [^] # Re: Dommage...

                Posté par  . Évalué à 2.

                C'est comme tout langage, si il a une syntaxe un peu "propre" à lui même, c'est difficile de comprendre un programme écrit dans celui-ci si on ne comprends pas sa syntaxe.

                J'ai appris l'OCaml l'année dernière (je suis étudiant), et même si il rebute au début (notamment quand on a appris à programmer avec la méthode impérative), maintenant je trouve que c'est un langage qui vaut la peine d'être maitrisé.
                C'est avec lui que j'ai appris l'approche fonctionnelle et une fois qu'on a appris les principes, c'est très agréable et pratique à utiliser.
            • [^] # Re: Dommage...

              Posté par  . Évalué à 4.

              Par "principal problème", tu veux dire qu'il vient devant les :

              "mais qu'est-ce que c'est que ce @@"

              "c'est quoi ce width _ -> 0"

              Et j'en passe. Bref, le concepteur du langage semble avoir pris un malin plaisir à aller à l'inverse de tout ce qui existait.

              Peut-être que la syntaxe est formidable, qu'elle roxor des ours polaires, n'empêche qu'elle est illisible pour toute personne ayant fait de la programmation "classique" (c, basic, cobol, java, pascal, ...), et qu'à bien y regarder, on croirait que c'est fait exprès.

              M'enfin, comme disait ma concierge, "pourquoi voir la méchanceté là où il n'y a généralement que la bêtise ?"

              J'exagère et je provoque un peu (on est vendredi dans 30 minutes), mais mon sentiment, c'est que OCaml n'a aucune chance de s'imposer comme un langage majeur vu les handicaps qui lui ont été imposés en terme de syntaxe.
              • [^] # Re: Dommage...

                Posté par  . Évalué à 2.

                À mon humble avis, si la syntaxe était vraiment ce qui change la donne en programmation, ça se saurait...

                Pour ma part, je trouve la syntaxe du Basic repoussante de loin, et pourtant, ce sont des langages assez utilisés. Avec Perl c'est encore plus vrai.
                La syntaxe, avec un peu d'habitude ça s'apprivoise, et après il n'y a plus de problème.

                Le problème à mon avis ce n'est pas OCaml ou Haskell ou Ruby ou je ne sais quel langage à la syntaxe "trop différente", c'est l'habitude qu'on pris les programmeurs C/C++/PHP/Java de n'utiliser essentiellement qu'une seule syntaxe (avec des variations), au point de leur faire pousser des cris parce qu'il y a un _ dans le langage !

                Si le plus dur quand on apprend la programmation fonctionnelle, c'était de s'habituer à voir des _ dans les fichiers sources, ça se saurait....

                Par ailleurs, pour info, le @@ n'existe pas dans la librairie standard OCaml, c'est juste un truc défini ici pour la composition de fonctions. Si tu as une autre suggestion plus mainstream-friendly, sachant que ° n'est pas accepté, ça peut toujours se changer.

              • [^] # Re: Dommage...

                Posté par  . Évalué à 3.

                Je ne sais pas ce qu'est l'opérateur @@.

                Pour le _ -> 0, c'est quelque chose de très puissant.

                En OCAML, on peut faire de la programmation par filtrage (i.e. a coup de switch mais en beaucoup plus puissant).

                Pour additionner les éléments d'une liste, on peut faire de la façon suivante:

                let rec glop l=match l with
                [] -> 0
                | x::l2 -> 1+(glop l2)

                le _ sert quand on ne moque du reste. Par exemple, pour tester si une liste ne contient qu'un seul élément (exemple débile, je sais), on peut écrire:

                let foo l = match l with
                _::[] -> true
                | _ -> false

                Dans l'exemple de la matrice, ce mécanisme est utilisé avec un mécanisme de récupérations d'erreurs.

                Si on exécute un programme qui peut lancer des erreurs, on peut les rattraper à coup de try ... with

                try
                mon_code_principal
                with
                qu'est-ce que je fais en cas d'erreur

                comme « mon_code_principal » peut lancer plusieurs type d'erreur, la section with
                fait du filtrage sur le type d'erreur

                try
                mon_code
                with
                division_by_zero -> print "division par zéro = la tête à Toto"
                | parse_error -> print "apprend à écrire banane !"

                Dans le coup de la matrice, on a besoin de calculer la taille de la matrice. Il peut y avoir un problème avec une matrice vide et seulement dans ce cas. On fait donc un

                try
                length matb.(0)
                with
                _ -> 0

                C'est tout.
              • [^] # Re: Dommage...

                Posté par  . Évalué à 3.

                La syntaxe d'Ocaml est peut-être un peu déroutante, ms on s'y habitue.

                Par contre moi je ne m'habitue pas au développeurs qui ne prenne pas soin de nommer correctement les valeurs. Et ils sont assez nombreux chez les dev ocaml ;)

                Haskell et Erlang ont des syntaxes qui mes semblent plus accessibles,
                même si Haskell introduit par ailleurs aussi d'autres concepts tout aussi déroutants ;)

                "mais qu'est-ce que c'est que ce @@"
                Un truc bien avec ocaml, c'est qu'il y a un interpréteur.
                Celui ci me dit que @@ est une fonction qui a ce type là


                # let ( @@ ) f g x = f (g x);;
                val ( @@ ) : ('a -> 'b) -> ('c -> 'a) -> 'c -> 'b =


                On est bien avancé me direz vous (avec raison)
                Je décode, c'est une fonction qui prends en argument
                deux fonction f, et g, et une valeur x.
                Les seules contraintes sur f et g, est que la "sortie" de g, doit être du type de l'"entrée de f". C'est pour cela qu'on voit que 'a apparait dans le typage de f, et de g.

                La définition elle même est la même qu'en math: on applique g à x, puis on applique f au résultat

                Exemple:

                # let double x = 2 * x;;
                val double : int -> int =

                # let couple x = (x,x);;
                val couple : 'a -> 'a * 'a =

                # couple(double 2);;
                - : int * int = (4, 4)

                # (@@) couple double 2;;
                - : int * int = (4, 4)

                # (couple @@ double) 2;;
                - : int * int = (4, 4)


                La dernière forme est sous forme infixe.
                On peut la décomposer pour mieux comprendre

                # (couple @@ double);;
                - : int -> int * int =


                En effet, on est pas obliger d'appliqué complètment une fonction, au lieu d'avoir une valeur "simple" en résultat, on obtient alors une nouvelle fonction.


                "c'est quoi ce width _ -> 0"
                try .... with ...;;
                permet de filtrer les exception.
                Là ce qu'il fait c'est que s'il y a une exception, on retourne 0.


                Bref, en tout cas il me semble clair que ça n'est pas un exemple idéal pour la programmation fonctionnelle:
                l'auteur y introduit bcp de concepts d'un coup. Pour ma part, j'aurai essayé de faire plus clair, quitte à ecrire plus de lignes, et à nommée qq résultats intermediaires.

                Mais je pense que Bluestorm a voulu nous montrer qu'il était possible d'écrire cela dans un langages fonctionnel,sans effet de bord, et non pas d'introduire progressivement les concepts de la programmation fonctionnelle.
                Si on a jamais vu d'ocaml avant, je comprends que ça puisse faire mal au yeux ;)
        • [^] # Re: Dommage...

          Posté par  . Évalué à 1.

          L'ennui avec les tableaux c'est que qu'ils par essence moins "fonctionnels" que les listes. Je m'explique, ils sont plus onéreux à créer que celles-ci car en plus de devoir les créer de la bonne taille (ce que l'on ne connaît pas toujours à l'avance), il faut les remplir après les avoir créé. Malheureusement, pour calculer les coefficients, notre ami a recréé un tableau, puis la parcouru une première fois pour le remplir et enfin, l'a parcouru un seconde fois pour faire sa somme (avec des 0, ce qui n'est jamais bon signe).

          Si l'on veut s'éviter la peine de recoder une fonction Array.fold_left jouant sur deux tableaux (de toutes les façon, la fonction Array.fold_left est programmée en impératif), alors on peut simplement utiliser une référence qui facilite bien la tâche et qui montre bien que le caml et à la fois souple et évolué, car il sait profiter des bons aspects de plusieurs méthodes de programmation. Merci l'INRIA !

          Je propose donc :

          let produit mata matb =
          ....let coeff li col =
          ........let k = ref (-1) in
          ........(Array.fold_left (fun tot m -> incr k; tot + m * matb.(!k).(col)) 0 mata.(li)) in
          ....Array.init (length mata) ((fun f g x -> f (g x)) (Array.init (Array.length matb.(0))) coeff);;
      • [^] # Re: Dommage...

        Posté par  . Évalué à 1.

        écrire un algo de résolution des tours de Hanoï impérativement, c'est l'horreur

        Euh ... non.

        Démonstration :
        - Tu bouges le petit pignon d'un cran vers la droite (1 -> 2, 2 -> 3, 3 -> 1) (ou vers la gauche, du moment qu'on garde le même sens) ;
        - tu fais le (seul) mouvement possible entre les deux tours où le petit pignon n'est pas ;
        Et tu recommences les deux étapes jusqu'à arriver à la solution.
    • [^] # Re: Dommage...

      Posté par  . Évalué à 0.

      > Que ce langage soit si peu utilisé !

      Oui c'est vraiment dommage... C'est vraiment l'un des langages les plus complets au niveau concepts et l'un des mieux conçus.

      > Pourquoi ce ne sont pas les meilleurs langages qui sont utilisés ?

      Et les meilleurs systèmes d'exploitation ;-)
      Il faudrait faire comme pour Linux, créer une communauté et nous battre pour le faire connaître et faire comprendre aux programmeurs Python ou PHP qu'ils pourraient faire des programmes beaucoup plus fiables...
      • [^] # Re: Dommage...

        Posté par  . Évalué à 2.

        C'est aussi le cas pour les systèmes d'exploitation.

        Le dernier exemple en date que j'ai sous la mais, c'est
        le super ordonnanceur de monsieur Ingo Molnar qui
        refait (en moins bien) ce qu'un universitaire à fait 11
        ans avant lui.

        cf. http://kerneltrap.org/node/8141. L'article cité par Ting
        Yang est de 1996.
        • [^] # Re: Dommage...

          Posté par  (site Web personnel) . Évalué à 4.

          Ce qui est dommage c'est que l'universitaire n'ai pas envoyé de patch !
          • [^] # Re: Dommage...

            Posté par  (site Web personnel) . Évalué à 4.


            Ce qui est dommage c'est que l'universitaire n'ai pas envoyé de patch !


            Le papier est de 96. Je ne pense pas que ce papier aurait pu donner lieu à un patch sur le noyau linux de 96. ;)

            On peut imaginer que l'auteur du papier de 96 a depuis fait du chemin...

            De plus son article trouve probablement des applications dans de nombreux autres domaines.

            Aussi, c'est le propre de la recherche scientifique : produire des résultats qui trouveront une application ultérieurement. Chaque chercheur ne fait pas tout depuis l'archi théorique jusqu'à la mise en ½uvre pratique dans le système de tout un chacun.

            Vu les messages, on peut raisonnablement penser que le patch en question verra le jour, et c'est ce qui compte.
            • [^] # Re: Dommage...

              Posté par  . Évalué à 2.

              Sauf qu'en fait les principes sont différent. Ie truc de l'universitaire est un EDF modifié alors que l'algo d'ingo non. (en gros, l'un tient compte de la date de fin d'execution, l'autre de la date de début et cela change pas mal le comportement de l'ensemble)

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

              • [^] # Re: Dommage...

                Posté par  . Évalué à 1.

                Dans le lien que j'ai donné, cette différence est mentionné et il me semble (je n'ai pas tout relu en détail) qu'Ingo semblait considérer l'approche de l'universitaire intéressante et qu'il allait l'essayer.

                Bref.
                • [^] # Re: Dommage...

                  Posté par  . Évalué à 2.

                  J'avais lu le lien à l'époque, la discussion avait continuer sur la lkml et Ingo avait montrer les différences.

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

          • [^] # Re: Dommage...

            Posté par  . Évalué à 3.

            Ce n'est pas le boulot d'un chercheur. Il ne faut pas tout confondre.

            Avoir du code incorporé dans le noyau linux n'est que très peu valorisé académiquement. Un universitaire va donc faire un patch, faire des mesures et sortir un papier. Une fois le patch écrit, il y a beaucoup de boulot pour arriver à le faire incorporer au noyau. Il n'y a qu'a voir les problèmes de Con Kolivas pour faire incorporer son ordonnanceur, les frustrations et les rancoeurs que ça peut occasionner.
            • [^] # Re: Dommage...

              Posté par  . Évalué à 2.

              Ce n'est pas le boulot d'un chercheur. Il ne faut pas tout confondre.

              Et bien c'est bien dommage que tout le monde soit satisfait d'une publication. Je trouve ca assez symptomatique de la recherche : on fait un beau papier qu'on essaie de faire publier dans un magazine le plus prestigieux possible, après on se congratule entre chercheur, et puis après plus rien (bon, pas toujours, certes).

              Il y a tant de belles choses a sortir des labo ! Personne ne va les chercher ... il faut les sortir soit même, comme, par exemple, faire son patch, et avoir la reconnaissance de l'industrie. Mais apparemment certains trouvent cela limite rabaissant.
              • [^] # Re: Dommage...

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

                Ba, le travail du chercheur, c'est de chercher (et de trouver, si possible), pas d'appliquer ses trouvailles. Une fois la publication disponible, les ingénieurs peuvent à leur guise utiliser l'idée.

                Comme tu le dis, le problème, c'est pas vraiment que le chercheur ne cherche pas forcément à faire la promotion de sa recherche, c'est plutôt que personne n'en fait la promotion, et que personne ne va prendre les idées disponibles pour les appliquer.

                En fait, c'est pas vraiment vrai : il suffie de voir les intégrations de Microsoft dans .Net des idées présentes dans OCaml, de regarder du coté de la recherche "appliqué", etc.
                • [^] # Re: Dommage...

                  Posté par  . Évalué à 2.

                  c'est plutôt que personne n'en fait la promotion, et que personne ne va prendre les idées disponibles pour les appliquer

                  J'adore cette manière de retourner le problème. Mon discours était de justement dire que c'était aux chercheurs eux même de faire (et d'apprendre a faire) la promotion de leur recherche ... tous simplement parce que personne ne peut le faire ou le fera à leur place.

                  Mon idée était de dire qu'une application, même sommaire, est le meilleur moyen d'attirer l'attention pour faire la promotion. Comme personne ne peut le faire a leur place, les chercheurs doivent donc le faire eux même.

                  Et tu conclue par me citer un exemple avec un grand groupe industriel : les grand groupes sont les seules et uniques entités pouvant se permettre d'allouer du temps a se pencher et essayer de comprendre le travail des chercheurs. Est ce vraiment le modèle économique et social que le monde de la recherche souhaite ?

                  Il y aurait justement tellement d'ingénieurs/techniciens dans des entreprises plus modeste qui présenterais bien a leur patron des projets plus ambitieux ... si seulement il y avait quelque chose a présenter ...
                  • [^] # Re: Dommage...

                    Posté par  . Évalué à 6.

                    Je pense que tu confonds le boulot de chercheur et celui d'ingénieur de recherche.

                    Certaines personnes sont douées pour chercher et trouver des trucs. Ce qu'elles produisent n'est certainement pas directement utilisable. Pour cela, il faut passer du temps pour polir, nettoyer, remettre en forme.

                    Ce travail de nettoyage, c'est plus celui d'un ingénieur de recherche. L'ingénieur doit évidemment travailler avec le chercheur.
                    Les chercheurs pourraient éventuellement passer du temps en polissage mais
                    - ce n'est pas ce qu'on leur demande. Il vaut mieux qu'ils inventent d'autres trucs que d'autres nettoieront ;
                    - ils ne sont pas forcément doués pour cela.

                    Je préfère qu'un Dijkstra, qu'un Knuth ou qu'un Tarjan passent leur temps à produire des trucs monstrueux qu'eux seuls peuvent trouver et que d'autres personnes fassent le lien.

                    Même au sein de la recherche la plus fondamentale, on retrouve ce genre de schéma. Pour parler d'un sujet que je connais bien.
                    1. Il y a 20 ans, 2 gars ont pondu une démo pour une vieille conjecture. La démo fait 600 pages. Pour une rapide introduction, voir http://en.wikipedia.org/wiki/Robertson-Seymour_theorem;
                    2. Un petit groupe de personne dont je fais parti passe beaucoup de temps à étudier cette démonstration pour bien la comprendre et pour la simplifier. C'est un bordel sans nom mais à force d'acharnement, sur ces 600 pages, on a réussi à faire fondre les 200 premières à moins de 40 pages
                    3. Ces 40 pages ont des implications très importantes en algorithmique théorique. Certains chercheurs essayent de faire les liens. On a donc maintenant de jolis algorithmes inutilisables pour plein de problèmes.
                    4. Certains chercheurs essayent de rendre ces algorithmes vraiment utilisable en pratique. Il existe maintenant des « proof of concept » super efficace pour certains problèmes particuliers.
                    5. Certains chercheurs commencent à écrire des bouquins « pour les masses » pour que certains ingénieurs de recherche apprennent ces concepts.

                    Avec un peu de chance, d'ici 20-30 ans, le travail commencé il y a 20 ans sera vraiment utilisé.
                    • [^] # Re: Dommage...

                      Posté par  . Évalué à 2.

                      Ingenieurs de recherche? Mais de qui parles-tu? Des petits jeunes de 23 ans qui vont bosser 12 mois pour l'INRIA a la fin de leurs etudes? Ou des types qui gerent les reseaux enseignement des Universites?

                      Dans le public, il n'y a pratiquement pas d'ingenieurs de recherche tels que tu les decris. Et malheureusement, des boites privees qui financent des ingenieurs pour tirer quelque chose de la recherche academique, il n'y en a pas beaucoup non plus (du moins en France).

                      Les chercheurs peuvent donc se bercer d'illusions et affirmer que leur recherche sera appliquee dans quelques decennies, il est tres clair que dans 99% des cas (et meme probablement plus), si ils ne s'interessent pas a la valorisation de leurs travaux, personne d'autre ne s'y interessera non plus.
                      • [^] # Re: Dommage...

                        Posté par  . Évalué à 3.

                        Ce n'est pas parce que « les décideurs préssés » comme il semble bon de les appeler ici ne se rendent pas compte de l'utilité d'embaucher des ig de recherche que ce boulot n'existe pas. Et ce n'est pas non plus parce qu'ils manquent que les chercheurs doivent faire un boulot qui ne leur est pas demandé.
              • [^] # Re: Dommage...

                Posté par  . Évalué à 2.

                Je suis d'accord mais certains ingénieurs ont une attitude légèrement méprisante vis-à-vis des chercheurs: les chercheurs dans leurs tours d'ivoire, déconnectés de la réalité, qui ne connaissent rien à la vie.

                Pour citer un exemple célèbre, il suffit de voir la discussion entre Torvald et Tannenbaum.

                Bref, je suis persuadé que certains ingénieurs sont prêts à regarder ce que font les chercheurs et que certains chercheurs sont prêts à aider les ingénieurs. Le principal problème, c'est qu'il n'y a pas de vraie culture de transfert et donc, c'est difficile.
                • [^] # Re: Dommage...

                  Posté par  . Évalué à 1.

                  Donc on est bien d'accord.

                  Mais il y a aussi un paramètre : le temps. En france, les chercheurs n'ont pas (plus que ca) a justifier le temps qu'il allouent a telle ou telle activité. Le réflexe des chercheurs, bien naturel, est d'allouer le maximum de temps a l'activité la plus prestigieuse, prometeuse, et parce que après tout c'est leur boulot, la recherche.

                  Mais mise a part la pénalité sur l'avancement de leur travaux, les chercheurs ne perdent rien (du moins en france) a passer du temps sur une application. Alors que pendant ce temps là, les entreprises, et leurs ingénieurs, s'occupent a s'assurer de quoi manger, se loger et vivre leur vieux jour a l'abris. (Le chercheur déconnecté de la réalité a souvent tendance a ignorer que la plupart des entreprise ne marchent pas bien, et donc, pas trop de sous a dépenser ni de temps a perdre).

                  C'est pourquoi, même si je suis d'accord avec toi, le problème est bipolaire, j'estime que c'est plus aux chercheurs de faire l'effort, tout simplement par ce qu'ils peuvent se le permettre.
                  • [^] # Re: Dommage...

                    Posté par  (site Web personnel) . Évalué à 5.

                    Je pense que tu généralises trop, en parlant "des chercheurs" comme une grande unité où tout le monde est pareil. En premier lieu, tu as des domaines où trouver des applications est plus facile que d'autres, une application d'un nouvel algorithme, ça se trouve, une application de l'analyse rigoureuse des équations d'Einstein, c'est pas du même calibre (et pourtant ça existe, le GPS).
                    Je suis d'accord que les personnes qui font de la recherche appliquée devrait faire des efforts supplémentaires (pour leur propre bien) pour valoriser leur travail par des applications, mais évitons de généraliser de trop. En particulier:
                    Le réflexe des chercheurs, bien naturel, est d'allouer le maximum de temps a l'activité la plus prestigieuse, prometeuse, et parce que après tout c'est leur boulot, la recherche.

                    Je fais une thèse dans un laboratoire de recherche, les gens s'intéressent en général...aux choses qu'ils aiment faire, qu'ils connaissent et qui s'accordent avec leur conviction, sans regard pour le prestige.
                    <exemple lourd>Par exemple, (je suis spécialisé en Cosmologie, relativité, désolé pour les exemples donc) la communauté scientifique s'accorde plus ou moins sur un scénario dit inflationiste de l'univers, une activité prestigieuse est d'essayer de faire des prédictions sur ce scénario. Deux des professeurs les plus renommés de mon groupe font des recherches inverses, sur une théorie sans inflation, donc beaucoup moins populaire.</exemple lourd>

                    Bref, tout ça pour dire que ta vision des chercheurs me semblent un peu réduite. De même, le
                    ils peuvent se le permettre.
                    la recherche académique dans de nombreux domaines est très dure, compétitive, et demande de passer de longues heures de travail, week end compris. Si tu as la vision du chercheur babacool qui donne deux heures de cours par semaine et se la coule douce, eh bien, je peux te dire que dans mon groupe de recherche, c'est très différent, un grand nombre de personnes viennent le week end pour bosser, rentre tous les soirs après 21h où reçoivent des engueulades par leur femme parce qu'ils ont encore passé la nuit dans leur bureau. Certes, on ne travaille pas comme des personnes en banque d'affaires, mais c'est pas dit qu'on puisse "se le permettre". En tout cas, pas tous.
                    • [^] # Re: Dommage...

                      Posté par  . Évalué à 0.

                      C'est un problème qui se porte même au delà des aspects ingénieurs/chercheur "en France"
                      Mais bien le thème de l'informatique dans sont ensemble. L'informatique n'est pas vraiment une science dure comme la physique, les mathématiques, la médecine ect… hors la vrai vocation des chercheurs universitaire c'est au moins de pousser leurs recherches à la production de quelque chose de tangible. Voilà pourquoi il existe les R&D, car si l'on se creuse vraiment la tête c'est de là que sort vraiment l'innovation. La question pourrait se poser encore autrement "les chercheurs informatiques sont ils vraiment utiles à partir du moment ou leurs travaux se basent sur de l'appliqué (job des ingénieurs en R&D).

                      Encore une fois, derrière recherche il y a "tentative de démonstration d'une théorie" et l'informatique ne se démontre pas.
                      • [^] # Re: Dommage...

                        Posté par  . Évalué à 5.


                        Encore une fois, derrière recherche il y a "tentative de démonstration d'une théorie" et l'informatique ne se démontre pas.


                        L'informatique est une branche des maths, l'informatique est à base de maths et toute l'informatique c'est des maths.
                        Or qui dit maths dit démonstration.

                        Allez, on va sortir les gros morceaux de la calculabilité (discipline fondamentale de l'informatique), avec le modèle de Turing (machine de Turing), comment on démontre que les machines de type RAM (le PC en est une) est également une machine de Turing.
                        On sort également la preuve qu'il n'existe pas d'antivirus (application du théorème diagonal de Gödel) ou qu'il est impossible de prouver en un temps raisonnable et de façon automatique qu'un programme de la machine de Turing est correct (vérification de code?).

                        Inutile? ultra utile au contraire! car tu va chercher une sémantique de langage de programmation qui sera (presque) aussi expressive que la machine de Turing, tout en se restraignant à la partie qui est prouvable de façon automatique.

                        Si tu n'a pas envie de changer de langage, alors on va appliquer des outils de vérification de code qui vont vérifier que 1. tu restes dans cette restriction qui est prouvable et 2. que la preuve est correcte.

                        Allons un peu plus loin: la démonstration est nécessaire: tu accepterais de monter dans un avion si son logiciel n'était pas prouvé correct?

                        Toute l'informatique est une histoire de démonstration. Les mauvais informaticiens sont le plus souvent de mauvais mathématiciens.
                        • [^] # Re: Dommage...

                          Posté par  . Évalué à 2.

                          Les mauvais informaticiens sont le plus souvent de mauvais mathématiciens.

                          Il faut noter que la réciproque est beaucoup moins vraie :)
                      • [^] # Re: Dommage...

                        Posté par  . Évalué à 2.

                        « L'informatique n'est pas vraiment une science dure comme la physique, les mathématiques, la médecine »

                        Pardon ? L'informatique, c'est une branche des maths (comme il a déjà été dit ailleurs). D'un côté, tu as les informaticiens théoriques ; par exemple, qui eut cru que, pour assurer qu'un bête
                        SELECT * FROM TABLE1 WHERE COND=1

                        tout une algèbre avait été créée ? Et crois-moi, l'algèbre en question est loin d'être triviale. La sûreté des types (chose qu'on retrouve en OCAML, certes, mais aussi dans des langages aussi communs que Java...), c'est avant tout du lambda calcul, c'est à dire des maths (petite anecdote : Church, à l'origine du lambda-calcul, avait comme thésard un certain Turing, à l'origine des machines du même nom ... Et à eux deux, on peut affirmer qu'ils sont à l'origine des tous les langages informatiques ou presque).

                        De l'autre, tu as les chercheurs faisant de l'informatique plus appliquée : étant donné un certain type de machine, avec un certain type de processeur, qui possède un certain nombre de caractéristiques (superscalaire, vliw, multithreadé, que sais-je), comment faire pour obtenir la meilleure performance pour un type d'application donné avec une méthode la plus générale possible ?

                        Il y a trop de paramètres en jeu pour pouvoir répondre à cette question de manière théorique (latence des instructions, latence des accès mémoires, problèmes de faux-partage, de deadlocks, etc) ; on est donc obligé de mesurer la performance de la méthode d'optimisation élaborée.

                        En fait, je pense que l'informatique est une science au même titre que la physique : comme elle, elle possède deux extrêmes (théorie et application), et une infinité d'intéractions entre les deux.

                        Contrairement à la médecine ou la pharmacologie, par exemple, qui profite bien entendu des progrès effectués en physique et en chimie, mais qui sont essentiellement expérimentales.

                        « la vrai vocation des chercheurs universitaire c'est au moins de pousser leurs recherches à la production de quelque chose de tangible »

                        Pas vraiment ; quand tu es dans le domaine de la recherche fondamentale (en maths ou en physique par ex), tu ne peux pas t'attendre à avoir tout de suite une application plus ou moins directe. En info théorique non plus, globalement (le nombre de papiers d'info théoriques qui traînent des théorèmes et autres équations, mais qui ne comportent pas de ligne de code est loin d'être négligeable). Quand tu es dans le domaine des sciences appliquées, par contre, tu as bel et bien des possibilités ... d'application, et là le chercheur a plutôt intérêt à montrer que ses recherches fonctionnent. Le seul problème, c'est que le chercheur, une fois qu'il a montré que sa solution était viable, il a autre chose à faire comme ... trouver la réponse à un autre problème.

                        Le seul moyen que je vois pour « proprifier » le travail du chercheur, c'est d'avoir un/des ingénieurs de recherche dans le même labo, qui travaillent avec lui, et implémentent proprement un prototype une fois qu'on sait que ça fonctionne. Seulement voilà : un ingénieur de recherche, c'est pas gratuit, et à moins de pouvoir ensuite se faire des sous avec le prototype, je ne vois pas pourquoi les labos s'embêteraient avec l'embauche de ce genre de gens (ça arrive, ceci dit, même en France).

                        « Encore une fois, derrière recherche il y a "tentative de démonstration d'une théorie" et l'informatique ne se démontre pas. »
                        Bien sûr que si. Un algorithme, ça se prouve ; une complexité algorithmique, ça se démontre ; une méthode de parallélisation efficace sur un type d'architecture, ça se conçoit puis se mesure ; les compilateurs passent leur temps à prouver que ton code est (in-)valide, du point de vue du langage utilisé ; les bases de données fonctionnent grâce aux propriétés algébriques grâce auxquelles on assure certaines propriétés (intégrité relationnelle, etc.).
                • [^] # Re: Dommage...

                  Posté par  . Évalué à 1.

                  >Pour citer un exemple célèbre, il suffit de voir la discussion entre Torvald et Tannenbaum.

                  Mouai, euh dans l'affaire Tannenbaum n'est pas en reste non plus question mépris: "c'est nul votre truc, ça ne marche que sur x86"..
                  Quand on voit que beaucoup plus tard, Minix3 n'est developpé en pratique quasiment que sur x86 ..

                  Sinon un theme de recherche que j'ai bien aimé c'est une meilleure intégration entre le gestionaire de mémoire virtuel et le ramasse miette, maintenant que la JVM est libre, ce serait faisable..

                  Je n'arrive pas a recuperer l'URL mais c'est le premier resultat de 'vm aware garbage collector' sur Google.
                • [^] # Re: Dommage...

                  Posté par  . Évalué à 2.

                  > Bref, je suis persuadé que certains ingénieurs sont prêts à regarder ce que font les chercheurs et que certains chercheurs sont prêts à aider les ingénieurs. Le principal problème, c'est qu'il n'y a pas de vraie culture de transfert et donc, c'est difficile.

                  Il ne faut pas oublier que la plupart des ingénieurs sont formés par des chercheurs ! Ce que vous dîtes est vrai pour les décideurs qui sont sorti des écoles il y a bien longtemps.

                  Sans compter que presque tous les chercheurs ne font pas que du théorique, et que bon nombre de publications (peut-être trop même) sont des applications de la recherche à des problèmes concrets mais "mal" résolus. En réalité, la communication ne passe pas mal entre la recherche et l'ingénierie, mais ça prend du temps et de l'énergie, et que les décideurs sont un peu dépassés et considèrent que ça marchait très bien comme ça. La plupart ne vont pas prendre le risque de faire utiliser une technologie que personne ne maîtrise encore sans en avoir déjà vu quelques démonstrations concluantes.
                  • [^] # Re: Dommage...

                    Posté par  . Évalué à 3.

                    On voit bien que tu n'as pas eu d'étudiants qui, quand tu imposes OCAML comme langage, pour un projet compil, se mettent à hurler qu'OCAML, c'est de la merde. Si c'était bien, ça serait utilisé dans l'industrie. Eux, ils veulent programmer en C, C++ ou java.

                    Un certain nombre d'étudiants considère que la fac, c'est un truc chiant qui ne sert qu'à leur permettre de rajouter une ligne sur leur CV et surtout pas à apprendre quelque chose. Les trucs utiles, ils les apprendront sur le tas.
                    • [^] # Re: Dommage...

                      Posté par  . Évalué à 2.

                      "Un certain nombre d'étudiants considère que la fac, c'est un truc chiant qui ne sert qu'à leur permettre de rajouter une ligne sur leur CV et surtout pas à apprendre quelque chose. Les trucs utiles, ils les apprendront sur le tas."

                      S'il pensait autrement, il ne serait pas à la fac mais dans une école d'ingé.


                      ... /me s'enfuit en courant.

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

            • [^] # Re: Dommage...

              Posté par  . Évalué à 0.

              Je pense que réside là tout le problème de la recherche : le chercheur cherche plus à être valorisé académiquement qu'à faire avancer les choses concrètement.

              L'infrasctructure sur laquelle travaille beaucoup de chercheurs est à base de logiciels produits par des universitaires : C, Unix, OCaml...

              De nos jours, les initiatives comme OCaml se font de plus en plus rares. Les chercheurs sont devenus des managers, et il n'y a plus grand monde pour pondre des contributions intégrables dans une machine de production. Les thésards, trop pressés par leurs deadlines produisent du code de prototype rarement transformé en code de production.

              C'était mieux avant.
      • [^] # Re: Dommage...

        Posté par  . Évalué à 2.

        Mettre Python et PHP dans le même sac, c'est un peu osé si je puis me permettre.

        Python est un langage bien conçu, comparé au PHP. Et je ne vois pas en quoi un programme Python serait mois fiable qu'un programme Ocaml. Car de toute façon, même en Ocaml, j'imagine que tu écris aussi des tests unitaires. Le typage n'est pas tout, il ne vérifier pas que ce que tu fais est bien ce que tu dois faire.

        J'aime bien Ocaml, mais dans la vie de tous les jours, Python est bien plus armé, notamment en ce qui concerne les librairies.
        • [^] # Re: Dommage...

          Posté par  . Évalué à 2.

          On peut aussi utiliser pycaml ou perl4caml qui permettent d'utiliser toutes les librairies de ces languages dans un prog ocaml. Pas toujours très agréable à utiliser, cela permet néanmoins de réutiliser beaucoup de code !
        • [^] # Re: Dommage...

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

          en python :
          >>> if 1 > 2:
          ...     "toto" + 1
          ... else:
          ...     1 + 1
          ... ^D
          2
          >>> 
          
          en OCaml :
          # if 1 > 2 then
              "toto" + 1
            else
              1 + 1;;
          This expression has type string but is here used with type int
          # 
          
          ("toto" est souligné) Donc on voit bien qu'en python, le code marchera jusqu'au jour où le test donnera "true", alors qu'en OCaml, il ne compile même pas...
          • [^] # Re: Dommage...

            Posté par  . Évalué à 1.

            C'est pour ça que je parle de test unitaire.

            Bcp de pro-typage statique négligent cette partie, pendant que le système de type les protège. Je maintient qu'on peut écrire du code correctement typé, ms qui fait n'importe quoi.
            • [^] # Re: Dommage...

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

              J'ai pas dit le contrainre, ni que les tests unitaires ne servent à rien. D'ailleurs, j'en fait des tests unitaires en OCaml.

              Mais, d'expérience, les tests unitaires sont beaucoup moins utile qu'en python : je n'ai jamais fait ressortir une erreur grâce à un test unitaire, car une fois que ca compilait, ca faisait ce que je pensais avoir programmé. Bien sur, il reste des erreurs parfois, mais ça a toujours été des erreurs dans des cas relativement complexes non mis en valeur par des tests unitaires.

              Ensuite, un gros avantage des tests unitaires, c'est de pas tout casser accidentellement. Or, très souvent, une telle erreur casse directement la compilation.

              Bref, à mon avis, les tests unitaires sont indispensable au développement en python, alors que ce n'est qu'un plus en OCaml.

              Pour conclure, je pense donc que grâce à son typage statique fort, un programme en OCaml est plus fiable qu'un programme en python, pour répondre à « je ne vois pas en quoi un programme Python serait mois fiable qu'un programme Ocaml » (j'aurai dû préciser que je répondai à cette phrase).
    • [^] # Re: Dommage...

      Posté par  . Évalué à 3.

      C'est vrai que OCAML a l'air d'avoir plein d'atouts pour lui.

      Cela dit, je trouve personnellement dommage de ne pas avoir la surcharge des opérateurs. Certains me diront que c'est à cause de l'inférence de type, mais ce serait bien si on pouvait quand même avoir la possibilité (le choix) d'avoir de la surcharge, quitte à expliciter les types lorsque le compilateur ne s'y retrouve pas...

      Autre chose : il me semble qu'il n'était pas évident d'interfacer une lib C/C++ et du code CAML (faire gaffe au GC, etc...). ça a changé ?

      Le jour où je pourrai utiliser '*' aussi bien pour les flottants que pour les matrices ou les entiers, le jour où je pourrai facilement interfacer du code C pour les parties critiques ou avec des bouts en asm, là je considèrerai CAML comme mon langage favori ! (j'ai oublié d'ajouter "le jour où QT4 et it++ seront accessibles depuis CAML"...)

      P.S.: question subsidiaire : pourquoi ont-ils développé leur compilateur totalement eux-mêmes plutôt que de contribuer à GCC ? ça aurait rendu le langage accessible sur plein d'autres plates-formes... !
      • [^] # Re: Dommage...

        Posté par  . Évalué à 3.

        Et oui en effet il n'y aura JAMAIS de surcharge des opérateurs (oui, je sais, il ne faut jamais dire jamais) parce que sinon on ne permet pas l'inférence de type, et le polymorphisme paramétrique. J'ai étudié dans un cours l'algorithme de typage, et il apparaît clairement que la surcharge ne permettrait plus de résoudre le système des contraintes, et de typer une expression.

        Alors, pourquoi ne pas oublier le typage automatique ?
        Parce que c'est la force principale de OCaml. Il est connu et reconnu que le typage fort, strict et automatique prévient de beaucoup d'erreurs. En fait je dirais presque que si un code Caml compile, alors il marche. C'est un peu faux évidemment, mais pas si loin que ça de la vérité. De plus le typage paramétrique est vraiment extrèmement plaisant à manipuler, par exemple pour faire des conteneurs standards, c'est 100x mieux qu'en C++.

        Sinon pour utiliser "*" sur des matrices tu ne peux pas mais tu peux avoir une syntaxe plus sympa par exemple avoir *_ en faisant :

        let prefix*_ a b = matrix_mul a b;;
        let c = a *_ b;;



        Sinon pour la question sur le compilateur je dirais que c'est lié au fait que OCaml soit à la base un projet de recherche, très ancien, non placé sous licence GPL.
        Donc initialement lorsque le projet a démarré, gcc n'existait pas et était encore moins multilangages.
        De plus il me semble que certaines spécificités des langages fonctionnels permettent des optimisations pas forcément très claires sur la représentation interne de gcc.
        Enfin, il ne faut pas oublier que OCaml doit tourner à la fois sur une machine virtuelle et sur un compilateur, et ce genre de chose doit êter pus difficile à obtenir avec le même comportement en écrivant d'une part un front-end gcc et de l'autre une machine virtuelle.
        • [^] # Re: Dommage...

          Posté par  . Évalué à 3.

          Et oui en effet il n'y aura JAMAIS de surcharge des opérateurs (oui, je sais, il ne faut jamais dire jamais) parce que sinon on ne permet pas l'inférence de type, et le polymorphisme paramétrique. J'ai étudié dans un cours l'algorithme de typage, et il apparaît clairement que la surcharge ne permettrait plus de résoudre le système des contraintes, et de typer une expression.


          C'est marrant parce que justement pour l'occasion de la 3.10 je suis allé farfouiller un peu sur le site de l'INRIA, et sur la page perso du type qui a refait camlp4 on trouve :
          http://gallium.inria.fr/~pouillar/talks/overloading-searchin(...)

          Par ailleurs, on peut aussi parler du Haskell qui a des moyens de surcharge assez poussés, et qui conserve bon an mal an une partie de son inférence de type. Par ailleurs, ils ont plein de trucs encore plus affreux comme le polymorphisme de second ordre et compagnie (mais il me semble qu'on l'a aussi en OCaml à quelques endroits, je l'ai juste jamais utilisé) qui doivent bien mettre à mal l'inférence des types. Mais elle a survécu : elle est pas totale, mais elle a survécu.
          • [^] # Re: Dommage...

            Posté par  . Évalué à 1.

            Oui en fait je voulais dire, avec l'algorithme tel qu'il est.
            Je viens de parcourir en diagonale les slides, et il semble que la forme de surcharge prévue soit un peu moins puissante que celle prévue par le C++ par exemple.

            De plus je me demande si les concepteurs de OCaml iront faire ceci, car la preuve du noyau de OCaml serait sans doute à refaire, ce qui doit prendre un certain temps. Après je n'ai pas vu en détails, il suffirait peut-être d'adapter.

            En tout cas ça va rendre l'UE "fondements de la programmation" plus difficile ;-)
        • [^] # Re: Dommage...

          Posté par  . Évalué à 1.

          http://www.haskell.org/tutorial/classes.html

          Et pourtant Haskell a aussi l'inférence de type. Je dirais donc que ça depend du modele de typage choisi.



          En fait je dirais presque que si un code Caml compile, alors il marche.
          oui, en tout cas il ne vas pas se vautrer ent laissant un core dump ;)
          Mais on est pas a l'abris d'exception runtime. Et surtout, ton programme fait-il vraiment ce que tu veux qu'il fasse?

          D'autre part, ocaml peut tourner en code natif, sur une machine virtuelle, ou en mode interprèté. Il me semble évident que que certaines parties du système sont communes à ces trois modes, et que le tout se marrie mal avec gcc(autant que je sache), donc autant utiliser le même code, tant qu'a faire.

          La seul utilisation de gcc que je vois possible serait pour la génération de code natif, ms j'avoue que même là j'ai des doutes.
          Je suis loin d'être un expert en gcc, et en compilation, ms par exemple, serait-il possible de générer du code optimisant la récursivité terminale avec gcc?
      • [^] # Re: Dommage...

        Posté par  . Évalué à 2.

        Pour la surcharge, c'est un problème souvent cité mais est-ce que les autres atouts d'ocaml ne permettent pas de dépasser ce petit problème ?

        Je suis en revanche d'accord avec toi sur QT4. Il manque clairement des bindings graphiques. Et lablGTK2 n'est pas assez documenté...

        Cela dit, comme toujours dans le logiciel libre... rien n'empêche de monter un projet pour le faire...
      • [^] # Re: Dommage...

        Posté par  . Évalué à 2.

        La question est la suivante. Que préfères-tu:
        - utiliser *. pour les réels ;
        - devoir déclarer le type de toutes les variables entières ou réelles ?

        Franchement, *. est beaucoup plus économique. Après, c'est juste de la syntaxe et comme toujours, les programmeurs sont très attachés à leurs habitudes et si un langage décide d'utiliser # au lieu de * pour la multiplication, ils n'utiliseront pas le langage. C'est exactement la même chose que le fil de discussion sur les raccourcis sous vi et blender.

        Dommage.
  • # Beurk, un langage impératif

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

    Quelle horreur, des effets de bords, des structures impératives, des trucs qui ont pas le même effet quand on les appelle avec les mêmes arguments, ahhhh bahhh cacaaaa pas bôôô impur, beeeerk.

    Vite, une injection de haskell !















    Bon, on n'est pas vendredi mais ça avait pas l'air de démarrer alors je me dévoue...
    • [^] # Re: Beurk, un langage impératif

      Posté par  . Évalué à 2.

      http://haskell.org/ghc/docs/latest/html/libraries/base/Syste(...)

      import System.IO.Unsafe
      import Data.IORef

      cast :: a -> b
      cast x = unsafePerformIO $ writeIORef r x >> readIORef r
      ..........where r = unsafePerformIO $ newIORef $ error "pwned le puriste"
      • [^] # Re: Beurk, un langage impératif

        Posté par  . Évalué à 4.

        On peut aussi, pour faire plus sérieux, citer un papier ( http://citeseer.ist.psu.edu/pippenger96pure.html ) où il est montré qu'il existe (au moins) un algorithme pour lequel un algo fonctionnel pur est au mieux en O(n log n), alors qu'il existe une version impérative en O(n).

        (après, ça n'enlève rien au mérite du Haskell, ni aux langages fonctionnels purs, mais là il faut défendre OCaml, alors tous les coups sont permis, voilà tout)
        • [^] # Re: Beurk, un langage impératif

          Posté par  . Évalué à 2.

          *PAN*
        • [^] # Re: Beurk, un langage impératif

          Posté par  . Évalué à 1.

          En réalité, plusieurs langages purs modernes fournissent des tableaux qu'on peut modifier en O(1). Ainsi on peut traduire n'importe quel algorithme impératif en une version pur qui passe un tableau à chaque opération, et le nombre d'opérations (donc l'expression O()) reste le même.

          (Cela dit, parfois on préfère écrire la version Θ(n log n).)
        • [^] # Re: Beurk, un langage impératif

          Posté par  . Évalué à 1.

          Extrait du papier cité :
          "it should be borne in mind that "purity" refers to the absence of RPLACA and RPLACD operations rather than the absence of side-effects"

          (Traduction libre : "« Pureté », dans ce papier, indique l'absence d'opérations RPLACA et RPLACD plutôt que l'absence d'effets de bords.")

          Tandis que dans le contexte de ce fil, ou bien dans le contexte des langages ocaml/haskell/mercury, les mots pur/impur indique l'absence/présence d'effets de bords.
      • [^] # Re: Beurk, un langage impératif

        Posté par  (site Web personnel) . Évalué à 4.

        Oui, et ? Tous les langages raisonnables sont turing puissant, donc on peut faire les mêmes choses dedans. On peut faire des effets de bord en haskell, et il y a même des librairies pour le faire salement, mais ce n'est pas dans le langage de base ni encouragé (sinon on ne se taperait pas des monades juste pour le plaisir), contrairement à ocaml.

        Mon trollomètre a à peine tressauté en lisant ton message, peut mieux faire.
        • [^] # Re: Beurk, un langage impératif

          Posté par  . Évalué à 1.

          Turing complete ça veut dire qu'on peut faire les même chose dedans, mais pas forcément avec la même efficacité.

          Brainfuck est Turing complete (me semble-t-il), et pourtant il sera moins efficace algorithmiquement (par exemple mettre un nombre N dans une case mémoire a une complexité plus grande que O(1), ce qui n'est pas le cas avec des nombres pas trop grands dans la plupart des autres langages).

          Le papier qui indique une borne inférieure de complexité moins intéressante avec un algo fonctionnel pur qu'un algo impératif tient donc toujours.

          Évidemment, ça ne concerne pas Haskell, qui n'est pas un langage fonctionnel pur, comme tu dis :p
          (par contre je suis pas sûr que le hack de l'UnsafePerformIO suffise pour échapper à la preuve de l'autre, mais on sait jamais ce qu'on peut faire avec ces trucs tordus...)
  • # Lisibilité et produit de matrices

    Posté par  . Évalué à 6.

    • Pour répondre à quelques objections sur la lisibilité, il me semble que tout langage permet d'écrire des choses illisibles (à partir du moment où il est Turing complet du moins). Un bon langage de programmation à mon sens est un langage qui permet d'écrire lisiblement. Dans pas mal de situations, Caml permet d'écrire lisiblement là où ni C ni Java ne le permettent (et la réciproque est plutôt rare).
    • Un code caml qui implante le produit de matrice peut être tout à fait lisible en fonctionnel et bien plus lisible que les versions impératives : deux fonctions auxiliaires (sigma et init_matrix) d'une ligne et une ligne pour le produit en lui même. C'est très lisible à partir du moment où on sait que "(fun i j -> expr)" désigne la fonction qui à i et j associe "expr".
    • Comme je ne suis pas doué, j'ai évidemment fait beaucoup d'erreurs en écrivant le code ci-dessous. Le compilo caml les a toutes corrigées, sauf une dans la fonction sigma qui conduisait à une boucle infinie systématiquement. Correction du bug -> tout baigne. C'est pas en C ni en Java qu'on aurait le même confort.
    • Cas des matrices de taille n fixée :
      (* Fonction d'intérêt général *)
      (* Calcule (f i) + (f (i+1) + ... + (f j) *)
      let rec sigma i j f = if j < i then 0. else (f i) +. sigma (i+1) j f;;
      
      (* taille des matrices *)
      let n = ...
      
      (* Construit la matrice des (f i j) *)
      let init_matrix f = Array.init n (fun i -> Array.init n (fun j -> f i j));;
      
      (* somme de matrices, juste pour s'amuser *)
      let sum p1 p2 = init_matrix (fun i j -> p1.(i).(j) +. p2.(i).(j));;
      ;;
      
      let prod p1 p2 =
        init_matrix (fun i j -> sigma 0 (n-1) (fun k -> p1.(i).(k) *. p2.(k).(j)))
      ;;
      
    • Cas des matrices de taille dynamique :
      (* Calcule (f i) + (f (i+1) + ... + (f j) *)
      let rec sigma i j f = if j < i then 0. else (f i) +. sigma (i+1) j f;;
      
      (* construit la matrice des (f i j), 0<=i<n, 0<=j<m *)
      let init_matrix n m f =
        Array.init n (fun i -> Array.init m (fun j -> f i j))
      ;;
      
      (* dimensions d'une matrice *)
      let dim_matrix p =
        let n = Array.length p in
        assert (n<>0);
        let m = Array.length p.(0) in
        (n,m)
      ;;
      
      (* somme de matrices, juste pour s'amuser *)
      let sum p1 p2 =
        let (n1,m1) = dim_matrix p1
        and (n2,m2) = dim_matrix p2 in
        assert (n1 = n2 && m1 = m2);
        init_matrix n1 m1 (fun i j -> p1.(i).(j) +. p2.(i).(j))
      ;;
      
      let prod p1 p2 =
        let (n1,m1) = dim_matrix p1
        and (n2,m2) = dim_matrix p2 in
        assert (m1 = n2);
        let c i j = sigma 0 (m1-1) (fun k -> p1.(i).(k) *. p2.(k).(j)) in
        init_matrix n1 m2 c
      ;;
      
    • [^] # Re: Lisibilité et produit de matrices

      Posté par  . Évalué à 2.

      Dans pas mal de situations, Caml permet d'écrire lisiblement là où ni C ni Java ne le permettent (et la réciproque est plutôt rare).

      Suivi d'un tas de code incompréhensible...

      Je ne suis pas sur que la démonstration soit convaincante.
      • [^] # Re: Lisibilité et produit de matrices

        Posté par  . Évalué à 1.

        Pareil : il faudrait voir l'équivalent en C ou Java ou autre pour comparaison. Pour ma part, je n'ai rien compris à son code.

        « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

        • [^] # Re: Lisibilité et produit de matrices

          Posté par  . Évalué à 2.

          ou en Perl

          no, wait...
        • [^] # Re: Lisibilité et produit de matrices

          Posté par  . Évalué à 4.

          C'est vraiment question d'habitude.

          Il part du principe qu'une matrice, c'est un tableau dont on veut remplir les cases.

          Pour cela, il utilise la fonction
          > let init_matrix f = Array.init n (fun i -> Array.init n (fun j -> f i j));;

          qui prend en paramètre une fonction f à deux arguments et qui construit la matrice
          f(0,0), f(0,1), f(0,2), f(0,3),...
          f(1,0), f(1,1), f(1,2),...
          f(2,0), f(2,1),...
          f(3,0),...

          Une fois qu'on a cette fonction, il suffit de donner en paramètre la fonction qui calcule le coëfficient. Je trouve cette approche très élégante.

          Pour l'addition, c'est la fonction
          > fun i j -> p1.(i).(j) +. p2.(i).(j)
          qui me semble vraiment lisible.

          Pour la multiplication, c'est la fonction
          > fun i j -> sigma 0 (n-1) (fun k -> p1.(i).(k) *. p2.(k).(j))
          Cette fonction est un poil plus compliquée mais pas trop.
          il a d'abord défini la fonction
          sigma i j f ->
          qui calcule f(i)+. ...+.f(j)

          ainsi, sigma 0 (n-1) (fun k -> p1.(i).(k) *. p2.(k).(j))
          calcule p1.(i).(0)*p2.(0).(j)+. ... +. p1.(i).(n-1)*p2.(n-1).(j), ce qui est bien la valeur voulue.

          Pour définir la matrice identité, on utilise
          fun i j -> if i=j then 1. else 0.

          etc...

          Bref, ce n'est pas parce que vous n'avez pas l'habitude de programmer de façon fonctionnelle que son code n'est pas élégant.
          • [^] # Re: Lisibilité et produit de matrices

            Posté par  . Évalué à 2.

            Tout à fait d'accord !

            D'ailleurs, je trouve rigolo de constater que ce qui rend son code beaucoup plus lisible que le mien là haut, c'est qu'il colle plus aux méthodes usuelles en mathématique; par exemple, la fonction sigma qui me paraît au premier abord le mélange obscur d'un init et d'un fold_left, est en fait plus naturelle à utiliser dans ce contexte que les init et les fold_left qui vont bien, parce qu'elle reflète l'écriture mathématique.

            Ma deuxième erreur a été de ne pas extraire le principe du double init : lui donner un nom (ici init_matrix) aide indéniablement à la compréhension.
    • [^] # Re: Lisibilité et produit de matrices

      Posté par  . Évalué à 2.

      > Le compilo caml les a toutes corrigées
      Heu...
      On va dire que j'ai mal compris, là. Tu peux expliciter ? Parce que un compilo qui corrige tout seul des trucs, moi ça a plutôt tendance à me faire peur...
      • [^] # Re: Lisibilité et produit de matrices

        Posté par  . Évalué à 1.

        Je pense que ce qu'il veut dire, et que tout les programmeurs OCaml ont expérimenté, c'est que le typage strict d'OCaml, associé aux avertissements en cas de filtrage non exhaustifs (ou le programmeur n'a pas envisagé tous les cas) permet au compilateur de lever des erreurs su beaucoup plus de cas.

        Donc en fait si ton code compiles, il a beaucoup moins d'erreurs possibles que ton code C qui compile...


        Par ailleurs la programmtion en Caml est souvent plus "sûre" car elle permet de coller de près aux concepts mathématiques. En effet de très nombreux algorithmes sont définis par des récursions, ou par "induction", ce qui se traduit littéralement en Caml...

Suivre le flux des commentaires

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