OCaml 4.00.0 est sorti

Posté par (page perso) . Édité par Lucas Bonnet, Xavier Teyssier, Christophe Guilloux et Bruno Michel. Modéré par Nÿco. Licence CC by-sa
42
11
août
2012
Programmation fonctionnelle

La nouvelle version 4.00.0 du langage OCaml est disponible en ligne depuis le 26 juillet 2012. Aussi, la réunion des développeurs OCaml (OUD'2012) aura lieu cette années à Copenhague le 14 septembre. Venez nombreux !

Parmi les dernières nouveautés disponibles dans cette version 4.00.0 :

  • l'introduction des types de données algébriques généralisés (Generalized Algebraic Data Types - GADTs), qui permettent de détecter encore plus de bugs dès la compilation ;
  • le générateur de code pour ARM a été complètement réécrit ;
  • les types des modules de première classe sont maintenant inférés quand cela est possible, et les modules peuvent eux-mêmes être extraits par filtrage ;
  • le compilateur est disponible sous forme de bibliothèque, et une nouvelle option -bin-annot permet de sauver l'arbre de syntaxe typé, ce qui devrait permettre l'apparition de nouveaux outils de développement plus évolués (refactoring, etc.) ;
  • optimisation des fonctions partielles ;
  • détection de code mort ou inutile (variables, open, champs, constructeurs, labels, etc.) ;
  • émission de directives CFI pour améliorer le debuggage sous GDB.

Pour ceux qui ne connaissent pas, OCaml est un langage à mi-chemin entre C et Python, avec des performances proches de C avec la concision de Python. Mais contrairement à ces deux langages, OCaml appartient à la famille des langages à typage très fort, ce qui permet de détecter la plupart des bugs à la compilation, raccourcissant encore plus le temps de développement ! Rien d'étonnant à ce qu'OCaml ait gagné à plusieurs reprises la ICFP Programming Contest, compétition très sélective de programmation sur trois jours organisée tous les ans.

OCaml permet aussi un mélange des styles impératifs, fonctionnels et objets. Par exemple, une fonction transformant un fichier en une liste de chaînes peut s'écrire :

(* val lines_of_file : string -> string list *)
let lines_of_file filename =
  let ic = open_in filename in
  let lines = ref [] in
  try
    while true do
      lines := (input_line ic) :: !lines
    done;
    assert false
  with End_of_file -> 
    close_in ic; 
    List.rev !lines
On y voit à la fois l'utilisation des exceptions (try...with), une boucle (while...do...done), mais la même fonction aurait pu être écrite sous forme complètement récursive par un partisan de la programmation fonctionnelle !

Pour la prochaine version majeure, l'apparition des namespaces, de foncteurs multi-modules et la possibilité de profiler en utilisant le nouvel outil 'perf' sous Linux, sont sur les bancs, et on entend même parler de support des multicœurs dans les couloirs…

  • # C'est triste ton avis sur Ocaml

    Posté par . Évalué à -9.

    Pour ceux qui ne connaissent pas, OCaml est un langage à mi-chemin entre C et Python, avec des performances proches de C avec la concision de Python.

    Tu veux dire, à mis chemin entre un langage avec un systéme de type pourri et un langage avec un systéme de type pourri et incapable de faire correctement du fonctionnel ?

    • [^] # Re: C'est triste ton avis sur Ocaml

      Posté par . Évalué à -4. Dernière modification le 11/08/12 à 14:52.

      Comme stratégie marketing, on a vu mieux quand même, essayer de pas faire peur aux gens et leur faire croire qu'ils vont se ramener à quelque chose de connu, alors qu'en fait, c'est pas le cas. Je pense qu'on peut se réjouir des efforts faits pour promouvoir Ocaml, comme Ocamlpro, mais de là à tomber dans la démagogie pure, je ne suis pas certain que ça soit une idée lumineuse.

      • [^] # Re: C'est triste ton avis sur Ocaml

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

        Merci pour la publicité pour OCamlPro, c'est toujours bien de mentionner qu'il y a maintenant une entreprise pour aider les utilisateurs industriels d'OCaml ! Heureusement, on est visiblement meilleurs en programmation qu'en communication ! ;-)

    • [^] # Re: C'est triste ton avis sur Ocaml

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

      C'est juste, j'aurais dû dire le "meilleur de C et de Python", i.e. la performance de C et la concision de Python. Merci pour la remarque constructive !

    • [^] # Re: C'est triste ton avis sur Ocaml

      Posté par . Évalué à 6.

      Sans vomir sur le C et le Python, il est vrai que j'ai le plus grand mal à placer OCaml à mi-chemin entre ces deux là tant il me semble dans une direction différente.

      La concision, c'est une propriété résultante d'un tas d'autres trucs. Je ne dirais pas qu'un langage est proche d'un autre en me basant sur la concision.

      Allez, il reste le fait que Python et OCaml proposent tous les deux la programmation orientée objet. Mais demandez donc aux dévs chez JaneStreet ce qu'ils pensent du modèle objet de OCaml (indice: dans une présentation par JaneStreet sur OCaml, le dév souriait en disant "Personne ne l'utilise!").

      Cela dit, OCaml, c'est bon, mangez-en!
      C'est le seul langage dont j'ai lu les débuts de tutoriaux qui m'ait jamais vraiment donné envie de m'y mettre (après avoir regardé du C, C++, Java, Python, Ruby). Pour les non-informaticiens mais avec un parcours plutôt sciences dures, c'est du bonheur: une impression de rigueur mathématique claire que je ne retrouve pas ailleurs!

      • [^] # Re: C'est triste ton avis sur Ocaml

        Posté par . Évalué à 1.

        Pour les non-informaticiens mais avec un parcours plutôt sciences dures, c'est du bonheur: une impression de rigueur mathématique claire que je ne retrouve pas ailleurs!

        En terme de rigueur et d'esprit mathématique, je pense qu'Haskell va bien au-delà d'OCaml. Son insistance sur la notion de "pureté" lui donne un aspect terriblement mathématique. Par contre, sa rigueur est parfois pénible quand on débute, sur du code un peu complexe (E/S, combinaisons de monades, etc).

        • [^] # Re: C'est triste ton avis sur Ocaml

          Posté par (page perso) . Évalué à 3. Dernière modification le 20/08/12 à 12:42.

          En terme de rigueur et d'esprit mathématique, je pense qu'Haskell va bien au-delà d'OCaml.

          Ceux qui veulent vraiment toute la rigueur et l'esprit des mathématiques peuvent sauter la case Haskell, et passer directement à Coq: programmer en Coq, c'est écrire la preuve mathématique que l'algorithme qu'on veut écrire est correct, puis Coq génère automatiquement le code OCaml correspondant. Du coup, c'est des vraies maths, et impossible de laisser un bug trainer dans le code.

          Bien sûr, ça demande un gros effort, et ça ne s'applique donc que dans des domaines où une telle sûreté est nécessaire : le compilateur Compcert a été écrit ainsi pour certains des logiciels embarqués dans les avions.

          Par contre, sa rigueur est parfois pénible quand on débute, sur du code un peu complexe (E/S, combinaisons de monades, etc).

          Le problème d'Haskell, c'est qu'un programme Haskell n'est lisible que de son auteur, et encore, pendant quelques mois. A force d'utiliser des identificateurs à 4 lettres, de la surcharge avec les classes de types et tous les symboles possibles et imaginables, pour pouvoir se vanter de la concision de leurs programmes, les développeurs Haskell rendent simplement leurs programmes immaintenables !

  • # A mi chemin ?

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

    Par exemple, une fonction transformant un fichier en une liste de chaînes peut s'écrire :

    Sinon, pour les gens qui ne sont pas nazi du typage, y a
    def read_file(filename):
    return open(filename).readlines()

    ( Godwin point +=1 )

    • [^] # Re: A mi chemin ?

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

      nazi du typage
      ???

      Pour la publication de Spying the World from your Laptop, nous avons fait de nombreuses analyses sur 500 millions d'adresses IP présentes sur le site PirateBay, les fichiers qu'ils téléchargeaient et leurs sessions sur plusieurs mois. Au début, l'équipe utilisait Python, pour des calculs relativement simples et sur qques millions d'adresses seulement. Finalement, nous avons changé pour OCaml, nous avons pu faire des calculs beaucoup plus complexes, obtenir les résultats beaucoup plus vite (et donc réduire les itérations pour obtenir les résultats intéressants), et sur l'ensemble des 500 millions d'adresses.

      Outre l'intérêt de détecter les bugs avant de lancer les calculs, c'est la concision d'OCaml (écrire en qques lignes un calcul complexe sur le graphe), la compacité mémoire (le graphe complet tenait dans les 16 GB de RAM de ma machine) et les performances qui nous ont fait préférer OCaml à Python pour ces analyses, et pas une "idéologie du typage" comme tu le sous-entends !

      PS: j'utilise File.read_lines pour OCaml, dans ma bibliothèque perso, j'écris rarement cette fonction, sauf pour montrer un exemple…

    • [^] # Re: A mi chemin ?

      Posté par . Évalué à 7.

      Tu as l'air de considérer "Nazi du typage" comme un défaut. Permets moi de te contredire. Dans la plupart des cas, un typage fort apporte beaucoup plus d'avantages que d'inconvénients.

      Le premier avantage d'un bon système de type est la sûreté. Un système de type sûr rejette les programmes absurdes et sémantiquement invalides dont l'évaluation échouairait. Donc, même si on ne peut pas garrantir que le programme termine bien et qu'il fasse ce qu'on veut qu'il fasse (c'est le problème de l'arrêt, indécidable de toute manière), on peut au moins essayer de garratir que le code va s'éxécuter. Ce n'est clairement pas le cas de C, ni de python. En C, les programmes invalides qui segfault compilent souvent trés bien. Je ne dis pas qu'Ocaml ne segfault jamais, mais il faut aller s'amuser avec des fonctions un peu avancés et pousser le systéme de type dans ses retranchements pour y arriver.

      Un autre avantage du typage statique fort, c'est qu'il permet de compiler un code plus efficace. En effet, si on ne connait pas le type des expressions pour une opération polymorphe, on est obligé de savoir traiter tout les cas, même si ce n'est pas forcément nécessaire. Exemple, l'expression + polymorphe qui sait prendre en compte plusieurs types. En Ocaml, les opérateurs ne sont pas polymorphes, ce qui évite d'avoir implictement des comportements auquel le développeur n'a pas pensé, comme ajouter un float et un int.

      Le typage augmente aussi la lisibilité du code. Dans un bon code ocaml, en lisant le nom d'une fonction et sa signature, on a souvent une bonne idée de ce qu'elle fait.

      Maintenant, les inconvénients. Souvent, les gens qui aiment le typage dynamique prennent comme argument qu'il est ennuyeux de déclarer le type des variables/fonctions en permanence. Ocaml n'a pas vraiment se problème, encore une fois grace à son système de type. Le compilateur utilise un algorithme d'inférence des types, qui permet, à partir d'une expression, d'en déduire sont type de manière déterministe. Dans la majorité des cas, (à moins d'utiliser des choses comme les foncteurs, ou les paramètres optionnels), on n'ajoute pas d'annotation de type. C'est le compilateur qui se charge de le faire pour nous, et qui, en prime, vérifie que le code est cohérent. Comme précisé dans la dépêche, Ocaml n'est pas plus verbeux que python.

      Pour finir, je pense qu'il faut considérer le typage comme une énorme aide au développeur plutôt que comme une contrainte.

      • [^] # Re: A mi chemin ?

        Posté par . Évalué à 5.

        En C, les programmes invalides qui segfault compilent souvent trés bien. Je ne dis pas qu'Ocaml ne segfault jamais, mais il faut aller s'amuser avec des fonctions un peu avancés et pousser le systéme de type dans ses retranchements pour y arriver.

        Si ce n'était que ça … J'adorerais n'avoir que des bugs qui provoquent un segfault en C. Le problème d'un langage qui ne propose pas de typage fort est justement qu'à l'exécution, le programme pourrait continuer de tourner et même renvoyer un résultat incorrect, mais « réaliste » dans le contexte de la spécification du programme. La sureté des types permet justement de s'affranchir de ce problème. Après, OCaml propose un typage statique, mais on peut parfaitement proposer une sureté qui s'effectue dynamiquement (par exemple, Java propose un typage fort pour les types non-primitifs, mais une grande partie des problèmes de types n'est détectée qu'à l'exécution).

        • [^] # Re: A mi chemin ?

          Posté par . Évalué à 2.

          Le problème d'un langage qui ne propose pas de typage fort est justement qu'à l'exécution, le programme pourrait continuer de tourner et même renvoyer un résultat incorrect

          Le typage ne résout pas vraiment ce problème… Il te faut un assistant de preuve et un compilateur prouvé si tu veux éviter ça. Le fait qu'ocaml n'ait pas de pointeurs ni de gestion mémoire manuelle évite en effet certains problèmes, le typage en évite quelques autres en évitant les cast implicites, mais bon, compiler en -Wall -Werror peut aider en C.

          Le typage n'est pas non plus magique.

          • [^] # Re: A mi chemin ?

            Posté par . Évalué à 3.

            Je parle bien entendu dans le contexte des interactions entre types. Les langages fortement typés empêchent justement de se retrouver bloqué à l’exécution pour des raisons de "mauvaises interactions" entre variables de types différents. Le C ne permet pas d’éviter ce genre d'erreur. OCaml, Java (pour les types non-primitifs), C++ (si si) proposent un typage fort, bien plus que le C. La vérification des types peut se faire statiquement ou dynamiquement, ça ne l’empêche pas d’être forte.

            Et si, je maintiens, les erreurs liées aux types peuvent donner des résultats incorrects dans les langages faiblement typée tels que le C, qui sont parfois difficiles à comprendre ou même détecter. Le fait que le typages de OCaml soit statique est bien pratique pour détecter ce genre de problème a la compil', mais en Java on les détecterait à l’exécution avec une jolie exception.

            • [^] # Re: A mi chemin ?

              Posté par . Évalué à 4.

              Pour être complet, on peut dire que l'on peut utiliser le typage un peu plus fortement que d'habitude pour interdire certaine forme de données qui sont en fait des bugs.

              Par exemple, en C, on aura tendance à retourner un nombre positif en cas normal et -1 en cas d'erreur, en ocaml, on utilise le type "a' option".

              On peut utiliser les type phantom pour typer différente type de string (raw, utf-8 ou binaire vs hexadécimal), ce qui est impossible en C.

              Je suis sûr qu'il y a plein d'autres exemples.

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

    • [^] # Re: A mi chemin ?

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

      Je préfère les nazis du typage aux nazis de l'indentation :

      >>> def read_file(filename):
      ... return open(filename).readlines()
        File "<stdin>", line 2
          return open(filename).readlines()
               ^
      IndentationError: expected an indented block
      
      

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: A mi chemin ?

        Posté par . Évalué à 2.

        Haha c'est drôle que tu dise ça parce qu'Haskell est encore pire au niveau de l'indentation. Des erreurs d’indentation provoquent des bugs stupide. Mais heureusement il est possible d'utiliser les accolades et les virgules pour contourner ce problème.

        Please do not feed the trolls

        • [^] # Re: A mi chemin ?

          Posté par . Évalué à -1.

          Au passage tu as lu le titre de la dépêche ? Ocaml a pas mal de différences avec Haskell. Déjà il n'est pas fonctionnel pur.

          • [^] # Re: A mi chemin ?

            Posté par . Évalué à 0.

            Krunch n'a pas droit à la même remarque désobligeante et à coté de la plaque ? Mon commentaire n'avait pas grand chose à voir avec le sujet. En revanche vu qu'il était question de nazis du typage ET de nazis de l'indentation, Haskell est LA référence. Ensuite, Haskell ressemble énormément à ML, infiniment plus qu'Ocaml à python ou C.

            C'est la mauvaise période du mois ?

            Please do not feed the trolls

  • # Version fonctionnelle

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

    Voilà une proposition pour une version fonctionnelle (sans gestion des erreurs).

    let maybe_input_line ic =
      try Some(input_line ic)
      with End_of_file -> None
    
    let process_file f filename =
      let ic = open_in filename in
      let answer  = f ic in
        close_in ic;
        answer
    
    let lines_of_file filename =
      let rec loop a ic =
        match maybe_input_line ic with
        | Some s -> loop (s :: a) ic
        | None -> a
      in
      process_file (loop []) filename
    
    

    Je suis hyper heureux de la sortie de OCaml 4, préparez-vous à le voir arriver sous FreeBSD!

    • [^] # Re: Version fonctionnelle

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

      Il ne manquerait pas une petite inversion de la liste à la fin :

      let lines_of_file filename =
        let rec loop lines ic =
          match maybe_input_line ic with
          | Some line -> loop (line :: lines) ic
          | None -> close_in ic; List.rev lines
        in
        let ic = open_in filename in
        loop [] ic
      
      
    • [^] # Re: Version fonctionnelle

      Posté par . Évalué à 1.

      J'ai toujours du mal avec les langages qui préfèrent les math aux utilisateurs, je m'explique: pour moi une fonction a des entrées et des sorties mais sous prétexte qu'il y a la curryfication, au lieu d'avoir des fonction avec plusieurs entrées et plusieurs sorties, on a: fonction: entree1 -> entree2 -> … sortie1 -> sortie2 (1)
      Beurk, ce n'est pas parce que la curryfication existe qu'il faut la montrer systématiquement!

      1: par exemple si on tape le programme du dessus dans l'interpréteur OCaml on a en sortie:
      val process_file : (in_channel -> 'a) -> string -> 'a = < fun >
      mais la fonction dans le code du programme avait des entrées et des sorties, pourquoi l'interpréteur n'affiche pas:
      val process_file : ((in_channel -> 'a), string) -> ('a = < fun >)
      ça serait beaucoup plus fidèle au code..

      • [^] # Re: Version fonctionnelle

        Posté par . Évalué à 1.

        J'ai l'impression que tu ne sais pas de quoi tu parle.

        • [^] # Re: Version fonctionnelle

          Posté par . Évalué à 1.

          C'est possible, mais il faudrait que tu m'explique en quoi je ne sais pas de quoi je parle!
          Quand je définis une fonction f(x:int, y:int)->int et que l'interpréteur affiche
          f: x:int -> y:int -> int (pas la vrai syntaxe d'OCaml) donc comme une fonction de fonction qui retourne un résultat alors qu'on lui a donné une fonction qui prend 2 valeurs et retourne un résultat.
          Certes mathématiquement c'est la même chose, mais visuellement je trouve le choix d'OCaml (et d'Haskell) moins lisible..

          • [^] # Re: Version fonctionnelle

            Posté par . Évalué à 1.

            La currification c'est juste le fait de découper l'application d'une fonction en plusieurs fois.
            En C par exemple tu pourrais faire:

            int f(int x, int y)
            {
                return x + y;
            }
            
            int f1(int y)
            {
                return f(4, y);
            }
            
            f1(1);
            
            

            au lieux de:

            let f x y = x + y
            (* ou encore: *)
            let f = (+)
            let f1 = f 4
            
            f1 1
            
            

            Donc tu va récupérer le résultat de la fonction (ici 5) dans les deux cas en applicant y à la fonction f1.
            Sauf que un cas est plus simple que l'autre.

            Je ne vois pas il y aurait plusieurs sorties ou en quoi ça serais moins lisible ?

            • [^] # Re: Version fonctionnelle

              Posté par . Évalué à 1.

              Effectivement je m'était trompé sur le cas avec plusieurs sorties, il faut utiliser un tuple de données donc tu as:
              entree1 -> … -> entreeN -> (sortie1, sortie2, …, sortieM)
              mais ce que j'aimerais avoir moi c'est:
              (entree1, … , entreeN) -> (sortie1, sortie2, …, sortieM)
              ça rend l'affichage du type des entrées et des sorties identiques.

              • [^] # Re: Version fonctionnelle

                Posté par . Évalué à 1.

                Je crois que tu n'as toujours pas saisie.
                Pourquoi t'obstine-tu à vouloir des tuples ?
                Que veux-tu dire par « l'affichage du type des entrées et des sorties identiques » ?

                • [^] # Re: Version fonctionnelle

                  Posté par . Évalué à -2.

                  Parce que normalement on a des fonctions a plusieurs entrées, quand je dit la fonction qui calcule l'aire d'un triangle, elle a pour paramètre la longueur et la hauteur donc si tu affiches
                  long -> haut -> résultat, ça ne correspond pas a ma vision normale d'une fonction a entrées multiple, un tuple de variable (j'ai bien compris que c'est possible en Ocaml, j'ai juste été surpris que ça ne soit pas la coutume).

                  Et en Ocaml, si tu veux avoir plusieurs sorties, tu es obligé d'utiliser un tuple pour les sorties, je trouve qu'il y a une certaine asymétrie mais bon c'est débatable.

      • [^] # Re: Version fonctionnelle

        Posté par (page perso) . Évalué à 5. Dernière modification le 17/08/12 à 19:17.

        Il y a grosso-modo deux raisons: la première, c'est qu'il est possible en OCaml de faire une fonction qui prend un n-uplet d'argument, comme en C, et de tout programmer comme cela:

        (* val process_file : (in_channel -> 'a) * string -> 'a  *)
        let process_file (f, filename) =
          let ic = open_in filename in
          let answer  = f ic in
            close_in ic;
            answer
        
        

        Tu peux généraliser la fonction précédente au nombre d'arguments que tu veux. Le compilateur natif d'OCaml est d'ailleurs assez intelligent pour compiler de la même façon un appel f x y et un appel f (x,y) au niveau du code assembleur, c'est donc uniquement un choix du programmeur.

        La seconde raison, c'est effectivement qu'il est parfois très pratique d'écrire des fonctions auxquelles on ne fournit pas tous les arguments: par exemple, si je définis une fonction println : out_channel -> string -> unit, je peux la faire itérer sur un répertoire pour afficher tous ses éléments de la façon suivante, puis définir des fonctions spécialisées pour stderr et stdout:

        let println oc filename = output_string oc filename; output_char oc '\n'
        let print_dir oc dirname = 
           Array.iter (println oc) (Sys.readdir dirname); 
           flush oc
        let print_dir_err = print_dir stderr
        let print_dir_out = print_dir stdout
        let _ = print_dir_err "/home"
        
        

        Le même programme à la C:

        let println (oc, filename) = output_string oc filename; output_char oc '\n'
        let print_dir (oc, dirname) = 
           Array.iter (fun filename -> println (oc, filename) ) (Sys.readdir dirname); 
           flush stderr
        let print_dir_err filename = print_dir (stderr, filename)
        let print_dir_out filename = print_dir (stdout, filename)
        
        let _ = print_dir_err "/home"
        
        

        Personnellement, je trouve la version avec l'application partielle beaucoup moins verbeuse, mais les deux sont aussi efficaces l'une que l'autre…

      • [^] # Re: Version fonctionnelle

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

        val process_file : ((in_channel -> 'a), string) -> ('a = < fun >)
        ça serait beaucoup plus fidèle au code..

        L'interpréteur fait ce qu'on lui demande. Si tu veux définir une fonction dont la signature est

        val process_file : ((in_channel -> 'a), string) -> ('a = < fun >)
        
        

        c'est possible, il suffit de changer la déclaration

        let process_file (f, filename) =
          let ic = open_in filename in
          let answer  = f ic in
            close_in ic;
            answer
        
        

        comme te l'a déjà fait remarquer Fabrice. Bien que ces deux définitions soient très semblables, il existe une différence dont les conséquences pratiques sont très importantes: il est beaucoup plus facile d'appliquer partiellement la première version que la seconde.

        Ainsi, si tu as un traitement f: in_channel -> 'a que tu veux appliquer sur une liste de fichiers l tu peux écrire

        List.map (process_file f) l
        
        

        avec la première version, tandis que la seconde t'oblige à introduire une fonction auxiliaire (on peut choisir une fonction anonyme) ce qui rend le code moins lisible.

        Depuis que je travaille dans une boîte qui utilise C++ je suis très malheureux car:
        — je redécouvre les charmes des boucles for;
        — personne ne sait programmer.

  • # Librairie graphique sous ocaml

    Posté par . Évalué à 4.

    Je profite de cette nouvelle, pour demander quelles sont les librairies graphiques utilisables avec ocaml notamment pour le dev d'interface graphique.

    Il y'a bien Tcl/Tk, mais je n'ai pas l'impression qu'elle est beaucoup employée.

    Il y'a également GTK visiblement, mais je n'ai pas vu beaucoup d'applications écrites en ocaml/GTK et il me semble que les dernières version de GTK ne sont plus supportées.

    Je ne sais pas non plus si ce qu'offre GTK/ocaml est comparable à ce qu'offre Swing/java par exemple.

    Si vous avez des retours d'expériences, ou connaissez un peu le sujet n'hésitez pas.

    • [^] # Re: Librairie graphique sous ocaml

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

      Il y'a également GTK visiblement, mais je n'ai pas vu beaucoup d'applications écrites en ocaml/GTK et il me semble que les dernières version de GTK ne sont plus supportées.

      Les dernières versions de GTK ne sont effectivement pas supportées, mais le binding disponible est écrit à la main, d'où une interface très OCaml bien plus agréable à utiliser que l'interface C que j'ai longtemps pratiquée.

  • # types de données algébriques généralisés ?

    Posté par . Évalué à 4.

    Quelqu'un aurait un exemple ? La page wikipedia est incompréhensible.

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

  • # Un petit merci

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

    J'en profite pour remercier le CAML et l'OCAML qui m'ont décidé a arrêté ma licence à Jussieu pour faire une école d'ingénieur.

    13 ans plus tard je ne regrette toujours pas ce choix. Vraiment Merci.

    • [^] # Re: Un petit merci

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

      Tu as préféré payer que réfléchir.

      À réfléchir.

      ;)

      La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

    • [^] # Re: Un petit merci

      Posté par . Évalué à 4.

      Et c'est pour ça que tu es devenu un troll lourdaud alors que tu aurais pu apprendre les nuances de ce que tu critiques pour le troller dans les règles de l'art.

      Think about that.

    • [^] # Re: Un petit merci

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

      Maintenant c'est le Scheme et le C qui sont enseignés en première année (j'encadre des TD et TP à Jussieu).

      • [^] # Re: Un petit merci

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

        Je pense que c'est une bonne chose. Heureusement on apprenait aussi le C, le Pascal, un dérivé de Prolog dont je ne me rappelle plus le nom et plein d'autre choses.

        Oui mon troll est gros, mais je ne dis surtout pas que la FAC, et Jussieu en particulier sont nuls, loin de là. Mais pour avoir essayé de faire un simple tetris avec des textures en CAML, je pense qu'à l'époque ce langage était un langage d'étude uniquement sans trop d'application derrière.

  • # Pour tester ocaml

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

    Je trouve que cette application web de découverte de Ocaml particulièrement sympa et accessible pour découvrir le langage:
    http://try.ocamlpro.com/

  • # Ça a l'air balèze en tout cas

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

    Rien d'étonnant à ce qu'OCaml ait gagné à plusieurs reprises la ICFP Programming Contest,

    C'est amusant comme formulation, ça donne l'impression que OCaml est venu sur ses petites jambes et a codé tout seul pour gagner.

    Plus sérieusement, cela démontre t-il la supériorité du codeur ou du langage, là est la question.

    • [^] # Re: Ça a l'air balèze en tout cas

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

      Voilà un extrait du règlement:

      In addition, the organisers will declare during the conference that:
      
      the first place team’s language is “the programming language of choice for discriminating hackers”,
      
      the second place team’s language is “a fine tool for many applications”,
      
      the winning lightning division team’s language is “very suitable for rapid prototyping”, and
      
      the team winning the judges’ prize is “an extremely cool bunch of hackers”. 
      
      

      De façon très explicite, ce sont les langages qui sont mis en avant par l'épreuve.

      (Le principe est que tous les participants humains sont infiniment doués en programmation et ne sont limités que par leur outil. :)

      • [^] # Re: Ça a l'air balèze en tout cas

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

        Plus sérieusement, cela démontre t-il la supériorité du codeur ou du langage, là est la question.

        Oui, on peut toujours dire que c'est les développeurs qui font la différence. Donc la conclusion est : les meilleurs développeurs codent souvent en OCaml… :-)

        C'est ce que m'avait répondu l'un des développeurs de Xen-api: vers 2004, après avoir développé Xen, la jeune société XenSource avait embauché une trentaine de développeurs (Ruby,C,Python,etc.) pour développer la couche de communication pilotant les hyperviseurs Xen (15% du Cloud, vous connaissez Amazon EC2 ?). Deux ans plus tard, toujours pas de produit, quand ils recrutent 4 développeurs à Cambridge, qui devaient écrire la doc, mais comme le produit n'arrivait pas, ils se sont dit qu'ils pourraient écrire un petit proto de leur coté… en OCaml. Un an plus tard, XenSource sort son produit, c'est le proto OCaml qui est dedans (et y est toujours !), et ils sont rachetés par Citrix pour qques centaines de millions de dollars…

        • [^] # Re: Ça a l'air balèze en tout cas

          Posté par . Évalué à 2.

          D'ailleurs cette année, la seule équipe qui, au second round, est encore dans les 5 premiers du classement à 24h et 72h, code en OCaml ( et pour certains, moulent par ici … ).

        • [^] # Re: Ça a l'air balèze en tout cas

          Posté par . Évalué à 2.

          Donc la conclusion est : les meilleurs développeurs codent souvent en OCaml… :-)

          Ou plutôt : les meilleurs développeurs qui participent à la compétition ICFP codent en OCaml.
          Vu que ICFP veut dire (d'après son site Web) International Conference on Functional Programming, l'échantillon doit être assez biaisé.

          • [^] # Re: Ça a l'air balèze en tout cas

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

            Ou plutôt : les meilleurs développeurs qui participent à la compétition ICFP codent en OCaml.
            Vu que ICFP veut dire (d'après son site Web) International Conference on Functional Programming,
            l'échantillon doit être assez biaisé.

            Il suffit de regarder les équipes participantes des concours des années précédentes pour se rendre compte que cette compétition a largement dépassé le cercle de la conférence pour toucher tous les bons développeurs du monde entier, et tous les langages sont largement représentés.

            Cela dit, c'est facile de tester: participez l'année prochaine, et vous verrez où vous vous classez !

            • [^] # Re: Ça a l'air balèze en tout cas

              Posté par . Évalué à 0.

              Il suffit de regarder

              Mmmh, c'est scientifique, ça.

              pour toucher tous les bons développeurs du monde entier

              Ah, « tous » ? vraiment ?

              participez l'année prochaine, et vous verrez où vous vous classez !

              J'en ai un peu rien à battre, à vrai dire :)
              (et les bons développeurs de ma connaissance non plus, je crois)

              • [^] # Re: Ça a l'air balèze en tout cas

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

                Il suffit de regarder

                Mmmh, c'est scientifique, ça.

                Oui, merci d'insister sur ce point, c'est ce que font les scientifiques, ils vérifient les faits, et pour cela, ils font des expériences, ou examinent des événements du passé s'ils ne peuvent pas les tester facilement. Donc, oui, un scientifique irait examiner les équipes des concours précédents, pour déterminer combien de programmeurs ont participé, d'où ils vennaient, et quels langages ils représentaient.

                participez l'année prochaine, et vous verrez où vous vous classez !

                J'en ai un peu rien à battre, à vrai dire :)

                Ben alors, pourquoi tu réponds ???

                • [^] # Re: Ça a l'air balèze en tout cas

                  Posté par . Évalué à 1.

                  Donc, oui, un scientifique irait examiner les équipes des concours précédents, pour déterminer combien de programmeurs ont participé, d'où ils vennaient, et quels langages ils représentaient.

                  Et l'échantillon est constitué / sélectionné comment ? Sérieusement, si c'est juste sur la base du volontariat, les résultats n'ont aucune valeur statistique.

                  Ben alors, pourquoi tu réponds ???

                  Parce que l'argument insinuant qu'OCaml est meilleur sous prétexte que des développeurs OCaml gagnent régulièrement dans un concours de programmation donné n'a aucune valeur si l'échantillon n'est pas rigoureusement constitué.

                  (il y a un autre problème à examiner, à savoir les règles pour gagner le concours et leur pertinence en fonction de la question posée ; mais bon, tant que l'échantillon n'a pas l'air rigoureux, inutile d'aller plus loin)

                  Note que des études sérieuses ont été faites concernant la productivité de différents langages de programmation. Je n'ai pas les références, et je ne sais pas si OCaml était inclus, mais ça doit se retrouver.

Suivre le flux des commentaires

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