[^]Re: Tout bon!

• [^]Re: Tout bon!

  Posté par tontonflingueur () le 28/01/2007 à 12:56. (lien). Évalué à 4.

  
  Ocaml n'est toujours pas compatible GPL. De plus, c'est devenu un langage franco-français, d'universitaire, sans aucune application majeur (peut être mldonkey et encore...).
  

  
  
  Il y a aussi l'excellent Unison http://www.cis.upenn.edu/~bcpierce/unison/docs.html.

  • [^]Re: Tout bon!

    Posté par Sytoka Modon (page perso, ) le 28/01/2007 à 17:58. (lien). Évalué à 4.

    Qui n'est plus développé malheureusement depuis pas mal de temps et que personne n'a repris...
    
    Bref, c'est pas le meilleur exemple.
    
    Unison est un super programme mais il lui manque deux choses qui m'empêche dersomais de le déployer : une équipe de développement, une IHM pour le configurer, notament pour la partie Windows.

• [^]Re: Tout bon!

  Posté par Jakie Kasperwsky () le 28/01/2007 à 14:32. (lien). Évalué à 5.

  Ocaml n'est toujours pas compatible GPL.

  
  
  En quoi Ocaml n'est pas compatible GPL ?
  
  L'inria n'a rien loupé du tout. On utilise rarement un autre language de programmation quand on connaît bien Ocaml. C'est donc à prori une réussite. Après si personne ne veut l'utiliser dans l'industrie, je ne vois pas ce que l'Inria peut y faire. De plus c'est pas leurs problème, ils fournissent un language performant et bien documenté et leur travail s'arrête là. L'inria n'est pas une société de service et n'a pas de marketing à faire. Microsoft délivera bientôt une copie d'Ocaml avec F# qui elle marchera sans doute beaucoup mieux grâce au marketing de MS. C'est donc plutôt la faiblesse de la veille technologique et la peur de prise de risque dans le milieu de l'informatique industrielle qui explique sa faible utilisation en dehors des universités.

  • [^]Re: Tout bon!

    Posté par champi () le 28/01/2007 à 15:12. (lien). Évalué à 3.

    Le compilateur est sous license QPL il me semble qui n'est effectivement pas compatible GPL. C'est libre mais ca n'incite pas à la collaboration mais bon c'est probablement pas le plus gros problème
    
    La communauté des développeurs du compilateur OCaml n'a pas su organiser et motiver les contributeurs extérieurs pour faire une bibliothèque standard complète comme c'est le cas dans le monde python (batteries included) + l'index de package cheeseshop ou CPAN dans le monde perl. Résultat, il faut installer des libs externes à la main sans conventions de développement communes et ca ralentit énormement la diffusion du langage aussi bien dans les entreprises que chez les developpeurs independants.
    
    Dans le monde OCaml il y a tout de même l'initiative le systeme de packaging GODI mais il n'est pas mis en avant sur le site officiel. L'INRIA n'a probablement pas vocation a faire du marketing, mais les résultats de ses développement sur Objective Caml gagneraient énormément a être mis en avant par la structuration d'une communauté de contributeurs extérieurs comme c'est le cas des autres langages open source.

    • [^]Re: Tout bon!

      Posté par MrLapinot (Jabber id, page perso, ) le 28/01/2007 à 18:29. (lien). Évalué à 3.

      Résultat, il faut installer des libs externes à la main sans conventions de développement communes

      
      Et GODI, il pue des chaussettes ? Et ocamlfind, c'est pas une convention pour trouver toutes les libs automatiquement ?

      --
      Mr Lapinot - Electrons prisonniers (blog)

      • [^]Re: Tout bon!

        Posté par champi () le 28/01/2007 à 20:12. (lien). Évalué à 3.

        Relis mon commentaire : je dis juste que GODI / ocamlfind ne sont pas suffisamment mis en avant pour packager les libs OCaml : cherche le lien vers GODI sur la page d'accueil de ocaml.org et compare avec le python package index sur python.org et rubygem sur www.ruby-lang.org.
        
        Le problème du non décollage de OCaml n'est probablement pas technique, le langage est excellent mais culturel : il est très en recul par rapport aux autres langages en terme d'intégration des contributions de la communauté dans le processus de développement.
        
        Mais bon il faut reconnaitre que la situation s'améliore : il ya deux ans, il n'y avait même pas GODI et le site officiel était digne des pages perso du début du web :)

        • [^]Re: Tout bon!

          Posté par MrLapinot (Jabber id, page perso, ) le 29/01/2007 à 15:42. (lien). Évalué à 1.

          Désolé, j'avais complètement sauté la phrase sur GODI...

          --
          Mr Lapinot - Electrons prisonniers (blog)

  • [^]Re: Tout bon!

    Posté par gege (page perso, ) le 28/01/2007 à 15:14. (lien). Évalué à 2.

    
    Après si personne ne veut l'utiliser dans l'industrie, je ne vois pas ce que l'Inria peut y faire. L'inria n'est pas une société de service et n'a pas de marketing à faire.
    

    
    
    Je ne suis vraiment pas d'accord, l'INRIA pourra faire les plus belles avancées techno possible, c'est a elle d'aller les vendre à l'industrie et de convaincre les industriels. Il faut leur montrer que c'est pas des trucs fumeux de chercheurs sans vraiment de retour sur investissement visible et démontré. Sans cela ça restera dans les cartons de l'INRIA ou au mieux dans un marché de niche après la création d'une start-up sur la techno qui vivotera quelques années...
    
    Je pense que l'INRIA s'en rend de plus en plus compte et c'est tant mieux...
    
    

    
    C'est donc plutôt la faiblesse de la veille technologique et la peur de prise de risque dans le milieu de l'informatique industrielle qui explique sa faible utilisation en dehors des universités.
    

    
    
    Les entreprises prennent des risques quand elle peuvent les calculer et qu'on vient leur présenter des nouvelles idées bien présentées (avec une vision industrielle) et adaptées à leur besoins (eclipse, python, ...)
    
    

    
    Microsoft délivera bientôt une copie d'Ocaml avec F# qui elle marchera sans doute beaucoup mieux grâce au marketing de MS
    

    
    
    C'est avec des réactions comme la tienne que les américains vont encore faire d'une bonne idée française une affaire juteuse pour eux...

    • [^]Re: Tout bon!

      Posté par Gniarf () le 28/01/2007 à 15:26. (lien). Évalué à 2.

      >> Microsoft délivera bientôt une copie d'Ocaml avec F# qui elle marchera sans doute beaucoup mieux grâce au marketing de MS
      
      > C'est avec des réactions comme la tienne que les américains vont encore faire d'une bonne idée française une affaire juteuse pour eux...
      
      tu peux développer ? je ne vois pas la suite logique, là...

      --
      Windows has no users. It has hostages.

      • [^]Re: Tout bon!

        Posté par gege (page perso, ) le 28/01/2007 à 16:06. (lien). Évalué à 3.

        Tout simplement ils vont reprendre une idée, comprendre son potentiel, l'adapter au marché (joli éditeur, belle boite, support, buzz...) et gagner du fric avec... c'est pas de l'anti américanisme de base, mais simplement une constatation qu'ils sont très doués pour ça (exemple l'ADSL, techno developpée en france, c'est les US qui ont trouvé son utilité...) et qu'on ferait bien de les imiter...

      • [^]Re: Tout bon!

        Posté par Gabriel () le 28/01/2007 à 16:07. (lien). Évalué à 2.

        Son propos me paraît tout à fait logique et sensé, il est même plein de bon sens. Si l'INRIA est fier et content de son langage, il faudrait que ce soient des gens proches de l'Inria - des français- qui développent ces idées.
        
        On ne peut pas faire comme s'il n'y avait aucun rapport entre la Recherche et l'Industrie. Surtout dans le domaine de l'informatique. Dans ce domaine il y a une course à l'innovation entre les différents acteurs. Microsoft, apple, google, sun, hp etc. Tous sont à la pointe de la technologie dans un ou plusieurs secteurs d'activités.
        En informatique, l'innovation va de paire avec l'industrialisation.
        
        Il faut des gens et des idées qui vont de l'un à l'autre, que les idées soient concrétisées, que le concret valident les idées.
        Autre exemple: regardez Ruby, magnifique langage. Il a connu un grand essor quand:
        1- il est sorti de son premier cercle, à savoir son public japonaise.
        2- il a été utilisé et validé à plus grande echelle par RoR.
        cqfd.
        
        
        D'autant que c'est un cercle vertueux à construire. Les chercheurs alimentent les gens du secteur informatique, qui donnent des sous aux chercheurs etc.
        
        
        C'est comme si un écrivain écrivait les meilleurs livres du monde mais ne les publiait pas.
        Ou comme une belle fille qui reste à la maison et ne sort jamais. C'est dommage. Elle ne perdra aucune beauté à aller dehors.
        
        Maintenant la question subsidiaire est : qu'est-ce qu'on fait? On s'engueule ou on bosse?

        --
        Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying

        • [^]Re: Tout bon!

          Posté par Jakie Kasperwsky () le 28/01/2007 à 17:55. (lien). Évalué à 5.

          Personnelement je n'ai pas trop envie de payer sur mes impôts des milliers de fonctionnaires supplémentaires pour aller menacer les entreprises françaises avec un flingue sur la tempe pour qu'ils investissent dans leurs travaux avant que Microsoft ne rafle la mise. Les industriels français sont sensé vouloir gagner de l'argent.
          
          

          Maintenant la question subsidiaire est : qu'est-ce qu'on fait? On s'engueule ou on bosse?

          
          
          Il n'y a pas de secret, comment c'est developpé F# ? Pour un ancien doctorant de l'INRIA, Alcatel par exemple proposera un travail d'ingenieur là ou MS research, Google, Sun, Cisco proposera 6000 euros net par mois pour faire de la vrai R&D. Pour pallier à ce problème, l'INRIA offre un service de pépinnière d'entreprise qui marche plutôt bien.

        • [^]Re: Tout bon!

          Posté par Sytoka Modon (page perso, ) le 28/01/2007 à 18:02. (lien). Évalué à 2.

          Surtout que l'INRIA n'est pas le CNRS. Dans INRIA, il y a le A final qui signifie Appliqué.
          
          Bref, faire un CPAN pour OCaml est tout à fait à la portée de l'INRIA si celle-ci le voulait réellement. Depuis le nombre d'année qu'on le lui dis (idem Scilab, idem Lisaac), je me dis que l'INRIA n'est pas réellement motivé sur ces projets.
          
          C'est son droit mais c'est dommage quand même...

          • [^]Re: Tout bon!

            Posté par Vivi (page perso, ) le 28/01/2007 à 18:09. (lien). Évalué à 7.

            je lole. Le A dans INRIA signifie Automatique, par contre le R signifie bien Recherche.

            • [^]Re: Tout bon!

              Posté par Sytoka Modon (page perso, ) le 28/01/2007 à 20:23. (lien). Évalué à 2.

              /mea culpa/, dire que cela fait des années que je suis dans le faux ;-)

            • [^]Re: Tout bon!

              Posté par Aurélien Girard () le 29/01/2007 à 08:55. (lien). Évalué à 4.

              Ah bon ? J'étais persuadé que c'était l'Institut National de Recherche en Informatique Amusante ?
              
              ~~>[]

[^]Re: Tout bon!

• [^]Re: Tout bon!

  Posté par MiniMoi () le 28/01/2007 à 14:15. (lien). Évalué à 3.

  Je ne sais pas si ce genre de projet va passionner les foules...
  J'ai l'impression que les utilisateurs d'OCaml aiment la "belle" informatique, c'est-à-dire l'algorithmique sophistquée...
  Il est vrai que le langage rend des choses compliquées tellement plpus simples (dès qu'il s'agit de récursivité en particulier) et propres que ceci est logique. Mais d'un autre côté je ne suis pas fan de la syntaxe dès qu'il s'agit de faire des applications "réelles", et je crois que la plupart des programmeurs OCaml n'aimeront pas trop passer des mois sur des projets de bindings...

  • [+] [^]Re: Tout bon!

    Posté par Martyanoff Nicolas (Jabber id, page perso, ) le 28/01/2007 à 20:41. (lien). Évalué à -4.

    Disons surtout que comme à peu près tous les langages fonctionnels, sur les gros projets, ça devient vite illisible (à noter que des langages impératifs arrivent aussi à être illisibles, pas besoin de citer de nom), que les perfs sont à chier (ou alors aucun de mes profs ne sait coder en caml, gênant pour des spécialistes de ce langage), certaines structures sont abscons (obligé de mettre +. au lieu de + pour une addition flottante, c'est du jamais vu), et l'environnement de devel est pitoyable (je ne veux même plus compter le temps passé à mettre en place un bête fenêtre avec le binding SDL.
    
    Alors, oui, je sais, je suis un méchant pas bien qui critique les idées des informaticiens théoriques, mais ceux-ci seraient bien avisés de faire aussi un peu de pratique, histoire d'essayer de montrer que leurs créations ne sont pas du vent (mldonkey pue; unison est pas mal, mais ce n'est qu'une surcouche rsync et/ou ssh, donc bof (et en plus il est très lent, mais bon))

    • [^]Re: Tout bon!

      Posté par mouftard () le 28/01/2007 à 21:38. (lien). Évalué à 2.

      ça devient vite illisible

      
      
      Prouve le.
      
      

      les perfs sont à chier

      
      
      Idem.
      C'est pas ce qu'en dit http://www.ffconsultancy.com/free/ray_tracer/comparison.html par exemple.
      
      

      certaines structures sont abscons (obligé de mettre +. au lieu de + pour une addition flottante, c'est du jamais vu)

      
      
      Ça veut dire quoi, "certaines structures sont absconses" ?
      
      Et merci de ne pas généraliser à tous les langages fonctionnels une spécificité (un défaut ?) d'OCaml, ils ne sont pas tous typés statiquement et tous ne haïssent pas le polymorphisme ad-hoc (cf. typeclasses en Haskell).
      
      

      l'environnement de devel est pitoyable

      
      
      De quoi parles tu ? Emacs ? Vim ? Emacs + Caml-mode ? Emacs + Tuareg ? Camlwin (bwahahah) ?
      
      Mais je suis d'accord, il n'y a rien de très évolué... Toutefois ce n'est pas le seul langage ou les libristes se contentent du triptyque éditeur de texte + shell + make.
      
      As-tu essayé Cameleon2 (moi pas) http://gna.org/projects/cameleon/ ?

      • [^]Re: Tout bon!

        Posté par . . (page perso, ) le 29/01/2007 à 00:45. (lien). Évalué à 2.

        La syntaxe de caml n'est pas la meilleure, c'est la raison pour laquelle il existe des préprocesseurs tels que camlp4. J'utilise de préférence twt: http://people.csail.mit.edu/mikelin/ocaml+twt/ qui permet d'obtenir une syntaxe proche de celle de python. Meilleure lisibilité et typage fort, productivité accrue.

        • [^]Re: Tout bon!

          Posté par reno () le 29/01/2007 à 12:59. (lien). Évalué à 4.

          Comment veux-tu qu'un langage devienne populaire si même ceux qui aiment le langage utilisent des préprocesseurs??
          
          La syntaxe *par défaut* doit attirer les programmeurs, autrement il ne décollera jamais..

          • [^]Re: Tout bon!

            Posté par . . (page perso, ) le 29/01/2007 à 17:33. (lien). Évalué à 1.

            Premièrement, je n'ai aucun espoir qu'un langage devienne populaire (que ce soit caml ou autre) et deuxièmement la syntaxe par défaut est probablement le moindre des problèmes.
            
            Si l'on regarde sh (posix shell) par exemple, cela n'empêche pas 90% des gens de coder en bash et de s'imaginer faire du shell portable.
            
            Pour le cas de caml, il manque de nombreux exemples pour se mettre au langage, la création de bindings avec c/c++ paraît en particulier beaucoup plus difficile qu'avec python ce qui ne donne pas envie de s'y mettre. Autre exemple, l'absence de support pour les librairies partagées compilées (environnements type unix) limite l'intégration de programmes caml avec d'autres applications.
            
            Pour s'intéresser au language, il faut peut-être commencer à s'intéresser à ce qu'on peut faire avec celui-ci dès aujourd'hui (autres que MLDonkey):
            
            Le solveur d'équations de Kalzium est écrit en caml http://edu.kde.org/kalzium/screenshots.php (basé sur eqchem : http://freehackers.org/~tnagy/eqchem.html), ce composant n'a toujours pas pu être réécrit en c++ malgré les efforts de l'auteur de Kalzium (utilise le solveur de contraintes "Facile" http://www.recherche.enac.fr/opti/facile/)
            
            L'environnement de développement Coq peut permettre de s'ouvrir au domaine des preuves formelles.
            
            Tout n'est pas forcément bon à prendre, mais il y a énormément à apprendre.

            • [^]Re: Tout bon!

              Posté par reno () le 30/01/2007 à 07:02. (lien). Évalué à 1.

              Ton post est assez 'décousu' mais je vais essayer d'y répondre.
              
              >deuxièmement la syntaxe par défaut est probablement le moindre des problèmes.
              
              Et bien dans mon cas personnel, cela a suffit pour me dissuader d'apprendre caml. C'est en parti la syntaxe, en parti l'accent mis sur le coté fonctionnel dans le livre (alors que c'est "vendu" comme étant un langage mixte).
              
              Ceci dit, je ne suis pas totalement réfractaire au fonctionnel: Scala (mélange objet/fonctionnel) me paraît intéressant.
              
              Pour le shell, certes sa syntaxe n'est pas terrible, mais il répond a un besoin auquel les autres langages ne répond pas, c'est pour ça qu'on continue a s'en servir.
              
              Sinon je ne vois pas trop le rapport avec Coq, outil peut-être intéressant, mais vu le jargon obscur utilisé, je n'ai pas eu envie d'apprendre.

      • [^]Re: Tout bon!

        Posté par Gilles G. () le 29/01/2007 à 08:43. (lien). Évalué à 3.

        Pour les perfs, je préfère le site shootout de chez debian, qui me paraît nettement plus neutre.
        Pour la comparaison avec C, c'est ici:
        http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)
        Et pour la comparaison avec Java, c'est ici:
        http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)
        
        Et effectivement OCaml ne s'en sort pas trop mal.

        • [^]Re: Tout bon!

          Posté par ndesmoul () le 29/01/2007 à 12:05. (lien). Évalué à 3.

          Certes les perfs d'OCAML n'ont pas à rougir face au C. Même si elles étaient moins bonnes le langage resterait intéressant de par ses qualités intrinsèques (même si je suis jamais arrivé à me faire aux langages fonctionnels...).
          
          Attention cependant à ne pas prendre au pied de la lettre ces benchs notamment pour les perfs des langages utilisant une machine virtuelle (avec JIT et autres optimisations à la volée) comme Java et C#. On avait déjà parlé il y a quelques temps ici de cette page.
          Certains des bench s'exécutent en quelques secondes, sans prendre en compte ni le temps de démarrage de la machine virtuelle ni les optimisations faites comme la recompilation native du code à la volée. Contrairement à ce qui est prétendu sur le site, si le programme s'exécute en 3s l'impact est important.
          
          Je rajouterai que les compétences exprimées dans chaque langages ne sont pas forcément équivalentes. J'avais jetté un coup d'oeil sur un des programmes Java proposé et j'avais vu des choses qui ne me semblaient pas optimales (genre recopie d'un tableau case par case alors que souvent il vaut mieux faire un arraycopy). Il n'est pas impossible que la même chose puisse être observée avec les autres langages du panel.
          
          Enfin j'ignore si c'est le cas ici mais avec un langage objet haut niveau on va avoir tendance à batir un model objet qui sera plus lisible et plus facilement (ré-)utilisable mais que les compilateurs ont encore du mal à bien optimiser; alors qu'en C ce sera disons plus 'crade', presque illisible mais plus optimisée. (Il y a peut-être une différence de philosophie)
          
          Il n'est pas impossible que l'on obtienne de meilleures performances aux benchs, sur certains langages, en partant de la version C traduite au plus près vers le langage cible.
          
          A contrario un langage de haut niveau rendra peut-être plus facile l'implémentation d'un algorithme optimisée, alors que sera un casse tête en C.
          
          Tout ça pour dire que les benchs, mieux vaut ne pas y accorder une importance démesurée et programmer avec le langage que l'on préfère.
          
          (C'était le dicton du jour...)

        • [^]Re: Tout bon!

          Posté par neologix (page perso, ) le 30/01/2007 à 00:54. (lien). Évalué à 0.

          Ces benchmarks ne veulent pas dire grand' chose.
          Si d'un côté tu as un mec d'Ulm qui code en OCaml, et de l'autre côté un mec comme moi qui code en C, l'issue est évidente.
          Il ne faut pas oublier un truc, c'est que la plupart des gens qui codent en OCaml savent coder, et sont généralement très bons. Ce qui n'est pas le cas avec beaucoup d'autres langages.

          • [^]Re: Tout bon!

            Posté par Gilles G. () le 30/01/2007 à 07:52. (lien). Évalué à 2.

            Les premières lignes vues sur http://shootout.alioth.debian.org sont
            
            

            How can we benchmark a programming language?
            We can't - we benchmark programming language implementations.
            
            How can we benchmark language implementations?
            We can't - we measure particular programs.
            
            Use: these are particular truths, they are not general truths

            
            Sinon, lire la première question/réponse de la FAQ (http://shootout.alioth.debian.org/gp4/faq.php )
            
            Il ne faut pas oublier un truc, c'est que les languages permettent d'exprimer de différentes façons différents algorithmes, et que c'est le compilateur qui doit tirer parti de ce qui est exprimé par le language pour effectuer les optimisations. Ces benchmarks donnent une idée du degré d'information contenues dans le langage en vue de l'optimisation des performances.

    • [^]Re: Tout bon!

      Posté par petitdragon () le 28/01/2007 à 21:44. (lien). Évalué à 5.

      Pour avoir fait ou participé à de très gros projets en C, en Java, en PHP et en OCaml, je t'assure qu'il n'y a pas photo : les programmes Caml restent beaucoup plus clairs que les autres. Une raison essentielle : le code est beaucoup plus concis grâce à la syntaxe et l'inférence de type. Et puis quand tu fais des grosses modifs de tes programmes, ils continuent à tourner après, parce que le typage est bien fait. C'est quand même un gros avantage ! Et je ne suis pas un théoricien !
      
      Pour les perfs, c'est faux. OCaml est réputé pour être très efficace. Moins que C évidemment mais beaucoup plus que Java...
      
      L'histoire des +. c'est le problème que l'on rencontre au premier cours de caml mais quasiment plus jamais après donc bof. On ne va pas juger un langage là-dessus, surtout qu'il y a des raisons à ce choix.
      
      Ton deuxième argument sur les environnements de devt est bon par contre... Il n'y a à peu près rien à part emacs. Le module eclipse ne fonctionne pas bien, cameleon peut-être deviendra un jour bien ? (je n'ai pas essayé récemment).

      • [^]Re: Tout bon!

        Posté par Papa Furax (page perso, ) le 29/01/2007 à 09:43. (lien). Évalué à 2.

        Le +. c'est vrai que c'est pas terrible, mais on s'y fait vite, une fois le typage compris.
        
        Par contre de ce coté, je préfère nettement les classes de types à la Haskell. C'est plus joli (subjectif !), mais surtour ça permet un polymorphisme plus large: je vois ça un peu comme une définition d'interface, qu'on peut utiliser après comme type.

        • [^]Re: Tout bon!

          Posté par karteum59 () le 29/01/2007 à 11:59. (lien). Évalué à 1.

          Le +. c'est vrai que c'est pas terrible, mais on s'y fait vite, une fois le typage compris.

          OK, pour les entiers et les flottants je peux concevoir qu'on en accomode vite en pratique.
          
          Mais pour tout le reste : (par exemple si je veux faire une classe matrix) je suis obligé de faire des fonctions ad'hoc (matrix_add, matrix_mul, etc.) et on ne peut pas dire que ça aide la lisibilité... OK, c'est pareil en C, mais pas en C++ ni dans tous les langages un tant soi peu modernes !
          
          Maintenant, je peux concevoir que cette contrainte (absence de surcharge des opérateurs / fonctions) provienne du typage automatique et qu'il faille choisir entre les deux fonctionnalités. Mais... est-ce vraiment le cas ? Je veux dire : le compilateur n'est-il vraiment pas capable de regarder le type des arguments d'entrée pour déterminer s'il doit effectuer l'opération '+' pour les entiers, les flottants, les matrices... ?

          • [^]Re: Tout bon!

            Posté par fmaz fmaz () le 29/01/2007 à 12:07. (lien). Évalué à 2.

            Réponse un poil hors sujet, sur l'exemple que tu donnes, il suffit de passer les opérations (+, *) en paramètre à ton code.

            • [^]Re: Tout bon!

              Posté par Papa Furax (page perso, ) le 29/01/2007 à 12:30. (lien). Évalué à 2.

              Excact.
              Si j'en crois l'idée du poste, l'exmple avec matrice de flottant et matrice d'entier serait plus parlant.
              
              Au passage:
              http://en.wikibooks.org/wiki/Haskell/Class_declarations

          • [^]Re: Tout bon!

            Posté par Gniarf () le 29/01/2007 à 14:44. (lien). Évalué à 2.

            lisibilité ?
            
            j'aimerais bien voir ta tête quand tu vas devoir maintenir du code usant et abusant des opérateurs surchargés.
            
            parce que si tu as une jolie fonction matrix_add ou matrix_mul à un endroit dans ton code, tu pourras te douter de ce qui va être appellé. et tu pourras utiliser la recherche textuelle ou autre outil de ton IDE pour voir qui appelle matrix_add dans ton projet.
            
            mais un '+' ou un '*' surchargé, tintin.

            --
            Windows has no users. It has hostages.

          • [^]Re: Tout bon!

            Posté par MiniMoi () le 29/01/2007 à 21:58. (lien). Évalué à 2.

            Pour avoir eu un cours de typage détaillant l'algo d'inférence de types de Caml, je doute que ça soit possible de mettre à la fois la surcharge des opérateurs et la sureté du typage ensemble...
            
            En effet une des grandes force de Caml est que l'algorithme de typage est prouvé, et une fois qu'on voit comment il fonctionne en détail, on comprend le pourquoi du comment...
            
            En plus il faut mettre un bémol à cette non surcharge des opéraeurs : beaucoup de fonctions en Caml sont polymorphes, justement grâce à l'algo d'inférence des types, qui donne des types polymorphes dès qu'il peut (par ex si je parle de la fonction foobar : 'a -> 'b -> 'a je sais qu'elle prend n'importe quel type en premier argument, n'importe quel type en euxième argument et renvoie n'importe quel type, mais le premier, pas le deuxième ;)

            • [^]Re: Tout bon!

              Posté par reno () le 30/01/2007 à 09:27. (lien). Évalué à 1.

              >En effet une des grandes force de Caml est que l'algorithme de typage est prouvé
              
              Bof, la tête du programmeur, elle n'est pas prouvée elle..
              Dans les cas ambigu, je pense qu'il est préférable que l'algorithme d'inférence de type sorte une erreur a la compilation, après tout pour corriger il suffit de rendre explicite le type désiré.

              • [^]Re: Tout bon!

                Posté par Thomas Douillard () le 31/01/2007 à 12:51. (lien). Évalué à 3.

                Bof, la tête du programmeur, elle n'est pas prouvée elle..

                
                
                Raison de plus pour qu'il évite de chercher un bug dans le compilo en croyant que la connerie vient de lui, parce que ça peut prendre du temps ces conneries ;)

[^]Re: Bémol !?

• [^]Re: Bémol !?

  Posté par qpad () le 29/01/2007 à 23:44. (lien). Évalué à 2.

  Bonjour,
  
  Est-ce que ces points sont susceptibles d'évoluer ?

  • [^]Re: Bémol !?

    Posté par mouftard () le 30/01/2007 à 07:59. (lien). Évalué à 2.

    Le chargement de code je n'en ai pas la moindre idée.
    
    En ce qui concerne un éventuel GC concurrent, un fil de discussion relativement récent sur la liste de diffusion dédiée au langage[0] a fourni une réponse intéressante de la part de Damien Doligez, "GC wizard" de la team OCaml :
    
    http://caml.inria.fr/pub/ml-archives/caml-list/2006/09/7fbdc(...)
    
    Il semble que l'obstacle soit plus philosophique que technique tout compte fait (bien que les difficultés d'implantation soient réelles), et que l'équipe attende d'avoir quelque chose de plus propre et élégant que threads et mémoire partagée pour offrir cette possibilité.
    
    Le mail se terminant par "In summary, you shouldn't hold your breath.", ça ne semble pas être pour tout de suite.
    
    <hypothèses>
    Il y a d'autres projets liés à la concurrence et la distributivité à l'INRIA, certains assez liés à OCaml, comme JoCaml. Peut-être que l'équipe Gallium attend quelque chose de ce coté, et préfère se concentrer sur d'autres aspects pour l'instant ?
    </hypothèse>

[^]Re: Bémol !?