Journal Quelques projets intéressants en OCaml

Posté par (page perso) . Licence CC by-sa
32
28
fév.
2013

Ocaml est souvent enseigné aux étudiant par un prof chiant qui nous impose une soupe théorique qu'on est pas forcément prêt à avaler (plus tard, on comprend son intérêt, mais plus tard).
C'est pourtant un langage puissant et généraliste, tout à fait adapté à faire des logiciels de la vraie vie. Et non, il n'y a pas que ML Donkey.

Je recense donc dans ce journal bookmark quelques projets sympa en OCaml, très divers, mais utiles.
Je précise que je n'ai jamais pratiqué la plupart de ces librairies.

Ocsiblog

Une plateforme de blog pour Ocsigen
https://github.com/mfp/ocsiblog

Caml-Shcaml

Une librairie pour manipuler facilement et puissamment les entrées-sorties du shell
https://github.com/tov/shcaml
Quelques exemples d'utilisation http://www.eecs.harvard.edu/~tov/code/shcaml/doc/

Archimedes

Une sorte de clone de gnuplot, utilisable sous forme de librairie.
Plein de fonctionnalité (type de traits, épaisseur, camemberts, etc…)
http://archimedes.forge.ocamlcore.org/

Gapi-ocaml

Une librairie client des Google-API
Permet de manipuler l'agenda google ou encore Google Analytics
https://github.com/astrada/gapi-ocaml/blob/master/examples/calendar/samples.ml
https://github.com/astrada/gapi-ocaml

OCaml-RDF

Une librairie pour manipuler les graphes RDF.
Permet l'export/import vers RDF/XML, ainsi que le stockage en base (PostgreSQL ou MySQL) ou en mémoire. Offre un mécanisme de transaction.
http://ocaml-rdf.forge.ocamlcore.org/

Weberizer

Un petit outil de templating html
https://github.com/Chris00/weberizer

Ocamldap

Bindings LDAP pour ocaml. https://gitorious.org/ocamldap/

OcamlJava

OcamlJava est un backend pour le compilateur binaire de Ocaml produisant du code JVM.
Propose aussi une suite d'outil pour interfacer facilement son code avec des librairies existantes en Java ou Scala.
Facilité par le fait que Ocaml est aussi un langage objet à classe.
http://ocamljava.x9c.fr/

OcamlLLVM

Un back-enddu compilateur ocamlopt (compilateur binaire) permettant de générer du code LLVM

https://github.com/colinbenner/ocamlllvm

WebSocket Server

Un serveur WebSocket https://github.com/mzp/websocket-ocaml

Ocaml-redis

Un client Redis

https://github.com/rgeoghegan/ocaml-redis

Ocaml-appengine

Une librairie pour faire tourner des application OCaml dans le Google Appengine https://github.com/avsm/ocaml-appengine
Utilise OcamlJava.

Camlimages

Une bibliothèque de traitement d'image gérant de multiples formats.
Propose aussi une interface vers Freetype pour écrire du texte sur des images.

http://cristal.inria.fr/camlimages/eng.html

Mikmatch

Une petite extention de syntaxe OCaml (avec CamlP4) permettant de faire du pattern matching avec des expressions régulières https://github.com/mjambon/mikmatch
Exemple :

(* Teste si la chaine commence par hello et renvoi le participant, None sinon *)
let msg = "Hello you" in
match msg with
    RE ["Hh"]"ello" space+ (alpha+ as name) -> Some name
  | _ -> None;;

Ocaml-spdy

Implémentation du protocole SPDY

https://github.com/djs55/ocaml-spdy

Ocaml-cstruct

Une extension de syntaxe et une librairie pour gérer de façon transparentes les bindings vers des librairies C.
Encore une librairie produite par le très prolifique Anil Madhavapeddy
https://github.com/avsm/ocaml-cstruct

Ocaml-ssh

Bibliothèque SSHv2 , client et serveur
https://github.com/avsm/ocaml-ssh

Memories

Un Filtre_de_Bloom
https://github.com/mjambon/memories

Froc

Une bibliothèque de programmation fonctionnelle réactive
Une description de ce paradigme ici http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming et ici http://en.wikipedia.org/wiki/Functional_reactive_programming
https://github.com/jaked/froc

Bitcask

Une petite librairie utilisant Redis et proposant une hashtable persistante. Le principe est de stocker les clé en mémoire et la valeur en base. Offre des
performances intéressantes
http://bitcask.forge.ocamlcore.org/

OPath

Moteur de rendu 3D basé sur un rendu "physique" des objets. Propose différents algorithmes des rendus ( distribution ray tracing, path tracing and 'Instant Global Illumination')
http://opath.sourceforge.net/index.html

  • # .

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

    un langage puissant et généraliste, tout à fait adapté à faire des logiciels de la vraie vie. Et non, il n'y a pas que ML Donkey.

    Il y a quand même un paquet de bibliothèques, bindings… dans la liste, et peu d'applis pour utilisateur final.

    • [^] # Re: .

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

      J'ai l'impression que les utilisateurs de OCaml codent vite fait un outil dont ils ont besoin et le laissent dans un coin, en laissant la lib qu'ils ont codé en libre.
      C'est aussi lié à la nature du langage : tu sais très vite quand ton logiciel est stable car le compilateur refuse de compiler sinon. Dès que ça compile et que ça marche, tu la laisses dans un coin.
      Par exemple, une fois j'ai codé ça en 2h, et j'y ais plus trop touché : https://github.com/ontologiae/ArteVOD

      Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

      • [^] # Re: .

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

        Que le langage soit super, soit. Que tu sois très fan, pas de problème, on est sur un site de passionnés après tout.

        Mais expliquer le peu d'applications finales par les qualités du langage, ça fait un peu fanboy quand même.

        • [^] # Re: .

          Posté par . Évalué à  3 .

          C'est aussi que le langage est surtout utilisé dans la recherche, où on code un prototype ou un proof-of-concept, mais pas trop d'applications orientées "utilisateur". On trouve quand même un nombre non négligeable de softs pour l'industrie ou la recherche en OCaml (sur opam, par exemple, il doit y avoir facilement 3 prouveurs automatiques et 2 plateformes de preuve).

          The cake is a lie.

        • [^] # Re: .

          Posté par . Évalué à  -6 .

          Je dirais qu'il y a 2 types de langages :

          1. Ceux qu'on utilise parce qu'ils répondent bien à un besoin (C, python, Java, C#)
          2. Les jouets avec lesquels on se force à faire des applications pour montrer que ça sert (OCalm, Haskell, Scheme…)
          • [^] # Re: .

            Posté par . Évalué à  0 .

            Les jouets avec lesquels on se force à faire des applications pour montrer que ça sert (OCalm, Haskell, Scheme…)

            Tu veux dire, ceux qui permette de développer en quelques heures un outil vite fait un peu baclé pour combler un petit besoin tout en s'épargnant le temps de stabilisation ?

          • [^] # Re: .

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

            Les jouets avec lesquels on se force à faire des applications pour montrer que ça sert (OCalm, Haskell, Scheme…)

            Etant donné qu'OCaml sert par exemple à écrire des "prouveurs" (je connais pas le terme exact) de programmes aéronautiques embarqués dans les fusées, je voudrais bien voir sur quel genre de trucs sérieux tu bosses.

          • [^] # Re: .

            Posté par . Évalué à  4 .

            On ne peut pas vraiment torcher un code en ocaml, mais la différence entre un code qui tourne et un produit est faible, contrairement au C par exemple.

            Ma boite l'utilise pour ses générateurs de code qualifié/certifié futur DO330/D0178b/EN50128/IEC1508.

            kcg

            Par rapport à un compilo en C, tu divises la taille du code par 3 (pas de gestion de mémoire).

            "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

        • [^] # Re: .

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

          Effectivement, il y a plusieurs raisons de l'insuccès du langage :

          • Trop complexe à maitriser, minimum de maitrise mathématique requis trop élevé
          • Ne satisfait pas les SSII, car trop bonne productivité (Le business model d'une SSII, c'est de vendre des jour.homme et des bugs, pas des bon logiciels)
          • Coût à l'exécution difficile à prévoir
          • Système de compilation avec tous les problèmes qu'on a en C (makefile etc…). Il y a ocamlfind/ocamlbuild, mais c'est pas génial. Absence de NameSpace. On vient enfin d'avoir un vrai système de paquet (OPAM)… en 2013
          • C'est pas un langage à l'aise pour faire des interfaces, et il n'y a pas de lib sympa pour ça
          • Niveau de la ML très haut et très orienté "système de type ultra compliqué", ce qui fait que les programmeurs normaux se sentent tout de suite largués et ont aussi l'impression de se sentir comme des m**** face à une armée de normaliens et de polytechniciens (le langage a été fait par un normalien).
          • Paradigme fonctionnel, pas enseigné de base et difficile à appréhender : on peut construire un algo impératif pas à pas, par essai erreur. En fonctionnel il faut comprendre le truc après s'être torturé les méninges : beaucoup de gens n'aiment pas concevoir leur algo sur papier, OCaml t'y oblige, souvent.

          Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

          • [^] # Re: .

            Posté par . Évalué à  6 .

            Je rajouterais aussi que le compilateur n'est pas gentil avec le débutant quand tu ne compiles pas souvent : l'erreur peut être renvoyé loin de son origine et des messages sibyllin comme 'le type toto n'est pas compatible avec le type toto' sont toujours surprenant (en cas de redéfinition du type en court de route, mais la ligne de la définition du type n'est pas donné). Je crois que ocaml 4.0 est meilleur sur ce terrain.

            La syntaxe est ultra compacte, c'est vexant de bloquer sur l'écriture d'une vingtaine de lignes de code. Mais ses lignes en représenteraient des centaines dans un autre langage (pattern matching sur un arbre, pour en créer un autre par exemple). C'est une question d'habitude.

            Sinon, les type sommes et les match c'est simplement génial.

            "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

          • [^] # Re: .

            Posté par . Évalué à  3 .

            Je tiens à préciser que je ne fait pas de ocaml, histoire que vous puissiez prendre mes propos avec la plus grande condésendance.

            Ne satisfait pas les SSII, car trop bonne productivité (Le business model d'une SSII, c'est de vendre des jour.homme et des bugs, pas des bon logiciels)

            On veux des noms!

            Coût à l'exécution difficile à prévoir

            Un exemple s'il vous plait monsieur?

            Niveau de la ML très haut et très orienté "système de type ultra compliqué", ce qui fait que les programmeurs normaux se sentent tout de suite largués et ont aussi l'impression de se sentir comme des m**** face à une armée de normaliens et de polytechniciens (le langage a été fait par un normalien).

            Tu as du en chier à polytechnique ou normal (ou sup…), ça ta laissé amer on dirait.

            Paradigme fonctionnel, pas enseigné de base

            La recursion est enseigné de base.

            On peut construire un algo impératif pas à pas, par essai erreur. En fonctionnel il faut comprendre le truc après s'être torturé les méninges : beaucoup de gens n'aiment pas concevoir leur algo sur papier, OCaml t'y oblige, souvent.

            Tant que du as des fonctions dans ton langage alors tu peux construire ton algo pas à pas.
            Que tu fasse du fonctionnel ou de l'impératif du doit comprendre le truc sinon ça ne marchera pas.
            Tout le monde utilise le papier et crayon au bout d'un moment c'est juste plus pratique pour dessiner des graphes.

            • [^] # Re: .

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

              Ne satisfait pas les SSII, car trop bonne productivité (Le business model d'une SSII, c'est de vendre des jour.homme et des bugs, pas des bon logiciels)

              On veux des noms!

              Bah, toutes, c'est une question de modèle économique : aucun intérêt à faire des logiciels qui marchent. C'est un peu comme le syndicaliste de Coluche : s'il fait trop grève il est pas payé, s'il fait pas assez grève, ça va finir par se voir. En gros, un logiciel bugué mais pas trop, afin de vendre de la tierce maintenance applicative et de ne pas se faire griller par un concurrent qui proposerait une qualité légèrement moins merdique

              Coût à l'exécution difficile à prévoir

              Un exemple s'il vous plait monsieur?

              J'en ai pas, mais prend un algo en O(n2 ) qui manipule pas mal de données (quelques centaines de Mo), tu risques d'avoir des surprises avec le GC déjà.
              Ensuite, c'est bateau, mais quand je code enC, je vois assez précisément ce que ça va donner en asm. En Ocaml, avec des systèmes de types hachement compliqués tu as un peu de mal à savoir ce qui va se faire en asm.

              Tu as du en chier à polytechnique ou normal (ou sup…), ça ta laissé amer on dirait.

              Au contraire, je suis un cancre patenté, j'ai un cerveau gauche sous performant par rapport au droit, ainsi que me le font remarquer d'une autre façon pas mal de mes contradicteurs ici même.

              Tant que du as des fonctions dans ton langage alors tu peux construire ton algo pas à pas.
              Que tu fasse du fonctionnel ou de l'impératif du doit comprendre le truc sinon ça ne marchera pas.
              Tout le monde utilise le papier et crayon au bout d'un moment c'est juste plus pratique pour dessiner des graphes.

              J'ai souvent écris des algos qui marche sans comprendre pourquoi, c'est d'ailleurs ma manière de faire. Je suis un mauvais codeur, mais je passe pour un bon, parce que j'ai 20 ans de code et du nez (cerveau droit).
              A regarder pas mal de gens, beaucoup font un mix entre "je comprend à peu près" et "essai erreur"

              Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

              • [^] # Re: .

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

                Ensuite, c'est bateau, mais quand je code en C, je vois assez précisément ce que ça va donner en asm. En Ocaml, avec des systèmes de types hachement compliqués tu as un peu de mal à savoir ce qui va se faire en asm.

                Hmmhmm, j'ai envie de dire (enfin sur le type) que c'est même l'inverse. En C, justement on voit poper des casts implicites un peu partout et tu perds de l'intégrité de la donnée en assembleur. Le système de type d'OCaml permet justement à ce qu'en asm, on face bien une addition entre 2 entiers. L'assembleur de nos processeurs ne propose pas de type, de ce faite, il faut s'en abstraire pendant la compilation. Un des moyens (le C) est de caster implicitements vers le type qu'on veut pour qu'on puisse faire une addition entre un (char *) et un (int). En OCaml, on interdit cela.

                Par contre, il est vrai qu'il n'est pas aisé de voir comment OCaml compile les fonctions vers l'assembleur (environnement initial, lambda-lifting …) mais en somme, les opérations de base (qu'on retrouve en C) sont facilement localisables.

                • [^] # Re: .

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

                  En ce qui concerne les nombres, Ocaml les box la plupart du temps, bien que l'unboxing ait fait du progrès. A partir de là, c'est pas évident d'imaginer ce que ça donne en asm…

                  Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

                  • [^] # Re: .

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

                    OCaml se débrouille tout de même pour l'unboxing (contrairement à Haskell) mais je pense réellement que le système de type de l'OCaml ne soit pas un problème dans la génération de l'asm. Au contraire, je pense que ça l'aide.

      • [^] # Re: .

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

        Par exemple, une fois j'ai codé ça en 2h, et j'y ais plus trop touché : https://github.com/ontologiae/ArteVOD

        Si c'est juste pour télécharger la VOD d'Arte, tu aurais aussi bien pu utiliser weboob ;-)

    • [^] # Re: .

      Posté par . Évalué à  9 .

      Ça dépend de quel utilisateur final tu parles. Si tu parles de Mme Michu qui écoute de la musique sur son ubuntu, c'est vrai qu'il n'y a pas grand chose pour elle. Écrire des applications de bureau en ocaml n'est pas forcément aussi facile que de le faire en python. Déjà parce qu'il n'y a à ma connaissance que des bindings GTK2 (j'ai vu passé des bindings EFLs aujourd'hui, mais je ne sais pas ce que ça vaut), mais aussi parce qu'on aura besoin de libs comme GSTreamer pour le son, par exemple, ou autres choses, et qu'il s'agit d'un cercle vicieux : moins il y a de libs/bindings, moins le langage est utilisé pour ce domaine, et moins il est utilisé, moins il y a de lib.

      Mais, il y a toutefois beaucoup d'applications pour l'utilisateur final, dans des domaines plus techniues. Par exemple, la preuve automatique, ou l'assistance à la preuve (caml a était initialement inventé pour ça) :

      l'analyse statique de code :

      la compilation,

      Je passe sur beaucoups de logiciels, en ne citant que les "gros" projets.

      Dans un domaine moins technique, on peut aussi citer la suite d'outisl ocsigen qui permet d'écrire des applications web riches client/serveur. C'est un excellent outil, ou non seulement la partie serveur est écrite en ocaml, mais aussi la partie client. On peut coder une application d'une seule pièce, puis un compilateur transforme le code ocaml client vers du javascript, et se charge de gérer les transferts de donnée.

  • # Froc (Une bibliothèque de programmation fonctionnelle réactive)

    Posté par . Évalué à  6 . Dernière modification : le 28/02/13 à 23:01

    Quel nom étrange …

  • # OCamldap

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

    C'est juste pour dire que le lien vers le dépôt d'ocamldap n'est pas le bon :/
    Voici le bon dépôt: https://bitbucket.org/deplai_j/ocamldap
    et celui vers le dépôt dev pour ceux que ça intéresse: https://bitbucket.org/deplai_j/ocamldap-next

    Note: le dépôt dev n'est pas une branche car la migration de svn à git a été un peu difficile.

  • # meta

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

    Plutôt qu'une liste en extension, je vais donner des meta-informations ;-)

  • # ctag/etag

    Posté par . Évalué à  2 .

    Je ne sais pas si ça peut servir mais il y a ça aussi.

  • # Ocsiblog

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

    Il semble que le dernier commit remonte à 4ans. Vu le développement de Ocsigen entre 2, ça ne doit même plus tourner depuis un bon bout de temps.

    On préfèrera certainement s'intéresser à Ocsimore, qui doit être mieux suivi…

    • [^] # Re: Ocsiblog

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

      Mieux suivi, mais pas forcément fait pour cette utilisation. (enfin pour le moment)

      Ocsimore est plutôt utile dans le cadre d'un wiki ou d'un blog multi-utilisateurs. Enfin dans le cadre d'une application plus lourde.

  • # Auto-promo

    Posté par . Évalué à  6 . Dernière modification : le 01/03/13 à 09:51

    Allons-y pour l'auto-promo,

    mon petit soft codé en O'Caml depuis quelques années et qui est utilisé par un nombre incroyable de 2 personnes.
    Il choppe les événements kernel sur des fichiers placés dans des répertoires surveillés et remonte l'info: par mail, par notification locale ou distante, dans une base de données.
    A l'origine, le but était de surveiller et comprendre ce qu'il se passait sur le système lorsque je voyais de la bande passante partir pendant mon absence.
    Technos utilisées: lex/yacc, multi-process pour séparer le cœur de l'appli de la partie réseau, chroot et baisse de privilèges, thread, TLS, authentification mutuelle, dbus, sql, inotify, /proc, envoi de mail (smtp ou smtps)

    Infos remontées en DB:
    login, username, program, program_pid, path, filename, filesize, filedescriptor, first_known_offset, last_known_offset, opening_date, closing_date, created, in_progress.

    https://github.com/gbe/repwatcher

    • [^] # Re: Auto-promo

      Posté par . Évalué à  2 .

      Cela mériterait un journal à part entière. Il manque une plus longue explication sur le problème à résoudre par ton logiciel, puis ses points forts actuels, voir une comparaison avec d'autres solutions, et quelques captures d'écran pour se faire une idée.

      "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

      • [^] # Re: Auto-promo

        Posté par . Évalué à  5 . Dernière modification : le 01/03/13 à 12:23

        Un journal peut-être pas mais je veux bien en discuter.

        Le problème à résoudre?
        À l'origine, ce qui m'intéressait était d'avoir des infos comme proftpd peut en fournir mais adapter aux transferts de fichiers par SSH. J'ai pensé greffer une verrue sur ssh mais finalement, j'ai opté pour une solution générique qui peut fonctionner avec d'autres programmes. Par exemple si tu écoutes une chanson avec VLC, tu auras une notification.

        Comment sont récupérés les évenements? Il y a très longtemps, ça bouclait sur "lsof" pour lister les fichiers ouverts. Si un fichier était ouvert et fermé entre les 2 appels de boucle, l'information était perdue.
        Aujourd'hui, c'est le kernel qui envoie les alertes à mon soft en user-space. Ce qui permet de gagner en réactivité. Les informations complémentaires sont extraites de /proc et du fichier lui-même. Les informations retournées par le kernel sont rudimentaires. Il faut se contruire les informations à la main. Ainsi, quand tu mets un dossier en surveillance, ce n'est pas fait récursivement. Donc tu dois aller lister les sous-dossiers pour les surveiller eux-aussi. Si un dossier est supprimé, tu as un event seulement pour ce dossier. La conséquence est que tu dois gérer ton arbre de dossiers et faire des parcours en profondeur quand un dossier est déplacé pour. De même quand tu as un événement sur un fichier, tu as seulement son nom. Si ce fichier est dupliqué à plusieurs endroits, comment savoir lequel a été ouvert et quel est son path complet? C'est ce que l'arbre permet de palier comme carence. Quant à /proc, ça me permet de savoir quel programme a ouvert le fichier et surtout, si le fichier est ouvert plusieurs fois par ce soft, de savoir qui a fermé qui (imaginez le même fichier transféré par SSH).

        Comme le but de ce soft était de tourner sur un serveur, je voulais être avisé à distance lors d'évènement. La démarche de lire la base est manuel et les notifications locales insuffisantes (j'ai pas dbus sur mon serveur). J'ai donc mis en place la partie réseau en protégeant les communications en TLS. Pour protéger le soft lui-même d'attaque par la porte d'entrée réseau, j'ai splitté l'appli en 2 processus (fork) dans le processus réseau, je change d'identité pour baisser les privilèges et je le chroote. Ceci est dans l'hypothèse que l'appli avait besoin d'être lancée en root. La partie notification par mail est arrivée récemment. Ca me gavait de devoir lancer le client réseau développer alors que les mails conviennent bien à mon usage. En revanche, l'autre utilisateur de mon projet a codé une appli web autour de la base de données remplie par Repwatcher ainsi qu'un soft pour recevoir les notifications sur son smartphone. La partie "push" du réseau prend alors pas mal de sens. Grace au "last_known_offset", tu peux te coder une barre de progression et calculer la vitesse de transfert.

        Que dire de plus? Les captures d'écran du terminal t'intéresse vraiment? :)
        Autrement, ce qui m'intéresse dans le développement de ce programme est de m'amuser, mettre en pratique des compétences de sécu, toujours m'améliorer. Avoir des retours pour m'améliorer m'intéressent beaucoup.

        Pour ce qui est des comparaisons, j'en ai pas vraiment à faire malheureusement. Quand j'ai démarré le développement, je n'avais pas trouvé de programmes qui remplissaient mon besoin et développer ce logiciel était aussi pour mon apprentissage de l'OCaml. Comme énoncé dans l'article, j'ai détesté ce langage à l'école et j'en riais en me disant que jamais je le mettrai dans mon CV.

        • [^] # Re: Auto-promo

          Posté par . Évalué à  3 .

          "Un journal peut-être pas mais je veux bien en discuter."

          Faut pas faire le modeste ! Un soft cela a besoin d'un peu de pub pour se lancer. Un commentaire aura peu de visibilité.

          Que dire de plus? Les captures d'écran du terminal t'intéresse vraiment? :)

          Pourquoi pas ! C'est la page la plus consulté sur les sites qui présente un logiciel. C'est toujours plus parlant pour le futur éventuel utilisateur.

          "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

  • # fraicheur ?

    Posté par . Évalué à  3 .

    Dans la liste, il manque l'état de maturation du code. Inutile de présenter un code béta inutilisable en pratique. Il est aussi intéressant de savoir si le projet est toujours soutenu. Un projet dont le dernier commit à plus de 1 an, est un très mauvais signe.

    "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

    • [^] # Re: fraicheur ?

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

      Soit c'est mauvais signe, soit il est tout simplement terminé. Pour en utiliser quelques uns de ce genre au quotidien, c'est plus souvent ce cas là que je rencontre.
      Pour mon petit soft, ça a été d'ailleurs la même histoire : il marche, j'y touche plus…

      Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

      • [^] # Re: fraicheur ?

        Posté par . Évalué à  2 .

        D'ailleurs est-ce qu'il existe un truc pour faire un client lourd ? J'avais entendu parler d'un binding gtk, dans quel état est-il ?
        J'adorerais un binding avec les EFL, mais cela n'a pas l'air simple :)

        "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

        • [^] # Re: fraicheur ?

          Posté par . Évalué à  3 .

          Il existe lablgtk2 qui est bien. Conduit par un habitué de l'INRIA, c'est soigné et c'est une bonne traduction en OCaml des concepts GTK.

          Après faut apprécier faire de la GUI GTK2…

          Le même homme travaille sur un concept de LablQT mais je crois qu'il n'arrive aps à suivre les changements du framework. :)

          • [^] # Re: fraicheur ?

            Posté par . Évalué à  2 .

            J'avoue aussi que j'aimerai un truc gui qui utilise les arbres de type de base plutôt que les objets pour représenté la gui, c'est plus simple de manipulation.

            "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

  • # Surpris

    Posté par . Évalué à  8 .

    Je suis surpris qu'on ne parle pas de l'excellente OCaml Batteries, une bibliothèque alimentée par la communauté pour compenser la trop pauvre lib standard (il parait que c'est un choix, très suspicieux comme choix).

    Ocaml Batteries fournit par exemple:
    - Des fonctions générales, on citera notamment (|>) et qui sert à "piper" les fonctions let a = (f x) |> g <=> let a = g (f x)
    - Les éumérations, des listes infinies évaluées paresseusement
    - Des séquences, des énumérations de nombres sur lesquels ont peut faire des opérations spécifiques tr1es pratiques
    - Des vrais printers faciles à utiliser et extensibles
    - Des outils de manipulation de fichiers puissants
    - Des types arborescents et leurs fonctions associées
    - Un logger, de l'UTF-8, les cordes (des string en mieux), des fonctions supplémentaires sur les types de base, et j'en oublie.

    C'est un indispensable pour le programmeur OCaml efficient, je m'en sert notamment pour utiliser des types de données plus couillus que les listes dès que la logique est validée.

    Dans le cadre de mon projet d'implémentation du langage de configuration TOML (comme le .INI en mieux), je vais surement ajouter le support des dates ISO8601 dans OCaml Batteries. Stay tuned !

    • [^] # Re: Surpris

      Posté par . Évalué à  1 .

      Il n'y pas que Batterie sur le marché des trucs en plus. DE mémoire, elles sont 3 (core ?).

      on citera notamment (|>) et qui sert à "piper" les fonctions let a = (f x) |> g <=> let a = g (f x)

      Sérieusement, il y a des gens qui pensent que ce genre de zigouigoui rend le code plus clair ? Pour un langage parlant (let … = in, match … with …), quelle idée de rajouter tous ses machines inexpressifs.([>, ~label, etc…)

      "éumérations"

      Le type somme ne suffit pas ?

      "Des outils de manipulation de fichiers puissants"

      Et portable windows/unix ?

      "je m'en sert notamment pour utiliser des types de données plus couillus que les listes dès que la logique est validée."

      Un code avec des listes est tellement plus lisible ! Est-ce que tu as réellement noté une augmentation de perf valable pour contre -balancer la lourdeur d'écriture ? J'ai l'impression que la collection doit être grosse (> 10 000 éléments) pour que cela soit intéressant.

      "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

      • [^] # Re: Surpris

        Posté par (page perso) . Évalué à  4 . Dernière modification : le 01/03/13 à 16:42

        Sérieusement, il y a des gens qui pensent que ce genre de zigouigoui rend le code plus clair ? Pour un langage parlant (let … = in, match … with …), quelle idée de rajouter tous ses machines inexpressifs.([>, ~label, etc…)

        Mais pour le coup ce n'est pas équivalent, si je comprends bien, le |> est à utiliser seulement quand à chaque étape on a juste besoin de la valeur renvoyée par la fonction précédente, donc d'un seul coup d'œil on comprend mieux comment s'enchaînent les valeurs, alors que avec des let … = in on doit vérifier que ça s'enchaîne bien comme ça. Après je dois dire que je ne sais pas si c'est très courant d'avoir ce genre de chaînes, mais on peut imaginer qu'elles pourraient être vraiment utiles, ça n'a pas l'air impossible : en haskell ce genre de ziguoiguoi est très abondant (en fait on peut difficilement y échapper) et ils n'ont pas l'air de s'en plaindre, même si personnellement je préfère toujours avoir le choix du style comme en ocaml: fonctionnel, impératif, ziguouigoui ou autre suivant le problème.

      • [^] # Re: Surpris

        Posté par . Évalué à  3 . Dernière modification : le 01/03/13 à 19:42

        Sérieusement, il y a des gens qui pensent que ce genre de zigouigoui rend le code plus clair ? Pour un langage parlant (let … = in, match … with …), quelle idée de rajouter tous ses machines inexpressifs.([>, ~label, etc…)

        Absolument ! Ca évite d'avoir a stocker les valeurs intermédiaires dans un calcul complexe.
        Du genre:

        let _ =
          Array.init 42
            |> populate
            |> filter filter_func
            |> Array.sort
            |> array_printer
        
        

        Ose me dire que c'est moins lisible qu'une série de let…in imbriqués. :)
        En plus, c'est assez facile de modifier la séquence de cas dans ces conditions puisque les fonctions ne sont pas dépendantes.

        Pour ce qui est des énumérations, ca n'a rien a voir avec les types sommes (qui sont géniaux, par ailleurs).
        Il s'agit de listes paresseuses infinies. Typiquement tu peux y mettre tous les naturels ou tous les entiers, puis faire des opérations de filtrage, et la parcourir a souhait en étant assuré que ton programme va terminer (si tu arrête ton parcours) et avec une faible empreinte mémoire.
        La doc montre d'ailleurs comment résoudre un probleme Euler en trois lignes. ;-)

        C'est un héritage de la Extlib 2, qui est maintenant abandonnée au profit de Batteries.

        Et portable windows/unix ?

        Il me semble que oui, après arriver a faire compiler Batteries sur Windows est possible mais c'est chiant. Faut en avoir le besoin.

        Un code avec des listes est tellement plus lisible ! Est-ce que tu as réellement noté une augmentation de perf valable pour contre -balancer la lourdeur d'écriture ? J'ai l'impression que la collection doit être grosse (> 10 000 éléments) pour que cela soit intéressant.

        Quand tu utilise des AVL ou des Rouge-Noir, c'est pas seulement pour des questions de rapidité mais aussi pour leurs propriétés intrinsèques.
        Comme tu le dis, la syntaxe des listes est tres legere et l'API autour est tres fournie, mais tu te retrouve ensuite a adapter la logique de ton code a cette facilité.
        En plus, clairement les arrays sont plus rapides et donnent moins de pression au GC, mais ce n'est pas tant pour les perfs que pour l'utilisation de la structure de donnée adaptée a ta manipulation. Si tu utilise ta liste comme une Queue, utiliser le module Queue augmente la lisibilité de ton code grandement meme s'il faut quelques characteres en plus.

        • [^] # Re: Surpris

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

          Pour ce qui est des énumérations, ca n'a rien a voir avec les types sommes (qui sont géniaux, par ailleurs).

          A mon avis le souci est précisément sémantique. Dans les deux familles de langages que je connais (C et Java), les enum sont précisement des sous-ensembles finis en bijection avec un sous-ensemble de N (assez similaire avec le souvenir que j'ai des types sommes en OCaml). Alors si les enums en OCaml+Batterie ont une sémantique totalement différente (semblable aux Streams en Scala), faut pas s'étonner des incompréhensions.

          • [^] # Re: Surpris

            Posté par . Évalué à  3 .

            Alors si les enums en OCaml+Batterie ont une sémantique totalement différente (semblable aux Streams en Scala), faut pas s'étonner des incompréhensions.

            Je ne m'étonne pas des incompréhensions, d'autant plus que je les ai moi aussi rencontrées un jour, et c'est bien pourquoi j'explique a chaque fois de quoi il s'agit juste apres avoir utilisé le mot.

            Il faut lire la phrase en entier parfois, ca aide a comprendre…

            • [^] # Re: Surpris

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

              J'essayais juste d'expliciter le risque d'incompréhension, en espérant que ça aide les deux bords (les puristes d'OCaml et les pragmatiques du C) à mieux comprendre. Mais promis la prochaine fois au lieu de défendre OCaml je chierai dessus allégrement puisqu'il semble qu'en effet ses adeptes soient bien des auto-imbus méprisants. Ca m'apprendra à penser que des universitaires puissent être autre chose que des pourris-gâtés.

              • [^] # Re: Surpris

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

                Ca m'apprendra à penser que des universitaires puissent être autre chose que des pourris-gâtés.

                Pourris-gâtés ? Tu parles de leurs salaires (des bacs+8 payés 2000 euro/mois à l'embauche), de leurs conditions de travail (passer leur temps à supplier l'ANR de leur donner des financements ridicules, compétition permanente pour publier, locaux délabrés, incitation pesante à "valoriser", etc.) ou de la reconnaissance de leur travail ("s'ils trouvaient, on ne les appellerait pas des chercheurs"…).

                Bon, ça n'a pas grand chose à voir avec le sujet de départ. Là où ils sont chanceux, les académiques, c'est qu'ils sont libres de choisir le langage à utiliser pour coder leurs prototypes, quand les autres langages sont imposés dans les boîtes. Et ils choisissent OCaml, le langage de choix pour les connaisseurs… ;-)

      • [^] # Re: Surpris

        Posté par . Évalué à  3 .

        Il n'y pas que Batterie sur le marché des trucs en plus. DE mémoire, elles sont 3 (core ?).

        D'active et maintenue ouvertement ? Il ne reste que Batteries. La ExtLib a accouché de Batteries, avec un meilleur design et une plus grosse communauté.
        Sinon il y a la JaneStreet CoreLib qui, parait-il est pas mal, mais c'est tout sauf communautaire puisque développé par la finance Shanghai-aise. C'est libre par contre, il me semble.

    • [^] # Re: Surpris

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

      Le problème de Batterie (mais je peux me tromper) c'est que ça te fait du CamlP4 dans ton dos, et ça pour moi c'est rédhibitoire. Autant sur du code perso, c'est pas grave, autant sur du code d'entreprise, je peux pas me permettre de compiler du code illisible. Surtout que les erreurs de CamlP4 sont totalement incompréhensible.

      En gros, j'utilise surtout ExtLib (massivement en fait), je sais que c'est complètement dépassé, mais ça suffit à mes besoins.
      Cela dit, j'ai jamais sérieusement étudié ni Batterie, ni Core.
      L'idéal serait que je rencontre qqun qui m'explique l'intérêt de l'un ou l'autre (un peu comme t'as l'as fais).

      Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

      • [^] # Re: Surpris

        Posté par . Évalué à  3 .

        Le problème de Batterie (mais je peux me tromper) c'est que ça te fait du CamlP4 dans ton dos, et ça pour moi c'est rédhibitoire. Autant sur du code perso, c'est pas grave, autant sur du code d'entreprise, je peux pas me permettre de compiler du code illisible. Surtout que les erreurs de CamlP4 sont totalement incompréhensible.

        Tu ne confonds pas avec LWT ? Il n'y a pas de P4 dans Batteries a ma connaissance. C'est du Ocaml pur.
        QTest, une lib de test inlinés utiise P4 je crois mais je ne trouve pas de traces de qtests dans le code du dépot.

        En gros, j'utilise surtout ExtLib (massivement en fait), je sais que c'est complètement dépassé, mais ça suffit à mes besoins.
        Cela dit, j'ai jamais sérieusement étudié ni Batterie, ni Core.
        L'idéal serait que je rencontre qqun qui m'explique l'intérêt de l'un ou l'autre (un peu comme t'as l'as fais).

        Simple : Batteries est le fils de ExtLib. Batteries est modulaire, Batteries est mature, testé, varié, documenté. Batteries est bon, mangez en !

        • [^] # Re: Surpris

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

          Tu ne confonds pas avec LWT ?

          L'extension camlp4 de Lwt n'est sûrement pas obligatoire.
          Elle est là uniquement (ou presque) pour les gens qui n'aiment pas la syntaxe des monades.

          • [^] # Re: Surpris

            Posté par . Évalué à  3 .

            En effet, j'ai tellement l'habitude d'utiliser l'extension de syntaxe LWT que j'ai oublié comment faire sans ! :D

      • [^] # Re: Surpris

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

        Dans quelle partie, batteries fait-il du camlp4 « dans le dos » ?
        Le seul que je vois là maintenant c'est la syntaxe pour les listes infini, mais comme toute extension camlp4, on est pas obligé de l'utiliser (sauf certains cas, pour ocsigen/macaque par exemple)

  • # Vraie application

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

    Oui, cette liste manque un peu d'applications industrielles.

    Un exemple que je trouve assez sympa : Citrix développe l'hyperviseur Xen, qui est utilisé sur 15% des PCs virtualisés dans le monde (Amazon EC2 par exemple). Quand vous installez un serveur avec xen, celui-ci a besoin d'un programme pour le contrôler, on appelle ça le "domaine zéro". Et bien, ces pros du système ont choisi OCaml pour cette application hypersensible, qui reçoit les demandes de l'adminstrateur et les traduit pour l'hyperviseur. Tout le code est open-source, c'est le projet XAPI sur Github.

    • [^] # Re: Vraie application

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

      Oups, c'est Xen-API, il y a un autre projet XAPI sur Github, qui n'a rien à voir avec Xen… mais c'est un plugin pour Haxe, vous connaissez ? C'est un langage pour écrire des applications (des jeux principalement) qui peuvent tourner sur plein de plateformes (web, mobiles, etc.)… et le compilateur est écrit en OCaml ! En voulant montrer une appli OCaml, j'en débusque une autre !

    • [^] # Re: Vraie application

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

      Une autre application plutot notable en ocaml, que j'utilise tous les jours avec plaisir, c'est unison . Je sais qu'il est en ocaml parce c'est ça qui le rend bien chiant à compiler et impossible a patcher (pour moi). Donc je lui rends hommage, mais je prefererais qu'il soit en c++

    • [^] # Re: Vraie application

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

      Le but était de montrer qu'il existe des librairies utilisables pour la vraie vie en OCaml, afin d'imaginer coder en les utilisant.

      Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

  • # Manque de marketing, propagande ?

    Posté par . Évalué à  6 .

    Caml/Ocaml a été l'un des langages que j'ai eu le plus de plaisir à apprendre étant à la fac, une fois les rudiments maîtrisés, on se rend vite compte de la puissance et de tout le potentiel de ce langage.

    Ses qualités tout le monde ici les connait on va dire, j'en citerai quelques unes encore qui a mes yeux sont loin d'être négligeables :

    • le fait de pouvoir produire du bytecode et le rendre portable
    • et une empreinte mémoire assez réduite pour le code produite bytecode ou code natif. Une empreinte mémoire peu plus importante que C, mais infiniment plus réduite que ce que produit JAVA.

    En termes de littérature, n'importe quel profane peut trouver matière afin de se familiariser et se former à ce langage. Les manuels/doc de caml sont très bien faits et certains bouquins de référence sont même mis à disposition gratuite (ex. http://caml.inria.fr/pub/docs/oreilly-book/).

    Le langage a largement atteint les milieux universitaires qui l'enseignent, que ce soit en prépa, ou dans les études d'ingénieurs. Des milliers d'étudiants sont formés à ce langage chaque année, et ce même hors de nos frontières (USA, Europe etc…).

    Bref alors avec tous ces atouts pourquoi la mayonnaise ne prend pas sorti de quelques marchés de niche ?

    Surtout si on le compare à Java qui est sorti quasiment à la même époque ?

    Et bien je me dis que c'est certainement le manque de marketing ou de propagande qui entourent ocaml qui lui font aujourd'hui défaut.

    Pour en revenir à Java, pour ceux qui s'en souviennent dans les années 95/96, Sun, la presse, la littérature abondante de bouquins très souvent écrits de manière opportuniste, nous juraient tous que Java is the Future, "Write once run everywhere".

    C'était sexy, on avait envie d'y croire. Las applets directement exécutables depuis un Netscape, ça faisait "class". Et puis google n'existait pas encore, et Java était promis à devenir le MicroSoft killer et oui tout allait tourner en JVM indépendamment de l'OS sous jacent, et la domination de Microsoft sur les OS allait surement être remise en cause, le géant de Redmond enfin menacé, une nouvelle ère de l'informatique allait s'ouvrir. Java c'était le langage de demain de l'internet la techno incontournable.

    Je me rappelle même qu'on écrivait des OS ou desktop en Java (cf http://en.wikipedia.org/wiki/Project_Looking_Glass)

    Bref la bande annonce était alléchante, l'histoire fut différente. Et tout le monde voulait s'embarquer dans le train Java, même si on en connaissait pas vraiment la destination.

    Aujourd'hui même si Java est largement bien implanté, dans l'industrie/entreprise/milieux informatiques, il est très loin d'avoir tenu tous ses engagements et promesses. Tant mieux ou tant pis, c'est à chacun de voir.

    Et bref pour Ocaml je pense qu'il lui a manqué cette "petite touche à l'Américaine" pour créer le "buzz" et l'intérêt qui font que certains langages marchent mieux que d'autres.

    Bref encore une fois les amerloques ont été plus forts que les petits chercheurs Gaulois de l'Inria. A quand la potion magique ? Une leçon peut-être à retenir pour l'avenir pour les produits qui sortiront des milieux scientifiques français.

    PS. : Je voulais citer une phrase qu'avait l'un de mes profs Christion Queinnec de Jussieu à propos de Java, que je trouvais bien tournée du genre "java est un langage nouveau qui ne fait que reprendre des principes éculés d'autres langages" ou quelque chose comme ça mais en beaucoup mieux formulé, mais pas moyen de m'en souvenir, ni de la retrouver, si parmi vous…

    • [^] # Re: Manque de marketing, propagande ?

      Posté par . Évalué à  5 .

      Mes impressions:
      1) Peu de librairies, par exemple je ne crois pas qu'il y ait une librairie pour Qt.
      2) Les manuels poussent à faire du fonctionnel (alors qu'OCaml peut aussi faire de l'impératif) ce qui rend le code moins lisible quand on n'a pas l'habitude.
      3) Une syntaxe qui pourrait être améliorer (celle de F# est mieux qu'OCaml).
      4) Pas/peu de marketing comme tu disais.

      Ça fait beaucoup..

      • [^] # Re: Manque de marketing, propagande ?

        Posté par (page perso) . Évalué à  1 . Dernière modification : le 04/03/13 à 10:46

        3) Une syntaxe qui pourrait être améliorer (celle de F# est mieux qu'OCaml).

        De quel point de vu ? À part les « in » qui ont été apparemment enlevé, je ne vois pas de différences.

        • [^] # Re: Manque de marketing, propagande ?

          Posté par . Évalué à  2 .

          Euh en fait j'avoue: ce que je l'ai marqué, c'est ce dont je me souviens quand j'avais regardé OCaml mais c'était déjà il y a un certain temps donc je me souviens de me "conclusions" de l'époque mais pas des raisons..

    • [^] # Re: Manque de marketing, propagande ?

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

      J'avais publié une étude que j'avais réalisé sur les raisons du succès de Java : https://linuxfr.org/news/naissance-dun-g%C3%A9ant-java
      Un dénommé ggins avait publié une analyse très intéressante : https://linuxfr.org/nodes/86730/comments/1251671

      Java est rassurant au niveau industriel : spécifications, comités pour les standards, produit poussé par une boite qui faisait des serveurs pour la vraie vie, etc…
      De plus, il était non disruptif par rapport à l'existant.

      OCaml, et les langages fonctionnels en général ne sont pas facile à appréhender, les systèmes de types complexes demandent un certain apprentissage avant de pouvoir les utiliser.

      Je pense aussi (mais c'est une pure intuition), que l'on comprend l'intérêt d'un tel langage, une fois que l'on a réalisé des grosses applications complexes et que l'on s'est pris le mur le de la complexité dans la face en codant avec un langage classique.

      Ce qui fait que :

      • Peu de développeur sentent le besoin d'aller voir de tels sortes de langage (Haskell, Ocaml, Scala qui percera le mieux je pense), tant qu'il n'ont pas subi un logiciel imaintenable.
      • Et même parmi ceux qui l'ont vécu, peu oseront ou voudront sortir de ce qu'ils connaissent.

      Les langages fonctionnels, de par leur niveau mathématique minimal requis, resteront des langages minoritaires.

      Les gens aiment MacDo, Céline Dion et Jean-Jacques Goldman.
      C'est comme ça.

      Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

      • [^] # Re: Manque de marketing, propagande ?

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

        Les langages fonctionnels, de par leur niveau mathématique minimal requis, resteront des langages minoritaires.

        Je ne vois pas où il y aurait besoin d'un niveau en mathématique minimal. À part si tu veux pouvoir suivre les papiers sur le sujet, je ne vois vraiment pas.

        • [^] # Re: Manque de marketing, propagande ?

          Posté par . Évalué à  2 .

          Pas sûr que ce soit un problème de math, mais je trouve que ce genre de question montre bien le problème d'Ocaml:
          http://linuxfr.org/forums/programmationautre/posts/ocaml-probleme-de-type-avec-les-modules

        • [^] # Re: Manque de marketing, propagande ?

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

          La notion de fonction de fonction, ou encore d'ordre supérieur, est par exemple difficile à comprendre par beaucoup de programmeurs.

          La notion de module, comme rappelé à côté est pas évidente. Je fais du OCaml quotidiennement depuis 1,5 an, et je ne suis pas encore super à l'aise avec.

          Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

          • [^] # Re: Manque de marketing, propagande ?

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

            Peut-être, mais rien qui ne requière de connaissance en maths.
            Les connaissances en maths peuvent servir à la limite pour comprendre la logique sous-jacente, et encore.

            • [^] # Re: Manque de marketing, propagande ?

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

              Je connais des gens qui ont eu des cours de programmation fonctionnel qui m'ont "c'est chiant, on dirait des maths". Je ne sais pas comment était le cours en pratique mais ça retranscrit bien l'esprit de beaucoup de monde à mon avis.

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

              • [^] # Re: Manque de marketing, propagande ?

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

                Le point n'est pas là. Ça a peut-être l'aire de maths (ça emprunte un paquet de concepts), mais on a pas besoin de maths pour comprendre et utiliser les concepts.

                • [^] # Re: Manque de marketing, propagande ?

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

                  Appelle ça comme tu veux, mais toujours est-il que par expérience, ces concepts d'ordres supérieurs sont difficile à appréhender, ce qui fut pour votre serviteur pas évident au début (j'ai du mettre 2 ans à vraiment maitriser ce concept et je suis pas fier de cette lenteur).

                  Le concept de fonction qui prend n arguments (non fonctionnels) et en rend un, tout le monde comprend. Le concept de fonction prenant en argument une fonction, c'est plus dur déjà. C'est en train de percer, avec les lambda qui deviennent à la mode, mais il va falloir du temps pour que ça parvienne au cerveau de tout le monde, si tant est que c'est utilisé.

                  Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

              • [^] # Re: Manque de marketing, propagande ?

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

                Je pense que c'est aussi parce que beaucoup d'enseignants adeptes d'OCaml présentent cela comme des maths.

                • [^] # Re: Manque de marketing, propagande ?

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

                  Pour la petite histoire, c'était de l'Haskell, ça doit être commun aux adeptes de la programmation fonctionnelle.

                  « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

Suivre le flux des commentaires

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