Fabrice Le Fessant a écrit 27 commentaires

Peut-on avoir une idée de ce que ça veut dire, quantitativement, « soutenir une idée » ?

Le strict minimum, ce serait de pouvoir financer une personne à plein temps dessus, pendant plusieurs années, d'abord pour la concevoir, ensuite pour la maintenir. Mais bon, c'est un minimum, je doute que le JDK ait été développé par une seule personne…

Et sinon, les implicites c'est pour quand ?

Euh, finalement, Grégoire a principalement travaillé sur les types dynamiques, les implicites sont dans sa roadmap, mais pour plus tard…

Est-ce qu'un jour la lib principal serait remplacé par battery ou un équivalent ?

Pour l'instant, il y a le choix entre Batteries et Core. Ni l'une, ni l'autre n'a l'adhésion de la communauté : Batteries manque de soutien industriel, et Core est un peu trop liée à Jane Street, ce qui est à la fois un avantage (qualité) et un inconvénient (évolution externe difficile). OCamlPro avait pour ambition d'en soutenir une, mais aucun client ne s'est manifesté pour soutenir financièrement cette idée.

Est-ce que le support de windows sera un peu plus "sympa" ? (sys.rename qui rale si le fichier destination existe mais pas sous linux, le module "Unix", installeur pas forcément à jour, …)

Oui, c'est dans les cartons ;-)

Est-ce qu'il existe une library graphique digne de ce nom ? Le binding gtk est connu mais bon gtk… :/

Je suis en train d'améliorer wxOCaml (https://github.com/OCamlPro/ocplib-wxOCaml), ça commence à devenir utilisable (voir le sous-répertoire "samples" qui contient plusieurs exemples que j'ai traduits de C++ à OCaml), et surtout, c'est prévu pour être facilement extensible, avec une génération quasi totalement automatique des stubs (ajout de nouvelles classes, de nouvelles
méthodes). Normalement, wxWidgets donne un rendu supérieur à celui de GTK, en tout cas sous Mac OS et Windows.

La prochaine version (4.01) est prévue pour juin-juillet 2013.

Parmi les modifications importantes :

• la propagation des types dans le filtrage : ça permet d'avoir des types avec des labels ou des constructeurs identiques sans que cela pose problème, en annotant les types filtrés (comme en C ou Java).
• en cas d'erreur "Unbound identifier", le compilateur suggère maintenant les identifiants les plus proches
• compilation en mode "frame-pointers" pour profiler avec Linux perf
• plusieurs optimisations, en particulier lectures/écritures optimisées des int 8,16,32 et 64 bits little/big endian
• plein de correctifs de bugs

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… ;-)

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 !

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.

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 !

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…

Tiens, un autre indice que le concours ICFP est bien connu, une News sur ce forum datant de 2002 et relatant la victoire d'une équipe en OCaml (et en second, d'une équipe en C) !

Merci en tout cas pour cette discussion, elle attire l'attention sur le prestigieux concours ICFP, qui mérite d'être connu de tous les développeurs ! La prochaine session aura lieu en juillet 2013, ça dure normalement 3 jours, en équipe, mais il y a une session "light" d'un jour seulement pour ceux qui ont une vraie vie ;-)

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 ???

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 !

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…

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

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…

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 ! ;-)

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 !

Disons que, pour l'instant, l'amélioration des performances n'est pas le chantiers prioritaire. Parmi les langages hyper-expressifs (Python, etc.), OCaml est largement plus performant, il a un problème avec le multi-core, mais c'est exactement le problème que celui de Python, et je n'ai jamais entendu personne faire ce reproche à Python sur un forum, en dehors de la communauté Python.

Aujourd'hui, je pense que le problème principal est d'améliorer l'accessibilité d'OCaml, en faisant des livres pour débutants, des tutoriaux en ligne (voir http://try.ocamlpro.com/), en améliorant les outils de développement (un bon mode Eclipse) et le support Windows (la version 4.00 imminente devrait avoir deux installeurs pour Windows concurrents, alors que la version précédente en avait zéro !).

Haskell et Scala ne sont pas loin derrière, mais ils appartiennent à la même famille que OCaml (ma comparaison était plutôt avec les langages comme Python), et surtout, un effort considérable a été déployé pour les rendre efficace : Scala utilise les JIT Java optimisés par Sun/Oracle pendant des années, et le compilateur Haskell est au top des optimisations, alors qu'OCaml ne fait pas beaucoup d'optimisations en comparaison, et a donc pas mal de marge de progression.

Après, Haskell est plutôt un langage pour les chercheurs, qui ont un amour fou pour rendre leurs programmes illisibles, en utilisant un maximum de combinateurs et de fonctions prédéfinies dont les noms ne doivent pas dépasser 5 caractères. Du coup, j'ai toujours un doute sur la maintenabilité de leurs programmes, alors que les programmes OCaml sont souvent très lisibles (le "style standard" est de spécifier les modules des fonctions, genre "List.iter", ce qui rend le code plus lisible parce qu'on peut facilement deviner les types et comprendre ce que ça fait). Scala, lui, est un compromis entre Java et fonctionnel, on a une expressivité proche de celle d'OCaml, l'accès à toutes les bibliothèques Java, mais pas la sûreté (on peut avoir des pointeurs NULL…).

Une chose particulièrement "crade" dans le shootout OCaml est l'utilisation de
grand coup forks pour compenser le mauvais support multi-core d'OCaml….

Pour avoir fait une thèse sur la concurrence et la distribution, et cotoyé des équipes qui travaillaient sur la détection de bugs dans les programmes parallèles, tu te trompes complètement : la manière propre de faire du parallèlisme, c'est justement le fork() et l'échange de messages, alors que le partage de mémoire en multi-core n'aboutit qu'à des programmes faux, qui deadlockent ou font des accès concurrents non-protégés dès que le programme se complexifie un peu. Autre avantage, le programme se distribue sur un cluster immédiatement, ce qui n'est pas le cas des programmes multi-core, qui souvent ne passent même pas à l'échelle de dizaine de coeurs. Bref, le mauvais support multi-core d'OCaml garantit d'avoir des programmes plus corrects et facilement distribuables à grande échelle, quel paradoxe !

Bon, je dis ça, mais chez OCamlPro, on va quand-même essayer d'améliorer le support multi-core d'OCaml, mais justement, en permettant de faire des forks dans le runtime (sans utiliser fork(), qui n'existe que sous Unix), et en fournissant un peu de partage de mémoire pour les données qui s'y prêtent (tableaux de flottants, chaînes de caractères). Ça devrait permettre d'exploiter le multi-core, sans augmenter trop les risques d'obtenir des programmes faux.

La plupart des entreprises que j'ai citées, même si leur soft principal n'est pas forcément libre, financent ou contribuent au libre. Xen-Api est totalement libre, mais Jane Street fournit en libre les bibliothèques sur lesquelles est bâti leur soft (ils ne vont pas rendre publiques leurs règles d'achat/vente par contre ! ;-) ), et la plupart des softs que j'ai cités dans l'avionique sont libres aussi (sauf Astrée, c'est bien dommage).

Si je cite les logiciels de l'avionique, c'est justement parce qu'ils présentent deux caractéristiques spécifiques: comme ils font des analyses sur le code pour vérifier qu'il n'y a pas d'erreur dedans, ils traitent (1) des quantités de données importantes (des programmes et les propriétés mathématiques qui en dérivent) (2) avec des algorithmes extrêmement compliqués.

S'ils choisissent OCaml, c'est que c'est l'un des seuls langages à répondre à ces deux problèmes :
- le runtime est optimisé pour traiter de grosses quantités de données en mémoire (la représentation des données est beaucoup plus compacte qu'en Java ou Python)
- le compilateur génère du code natif efficace
- une fois que le typeur est passé sur le programme, on peut se concentrer sur les seuls bugs qui pourraient rester.

Tous les programmeurs n'ont pas besoin de passer à OCaml. Mais s'ils veulent s'investir dans un projet important et exigeant, c'est le langage à choisir…

Je ne suis pas si sur que la faible popularité d'OCaml soit imputable à l'enseignemen,
il y a pas mal d'université enseignany Ocaml en france, particulièrement dans l'Est.

Hélàs, OCaml est souvent enseigné dans un cadre très restreint, comme exemple de langage fonctionnel. On impose aux élèves de n'utiliser qu'une toute petite partie du langage, et ils en sortent généralement dégoutés. C'est un paradoxe, car OCaml permet à la fois la programmation impérative (il y a des boucles, des variables modifiables), la programmation fonctionnelle typée, et la programmation orientée-objet (on peut définir des classes, des objets, et appeler des méthodes). Il permettrait au contraire de n'utiliser qu'un seul langage pour enseigner tous ces paradigmes !

OCaml est un langage qui par design impose de fortes limitations à l'utilisateur en
échange d'une fiabilité élevée, voir même trés élevée.

Des limitations ? Pour le débutant, oui, parce qu'il a l'impression de se battre contre le typeur, qui lui indique ses erreurs, sans se rendre compte que son programme est simplement faux sinon. Après avoir développé un gros projet en OCaml, on trouve au contraire que le système de types est une aide indispensable, qui facilite le travail (on peut être moins rigoureux qu'avec un autre langage, parce qu'on sait que le typeur nous surveille !) et on ne comprend plus comment des gens peuvent encore développer en Python ou Java (on les regarde comme les adultes regardent les enfants, la naïveté éveille la bienveillance…)

Il y a des tas de situations ou subir ces limitations est gênant, rébarbatif et souvent
une perte de temps,

C'est tout le contraire, pour le connaisseur, le typeur fait gagner du temps, le code est aussi court qu'en Python (en OCaml, on n'indique pas les types, le typeur les devine), et les erreurs sont toutes attrapées tout de suite, avant même les premiers tests.

il n'est pas trés étonnant que pour des domaines ou la fiabilité est secondaire,
l'enseignement d'un autre langage est plébiscité par les entreprises….

Je ne connais pas d'entreprises pour lesquelles la fiabilité est secondaire. La fiabilité du code, c'est aussi la capacité de ce code d'être adapté et maintenu sur le long terme, sans introduire de bugs. Je connais des entreprises qui ont crû la fiabilité secondaire, et qui galèrent ensuite pour maintenir un code non-maintenable (soit elles y dépensent des sommes folles, soit elles perdent des clients parce que leurs coûts deviennent trop élevés). Avec OCaml, pour toute modification du code, le typeur indique tous les endroits à modifier, la maintenance (corrective comme évolutive) est ensuite un jeu d'enfant…

Ceci dit si dans le lot il y a avait des applications libres ça serait bien aussi ;
maintenant on sait que Ocaml est sorti des labo et sert à faire des applications bien
proprio aussi ! :)

Avant de faire de telles remarques, il faut se renseigner ! Des applications libres en OCaml, il y en a aussi (dont une partie des fameuses applis industrielles !):
- MLdonkey, premier client pair-à-pair multi-protocole (edonkey, kad, bittorrent, etc.)
- Unison, LA solution pour synchroniser ses répertoires entre plusieurs ordinateurs
- Frama-C, plateforme d'analyse de code C, et Alt-Ergo, SMT-solver pour analyseur de code
- Ocsigen, plateforme pour programmer le web (cet article)
- Xen-Api, le logiciel de Citrix pour contrôler Xen (tout le code est sur GitHub)

Parce que les meilleurs lignes de code c'est aussi bien souvent celles qu'on écrit pas,
aussi faciles soient elle à écrire.

J'ai personnellement écrit les 20000 premières lignes de MLdonkey en OCaml, et maintenu le logiciel de 2001 à 2005. Je ne suis pas sûr de comprendre ce que tu veux dire dans cette phrase.

Je me dis souvent qu'il serait intéressant d'avoir un langage de script basé sur OCaml, i.e. la possibilité d'écrire du OCaml et de le faire interpréter au fur et à mesure (il y a un REPL, mais il compile avant d'exécuter, alors qu'il faudrait qu'il exécute et ne type que paresseusement…). Cela permettrait aux débutants de commencer à programmer et, comme en Python, d'exécuter des programmes même s'ils sont faux.

Cela dit, c'est aussi la paresse des profs d'informatique qui est en cause : ils préfèrent se simplifier la vie en enseignant Java, tout en sachant qu'un langage comme OCaml serait bien plus utile pour nos entreprises, pour les développement pro. Et comme OCaml est difficile à apprendre, si on ne l'a pas appris à l'université/école d'ingénieur, il est dur de s'y mettre tout seul. Tout le contraire de Python de ce point de vue.