Ocsigen est une technologie libre de développement de sites et applications Web client-serveur. Une de ses particularités est d'offrir la possibilité d'écrire les côtés client et serveur non seulement dans le même langage, OCaml, mais comme un seul et même programme. Particulièrement bien adaptée au développement d'applications HTML5 très dynamiques, Ocsigen permet également de repenser et simplifier l'implémentation des comportements standard des sites Web traditionnels (signets, bouton « back », liens, formulaires, etc.). En outre, il permet de combiner ces deux approches de manière très naturelle.
Ocsigen met l'accent essentiellement sur deux points : d'une part, offrir un langage très expressif, ce qui permet d'écrire du code simple et court ; d'autre part, aider à produire du code et des applications fiables et faciles à maintenir. C'est la raison pour laquelle Ocsigen utilise OCaml, un langage de programmation compilé très puissant et au système de type très riche. La grande expressivité d'OCaml est complétée par un grand nombre de nouveaux concepts inédits et spécifiques au Web (services, sessions sophistiquées, etc.) qui permettent de simplifier l'implémentation de comportements dynamiques complexes. De plus, Ocsigen exploite au maximum le typage d'OCaml pour qu'un maximum de garanties de fiabilité soient données dès la compilation (par exemple la validité des liens). Cela va même jusqu'à la vérification à la compilation que les pages générées seront conformes aux recommandations du W3C !
NdM : Ocsigen est sous licence LGPL 2.1
Sommaire
Le pouvoir des fonctions
La façon de programmer des sites Web traditionnels a été intégralement repensée, grâce à des concepts de haut niveau qui simplifient énormément l’implémentation de comportements complexes classiques du Web (sessions, bouton « back »…).
Les requêtes sont traitées par le serveur par le biais des « services », notion centrale dans Ocsigen. Un service peut être vu comme un générateur de contenu (HTML, fichiers, redirection, etc.), pouvant être déclenché par un clic sur un lien, un formulaire, ou par une requête du programme client.
Un service est en général associé à une URL et peut prendre des paramètres de types variés. L'identification du service à exécuter ainsi que la vérification et la conversion des paramètres sont faites automatiquement. Par exemple, le morceau de code suivant définit un service s, à l'URL user/profile, attendant un paramètre d'URL appelé i de type entier.
let s = Html5.register_service
~path:["user"; "profile"]
~get_params:(int "i")
(fun g p -> ... (* an HTML5 page *))La fonction register_service prend un premier paramètre (étiqueté "path") pour l'URL, un deuxième ("get_params") pour la description des paramètres du service et une fonction, qui génère la page à partir des paramètres GET et POST (ici, g est un entier).
Il existe d'autres types de services, répondant à des besoins différents — par exemple, des services accessibles à n'importe quelle URL pour faire des appels de fonctions distants (par exemple la connexion d'un utilisateur depuis n'importe quelle page). Il est aussi possible de créer dynamiquement des nouveaux services personnalisés pour un utilisateur, ce qui rend triviale la programmation de formulaires en plusieurs étapes.
Grâce aux services, on ne manipule jamais d'URL directement. Dans le code, on fera pointer un lien vers un service et non vers une URL, ce qui garantit l'absence de liens morts internes au site.
```
#Applications distribuées#
Un site Web était auparavant une plate-forme de contenu, avec parfois des comportements dynamiques côté client localisés, souvent en utilisant le plug-in Flash. Aujourd'hui, les navigateurs sont en train de devenir des machines virtuelles dans lesquelles s'exécutent des applications complexes. Cette évolution des possibilités des navigateurs ne s’est pas réellement accompagnée d’une évolution des technologies de programmation sous-jacentes. La plupart des applications que nous utilisons aujourd’hui sur le Web sont développées avec des frameworks classiques côté serveur et en Javascript côté client, sans aucune intégration entre les deux parties. Ces techniques de programmation sont de très bas niveau (proches des protocoles), ce qui oblige les programmeurs à se préoccuper de beaucoup de détails eux-mêmes (notamment du point de vue sécurité).
Ocsigen résout ces problèmes en proposant une approche radicalement différente. L'application Web est écrite dans un seul et même langage et correspond à un seul programme regroupant le code exécuté sur le serveur et le code exécuté sur le navigateur. Cela permet d'utiliser les mêmes bibliothèques des deux côtés et cela simplifie grandement la communication client-server car les deux parties partagent les mêmes structures de données et aucune conversion manuelle n'est nécessaire. On peut même par exemple utiliser côté client des variables définies côté serveur. Techniquement, le code client est compilé vers JavaScript à l'aide d'un compilateur très efficace.
Les parties client et serveur sont distinguées dans le code OCaml grâce à une syntaxe spéciale.
```ocaml
{client{
... (* Code OCaml exécuté au chargement de la première page du site *)
}}
{shared{
... (* Code OCaml commun aux côtés client et serveur *)
}}
{server{
... (* Code OCaml exécuté au lancement du serveur (définition de fonctions, etc) *)
let a = ... (* Définition d'une valeur côté serveur appelée a *)
...
(* Génération d'un morceau de page : *)
div
~onclick:{{ (* Code Ocaml exécuté quand l'utilisateur clique sur l'élément <div> *)
... %a ... (* qui utilise la valeur a définie sur le serveur *)
}}
[ (* contenu du div *) ]
}}
La communication entre le serveur et le programme client est également prise en charge automatiquement, dans les deux sens : cela permet par exemple de recevoir des notifications de la part du serveur, en très peu de lignes de code.
Un des points forts d'Ocsigen est la possibilité d'utiliser une application côté client tout en conservant les comportements traditionnels des sites, basés sur les URLS, liens, formulaires et signets, etc. L'application ne s'arrête pas lorsque vous suivez un lien ! Cela permet par exemple d'implémenter un site dans lequel vous pouvez continuer à naviguer tout en écoutant de la musique, et ce, très facilement (c'est même le comprtement par défaut !).
Pour exécuter du code OCaml dans un navigateur, Ocsigen dispose d'un compilateur OCaml vers Javascript très efficace, qui est de plus en plus utilisé pour développer des applications dans un navigateur en bénéficiant du confort apporté par le langage OCaml. Par exemple la société californienne Besport est en train de développer un moteur d'affichage de cartes géographiques depuis les données OpenStreetMap. Et sur le site Try OCaml, le compilateur OCaml lui-même a été compilé vers Javascript pour permettre de tester le langage depuis une page Web.
```
Fiabilité et validités des applications
L'utilisation d'un langage de script pour écrire des applications complexes conduit la plupart du temps à des programmes très difficiles à maintenir et à faire évoluer lorsque la taille du code devient importante. Ocsigen, au contraire, a fait le choix d’utiliser un langage de programmation compilé. Et plutôt que créer un nouveau langage, il utilise un langage existant, OCaml, ce qui lui permet de bénéficier d’une communauté de développeurs active et d’un ensemble important de bibliothèques utiles. Ce langage a été choisi parce qu’il est l’un des plus évolués en terme d’expressivité et de fiabilité, tout en restant pragmatique dans ses choix.
En particulier, il dispose d’un système de types très sophistiqué, qui permet de vérifier un grand nombre de propriétés du programme à la compilation, avant même de le lancer, et d’éviter ainsi beaucoup de bugs. Ocsigen utilise ce système de types de manière poussée pour aider le programmeur à trouver ses erreurs. Cela a pour conséquence de faire des programmes très fiables et faciles à faire évoluer, avec seulement un peu plus de rigueur au départ.
Un exemple frappant est la vérification à la compilation de la validité du HTML qui garantit que toutes les pages générées par le programme seront valides. Par exemple, si f est une fonction qui renvoie une liste de blocs (`<p>`, `<div>`, etc.) alors le compilateur vous autorisera à utiliser les valeurs retournées à l'intérieur d'une balise `<body>` mais pas à l'intérieur d'un `<p>`.
Ocsigen vérifie beaucoup d'autres aspects de l'application : absence de liens cassés, conformité des formulaires par rapport aux services vers lesquels ils pointent, etc.
En résumé, Ocsigen est un framework Web polyvalent, permettant de développer aussi bien des sites à la manière des frameworks MVC que de véritables applications sophistiquées avec interface dans un navigateur. L'utilisation d'un langage très évolué permet de programmer de manière concise et en faisant très peu de bugs.
```
Aller plus loin
- Ocsigen (797 clics)
- Exemple : appli de dessin collaboratif (1019 clics)
- Le tutoriel : écrire le logiciel de dessin collaboratif en moins de 100 lignes de code (650 clics)
# Journée Ocsigen à Paris en octobre prochain
Posté par Vincent Balat . Évalué à 9.
En complément de l'article, je signale qu'une journée de formation à Ocsigen sera organisée en octobre prochain à Paris. Pour vous tenir informé, suivez la mailing du projet de ou rejoignez-nous sur les réseaux sociaux !
Vincent
# Suis-je le seul a être dérangé ?
Posté par Niniryoku . Évalué à 1.
La dernière fois c'était pour un logiciel propriétaire. Cette fois ci, c'est mieux, le logiciel est libre.
Mais suis-je toujours le seul à être dérangé par les dépêches rédigées par un compte jetable (cette fois ci le compte n'en est pas un, mais c'est une personne non inscrite à DLFP) qui font la promotion partiale d'un produit. Typiquement, (j'ai juste survolé la dépêche) on retrouve des choses comme :
ou encore :
De ce que j'ai survolé, Node.js fait exactement la même chose en JavaScript, mais il n'est pas mentionné.
Bref suis-je le seul dérangé par les dépêches commerciales sur LinuxFR faites par des personnes extérieur ? (Je n'ai rien contre une dépêche d'un produit fait par une moule active.)
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Suis-je le seul a être dérangé ?
Posté par Littleboy . Évalué à 9.
En l'occurence, c'est poste par une doctorante du chef de l'equipe de dev.
On peut regretter le fait qu'elle n'ai pas cree de compte et ne puisse pas repondre aux questions posees. L'article en lui-meme est interessant et bien ecrit (meme si ca fait un peu trop pub parfois) mais c'est bete de poster ca sur un site de discussion comme on irait envoyer son dossier de presse a un des nombreux sites de spam qui publient tout et n'importe quoi (si vous envoyer ca a des journalistes un minimum serieux mais ne prenez pas la peine de repondre aux questions, ils vont vous envoyer chier et vous ajouter a leur blacklist).
Une occasion manquee :(
[^] # Re: Suis-je le seul a être dérangé ?
Posté par patrick_g (site web personnel) . Évalué à 10.
D'un autre côté, si des questions pertinentes sont postées, peut-être que l'auteur créera un compte et y répondra.
[^] # Re: Suis-je le seul a être dérangé ?
Posté par severinem . Évalué à 10.
Coucou,
Me voici donc avec mon tout nouveau compte, tout neuf, prête à recevoir vos critiques!
Cela faisait longtemps qu'on nous réclamait un article sur Linuxfr, notamment sur la tribune… c'est juste le 2e en 7 ans. Faut-il empêcher les auteurs d'écrire des articles sur leur logiciel et ne voir du coup sur linuxfr que des articles sur des projets mainstream ?
Ensuite, les phrases que tu cites décrivent très bien le travail de l'équipe de recherche qui a développé l'outil et de l'équipe OCaml : améliorer l'expressivité et la fiabilité des langages. C'est assez objectif, on a des arguments, notamment des articles de recherche… On a fait l'effort de faire un article long pour donner des infos techniques.
Enfin Ocsigen n'a rien de commercial… C'est un projet libre collaboratif issu d'un labo de recherche. Il n'y a pas de boîte derrière (et quand bien même ?).
Si vous avez des questions de fond, n'hésitez pas!
[^] # Re: Suis-je le seul a être dérangé ?
Posté par Larry Cow . Évalué à 5.
Va pour une question de fond, donc. Je n'ai pas touché à Caml depuis des années, et tout cela est un peu lointain. Pour un peu, je l'aurais cru disparu. Et là, à quelques mois d'intervalles, on voit passer deux solutions en Caml sur le même créneau.
En clair : avez-vous des relations avec Opa ?
Bon, et si vous continuez tous, il va falloir que je me remette au Caml. Groumf.
[^] # Re: Suis-je le seul a être dérangé ?
Posté par Vincent Balat . Évalué à 3.
Pas de liens direct avec Opa, même si l'on se connaît et qu'on discute. La grande différence est qu'Ocsigen est un framework OCaml alors qu'Opa est un langage qui n'a rien à voir (implémenté lui-même en OCaml).
Les projets sont assez proches dans leur buts ce qui explique le choix d'un langage très évolué comme OCaml (comme langage de programmation de sites pour nous et comme source d'inspiration et langage d'implem du langage pour eux). Cela dit les choix qui ont été faits sont très différents et le style de prog aussi.
[^] # Re: Suis-je le seul a être dérangé ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Quel est la pérennité d'un tel projet ? Ocaml lui-même a du mal à avoir des ressources pour continuer à être développé, en dehors de ce qui intéresse les chercheurs.
Qu'est-ce qui peut me dire que dans 3 ans, le projet ne sera pas abandonné ? Le problème se pose aussi pour opa, mais en pire car ils doivent aussi maintenir le langage.
Sinon quelle est la différence entre les 2 projets, vu de loin, ils ont l'air identique à part le nouveau langage vs ocaml.
"La première sécurité est la liberté"
[^] # Re: Suis-je le seul a être dérangé ?
Posté par psychoslave__ (site web personnel) . Évalué à 5.
Bah sauf si une météorite tombe sur un congrès de chercheurs impliqués dans le projet, pourquoi disparaîtrait-il dans les années à venir ? Moi je trouve ça intéressant de voir qu’il y a des chercheurs qui essaient de pousser des solutions mûrement réfléchies vers l’industrie. On entends souvent parler du manque de coopération entre les deux milieux, là on voit un effort certain réalisé d’un coté.
[^] # Re: Suis-je le seul a être dérangé ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Je trouve cela très bien.
A moins que le système est changé, la recherche fonctionne par projet à but scientifique d'une duré fixe (3 ans ? 5 ans ?). Une équipe est présenté avec un but scientifique. Développer un produit pour l'industrie n'est pas un but scientifique accepté.
Donc, le risque est qu'à la fin du temps du projet, il ne soit pas renouveler, ou alors, il le sera avec un autre but scientifique et donc le développement se fera à la marge.
Le top est le genre de fondation comme la Fondation Linux, qui a pour but de développer Linux et les grosses boites payent la fondation pour qu'elle en ait les moyens. Mais il faut amorcer la pompe.
"La première sécurité est la liberté"
[^] # Re: Suis-je le seul a être dérangé ?
Posté par catwell (site web personnel) . Évalué à 2.
Ocsigen est un projet libre depuis au moins 2005. Je ne l'utilise pas personnellement mais ça fait au moins 5 ans que j'en entends parler. L'équipe de développement est relativement fournie : http://ocsigen.org/credits Il est packagé dans les distributions Linux majeures, dont Debian depuis 2006.
Crédits accordés à la recherche ou pas, c'est un projet libre sérieux. Après, comme avec à peu près n'importe quelle technologie, il faut réfléchir à ce que l'utiliser pour un gros projet implique. Mais j'hésiterais moins à utiliser OCaml que par exemple [troll]MongoDB[/troll].
[^] # Re: Suis-je le seul a être dérangé ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je fais du ocaml uniquement professionnellement depuis 1 an et demi. Cela veut bien dire que des boites l'utilisent.
"La première sécurité est la liberté"
[^] # Re: Suis-je le seul a être dérangé ?
Posté par catwell (site web personnel) . Évalué à 1.
Arf pardon, s/OCaml/Ocsigen/.
Tu es le Nicolas Boulay qui bosse chez Esterel ?
[^] # Re: Suis-je le seul a être dérangé ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je suis si connu que ça ?
"La première sécurité est la liberté"
[^] # Re: Suis-je le seul a être dérangé ?
Posté par catwell (site web personnel) . Évalué à 1.
Non non, j'ai cherché sur LinkedIn, j'étais curieux de savoir quelle boite utilisait OCaml (et je me suis intéressé à Esterel - le langage - il y a un moment).
[^] # Re: Suis-je le seul a être dérangé ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
ocamlpro doit avoir une liste de boite qui l'utilise. C'est un début de boite qui soutient le développement de ocaml.
"La première sécurité est la liberté"
[^] # Re: Suis-je le seul a être dérangé ?
Posté par Ontologia (site web personnel) . Évalué à 3.
Ma boite s'appelle Cowebo et on utilise aussi OCaml. On l'utilise pour quelques chose qui n'a rien à voir avec du calcul formel. C'est essentiellement une GED.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Suis-je le seul a être dérangé ?
Posté par Niniryoku . Évalué à 3.
Je tiens à me défendre la dessus, je n'ai absolument rien contre les projets commerciaux sous licence libre. Ce que je reprochais c'était le coté « dossier de presse » de la dépêche.
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Suis-je le seul a être dérangé ?
Posté par ZankFrappa . Évalué à 1.
Je suis assez d'accord avec toi, même si ici il ne s'agit pas exactement d'un projet commercial. Je trouve que, pour un projet assez expérimental comme celui-ci, la partie technique aurait pu être détaillée davantage, et les origines du projet (et ses concurrents) un peu mieux traités (un peu comme dans cet autre article, un peu plus ancien).
Néanmoins je suis content de voir que Ocsigen fait parler de lui, ainsi que d'apprendre la date d'une rencontre en octobre.
[^] # Re: Suis-je le seul a être dérangé ?
Posté par ®om (site web personnel) . Évalué à 6.
Si tu avais écrit ton commentaire avec Ocsigen, j'aurais pu lire "cet autre article" ;-)
Bon, ça va, on peut le corriger.
blog.rom1v.com
[^] # Re: Suis-je le seul a être dérangé ?
Posté par ZankFrappa . Évalué à 1.
Hé oui, malheureusement je l'ai écrit avec mon téléphone, qui supporte très mal le site (et donc j'ai copié-collé le lien à l'aveuglette). Merci d'avoir corrigé à ma place.
[^] # Re: Suis-je le seul a être dérangé ?
Posté par Zenitram (site web personnel) . Évalué à 8. Dernière modification le 28 juin 2012 à 09:22.
Perso, je ne vois pas pourquoi on ferait la différence entre "des nôtres" et "pas des nôtres", ça fait très communautarisme sectaire comme phrase.
le nom, l'origine, l'âge du compte (ou pas de compte), le nombre de commentaires, qu'est-ce que ça apporte à la qualité d'une dépêche? Pourquoi ça serait mieux si cette même dépêche est écrite par un compte actif?
Après, oui, certes, ça fait un peu "commercial", mais on n'est pas non plus obligé de connaitre tous les logiciels sur terre qui feraient un peu la même chose, et la personne est venue présenter ce logiciel, pas un comparatif avec d'autres logiciels, donc je trouve normal de ne pas en parler dans la dépêche. Elle présente "son" logiciel, c'est tout, rien de mal.
Ensuite : proprio ou que libre, c'est un choix rédactionnel de l'équipe. Mais pareil, je trouverai bizarre que "proprio fait par une moule active" ça passe et pas "proprio fait par un nouveau". On accepte le proprio ou pas, sans ségrégation qui n'a rien à voir plutôt?
Bref, tu n'es sans doute pas seul, mais sans moi pour le "ça dérange". Par contre le communautarisme de ton commentaire me dérange un peu ;-). On peu aussi s'ouvrir.
[^] # Re: Suis-je le seul a être dérangé ?
Posté par Vincent Balat . Évalué à 10.
Si ça peut te rassurer je suis moule active depuis 1998… et j'ai écrit l'article avec Séverine…
[^] # Re: Suis-je le seul a être dérangé ?
Posté par spider-mario . Évalué à 4.
Node.js est très loin de faire « exactement la même chose ». La dépêche mentionne non seulement le fait que la partie serveur et la partie client soient écrites dans le même langage mais également une intégration transparente entre les deux, là où Node.js est de bien plus bas niveau :
Si l’on exclut le fait que Node.js s’utilise en JavaScript (ce qui n’est pas nécessairement excellent selon la personne), Node.js est en ces points comparable aux frameworks classiques.
# Intéressant
Posté par ®om (site web personnel) . Évalué à 3.
Ça a l'air très intéressant.
Par contre, ne jamais avoir codé en OCaml augmente considérablement le "coût d'entrée" pour suivre le tutorial sans se demander ce que fait chaque ligne…
Mais je garde le lien pour quand j'aurai un moment.
blog.rom1v.com
# vitesse ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Quel vitesse peut on obtenir de ce genre de système ? J'ai l'impression que les téchno web sont souvent très lente.
Est-ce que ocsigen permet de bénéficier de l'astuce du moteur en page 404 ? En gros 90% des liens sont accessible en html statique, seul les liens dynamique ou manquant sont redirigés vers le moteur. La vitesse du moteur est souvent très faible par rapport à l'envoie d'une page statique.
"La première sécurité est la liberté"
[^] # Re: vitesse ?
Posté par foreground . Évalué à 3.
Oui, par défaut le serveur HTTP d'Ocsigen est configuré pour n'appeler le moteur de contenu dynamique (a.k.a. Eliom) uniquement s'il n'y a pas de contenu statique associé à l'URL demandée.
Concernant la vitesse global du système, je n'ai pas fait de bench personnellement mais toutes les entrées/sorties sont asynchrones à la lighttpd ou nginx ; et, le projet repose sur un mécanisme de thread coopératif très efficace : LWT.
[^] # Re: vitesse ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Sans teste, cela ne veut pas dire grand chose.
Si j'ai bien compris, vous n'utilisez pas un serveur connu comme Apache ou nginx, mais un truc uniquement pour faire tourner Ocsigen. Est-ce que vous ne risquez pas d'avoir toujours un manque de fonctionnalité, vu la taille de ce genre de serveur ?
"La première sécurité est la liberté"
[^] # Re: vitesse ?
Posté par foreground . Évalué à 2.
J'ai juste dit que je n'en avais pas fait personnellement de mesures de performances :) Je ne doute pas que l'équipe d'Ocsigen en a fait et pourra donner les pointeurs utiles.
Sinon, à propos des fonctionnalités du serveur HTTP spécifique d'Ocsigen, il a déjà de nombreuses années d'existence et il contient un certain nombre d'extensions comme
comet,CORS, ou les plus classiquerewrite,redirect,deflate,accesscontrol, voir mêmeCGIen cas de besoin. Dans les quelques essais persos. j'ai toujours trouvé les fonctionnalités dont j'ai eu besoin. De manière plus générale, je suppose qu'il est toujours possible d'utiliser Ocsigen derrière un reverse proxy.[^] # Re: vitesse ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Quel intérêt de mettre des ressources dans le codage d'un serveur web quand il existe tellement de projet concurrent plus aboutis ?
"La première sécurité est la liberté"
[^] # Re: vitesse ?
Posté par catwell (site web personnel) . Évalué à 3. Dernière modification le 28 juin 2012 à 14:37.
Hmm, parce que ça n'est pas du CGI ?
Prends une application Web typique en Ruby par exemple : même si ton frontal est nginx, tu auras un serveur Web dans tes processus applicatifs (par exemple Mongrel ou Thin), et tu utiliseras la directive proxy_pass, probablement avec un pool de serveurs applicatifs derrière.
C'est la même logique : HTTP est le protocole utilisé par ton application pour communiquer avec le monde extérieur.
Après s'il existe d'autres serveurs Web en OCaml ou éventuellement avec des bindings OCaml c'est une autre histoire. Mais encore une fois Ocsigen est un vieux projet et une référence pour tout ce qui est Web en OCaml (en tout cas d'après Google).
EDIT: Et oui clairement si tu as du contenu statique tu laisses le frontal le servir, tu ne tapes sur tes processus applicatifs que pour le contenu dynamique en général…
[^] # Re: vitesse ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Je pensais plus au cache version Linuxfr, ou l'applicatif contrôle les fichiers statiques servi.
"La première sécurité est la liberté"
[^] # Re: vitesse ?
Posté par Michaël (site web personnel) . Évalué à 2.
Même les tests ne veulent pas souvent dire grand chose! (Source How to produce the wrong data without doing anything obviously wrong.)
[^] # Re: vitesse ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Cela donne une idée tout de même. Le principe est de savoir exactement ce que l'on mesure.
"La première sécurité est la liberté"
[^] # Re: vitesse ?
Posté par Michaël (site web personnel) . Évalué à 2.
Dans l'article dont je cite le titre, les auteurs observent des variations de vitesse avec un rapport 4 dans plusieurs éxécutions du même programme. Cela veut dire qu'à moins d'avoir de sérieuses raison de penser le contraire, voire ton programme A' amélioré tourner 4 fois plus vite que le programme A original est peut-être tout simplement associé à un phénomène aléatoire (une erreur de mesure). Ensuite le problème qu'on a à faire des tests statistiques est que les observations que l'on fait ne sont pas indépendantes les unes des autres (en première approximation, un ordintateur est déterministe) c'est-à-dire que l'hypothèse de base de tout test statistique n'est pas remplie.
[^] # Re: vitesse ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Dans l'article en question, il parle de différence de vitesse selon l'ordre de link et la taille des variables d'environnement avec des écart de + ou 5 % et + ou - 10%. Cela reste pas énorme.
C'est pour cela que je parlais de savoir de quoi on mesure. Un bench ne peut être qu'une application réelle. J'ai déjà mesuré des bouts d'application. Le problème est qu'entre le temps d'exécution en cache "froid" et le temps en cache chaud,il peut y avoir une différence de 10x ! La mesure n'a de sens que dans le cas d'usage de l'application complète.
"La première sécurité est la liberté"
[^] # Re: vitesse ?
Posté par small_duck (site web personnel) . Évalué à 2.
LWT est très bien, mais il faut s'accrocher au début pour comprendre comment l'utiliser, et comment adapter ses bibliothèques non coopératives. Une fois qu'on a compris, vient la phase où on veut tout faire en coopératif :)
[^] # Re: vitesse ?
Posté par Ontologia (site web personnel) . Évalué à 4.
Le gros problème de LWT est qu'il ne sait pas utiliser le multicore à cause du runtime OCaml qui n'est pas réentrant. Fabrice Le Fessant avait commencé à travailler sur la question, mais il n'a pas les ressources ni la priorité de finir.
En ce qui me concerne, je n'ai pas utilisé OCsigen, car pas besoin de générer du HTML, je fais une webapp, mais OCamlNet, dont Ocsigen utilise quelques libs.
OcamlNet propose un système permettant de définir des CGI, il multiprocess automatiquement.
Mes benchs sur une page Html générée (récupération d'arguments numérique, petit calcul, génération html), me donne environ 4000 req.s-1 sur un i7 2ghz, avec 60% d'occupation (des 8) processeurs (je soupçonne la pile réseau d'avoir été un goulot d'étranglement).
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: vitesse ?
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 3.
C'est justement l'un des avantages d'utiliser Ocsigen : le code client est compilé vers Javascript, d'une façon très efficace, tandis que le code serveur est compilé en code assembleur par OCaml, ce qui le rend beaucoup plus efficace que s'il était interprété. Il y a donc des chances que les applis web en Ocsigen soient beaucoup plus rapides que des applis écrites en utilisant des frameworks plus "habituels"…
[^] # Re: vitesse ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3. Dernière modification le 29 juin 2012 à 17:50.
Imagines que la page d'acceuil de linuxfr soit gérer par un truc dynamique, à chaque connexion le moteur doit être exécuter. Si la page html est généré uniquement en cas de modification, 99% du temps, le serveur sert une page statique.
Dans le cas de reverse proxy, il me semble qu'il y a un problème pour prévenir le truc de devant par un "ça a bougé". Il faut fonctionner avec des timeout court si on veut de la réactivité, c'est pas forcément top, car le moteur sera appelé pour rien.
C'est pour cela que je parle de performance à l'époque du passage à templeet, les perf avait exploser avec cette technique (même si il y a avait du php dessous).
Ce n'est pas parce que le code est compilé qu'il ne peut pas avoir d'énorme faiblesse dans l'architecture, vu la complexité du web. Cela serait bête qu'une seul personne puisse faire un DOS sur un site web.
"La première sécurité est la liberté"
# Précisions sur la facilité de maintenance?
Posté par openmind . Évalué à 4.
Je n'ai pas compris cette partie. Pouvez-vous m'expliquer en quoi une application en langage compilé est plus facile à maintenir qu'une application en langage de script?
Merci :)
[^] # Re: Précisions sur la facilité de maintenance?
Posté par ®om (site web personnel) . Évalué à 2.
Il y a des avantages et des inconvénients.
En script, tu prends un vi tu modifies, et rien d'autre à faire. (simplicité)
En compilé, tu prends un vi tu modifies, il faut compiler, et le compilateur te dit qu'il y a une erreur (de typage par exemple) dans ton code donc tu t'en aperçois avant de déployer. (robustesse)
blog.rom1v.com
[^] # Re: Précisions sur la facilité de maintenance?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
et la mise à jour à chaud est pris en compte ?
"La première sécurité est la liberté"
[^] # Re: Précisions sur la facilité de maintenance?
Posté par small_duck (site web personnel) . Évalué à 1.
Toutafé: il est possible d'envoyer un signal au serveur Ocsigen pour lui faire recharger tous ses modules.
[^] # Re: Précisions sur la facilité de maintenance?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Et il se passe quoi avec les données persistantes ?
"La première sécurité est la liberté"
[^] # Re: Précisions sur la facilité de maintenance?
Posté par GNU_Eths . Évalué à 2.
echo reload > /var/run/ocsigenserver_command
[^] # Re: Précisions sur la facilité de maintenance?
Posté par V . Évalué à 4.
Quand tu modifies quelque chose dans le programme, par exemple quand tu changes un champ dans une structure de données ou quand tu changes les paramètres d'une fonction, OCaml va t' indiquer tous les endroits du programme qu'il faut que tu adaptes. Du coup c'est très facile de faire évoluer ton programme sans avoir peur que ça casse dans tous les coins.
[^] # Re: Précisions sur la facilité de maintenance?
Posté par openmind . Évalué à 2.
ah ok!
Et comment est-ce signalé, concrètement? Par une liste de messages au moment de la compilation?
Est-ce propre à OCaml ou aux langages compilés?
(Ne riez pas, je n'ai jamais utilisé que des langages non compilés)
[^] # Re: Précisions sur la facilité de maintenance?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Tu as une liste d'insulte en disant qu'il n'aime pas tel ou tel truc.
"La première sécurité est la liberté"
[^] # Re: Précisions sur la facilité de maintenance?
Posté par Vincent Balat . Évalué à 5.
Disons qu'OCaml pousse ça beaucoup plus loin que la plupart des autres langages compilés. Les types d'OCaml sont beaucoup plus riches donc peuvent vérifier plus de propriétés du programme. Par exemple Ocsigen va même jusqu'à vérifier que le programme ne peut pas générer de pages non conforme ! En gros il ne te laissera même pas exécuter le programme tant qu'il y a une possibilité d'échouer sur ce que tu lui as demandé de vérifier.
C'est très strict, mais dès que le programme devient gros tu évites d'avoir une usine à gaz. Je dirais que pour un petit programme un langage de script est souvent suffisant mais pour un programme un peu complexe, OCaml t'apporte beaucoup.
[^] # Re: Précisions sur la facilité de maintenance?
Posté par mackwic . Évalué à 0.
Bon, il y a deux choses : langage compilé, et langage fonctionnel.
Le langage est compilé : il va etre traduit en code binaire, le compilateur s'assure que ton code est syntaxiquement correct (pas de syntax error), puis qu'il est grammaticalement correct (
int int = int;est syntaxiquement correct dans de nombreux langages, mais est souvent grammaticalement incorrect carintest un mot clef souvent réservé).Dans un langage fonctionnel, toute instruction retourne une valeur. Cette valeur est typée (int, char, array, etc.) et donc le compilateur peut suivre les appels et vérifier que ton programme est cohérent.
En étendant le systeme de typage, on peut considérer une balise comme un type et donc vérifier aussi la cohérence de ta page, ton form, ton cookie, etc.
Dans le cas particulier d'OCaml (il y a plusieurs langages de prog fonctionnels), le compilateur est capable de deviner tous les types que tu utilise dans tes appels.
Cela veut dire que une fois que ton compilateur a vu juste, tu a probablement utilisé correctement les fonctions voulues.
Ocaml permet aussi de faire des expressions qui ne retournent RIEN (car rien est un type ;-) ), c'est le coté pragmatique dont parle la dépeche. Je ne sais pas en quoi c'est utile dans Ocsigen, mais ca doit bien l'etre quelque part.
[^] # Re: Précisions sur la facilité de maintenance?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
REtourner rien permet d'avoir des fonctions qui fait des effets de bords.
D'ailleurs, pourquoi n'est-il pas possible de définir une entrée/sortie "sous-entendu" ou caché, après tout un read ou un write dans un fichier est simplement une IO caché. Ainsi, on aurait toujours une vérification de type par "en dessous".
Un truc top aussi serait l'inclusion des exceptions dans le typage, car il est difficile de savoir ce qu'une fonction peut lever comme exception. Ou alors, il faut augmenter ocamldoc pour avoir ces infos.
"La première sécurité est la liberté"
[^] # Re: Précisions sur la facilité de maintenance?
Posté par GNU_Eths . Évalué à 2.
Tu entend quoi par "entrée/sortie sous-entendu" ?
Tu veux peut-être parler des monades ?
Pour l'inclusion des exceptions dans le typage (comme throws en C#/Vala/Java), je pense que c'est effectivement un truc manquant.
[^] # Re: Précisions sur la facilité de maintenance?
Posté par mackwic . Évalué à 0.
Je ne comprends pas, tu veux dire un truc comme ça ?
# Ocsigen server only ?
Posté par Firwen (site web personnel) . Évalué à 1.
C'est possible d'héberger un service ocsigen derrière un apache ou autre en fastCGI / CGI / modX ou autre ?
Deployer son propre serveur web peut être une grosse limitation sur certains environnements, voir peut provoquer un ulcère gastrique à certaines team sécu.
[^] # Re: Ocsigen server only ?
Posté par Maxime (site web personnel) . Évalué à 2.
Je dis ça sans connaître Ocsigen mais pourquoi tu ne pourrais pas utiliser un apache + mod_proxy ?
[^] # Re: Ocsigen server only ?
Posté par Vincent Balat . Évalué à 1.
Oui bien sûr. On peut mettre un front-end Apache et un reverse proxy vers Ocsigen (comme on ferait avec Tomcat) ou bien le contraire (Ocsigen en front-end et Apache derrière) en fonction de ce que tu veux faire. C'est équivalent à fastCGI et très simple. On le fait couramment.
# Utilisation d'OCaml dans l'industrie
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 6.
Bravo Séverine pour ton article !
En lisant ce forum, je m'aperçois que beaucoup ne savent pas encore qu'OCaml est sorti depuis longtemps du périmêtre clos des laboratoires, pour être utilisé dans de belles applications industrielles.
Pour avoir créer une entreprise qui fait du support aux entreprises l'utilisant (OCamlPro, http://www.ocamlpro.com/), je connais quelques exemples intéressants:
- Jane Street Capital : ils font 10 milliard de dollars de transactions en bourse par jour… automatiquement, depuis un système quasi-entièrement écrit en OCaml (partis de Visual Basic, ils avaient essayé C#, mais seule la conversion à OCaml a fonctionné, et tourne depuis 7 ans).
- Citrix : ils développent et commercialisent XenServer, utilise OCaml pour l'appli qui contrôle l'hyperviseur dans la VM0. Bref, quand vous gérez votre machine chez Amazon EC2, vous discutez sans le savoir avec une appli OCaml !
- Microsoft : ils distribuent dans leur SDK un analyseur en OCaml, qui détecte certains bugs dans les drivers de périphériques pour Windows. Étonnant pour une entreprise qui dispose, sur .Net, d'une ribambelles d'autres langages de programmation !
- L'industrie avionique : difficile de compter le nombre de logiciels en OCaml utilisés dans cette industrie, où il faut que les logiciels soient rapides tout en restant fiables. Il y a Scade KCG (Esterel Technologies), Frama-C et ses plugins (CEA, Airbus, Atos Origin), Penjili (EADS), Alt-Ergo (utilisé par Airbus et AdaCore), Astrée (AbsInt), et plein d'autres.
Développer en OCaml, c'est aussi facile qu'écrire du Python, mais avec deux différences:
- le compilateur trouve la plupart des erreurs sans avoir en exécuter le programme, ça économise plein de temps de debuggage et de tests
- le compilateur compile vers du code natif, qui tourne presque à la vitesse du C.
Et cerise sur le gateau: Ocsigen fournit un compilateur OCaml vers Javascript qui permet de faire tourner n'importe quel programme OCaml dans un navigateur à pleine vitesse: à tester sur http://try.ocamlpro.com/ !
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Firwen (site web personnel) . Évalué à 4.
OCaml est certes un language qui a des qualités, mais le niveau d'entrée d'OCaml est bien plus élevé que pour python ou que tout language de script :).
Justement car le compilateur est strict, trés strict même.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 2.
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.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Firwen (site web personnel) . Évalué à 5.
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.
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.
Il y a des tas de situations ou subir ces limitations est gênant, rébarbatif et souvent une perte de temps, 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….
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Firwen (site web personnel) . Évalué à 2.
désolé pour le piètre orthographe de mon précédent commentaire, j'implore l'excuse netbook + hotel + connexion pourrie :D
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 5.
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 !
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…)
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.
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…
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par lendemain . Évalué à 0.
Quel est le problème avec les typage java?
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Integer et int qui sont différent. Les comportement bizarre des tests sur les strings selon qu'elles sont canonisé ou pas.
En ocaml, tu peux écrire :
Cette gestion des "types somme" peut te faire gagner un temps de malade sachant que le typeur vérifie que les matchs sont complets.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Ontologia (site web personnel) . Évalué à 9.
Concernant les sociétés où la fiabilité serait secondaire, je serai un brin cynique.
Un éditeur a ce genre de problématique, là d'accrord.
Une SSII n'a pas forcément intérêt à ce que le logiciel fourni soit totalement fiable car cela la prive de juteux contrats de tierce maintenance applicative.
Vendre un logiciel, c'est vendre des bugs…
On pourrait penser que les SSII se livrant à ce genre de pratique se font éliminer avec le temps, mais même pas… Les grands employeurs de prestataires sont la SNCF ou la Poste car leur salariés interne ne foutent rien, l'improductivité, la lourdeur des procédures, le trop plein de cadres (pyramides des ages oblige), oblige à recourir à des gens en condition de salariats "normale" pour que quelque chose fonctionne. Je l'ai vu moi même, et j'ai encore eu un énième témoignage d'un copain en ce moment en presta à la SNCF.
Des logiciels bugués, ça donne une raison d'exister à ces cadres, ainsi qu'à ceux des SSII qui vont intelligemment expliquer, que le cahier des charges était faux, que le client a mal recetté, que l'environnement à changer, etc… Pour renégocier le contrat ou en gagner un autre. Et ça tourne, un coup c'est Cap, un coup c'est Accenture. Ils s'en tapent, ça tourne toujours entre eux.
De toutes façons, les grand comptes veulent des technos standard, autrement dit, Java.
Pourquoi, certes parce que dans certains cas on veut pouvoir trouver des compétences dans 15 ans, mais aussi, parce que l'industrie veut des programmeurs qui puissent être formés en trois mois.
Ces gens là comprennent pas qu'un bon développeur est 15 fois plus productif qu'un mauvais, alors qu'il coute au pire deux fois plus cher.
C'est pour ça que des langages comme OCaml seront toujours le choix d'éditeurs ou de domaines spécialisés.
Le phénomène s'entretient, car en choisissant OCaml dans mon appli coeur métier, j'ai fait prendre un très gros risque à la boite, et très peu de boite acceptent de prendre ce risque.
Tout le monde suit le leader.
Je pense que la formation est essentielle et qu'il faudrait essayer d'introduire les langages fonctionnels dans des formations bac+4 qui pullulent (des sous écoles d'ingénieurs).
Mais je suis assez pessimiste.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . Évalué à 6.
Malheureusement, je confirme, c'est un business model courant.
Et même s'ils le comprennent, ça ne change rien : ils vendent des mois*hommes, pas des bons logiciels. Les grosses SSII fonctionnent avec des juniors inexpérimentés, et quand ils deviennent plus âgés ils se débrouillent pour qu'ils partent d'eux-mêmes, pour ne pas avoir à les augmenter ni leur verser d'indemnité.
Autant ça serait bien que les étudiants soient initiés aux langages fonctionnels, autant il y a des tas d'autres trucs qui serait bien de leur enseigner. Comme la complexité des algorithme par exemple : sans ça ils ne pourront jamais bien coder en impératif, même si c'est le seul paradigme qu'ils connaissent. Je ne crois pas que les BTS la voit, et c'est pareil pour plein de formations en BAC+4 (alors que J2EE ça ils le voient…).
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Ontologia (site web personnel) . Évalué à 4.
Je confirme qu'en BTS ce n'est pas vu. Déjà qu'on a du mal à leur faire comprendre la notion d'expression booléenne, de type, alors le fonctionnel…
N'oublie pas qu'une non maîtrise de la complexité introduit des bugs qui peuvent être facturés "Non mais vous comprenez, mais là, c'est très complexe, il faut qu'on mette nos meilleurs ingénieurs dessus".
Et paf du jour.homme à 700 euros/jour !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Les gens qui se battent contre le typeur sont simplement des gens qui se battent contre leur programme faux.
Ocaml a d'autres limitations : pas d'interface graphique "native", un compilo qui renvoit des message d'erreur pas toujours d'une grande limpidité (même si on apprend à les déchiffrer avec le temps), outils de développement loin d'eclipse ou l'équivalent, ceux qui existe étant très proche de linux et loin de windows.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Michaël (site web personnel) . Évalué à 3.
OCaml est peut-être difficile à apprendre mais il est facile à utiliser, car comme tu le dis, le compilateur trouve toutes les erreurs!¹ Au contraire, python est facile à apprendre et difficile à utiliser car l'interpréteur ne trouve aucune erreur. Vu qu'on passe beaucoup plus de temps à utiliser un langage qu'à l'apprendre… pour moi c'est tout vu!
¹ Comme je suis sûr que certains ne me croient pas je détaille. Quand je programme je fais couramment les erreurs suivantes:
Le compilateur OCaml trouve toutes les erreurs de type 1, 2, et 3 automatiquement. En travaillant sur la structure de notre programme, on peut faire en sorte que le compilateur trouve aussi toutes les erreurs de tzpe 4. (Il faut exprimer les invariants du programme dans le système des types.) Les seules erreurs que ne trouve pas le compilateur OCaml sont celles de type 5, c'est plutôt bien et beaucoup mieux que ce que font d'autres langanges. Les langages interprétés ne détectent les fautes de type 1, 2, ou 3 que lorsqu'ils essaient de les éxécuter, par exemple. Les langages compilés ne s'en sortent pas tous mieux, par exemple les lanagages à surcharge d'opérateur peuvent accepter des programmes faux qui ont l'air corrects à cause de cette surcharge!
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . Évalué à 3.
Imaginons maintenant que les bugs de type 5 sont ceux qui prennent 99% du temps de debugage (c'est un chiffre sorti de mon chapeau, juste pour relativiser tes propos). Cela expliquerait pourquoi les codeurs Ocaml, malgré la supériorité de leur langage, n'arrivent quand même pas à écraser les autres codeurs, en écrivant le même genre de logiciel mais 10 fois plus vite et 10 fois meilleurs (comme certains aimeraient le croire).
Attention malgré tout mon amour pour Python, je reste lucide sur le fait que le typage dynamique est un peu une solution de facilité (mais Python a au moins le mérite de bien le faire, contrairement à d'autres - qui a dit PHP ?! ), et Ocaml a beaucoup de qualité que j'attends des langages du future.
Personnellement, le Développement Piloté par les Tests a plus contribué à la diminution du temps que je passe à chercher des bugs que l'apprentissage de n'importe quel langage.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par claudex . Évalué à 4.
Il est aussi avancé par certains que moins de déclarations aide à relire plus facilement le code et à trouver ces bugs du type 5 plus facilement. Je pense que ça dépend du programmeur mais c'est un argument que je trouve acceptable.
« 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: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . Évalué à 0.
Ça me semble acceptable en effet (il y a des tas d'autres facteurs c'est sûr). Je suis de toutes les façons un adepte des codes concis, et je passe une bonne part de mon temps de codeur à enlever des lignes de code, à factoriser. Quitte à avoir des bugs de type 5, autant ne pas les copier/coller.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Pour les bug de type 5, j'utilise les assertion autant que possible. Mais ce n'est pas toujours facile.
Ocaml affiche la pile d'appel qui déclenche les assertions fausses, cela localise l'assertion fausse mais aussi le chemin pour y arrivé. Le problème restant est qu'en cas d'inlining, certaines fonctionnes disparaissent de la trace.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Les assertions c'est bien, et ce n'est pas mutuellement exclusif avec les tests unitaires. Mais ça ne les remplace pas. Dès que tu as un algorithme non trivial (un algorithme quoi! ), tu as plusieurs chemins possibles : les combinaisons se multiplient et les assertions sont inutiles (ou deviennent 3 fois plus nombreuses que les lignes de code 'normales', et vont pourrir ton code).
Si tu fais un algorithme de tri, tu ne vas pas mettre 15 lignes d'assertions (avec des boucles et tout) pour vérifier que tous tes éléments initiaux sont présents, et qu'ils sont bien classés. C'est beaucoup plus sains et simple de faire une dizaine d'assertions dans tes test unitaires du genre :
assertEqual(sort([]), [])
assertEqual(sort([1]), [1])
assertEqual(sort([1, 2]), [1, 2])
assertEqual(sort([2, 1]), [1, 2])
etc…
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Ontologia (site web personnel) . Évalué à 3.
Ma pratique de la programmation et le retour vers des langages de script (je fais du OCaml ou du JS et je vois bien la différence) me montre que je fait surtout des erreurs de type 1, 2 et 3. Surtout 1 et 2 d'ailleurs.
Donc en Js, malgré use strict et jslint, je souffre, et je perd du temps.
Non franchement, en pratique, quand OCaml te dit "ok, pour la compil, pas d'erreur" ton code bug rarement.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . Évalué à 1.
D'un côté je suis assez d'accord. La plupart du code qu'on écrit est trivial ; le plus important se situe plus dans son design général qu'on doit garder propre. Peu de codeur passent la majeure partie de leur temps à plancher sur les algos vraiment pointus. Pourtant, sans test unitaire derrière, je ne ferais pas confiance à un programme en Ocaml, aussi puissant soit son typage, pour ce qui est de la gestion des régressions notamment. Ce n'est pas le compilateur qui va te dire "Andouille ! Ta fonction n'était pas prévue pour gérer une liste avec des doublons, donc en changeant tel comportement, tu as cassé telle autre fonctionnalité de ton programme (que tu ne vas pas tester en cliquant forcément, tu testes celle que tu viens de coder)." En revanche des tests unitaires bien fait vont souvent le faire, et ce même dans un langage pas aussi bien que Ocaml.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pour les tests, c'est 100% vrai.
Ocaml ne propose pas de "vrai" contrat, mais tu peux faire des choses avec les assertions et ajouter des vérifications "runtime". C'est n'est pas statique comme le typeur, mais cela diminue le besoin d'écrire les tests eux-même, puisque le code (en mode debug) s'autovérifie.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Pour rajouter une couche,un code qui marche en ocaml est très proche d'un code fini, pas besoin de rajouter une grosse couche de gestion d'erreur. En C, une fois qu'une maquette marche, il faut rajouter toutes la gestion d'erreur pour éviter les "core dump", il faut revoir toutes les allocations mémoire pour éviter les buffer overflowx, etc…
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Firwen (site web personnel) . Évalué à -1.
Ton pavé ne veut strictement rien dire, un programmeur C qui n'anticipe pas la gestion des erreurs est un néophyte ( et je reste poli ) . Ta phrase donne juste l'impression que tu n'as pas l'air de connaître grand chose à la prog système.
Ce n'est pas parce que le C n'implémente pas nativement les exceptions qu'il n'y a pas de méchanisme "propre" pour faire de l'error report : GError, errcode, ou un errbuff dans le context courant….
Quand aux problèmes d'allocation mémoire, C++ et la RIAA apporte des réponses à tous les problèmes les plus courant… Et valgrind associé aux tests fonctionnels font le reste.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je crois que tu devrais relire le pavé :) Je n'ai jamais parler d'exception et gérer correctement toutes les erreurs avec le bon messages en C te pourris ton code correctement. Souvent tu préfères tester un truc qui marche avant de toute faire proprement. Si tu fais propre dés le début, il est évidement que tu ira bien plus vite en ocaml.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Michaël (site web personnel) . Évalué à 2.
J'ai récemment écrit un programme en Python, qui fait une analyse de réseau routier et de relief pour localiser les tronçons de route qui sont des ponts. Cela m'a pris trois mois à temps plein, en profitant d'une bilbiothèque toute faite pour accéder aux données. J'estime à plus des 3/4 le temps que j'ai passé à debugger des erreurs de frappe, qui n'arrivent pas toujours dans les premières secondes du programme. Si j'avais pu travailler en OCaml j'aurais certainement torché ça en 5–6 semaines en prenant une semaine pour implémenter ou lier la bibliothèque en question.
C'est parceque les développeurs OCaml sont tous des gentils qui n'aiment pas écraser les autres. De plus les diçaïdeurs sont en majorité des gens allergiques au risque, qui préfèrent travailler avec une technologie peu productives mais bien acceptée (comme C++) que prendre le risque d'introduire une innovation. Ni les supérieurs du diçaïdeur ni ses clients ne leur reprocheront le choix de C++, pour continuer sur cet exemple.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . Évalué à 0.
Es-tu plus expérimenté en Ocaml qu'en Python ? Si oui, la comparaison est biaisée de toute les façons ; moi qui n'ai pas fait de Ocaml depuis l'école je mettrais 10 fois plus de temps qu'en Python et ça ne prouvera rien non plus.
Lol. Je suis bien content que Joseph Swan/ Thomas Edison n'étaient pas des gentils ayant peur de mettre les fabricant de bougies au chômage en inventant l'ampoule électrique.
Mais c'est vrai que c'est plus facile de se plaindre de son patron que de prouver ses dires (de la seule façon possible, à savoir passer à l'action).
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Michaël (site web personnel) . Évalué à 4.
Je fais autant de fautes de frappe en OCaml qu'en Python. Dans le premier langage, elles sont trouvées par le compilateur, dans le second, elles ne le sont pas.
Tu parles de quoi?
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Cette remarque ne t'était pas forcément destinée. Mais un certain nombre de techos affirment qu'ils pourraient très bien faire des logiciels qui poutrent, être 10 fois plus productifs, si seulement les imbéciles de décideurs prenaient le risque de leur faire confiance (et je suis d'accord hein, les dirigeants n'y connaissent souvent pas grand chose en technique, ils savent juste ce qu'est la vente). Sauf que parmi ces techos justement, très peu iront se mettre en danger justement, et continueront à faire ce que les décideurs leur disent de faire ; comme quoi il n'y a pas que les décideurs qui n'aiment pas les risques, c'est assez naturel en fait.
Pou caricaturer, je dirais qu'aux USA des techos montent leur boite, en France ce sont les commerciaux qui le font.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 2.
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…
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"(la représentation des données est beaucoup plus compacte qu'en Java ou Python)"
Et pourtant, c'est un paquet de pointeur et d'indirection, j'aimerais pas voir la tête du layout mémoire Java ou Python.
"le compilateur génère du code natif efficace"
Il est très bien placé dans le shoutout, mais il a pourtant pas mal de marge d'amélioration.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par lendemain . Évalué à 0.
d'après le shootout haskell et scala ne sont pas loin dérrière.
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ghc&lang2=ocaml
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=sbcl&lang2=ocaml
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=scala&lang2=ocaml
On peut se demander si le shootout est basé sur la vm ou du code natif?
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Firwen (site web personnel) . Évalué à 2.
Les lignes de commandes utilisées sont affichés dans le shootout.
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….
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 3.
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.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il "suffirait de fournir un fork() portable + une lib de message qui fonctionne sans copie.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Firwen (site web personnel) . Évalué à 2.
Sauf qu'un fork est peut être parfait et "sûr" en théorie, mais il a un coût de création élevé en pratique, spécialement comparé à une pool de threads.
Le cout qu'impose une creation de processus rend la parallélisation de petite portion de code complémentement inutile en pratique….
Et je ne parle même pas du cout du "messaging" par pipe…
Ce n'est pas pour rien que des langages orienté "concurrency" avec des routines "light" fleurissent sur la toile….
A titre de comparaison, Erlang support le SMP dans son threading léger depuis les années 2000 si ma mémoire est bonne….
En OCaml, on a l'immutabilité par défaut, sans aucun avantage de l'immutabilité par défaut…
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Comme pour un pool de thread, il est possible de faire un pre-fork.
La parallélisation de petite zone de code en thread est également inutile en pratique à cause de la gestion des caches.
Erlang ne supporte pas le multicore, ces thread sont des threads léger comme lwp. (Et je ne parle pas de performance.) Je ne sais toujours pas si il supporte le mutli-coeur actuellement.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Depuis quelques années (mais c'est pas hyper vieux non plus), la VM Erlang gère le SMP ; je ne connais pas la politique exacte des threads, mais j'imagine que c'est un pool de threads, avec un thread par core, et comme tu dis des threads légers par dessus (vu qu'Erlang encourage la création de dizaines de 'processus erlang', ça serait bête de créer un thread système pour chacun). J'imagine qu'avant il fallait lancer une VM par core 'à la main' pour exploiter son hard au maximum.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je ne suis pas sûr que cela soit bête. Les pthreads linux ont fait le choix de faire un thread pour thread noyau. Cela évite d'avoir 2 schedulers qui se battent pour gérer les ressources et cela permet d'avoir le soutien du système mémoire, qui gère le "false sharing" et autre subtilité.
Il me semble que Linux peut gérer 100 000 threads sans soucis autre que l'allocation de la mémoire pour la pile (en 32 bits).
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Firwen (site web personnel) . Évalué à 2.
Un pré-fork impose d'avoir un context "out-of-date" au moment de ou le processus forké va être utilisé, donc impose une transmission du context "courant/maitre", donc impose encore un overhead supplémentaire.
Si on a inventé les processus légers, ce n'est pas juste pour emmerder les gens qui font de la preuve logiciel et de la sécurité logiciel.
Et fait est que OCaml a un support relativemement mauvais du multi-thread comparé à ses principaux concurrents ( Scala, Erlang et F# pour ne pas les citer ).
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il n'y a quand même rien de plus complexe que la programmation par thread. Ce genre de programme sont souvent truffé de bugs complexes. Cela n'est pas pour rien que des logiciels comme Chrome font marche arrière et utilise des processus.
Rien n'empêche l'utilisation de thread au lieu de processus, juste pour une implémentation de passage de message sans copie.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Michaël (site web personnel) . Évalué à 2.
Il me semblait qu'il était possible de partager de la mémoire entre un processus et son fils—n'est-ce plus le cas? ET de façon indirecte (par exemple mmappant un fichier dans les deux processus?)
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Non, ce qui est compliqué, c'est de gérer des locks, pas les threads en eux-mêmes. Il faut bien séparer les deux car il existe d'autres façons pour des threads de partager des données (communiquer par messages par exemple). Cf une présentation très intéressante sur le sujet : http://swtch.com/~rsc/talks/threads07/
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par claudex . Évalué à 3.
D'ailleurs la mémoire transactionnelle (qui arrive dans GCC par exemple) essaye de corriger ce problème.
« 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: Utilisation d'OCaml dans l'industrie
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 4.
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…).
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Ontologia (site web personnel) . Évalué à 4.
Le gros problème d'Haskell en production est l'impossibilité de prévoir la consommation mémoire.
J'ai des amis fan d'Haskell qui serait ravis de l'utiliser, mais ces points les bloquent, résultat, ils font du Scala.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Est-ce que des optimisations sont prévues, ou est-ce qu'au vue des ressources humaines ce n'est pas une priorité ?
Est-ce qu'utiliser LLVM pourrait améliorer les performances ? Ou est-ce que la majorité des optimisations devraient de toutes les façons avoir lieu au niveau du frontend (en évitant des copies par exemple) ?
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Ontologia (site web personnel) . Évalué à 4.
En gros l'INRIA ne veut plus trop investir dans OCaml, car ils ont peu à y gagner financièrement.
Et comme ils ont fortement tendance à être des buses en business, ils ont jamais su trouver un modèle.
Je crois que OCaml, c'est 2 jour.homme par mois avec la priorité de corriger les bugs et d'avancer dans le système de type.
A leur décharge, c'est très dur de gagner de l'argent avec un langage.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Utiliser LLVM doit revenir à réécrire le compilateur, ce n'est pas une priorité à mon avis.
De plus, l'utilisation d'un GC oblige a avoir une gestion très fine de tous les pointeurs. C'est pour cela que c'est très difficile de faire un langage avec GC qui passe par l'intermédiaire du C.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 2.
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 !).
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Peut-être que tu bosses beaucoup au lieu de mouler :) , mais si, le GIL est un défaut de Python souvent cité (sur LinuxFR par exemple). Même pour les gens qui aiment Python, comme moi, oui c'est clairement un défaut. Ce n'est pas pour rien qu'il y a :
Oui entièrement d'accord. Ce n'est surement pas le genre de trucs qui motive les gens de l'INRIA, mais il faudra en passer par là pour populariser Ocaml.
En fait ma question sur les performances, notamment ce qu'il faudrait améliorer, était plus de la curiosité technique qu'autre chose. Tu ne réponds pas à cette partie, mais si tu ne sais pas trop ce n'est pas grave (alors que pour Python c'est assez facile de comprendre ce qui est lent), je profitais juste de la chance de parler à quelqu'un qui met les mains dans le cœur d'Ocaml.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Les performances moyennes que l'on peut obtenir d'un langage n'est pas une caractéristique comme les autres. Il est souvent question de savoir si cela va passer ou pas, pour l'application finale avant même de commencer à coder. C'est l'inverse du processus habituel qui consiste à optimiser en phase finale de développement, après mesure des performances.
Je reste persuader que si un langage de plus haut niveau que le C, qui permet donc de développer plus vite un produit final et qui dans le même temps garantie une performance (en temps et en espace mémoire) supérieur la plus part du temps, aura un grand succès, quel que soit les outils de développement disponibles. Il existe un tas d'application demandeuse de performance (jeux, multimedia, temps réel, voir application serveur.) pour faire décoller le langage.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . Évalué à -1.
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 ! :)
Parce que les meilleurs lignes de code c'est aussi bien souvent celles qu'on écrit pas, aussi faciles soient elle à écrire.
Ocsigen semble donc aller dans la bonne direction, et sera encore plus convaincant quand de belles webapp libres et incontournables l'utiliseront (je n'ai n'ai rien vu de tel sur le site d'Ocsigen, fort joli au demeurant).
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 3.
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)
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.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Ok, enchanté et bravo !
Les torts sont partagés on va dire : je ne savais pas que Xen-Api était libre (je ne le connais même pas à vrai dire), mais en l’occurrence ça m'a l'air d'être un peu l'exception parmi tes super applis industrielles que tu citais en premier. Et c'est bien d'elles dont je parlais ("si dans le lot il y a avait des […]" ) ; parce que sinon, oui je sais qu'il y a des applications libres en Ocaml. Mais justement ce n'est pas forcément celles que tu cites pour convaincre qu'Ocaml c'est bien. Et pour cause, ce sont de 'petites' applications (cela n'a rien de péjoratif hein).
Donc je persiste, ça serait bien si il y avait plus de grosses briques à la fois libres et réussites industrielles en Ocaml. Par exemple en Java[*], même si ça va servir malheureusement à faire principalement des applications métiers proprios (mais ce n'est pas la question), il existe tout un tas de grosses briques libres qui font référence et rare sont les applications java qui n'en utilisent aucune.
[*] et je ne fais pas la promotion de Java, moi je suis principalement Pythoniste.
Alors je développe. Si un logiciel remplit mon besoin à 95%, je vais sûrement le modifier pour obtenir les 5% restants (et ce même s'il est écrit dans un langage vraiment tout pourri) plutôt que le réécrire depuis zéro an Ocaml, malgré toute la puissance de ce langage (d'où les 95% de lignes "qu'on n'a pas écrites").
Donc j'espère qu'Ocsigen sera une de ces briques libres de référence. Mais j'attends que des webapps reconnues l'utilisent ; les meilleurs frameworks ne sont devenus ce qu'ils sont que parce qu'ils étaient réellement utilisés par des tas d'applis qui les ont éprouvés. Voilà pourquoi je cherchais une section sur le site d'Ocsigen listant les utilisations de ce dernier.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Fabrice Le Fessant (site web personnel) . Évalué à 4.
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).
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . Évalué à 0.
OK, merci pour les précisions. En tout cas je serais ravi de lire une dépêche présentant ces softs libres (et je ne pense pas être le seul), ça éduquerait les geeks incultes que nous sommes. :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.