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 Sufflope (site web personnel) . Évalué à 5.
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 Ontologia (site web personnel) . É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
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: .
Posté par GuieA_7 (site web personnel) . É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 c^3 . É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 stopspam . Évalué à -6.
Je dirais qu'il y a 2 types de langages :
[^] # Re: .
Posté par Enj0lras . Évalué à 0.
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 Sufflope (site web personnel) . Évalué à 9.
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 Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: .
Posté par Ontologia (site web personnel) . Évalué à 4.
Effectivement, il y a plusieurs raisons de l'insuccès du langage :
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: .
Posté par Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: .
Posté par lendemain . É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.
On veux des noms!
Un exemple s'il vous plait monsieur?
Tu as du en chier à polytechnique ou normal (ou sup…), ça ta laissé amer on dirait.
La recursion est enseigné de base.
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 Ontologia (site web personnel) . Évalué à 2.
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
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.
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.
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"
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: .
Posté par Dinosaure (site web personnel) . Évalué à 1.
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 Ontologia (site web personnel) . É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…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: .
Posté par Dinosaure (site web personnel) . É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 MrLapinot (site web personnel) . Évalué à 2.
Si c'est juste pour télécharger la VOD d'Arte, tu aurais aussi bien pu utiliser weboob ;-)
[^] # Re: .
Posté par Enj0lras . É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 totof2000 . Évalué à 6. Dernière modification le 28 février 2013 à 23:01.
Quel nom étrange …
# OCamldap
Posté par GNU_Eths . É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 BAud (site web personnel) . Évalué à 2.
Plutôt qu'une liste en extension, je vais donner des meta-informations ;-)
# ctag/etag
Posté par lendemain . Évalué à 2.
Je ne sais pas si ça peut servir mais il y a ça aussi.
# Ocsiblog
Posté par Maclag . É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 GNU_Eths . É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 dest . Évalué à 6. Dernière modification le 01 mars 2013 à 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 Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: Auto-promo
Posté par dest . Évalué à 5. Dernière modification le 01 mars 2013 à 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 Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
# fraicheur ?
Posté par Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: fraicheur ?
Posté par Ontologia (site web personnel) . É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…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: fraicheur ?
Posté par Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: fraicheur ?
Posté par mackwic . É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 Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
# Surpris
Posté par mackwic . É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 fonctionslet 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 Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: Surpris
Posté par anaseto . Évalué à 4. Dernière modification le 01 mars 2013 à 16:42.
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 mackwic . Évalué à 3. Dernière modification le 01 mars 2013 à 19:42.
Absolument ! Ca évite d'avoir a stocker les valeurs intermédiaires dans un calcul complexe.
Du genre:
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.
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.
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 Sufflope (site web personnel) . Évalué à 1.
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 mackwic . Évalué à 3.
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 Sufflope (site web personnel) . É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 Fabrice Le Fessant (site web personnel) . Évalué à 6.
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 mackwic . Évalué à 3.
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 Ontologia (site web personnel) . É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).
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surpris
Posté par mackwic . Évalué à 3.
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.
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 GNU_Eths . Évalué à 2.
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 mackwic . É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 GNU_Eths . É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 Fabrice Le Fessant (site web personnel) . É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 Fabrice Le Fessant (site web personnel) . É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 Troy McClure (site web personnel) . É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 Ontologia (site web personnel) . É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.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Manque de marketing, propagande ?
Posté par Anonyme . É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 :
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 reno . É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 GNU_Eths . Évalué à 1. Dernière modification le 04 mars 2013 à 10:46.
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 reno . É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 Ontologia (site web personnel) . É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 :
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.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Manque de marketing, propagande ?
Posté par GNU_Eths . Évalué à 6.
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 reno . É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 Ontologia (site web personnel) . É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.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Manque de marketing, propagande ?
Posté par GNU_Eths . É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 claudex . É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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Manque de marketing, propagande ?
Posté par GNU_Eths . É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 Ontologia (site web personnel) . É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é.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Manque de marketing, propagande ?
Posté par Dr BG . É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 claudex . Évalué à 3.
Pour la petite histoire, c'était de l'Haskell, ça doit être commun aux adeptes de la programmation fonctionnelle.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.