vendredi 03 octobre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Infos Locales

Liens connexes

Gulliver (293 hits)
MCE (168 hits)
Plan pour venir (121 hits)
OCaml (443 hits)

Dépêche modérée par

Ragnagna

Dépêche éditée par

pterjan

Infos Locales : Présentation d'OCaml à Rennes le jeudi 7 avril, 20h, MCE, 48 bd Magenta

Posté par David Mentré (page perso, ). Modéré le 06 avril 2005.

Un membre de Gulliver (ma pomme) fera une présentation du langage de programmation OCaml le jeudi 7 avril, à 20h à la MCE de Rennes, 48 boulevard Magenta.

Titre de l'exposé : OCaml: pourquoi c'est (presque ;-) le meilleur langage du monde.

Comme on peut le deviner, l'exposé sera parfaitement objectif. :) Plus sérieusement, j'essayerai de présenter les points forts et faibles de cet excellent langage.

Gulliver (293 hits)
MCE (168 hits)
Plan pour venir (121 hits)
OCaml (443 hits)

> Lire les commentaires (57 commentaires, moyenne: 1,8).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Pérénité

Posté par Sytoka Modon (page perso, ) le 06/04/2005 à 08:33. (lien). Évalué à 3.

J'aurais deux petites questions :

- Pérennité du langage ? Je me souviens d'un super langage (Sather) qui est mort, si je me souviens bien, parce qu'on a coupé les crédits à l'équipe universitaire qui le développait. Quid de OCaml à l'INRIA ? Et dans la même veine, quel est l'intérêt pour l'INRIA de développer OCaml ?

- Autre aspect, la grande force de Perl (et de TeX) est à mon avis le CPAN. Pas besoin de chercher midi à quatorze heure, tout est sur le CPAN. Je ne comprends pas pourquoi les autres langages ne font pas de même. Ce n'est pas la place disque et un serveur qui doivent manquer à l'INRIA. Je sais qu'il y a un embryon de base commune pour OCaml mais ca n'a rien à voir avec un CPAN où tous les fichiers sont sur le même serveur.

A mon humble avis, l'absence d'un équivalent CPAN est rédhibitoire. Certes, des langages comme Python ou php se développe mais c'est "grâce" au lacune de Perl ;-)

[^]Re: Pérénité

Posté par nardzir () le 06/04/2005 à 09:21. (lien). Évalué à 1.
Pérennité du langage ?
"Il est développé et distribué par l'INRIA depuis 1985."
donc 20 ans cette année ... La communauté existe et les applications developpées en caml sont assez nombreuses (une petite recherche sur le web pour t'en convaincre). De plus il est beaucoup utilisé par l'enseignement en informatique. A titre d'exemple mldonkey est ecrit en caml.

Pour le CPAN, je te repondrais simplement que la distribution complete de caml contient deja presque tout. Si tu y ajoutes la documentation tres bien faite, tu obtiens un environnement de developpement tres complet. Mais c'est vrai qu'une base equivalente serait un veritable plus.
- [^]Re: Pérénité
  
  Posté par Croconux () le 06/04/2005 à 14:23. (lien). Évalué à 1.
  donc 20 ans cette année
  OCaml a fait assez peu parler de lui en 20 ans, un peu comme hurd dirons certains...
  
  La communauté existe et les applications developpées en caml sont assez nombreuses
  Je n'en ai pas trouvé beaucoup. C'est sans doute du au fait que Caml oblige à penser différemment. C++, Java, C#, tout ça se ressemble. Quand on a touché à l'un on passe sans problème à un autre langage. Caml est vraiment différent. La façon de coder ressemble plus à un énoncé mathématique. Les matheux purs adorent, les informaticiens n'arrivent pas à s'y faire. En général quand on cherche à sortir un truc sensé changer la face du monde mais totalement différent de tout ce qui existe on se prend un bide.
  
  De plus il est beaucoup utilisé par l'enseignement en informatique
  C'est à peu près le seul endroit ou j'ai pu croiser du Caml. Et encore, j'ai eu des profs de l'Inria...
  - [^]Re: Pérénité
    
    Posté par gph () le 06/04/2005 à 15:10. (lien). Évalué à 1.
    OCaml a fait assez peu parler de lui en 20 ans, un peu comme hurd dirons certains...
    Tu as vu ca ou?
    
    Moi j'avais lu de très bon compartif avec d'autres langages (enfin implémentation) sur Ocaml.
    
    Je n'en ai pas trouvé beaucoup. C'est sans doute du au fait que Caml oblige à penser différemment. C++, Java, C#, tout ça se ressemble
    Oui c'est comme programmer en Java t'oblige à penser différemment que programmer en C (objets vs impératif pur.)
    
    Les matheux purs adorent, les informaticiens n'arrivent pas à s'y faire. En général quand on cherche à sortir un truc sensé changer la face du monde mais totalement différent de tout ce qui existe on se prend un bide.
    Je ne suis pas d'accord du tout avec toi, les informaticiens adorent. En tout cas les gens qui font de la recherche en informatique ont tendance à aimer ce langage. De plus comme tu le dis le langage étant assez proche des mathèmatiques, ce qui est pratique pour les chercheurs: ça permet de mettre en oeuvre facilement leurs solutions.
    
    Je vais prendre un exemple: je suis élève à l'ENAC, et au labos d'informatique de l'école, tout est developpé en OCaml. Ca va de programme de simulation de trafic et de résolution de conflit, à un drone écrit par deux personnes de l'ENAC en partie en OCaml.
    
    C'est sur que c'est un langage moins utilisé que le C, mais il est performant et convient très bien au besoin de chercheurs, donc je pense qu'il n'est pas pret de partir à la trappe comme tu sembles le dire.
  - [^]Re: Pérénité
    
    Posté par fmaz fmaz () le 06/04/2005 à 19:01. (lien). Évalué à 3.
    C'est drole, en maîtrise, j'ai eu un projet compil à faire.
    Pas le choix, c'était OCAML imposé. Il y a eu un tolé général:« c'est
    quoi ce langage que personne ne connait! Nous, on veut être
    crédible au près des boites, on veut du C++, du JAVA... »
    La prof a tenu bon. Trois mois plus tard, quasiment toute le module
    trouvait qu'OCAML roxositationnait des maman ou et même des papa
    ours, ta mère en short.
    
    OCAML est vraiment un bon langage. Son principal problème est
    fonctionnel et que les informaticiens sont plus habitué au paradigme
    impératif. Ceci dit, c'est justement très bien qu'on impose ce genre
    de langage dans les cursus universitaires. C'est beaucoup plus
    important pour former un gars polyvalent que de lui apprendre
    C, C++, Java, Basic, Pascal, Cobol...
    - [^]Re: Pérénité
      
      Posté par Stéphane TRAUMAT (page perso, ) le 06/04/2005 à 20:04. (lien). Évalué à 3.
      Je suis pas d'accord.. j'ai fait un peu de ocaml... et en fait, ca m'a jamais vraiment servi chez mes clients ou dans les boites ou j'ai bossé.. par contre, connaitre C++ à fond te permet d'aborder tous les langages sans problème!
      
      Sauf le perl... ca j'y arrive pas.. Mais ca doit etre un truc dans mes genes
      - [^]Re: Pérénité
        
        Posté par fmaz fmaz () le 06/04/2005 à 21:06. (lien). Évalué à 2.
        Ce que je veux dire, c'est que si tu connais à fond 1 langage
        impératif (par exemple le C), tu peux rapidement être opérationnel
        sur n'importe quel langage impératif.
        La situation est semblable avec les autres paradigmes de
        programmation.
        
        De ce point de vue, je pense qu'il est bien de montrer à des étudiants
        qu'il existe des langages fonctionnels, logiques, à poil raz.
        
        Messieurs Turing et Church étant passé par là, on peut tout faire en
        COBOL. Ceci dit, il peut être intelligent de ne pas TOUT faire en COBOL
        (même si on adore COBOL et qu'on le connait par coeur).
        
        Par exemple, un langage fonctionnel comme OCAML est très pratique
        pour écrire un interpréteur ou un compilo.
      - [^]Re: Pérénité
        
        Posté par Philippe Fremy (page perso, ) le 07/04/2005 à 14:18. (lien). Évalué à 2.
        Le fait d'avoir fait une incursion dans un autre paradigme de programmation te permettra d'avoir plus de solutions dans ta boite a outils du programmeur. Tu verras qu'un jour, ca fera la difference chez un client.
        
        Genre un jour, tu vas tomber sur un projet. Tu vas commencer a te prendre la tete avec des objets et de l'heritage et tout d'un coup, l'illumation te viendra: c'est un probleme qui doit se resoudre avec une approche beaucoup plus fonctionelle. Meme si tu codes au final la solution en C++, tu utiliseras des techniques de programmation fonctionelle qui te donneront une solution plus elegante qu'une solution en style objet.
        
        C'est pour ca que c'est important d'avoir touche a OCaml.
        
        Si tu vas voir la page du "Great Language Shootout", tu verras que OCaml a le meilleur score dans de nombreuses configurations.
        
        Meme si je n'en ai pas fait beaucoup, ce que j'ai aime dans ce langage, c'est l'inference de type. Alors que python introduit des bugs subtils et indectables par sa resolution dynamique des attributs, OCaml a une approche hyper clean qui te permet de trouver des problemes subtils tres tot dans le cycle de dev. Et surtout, il ne te force pas la main sur les types (contrairement au C++ ou a Ada ou tu dois vraiment _tout_ dire) mais se debrouille lui-meme pour deduire des infos que tu lui as fourni, les types qui sont utilises.
        
        --
        phil.freehackers.org
    - [^]Re: Pérénité
      
      Posté par reno () le 07/04/2005 à 05:59. (lien). Évalué à 2.
      Maintenant quand tu arrives dans une boite et que tu n'es pas capable de faire du C ou du C++ propre car tu ne l'as pas suffisamment utilisé, cela ne va pas être très bien vu..
      
      OCaml a aussi un probleme de syntaxe: par défaut sa syntaxe est assez pourri..
      J'avais essayé d'apprendre ce language, mais j'ai abandonné car Ocaml c'est quand même assez bof-bof au niveau syntaxe.
      
      Je ne dois pas être le seul a leur avoir fait la remarque, apparemment il y a une syntaxe "alternative" possible, mais j'ai découvert Ruby entre temps et je n'ai donc pas regarder à quoi ça correspond..
      - [^]Re: Pérénité
        
        Posté par nardzir () le 07/04/2005 à 08:00. (lien). Évalué à 1.
        Je ne vois pas ce que tu reproches a la syntaxe d'OCaml ??? Au contraire je la trouve tres clair. Enfin bon les gouts et les couleurs ;)
      - [^]Re: Pérénité
        
        Posté par nardzir () le 07/04/2005 à 08:06. (lien). Évalué à 2.
        Maintenant quand tu arrives dans une boite et que tu n'es pas capable de faire du C ou du C++ propre car tu ne l'as pas suffisamment utilisé, cela ne va pas être très bien vu..
        Je connais des craques en C qui ont mis plusieurs semaines a ecrire un interpreteur alors qu'avec des langages de plus haut niveau (dont Caml, mais aussi ruby, prolog voir meme perl ou python) cela ne leur aurait pris que quelques heures ...
        
        Je pense que tu confonds deux choses : La connaissance d'un langage et la connaissance de paradigmes. Cela ne sert strictement a rien de passer sa scolarité a apprendre un langage particulier sous pretexte que c'est ce langage qui est utilisé dans l'industrie. Au contraire, mieux vaut survoler a peu pres tous les langages. Cela te donnera une ouverture d'esprit et te permettras de faire les bons choix.
        
        A titre d'exemple je n'ai eu que 1 mois de TP sur le C et un cours sur le C++. Cela ne ma pas empeché de faire des stages et plus tard d'etre employé par des sociétés ne developpant que dans ces langages.
        
        [^]Re: Pérénité
        
        Posté par Philippe Fremy (page perso, ) le 07/04/2005 à 14:21. (lien). Évalué à 1.
        Je suis d'accord avec toi, mais il ne faut pas tomber dans l'exces inverse: des gens qui n'ont que survole les langages et qui les connaissent mal.
        
        Si tu n'as fait que survoler du C++, j'espere que quand tu as commence ton stage, tu t'es achete un bon bouquin et tu as comble tes lacunes.
        
        Pour citer un exemple, j'ai fait passer des entretiens a des stagiaires qui avaient fait du C++ mais pas de C, ou bien du C++ mais pas de pointeurs. Ca me parait tres tres limite et je ne comprends pas trop le raisonnement de leur prof. Si ils veulent leur eviter les pointeurs, qu'il leur fassent faire du Java.
        
        --
        phil.freehackers.org
        
        [^]Re: Pérénité
        
        Posté par reno () le 07/04/2005 à 18:58. (lien). Évalué à 1.
        Oui, enfin survoler pas trop vite quand même: le petit jeune prestataire pour ma boite s'est trompé dans des histoires d'alignements mémoire, ne vérifie pas systèmatiquement les codes retour des fonctions de libraire, utilise sprintf plutôt que snprintf, etc..
        
        Survoler un language, c'est bien, je l'ai fait aussi (Lisp, Prolog) à l'époque mais il vaut quand même se batir une "culture" sur un language utilisé: je n'ai jamais utilisé ni Lisp, ni Prolog, et je ne pense pas jamais les utiliser alors à part savoir qu'ils existent bof..
        
        Pour ce qui est d'écrire des interpréteurs en C, je l'ai fait aussi, pourquoi?
        Je n'avais pas le choix du language! Donc les languages exotiques, c'est bien, mais ça reste peu connu et donc peu utilisable.
        
        Dans mon projet actuel, j'ai bien essayé de vendre Ruby, mais trop peu répandu --> shell + C.

[^]Re: Pérénité

Posté par champi (page perso, ) le 06/04/2005 à 09:49. (lien). Évalué à 2.

A mon humble avis, l'absence d'un équivalent CPAN est rédhibitoire.

Je ne connais pas bien CPAN donc je ne peux pas te dire si c'est equivalent mais il existe une distribution source et cross plateforme (Linux, Solaris, FreeBSD, NetBSD, Cygwin, HP-UX, MacOS X) de OCaml et de ses principales bibliothèques : GODI

http://godi.ocaml-programming.de/(...)

Ca marche super bien. C'est basé sur le système des ports bsd. Y a deja pas mal de paquets dispo mais de nouveaux packagers sont les bienvenus.

http://godi.ocaml-programming.de/toc/toc-3.08.html(...)

Si on ne veut pas passer par GODI, debian/ubuntu est de loin la meilleur distrib en terme de pacquets pour OCaml.
- [^]Re: Pérénité
  
  Posté par Sytoka Modon (page perso, ) le 06/04/2005 à 12:31. (lien). Évalué à 2.
  Il faut aller sur le CPAN de Perl pour comprendre (ou le CTAN de TeX)
  
  http://www.cpan.org/
  
  C'est pas du tout pareil que le reste. Il y a TOUT, tout et tout. Tout le monde peut mettre son module, ses sources. Bref TOUT.
  
  Dans les autres langages, il faut aller piocher ici ou là les infos. Les sites web vont et viennent, les versions aussi. C'est pas fiable en général.
  
  On me dis que la distribution OCaml a déjà beaucoup de chose, je suis d'accord. En pratique, il manque toujours quelques choses ;-) Là est l'intérêt d'un CPAN, toute nouvelle classe, module, bibliotheque... faisant partie d'un programme peut y être intégré dans l'espace de nom commun à tout le monde et être utilisé par la suite par d'autres projets.
  
  Le CPAN, c'est quelques "main" et des milliers de modules. C'est relativement anarchique : un espace de nom est affecte au premier qui le prend mais n'importe qui peut le completer. En pratique, cela marche tres bien et les bons modules ont des espaces de nom tout a fait correct.

[^]Re: Pérénité

Posté par Nicolas Chapin (page perso, ) le 06/04/2005 à 10:17. (lien). Évalué à 1.
"Certes, des langages comme Python ou php se développe mais c'est "grâce" au lacune de Perl "

Un langage se développe principalement par l'effet marketing (voir Java et .Net) et le fait que les programmeurs ne veulent pas sortir de leur zone de confort.

Mais dans une vrai approche d'ingéneirie on défini d'abord ce que l'on veut (Le besoin et les contraintes ) et comment on va le faire (la technique) et le langage utilisé doit donc être choisi en fonction:
* du besoin qu'il adresse (PHP permet de créer rapidement et facilement des sites dynamiques, C est proche du matériel donc convient pour le développement Système, Erlang pour de la forte concurrence).
* La facilité et les métaphores qu'ils proposent (assembleur, procédural, objet, fonctionnel).
* Un framework puissant (CPAN pour perl, Bibliothèques C, package Java).

De ce point de vue OCaml est à mon avis l'un des meilleurs langages du moment:
* C'est un langage de type fonctionel avec de jolis concepts
- Induction des types
- Fonctions d'ordre supérieur (on peut passer des fonctions en paramètres à des fonctions)
- Filtrage par motif
- j'en passe et des meilleurs
* Il y a un bon framework
* Il réponds à la pluspart des besoins

Un bonne example et celui de Paul Graham et de l'utilisation de Lisp pour coder un moteur de magazin online (Racheté depuis par Yahoo!):
http://www.paulgraham.com/avg.html(...)
- [^]Re: Pérénité
  
  Posté par Sytoka Modon (page perso, ) le 06/04/2005 à 12:43. (lien). Évalué à 1.
  Je suis d'accord avec toi. J'avais mis cette phrase pour conclure vite fait ;-)
  
  De plus, OCaml et Perl ne joue pas dans la même cour du tout... J'ai toujours entendus beaucoup de bien d'OCaml, et j'utilise l'excelent programme unison, mais je n'ai quand même pas l'impression qu'il décolle.
  
  J'entend aussi beaucoup de bien d'Haskell. Quelqu'un connais les + et les - des deux. Je crois que ce sont tous les deux des enfants de ML ?
  
  Enfin, contrairement à l'un des post ci-dessus, vu l'état de l'INRIA (et du CNRS et de toutes les EPST...), je n'ai pas absolument confiance dans sa pérennité. Si l'INRIA décidait d'arréter, cela gènerait'il vraiment beaucoup de monde ?
  
  Qu'est ce qui motive l'INRIA dans OCaml ?
  - [^]Haskell VS OCaml
    
    Posté par brouillon () le 06/04/2005 à 15:38. (lien). Évalué à 2.
    Si OCaml et Haskell possedent tous les deux un moteur de type à la ML
    leurs differences sont profondes.
    
    - OCaml est un langage fonctionnel à évaluation stricte et possède par la même occasion des traits impératifs. Le fait que celui-ci melange les deux approche, le rend particulierement agreable à utiliser, on a les avantages des fonctions d'ordre superieurs et du moteur d'inference de type avec la simplicité de la programmation impérative (que certains trouverons plus naturel et plus simple).
    
    - Haskell est un langage fonctionnel à évaluation paresseuse qui lui ne possede "aucun" aspect impératif. En theorie il ne possede donc aucune des caractéristiques presente sur une machine VonNeuman (pas d'allocation, pas de structure de controle de l'execution...). En cela on dit souvent que c'est un langage fonctionnel "pur". Ces aspects le rende assez difficile au premier abord, voir rebuterons même les plus motivés. C'est essenciellement un langage de recherche, même si il commence à être utilisable dans le cas d'application plus courante.
  - [^]Re: Pérénité
    
    Posté par David Mentré (page perso, ) le 06/04/2005 à 20:07. (lien). Évalué à 1.
    
    J'entend aussi beaucoup de bien d'Haskell. Quelqu'un connais les + et les - des deux. Je crois que ce sont tous les deux des enfants de ML ?
    
    Haskell fait du fonctionnel pure. C'est très séduisant car on peut raisonner sur les programmes. En pratique, Haskell est plus lent qu'OCaml, mais pas au point que ce soit inutilisable. Au niveau langage, chacun des deux a ses spécificités, après c'est à chaque programmeur de dire ce qu'il préfère.
    
    Qu'est ce qui motive l'INRIA dans OCaml ?
    
    Tu veux dire : qu'est qui motive les développeurs d'OCaml à continuer ? Ben c'est leur bébé. Et ces derniers temps, ça va plutôt bien pour OCaml. Evidemment, sur 30 ans, on ne sait pas si le langage sera toujours là. Mais dans 30 ans, fera-t-on toujours du Java ou du C ? (pour le C oui, vu le passif... :-)
  - [^]Re: Pérénité
    
    Posté par Ontologia (page perso, ) le 08/04/2005 à 17:49. (lien). Évalué à 2.
    Il faut savoir que les hautes instances de l'Inria considère que le projet Caml est un échec...
- [^]Re: Pérénité
  
  Posté par Stéphane TRAUMAT (page perso, ) le 06/04/2005 à 15:32. (lien). Évalué à 2.
  Euh est ce que java et .net se sont pas développés car ce sont de bons langages avec de solides plateformes ?
  
  Pkoi choisir ocaml plutot que Java ? est ce que j'ai mon hibernate, mon junit, mon struts... ?
  
  Comment j'attaque les bases du marché ? ldap ?
  
  Je ne crois pas que tout soit marketing
  - [^]Re: Pérénité
    
    Posté par Nicolas Chapin (page perso, ) le 07/04/2005 à 07:34. (lien). Évalué à 1.
    Qu'est ce qui est venu en premier?
    
    Java ou Hibernate?
    Java ou JUnit?
    Java ou Struts?
    
    Tout ces projets on été développé parce qu'en premier Java a bénéficié de la force de frappe marketing de Sun. Idem pour .Net
    
    Maintenant imagine que l'INRIA ait disposé de la même force et au lieu d'un langage apprécié seulement des universitaires et des hardcore hackers tu aurais une plateforme qui poutre les nounours (ce qui est déjà le cas, cf. caml humps) largement diffusée.
    
    Je n'ai pas dit que Java et C# (.net n'est pas un langage mais un framework) sont de mauvais langages (Quoique ... :) mais là on tombe dans le troll), mais grâce à la puissance de frappe de leur créateur, ils ont pu attirer une communauté qui a ensuite développé tout un framework autour.
    - [^]Re: Pérénité
      
      Posté par Stéphane TRAUMAT (page perso, ) le 07/04/2005 à 09:23. (lien). Évalué à 3.
      Je ne suis pas d'accord avec toi, si la force marketing etait si importante, la plupart des gens feraient du VB et du windev !
      Mais voila, un langage ne se juge pas qu'à ca.

[^]CPAN?

Posté par Tobu () le 06/04/2005 à 14:40. (lien). Évalué à 2.
En plus de GODI, il y a la bosse du chameau: http://caml.inria.fr//cgi-bin/hump.fr.cgi(...) .
Ce site regroupe par type, thème, license quelques centaines de bibliothèques, bindings, applications, extensions du langage avec les mises à jour.

A noter qu'il est dans la majorité des cas très facile de faire appel à des bibliothèques C: j'ai jeté un ½il aux bindings vorbis, chaque fonction C est enrobée en 5 à 10 lignes triviales pour avoir une fonction caml.
- [^]Re: CPAN?
  
  Posté par tgl () le 06/04/2005 à 16:08. (lien). Évalué à 3.
  > A noter qu'il est dans la majorité des cas très facile de faire appel à
  > des bibliothèques C: j'ai jeté un ½il aux bindings vorbis, chaque
  > fonction C est enrobée en 5 à 10 lignes triviales pour avoir une
  > fonction caml.
  
  OCaml fait aussi partie des langages de sortie de SWIG, et donc ces quelques lignes sont potentiellement générables de façon quasi automatique (même si les quelques bindings OCaml que j'ai croisé jusqu'ici ont plutôt l'air d'être écrits à la main).

transparents

Posté par hugo_lec () le 06/04/2005 à 08:37. (lien). Évalué à 3.

Super ! Malheureusement, je n'habite pas à Rennes. Est-ce que tu mettra tes transparents sur le net ?

[^]Re: transparents

Posté par David Mentré (page perso, ) le 06/04/2005 à 19:55. (lien). Évalué à 4.
Et hop ! Sources OOo, HTML et PDF :
http://www.linux-france.org/~dmentre/gulliver/expose-ocaml-2005-04-(...)
- [^]Re: transparents
  
  Posté par Lucas Bonnet () le 07/04/2005 à 05:47. (lien). Évalué à 1.
  Le .sxi me donne une erreur 403, mais le .pdf marche.
  
  Merci, je me contenterai du PDF pour aujourd'hui :)
- [^]Re: transparents
  
  Posté par Olivier Faurax (Jabber id, page perso, ) le 10/04/2005 à 00:53. (lien). Évalué à 1.
  correction :
  http://www.linux-france.org/~dmentre/gulliver/presentations/expose-ocaml-2005-04-07/
  
  --
  xmpp:ofaurax@jabber.fr

Lent ?

Posté par Nicolas Boulay () le 06/04/2005 à 16:03. (lien). Évalué à 1.

Pourquoi Ocaml est encore derrière le C en terme de vitesse ?

[^]Re: Lent ?

Posté par brouillon () le 06/04/2005 à 16:25. (lien). Évalué à 2.
Parceque le C est l'un des langages les plus proche de la machine après l'assembleur (je pense que le fortran est à placer entre les deux ) et qu'a ce titre il est l'un des plus apte à en tirer le meilleur parti celui de la machine.

Le revers de la médaille c'est que tu programme à très bas niveau et qu'a ce titre
tu a à te preoccuper de détail dont dans une très grande majorité des cas tu aimerai
ne pas avoir à gerer. Ainsi il ne faut pas s'etonner du nombre de buffer overflow
issue de certain programme en C (ou autre) par rapport à d'autre ecrit en Java.

Donc dire que OCaml est derrière le C en terme de vitesse n'est pas clair. Qu'est ce qui est plus rapide en C qu'en OCaml ? De mon avis, on est par exemple beaucoup plus rapide à ecrire un programme en OCaml qu'en C.
Et puis il suffit de gouter au systeme de typage à la ML pour comprendre le plaisir
que l'on peut avoir à coder en OCaml.

Si Ocaml est encore derriere le C en terme de performence dans le cas d'application
tres pointues, cest parceque par ailleur il offre un confort d'utilisation sans commune mesure vis a vis de celui ci, et que ce confort passe a travers l'utilisation d'un machine virtuelle qui naturellement prend des resources.
- [^]Re: Lent ?
  
  Posté par Nicolas Boulay () le 06/04/2005 à 18:11. (lien). Évalué à 2.
  Vu que le c est limite de l'assembleur, tu peux toujours optimiser à mort ton code. Le problème est que 1) c'est long, 2) le code devient totalement imbitable et imintenable.
  
  Pour la rapitdité de dev, je pense plus à perl qu'à ocaml :)
  
  Vu le niveau d'abstraction, le compilo d'ocaml pourrait faire des choses impossible ou difficile en C comme le controle du layout mémoire ou l'utilisation du SIMD.
  - [^]Re: Lent ?
    
    Posté par David Mentré (page perso, ) le 06/04/2005 à 20:23. (lien). Évalué à 1.
    
    Pour la rapitdité de dev, je pense plus à perl qu'à ocaml :)
    
    J'ai découvert OCaml en 2e année de thèse. A l'époque, je faisais un logiciel de traitement symbolique et je l'avais commencé en Perl. Au-delà de 1.000 lignes, Perl est une vraie daube(tm) : un cauchemar pour faire de la programmation claire (le moto : "y'a toujours un comportement par défaut" de Perl devient très vite ingérable. Le programme tourne mais ne fait jamais ce que l'on veut).
    
    J'ai commencé OCaml en lisant le bouquin de Leroy et Weis sur la plage, pendant mes vacances. En revenant, j'ai codé direct la nouvelle version : depuis, je suis un fan d'OCaml. Je trouve que mon code est clair, bien structuré et efficace. Et tu limites pas mal de bug par construction.
    
    Evidemment, pour un petit script de vérif de sortie de brochage d'un FPGA par rapport à un logiciel de CAO, je sort mon Perl. Mais dès que je veux faire un programme, c'est à dire quelque chose de structuré qui doit durer, je ne vois pas mieux qu'OCaml (suivant les cas, cf. mon exposé).
    
    Vu le niveau d'abstraction, le compilo d'ocaml pourrait faire des choses impossible ou difficile en C comme le controle du layout mémoire ou l'utilisation du SIMD.
    
    Si je me souviens bien, OCaml fait quelques siouxeries sur IA64. Quand au contrôle du layout mémoire, c'est LE point sur lequel je voudrais qu'OCaml progresse. Mais j'ai pas encore les idées claires sur ce qu'il faudrait faire.
    - [^]Re: Lent ?
      
      Posté par Nicolas Boulay () le 06/04/2005 à 20:41. (lien). Évalué à 2.
      Il faut abolir le modèle où l'acces à la mémoire est jugé à un coup uniforme, c'est complètement faux (de 1 à 150 !).
      
      La mémoire dispose d'un grand nombre de "multiple" (taille de write buffer, ligne de cache L1, L2, page mémoire de 4 ko et 4 Mo). On peut aussi tenir compte de l'associativité des caches et donc de l'aliasing des adresses mémoire dans les bits lsb d'adresses.
      
      Tu peux déjà aligner les adresses mémoires avec l'utilisation qui est en faite (genre trier les élements d'un struct en fonction de l'utilisation de ses champs). Jouer avec le preload et le prefetch pourrait aussi améliorer les choses. Et augmenter la localité d'acces.
    - [^]Re: Lent ?
      
      Posté par Nicolas Boulay () le 06/04/2005 à 20:54. (lien). Évalué à 2.
      pour le perl tu as fait du perl objet ?
      - [+] [^]Re: Lent ?
        
        Posté par Sebastien Tanguy (page perso, ) le 07/04/2005 à 19:15. (lien). Évalué à -2.
        Perl... objet... perl objet...
        
        AHAHAHAHAHAHAH
        
        C'est bon de rire parfois.
        
        Si c'est pour faire de l'objet, sans avoir à pousser le masochisme jusqu'à OCaml, il y a toujours Python et Ruby.
        
        seb.
        
        [^]Re: Lent ?
        
        Posté par Nicolas Boulay () le 08/04/2005 à 08:56. (lien). Évalué à 2.
        Je ne connais pas les facilités objet de python et ruby mais perl propose notament une facilité bien sympa : tu n'est pas obliger de créer une classe mère pour manipuler 2 objets semblable, il suffit que les methodes existent. Je trouve cela terrible.
        
        [^]Re: Lent ?
        
        Posté par Tobu () le 08/04/2005 à 17:39. (lien). Évalué à 3.
        Un aspect intéressant (unique?) de OCaml est la distinction entre sous-typage et héritage. D'une part on peut utiliser un point coloré comme point même s'ils ont été définis indépendamment et s'il n'y a pas d'héritage. Ce qui permet d'écrire:
        let print_obj a = Printf.printf "%s\n" a#to_string;;
        
        D'autre part on peut hériter de classe sans faire un sous-type de ces classes. Par exemple, on peut définir une classe «['a] clonable» avec une méthode clone de type unit -> 'a sans casser le système de types (autre exemple courant: une classe 'comparable').
        En java par example, la méthode est de type 'a -> object, et on est obligé d'utiliser un cast avec vérification dynamique du type et risque d'exception.
        
        Les deux gros avantages de ce typage entièrement statique, c'est qu'il n'y a pas de coût en perf (comme pour du C avec des cast statiques) et que l'on évite toute une catégorie de bugs (plus sûr que pas de vérification comme en C et qu'une vérification dynamique comme dans Java, python et les langages dynamiques en général).
        
        [^]Re: Lent ?
        
        Posté par Sebastien Tanguy (page perso, ) le 09/04/2005 à 13:55. (lien). Évalué à 0.
        Ce sont à chaque fois des langages objets à faible typage (ou du moins typage non déclaré) ce qui fait qu'on n'a juste à créer les bonnes méthodes. Ça fait une forme de polymorphisme à pas cher, mais ce n'est pas non plus tout ce qui définit un langage objet.
        
        Après, dans d'autres langages, on peut aussi passer outre. Typiquement, en Java il "suffit de" faire implémenter aux objets manipulés une interface particulière comprenant les méthodes communes. (l'avantage de cette situation est de permettre d'éviter d'éventuelles erreurs au runtime vu qu'en évitant les cast, on aura vérifié à la compilation les types).
        
        seb.

[^]Re: Lent ?

Posté par fmaz fmaz () le 06/04/2005 à 19:07. (lien). Évalué à 1.
Et pourquoi JAVA, c'est lent?

Faut comparer ce qui est comparable.
- [^]Re: Lent ?
  
  Posté par Nicolas Boulay () le 06/04/2005 à 20:01. (lien). Évalué à 2.
  C'est évidement comparrable.
  
  Java n'est pas compilé en code machine. tu ne peux pas prendre avoir la vitesse du C. Ce n'est pas le cas de Ocaml qui pourrait être plus rapide que le C. Et je ne vois vraiment pas pourquoi je me suis fait moinsé !
  - [^]Re: Lent ?
    
    Posté par fmaz fmaz () le 06/04/2005 à 21:11. (lien). Évalué à 1.
    À la base, OCAML est compilé vers une machine virtuelle.
    Ceci dit, je n'ai jamais essayé de faire tourner un prog compilé
    sur un i386 sur autre chose mais j'imagine que ça doit marcher
    sans problèmes.
    
    Maintenant, il existe des compilateurs spécifiques pour obtenir
    un code natif pour quelques architectures.
- [^]Re: Lent ?
  
  Posté par Stéphane TRAUMAT (page perso, ) le 06/04/2005 à 20:05. (lien). Évalué à 2.
  Et qui dit que java c'ets lent... vous etes lourd ;)

[^]Re: Lent ?

Posté par David Mentré (page perso, ) le 06/04/2005 à 20:13. (lien). Évalué à 1.

Pourquoi Ocaml est encore derrière le C en terme de vitesse ?

Parce que les développeurs d'OCaml ne cherchent pas à faire les super-optimisations de scheduling d'instruction qui permettraient de gratter les quelques cycles manquants en calcul numérique pur.

Parce que OCaml a quand même un ramasse miettes, et qu'il a un surcoût (léger certes, mais surcoût quand même).

Parce qu'un processeur est conçu pour exécuter du C et pas du OCaml. Mais ça ça changera quand on fera nos processeurs libres. ;-)
- [^]Re: Lent ?
  
  Posté par Nicolas Boulay () le 06/04/2005 à 20:45. (lien). Évalué à 3.
  Les processeurs actuelles faient pour faire du C, c'est une plaisanterie ?
  
  Les risc du début des années 80 étaient fait pour le C. Cela remonte un peu aujourd'hui hein...
  
  La croyance veut que l'on gagne qq cycles en optimisation. C'est faux. J'ai "étudié" le code de la multiplication matriciel en entier en C. Entre la version simple de 4 lignes, et la version imbitable de 100, il y a un rapport 4 de vitesses (+400%).
  - [^]Re: Lent ?
    
    Posté par Tobu () le 08/04/2005 à 17:50. (lien). Évalué à 3.
    Mais la version en 100 lignes utilise un meilleur algorithme (on passe d'un O(n^3) à O(2 et des poussières)).
    Pour les optimisations algorithmiques, le plus important est d'avoit un langage pratique et concis, pas un langage proche de la machine.
    - [^]Re: Lent ?
      
      Posté par Nicolas Boulay () le 08/04/2005 à 20:32. (lien). Évalué à 3.
      non non, je parle bien d'optimisation de codage, sinon cela n'aurait aucun sense.
      
      Je suis d'accord que la multiplication matriciel est un cas particulier mais quand même !
      
      Pour les optimisations algorithmiques, le plus important est d'avoit un langage pratique et concis, pas un langage proche de la machine.
      
      C'est évident ça. C'est ce que je dis au début. Mais pourquoi le langage ne peut pas rester clair et être performant ?
      
      La compilation du C a fait des progres mais des fonctionnalités du C rendent impossible tout une classe d'optimisation, notamment concernant le layout mémoire. Donc le Ocaml étant de plus haut niveau, il est plus facile d'optimiser, donc ocaml devrait produire du code plus rapide que le c.
      - [^]Re: Lent ?
        
        Posté par Tobu () le 09/04/2005 à 04:25. (lien). Évalué à 2.
        Pardon, c'est en effet une question intéressante.
        
        Avec le système de modules, les types ont une portée limitée, ce qui devrait laisser pas mal de libertés dans ce domaine: pas de contraintes de compatibilité binaire, et on peut faire une analyse du flot d'exécution.
        
        Dans l'idée de modifier aggressivement la gestion de la mémoire à partir d'une analyse statique, il y a ce papier: http://citeseer.ist.psu.edu/reynolds02separation.html(...) (et aussi http://pag.csail.mit.edu/reading-group/tofte94implementation.pdf).(...)
        Il mentionne la possibilité de passer la gestion mémoire en statique au lieu d'utiliser un ramasse miettes, ce qui à première vue est incompatible avec les langages fonctionnels. On gagne (un peu) en temps d'exécution du ramasse-miettes, et surtout on utilise moins de place, et on peut mieux tirer parti du cache processeur.
        
        Dans le même genre on parle d'étendre le système de types pour y intégrer une information d'état récupérée par analyse du flot - par exemple marquer qu'une fonction prend des types en accès-concurrent et renvoie le même type en lecture-seule.
        
        Plus concrètement, on peut améliorer certaines structures de données existantes dans des cas précis. Récemment on a une implémentation du module List (hyper utilisé) qui utilise des VListes: http://article.gmane.org/gmane.comp.lang.ocaml.lib.devel/1866(...)
        La performance mémoire est meilleure puisque l'on utilise des blocs adjacents de taille importante (la version originale utilisait huit blocs adjacents seulement). La performance en caclul est meilleure aussi puisqu'on fait disparaitre la distinction entre liste et tableau!
        
        [^]Re: Lent ?
        
        Posté par Nicolas Boulay () le 09/04/2005 à 23:55. (lien). Évalué à 2.
        Quand je parle layout mémoire, je ne pensais pas au ramasse miette mais à la représensation des données en mémoire réel.
        
        L'exemple typique c'est une grosse structure. Les doc AMD/intel préconnise de classé par ordre de taille décroissante les élements d'une structure. Pourquoi ? Parce que le compilo rajoute du padding pour s'aligner sur 32 bits si des char sont mélanger avec des int. La structure augmente donc de tailles. Mais à cause des compilations séparées, un compilo C ne peut pas réarranger l'ordre des éléments.
        
        J'avais fait le teste avec la librairy ffmpeg. Elle utilise une énorme structure à la base. Juste en modifiant l'ordre dans la structure j'avais gagné 2% de perf.
        
        Dans le même ordre d'idée, une fonction d'initialisation pourrait faire les affectations dans l'ordre mémoire de la structure et non l'ordre du code. etc...
        
        La maitrise du layout des données en mémoire permet aussi de pouvoir utiliser des instructions SIMD.
        
        Sinon, ta liste me fait furieusement penser à judy http://docs.hp.com/en/B6841-90001/ch01.html(...)
        En gros, c'est des arbres 256-aires plus des astuces pour stoquer des infos de types dans les 3 bits d'adresses non utilisé.
        
        [^]Re: Lent ?
        
        Posté par Tobu () le 11/04/2005 à 23:15. (lien). Évalué à 2.
        re Judy, ça fait un peu penser à un système de fichiers (un arbre avec des structures alternatives pour chaque n½ud). C'est bien comme hashtable.
        Les VListes sont moins sophistiquées, et adaptées aux listes et aux arrays. En particulier on peut partager un suffixe entre plusieurs listes, nécessaire pour les langages fontionels.
        
        Il y a un bon résumé des techniques d'optimisations liées au typage dans ce papier de Xavier Leroy: http://citeseer.ist.psu.edu/leroy98overview.html(...)
        
        Et plein d'articles ici: http://ropas.kaist.ac.kr/survey/tc/(...)
        
        [^]Re: Lent ?
        
        Posté par Nicolas Boulay () le 12/04/2005 à 07:45. (lien). Évalué à 2.
        judy est avant tout un "sparse array", un tableau avec des trous. Cela n'a absolument rien à voir avec des fonctions de hash vu que la structure est celle d'un arbre. Ils ont ensuite construit le reste par dessus.

Calcule numérique

Posté par salvaire () le 06/04/2005 à 17:06. (lien). Évalué à 2.

Quelqu'un a t'il expérimenté OCaml avec du calcule numérique? En effet, le ramasse miette réduit l'intervalle des nombres d'un bit, et le langage ne propose que entier ou flottant. Ces caractéristiques me semble handicapant pour ce type d'application. Sinon, c'est un langage intéressant.

[^]Re: Calcul numérique

Posté par kjus () le 06/04/2005 à 19:34. (lien). Évalué à 1.
Le langage propose plus que cela, il y a en effet un type int de 32 bits (ainsi que 64) , et on peut manipuler de base des entiers en précision arbitraire (types big_int et num et nat !)
http://caml.inria.fr/pub/docs/manual-caml-light/node18.html(...) , par exemple
- [^]Re: Calcul numérique
  
  Posté par salvaire () le 07/04/2005 à 11:03. (lien). Évalué à 2.
  Oui, mais les big_int et autre c'est pas sérieux pour des calcules consommant beaucoup de temps cpu rien quand float.

[^]Re: Calcul numérique

Posté par David Mentré (page perso, ) le 06/04/2005 à 20:01. (lien). Évalué à 2.
Pour le calcul scientifique (et donc numérique), un livre complet a été écrit sur le sujet :
http://www.ffconsultancy.com/products/ocaml_for_scientists/(...)

Sinon, son auteur a fait un email récent comparant OCaml à C++ sur x86 32 et 64 bits. OCaml n'est pas toujours le premier mais pas non plus le dernier. Et ne pas oublier qu'il n'y a pas de mémoire à gérer ! Rien que pour ça...

http://caml.inria.fr/pub/ml-archives/caml-list/2005/03/9aa5c15129d1(...)

OCaml# ?

Posté par TazForEver () le 06/04/2005 à 22:50. (lien). Évalué à 1.

est-ce qu'il existe des versions d'OCaml pour d'autres machines virtuelles ? Genre .Net/Mono ?

Un peu à la manière de Python/IronPython/Jython, etc.

Ça serait vraiment intéressant je pense.

D'ailleurs, quid de la portabilité ? je parle pas du coeur qui j'imagine est portable, je parle du reste, voir la partie GUI ? existe-t-il des bindings avec des bibliotèques type GTK+ ou tout le fatras de GNOME ?

J'ai bien aimé le coup de 'fais une recherche sur google' ... 'MLdonkey est écrit en OCaml' pour ne citer que lui, et bien presque ! Pour qu'un langage décole, j'ai quand même l'impression qu'il faut une killer-app pour attirer les développeurs. Et je ne parle de la qualité de MLdonkey, qui bouffe beaucoup de temps CPU. Et de mémoire (ça fuit terrible). D'ailleurs, debian propose à l'installation de redémarrer toutes les 24H mldonkey pour éviter une trop grande dégradation des performances...

[^]Re: OCaml# ?

Posté par Vivi (page perso, ) le 07/04/2005 à 12:13. (lien). Évalué à 1.
est-ce qu'il existe des versions d'OCaml pour d'autres machines virtuelles ? Genre .Net/Mono ?

il y a F#, une implémentation d'une partie du langage caml pour .NET :
http://research.microsoft.com/projects/ilx/fsharp.aspx(...)

il y a aussi ça : http://www.pps.jussieu.fr/~montela/ocamil/(...)

De manière générale c'est pas super car les autres machines virtuelles ne sont pas trés adaptées aux langages fonctionnels.

existe-t-il des bindings avec des bibliotèques type GTK+ ou tout le fatras de GNOME ?

LablGTK http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html(...) est une interface GTK+ avec des bouts d'autres choses (gnomecanvas, gnome-panel... ). C'est pas mal complet et utilisable.

il faut une killer-app pour attirer les développeurs
mouais, ça dépend aussi à quels développeurs tu t'adresses ... C'est sûr qu'il n'y a pas des masses de clients IRC en caml. Mais les killer-apps sont déjà là : OCaml est trés apprécié et utilisé dans la recherche sur les langages (voir Coq par exemple).

Revenir en haut de page

Articles précédents : Infos Locales

Liens connexes

Dépêche modérée par

Dépêche éditée par

Infos Locales : Présentation d'OCaml à Rennes le jeudi 7 avril, 20h, MCE, 48 bd Magenta

Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Haskell VS OCaml

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]Re: Pérénité

[^]CPAN?

[^]Re: CPAN?

transparents

[^]Re: transparents

[^]Re: transparents

[^]Re: transparents

Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[+] [^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

[^]Re: Lent ?

Calcule numérique

[^]Re: Calcul numérique

[^]Re: Calcul numérique

[^]Re: Calcul numérique

OCaml# ?

[^]Re: OCaml# ?