OCaml summer project

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
0
28
jan.
2007
Communauté
Le "OCaml Summer Project" est un projet visant à encourager le développement de la communauté de développeurs du OCaml en proposant des financements pour aider des étudiants à réaliser l'été prochain des projets de logiciel libre dans le langage de programmation Objective Caml.

Le financement proposé est de 6000$ par étudiant. Une rencontre entre les participants est organisée à la fin de l'été à New-York. Les soumissions doivent être effectuées avant le 15 mars. Entre 5 et 10 projets devraient être acceptés. Ce financement est offert par Jane Street Capital, une société de courtage new-yorkaise qui cherche à s'appuyer sur des technologies de pointe et qui s'implique beaucoup dans la recherche et le développement sur les langages de programmation.

Les projets sont à réaliser individuellement ou en équipe de deux. Une liste de projets est suggérée par les organisateurs, parmi lesquels un éditeur en OCaml, des bindings (liaisons) pour des bibliothèques (il manque toujours un binding Qt pour OCaml !), un résolveur d'équations, des outils de visualisation scientifique, des bibliothèques pour des applications multi-processus, etc.

Objective Caml est un langage multi-paradigme (impératif, fonctionnel, objet) de la famille ML, disposant d'un système de type évolué permettant de réduire considérablement les bogues d'exécution possible. Il est réputé pour sa fiabilité, sa concision, sa rapidité, et la facilité de maintenance des applications.

Aller plus loin

  • # Tout bon!

    Posté par  . Évalué à 5.

    Très intéressant ça.
    Ca donne une meilleure visibilité à l'Ocaml, montre qu'il est utilisé "dans la vraie vie" et que les entreprises qui l'ont choisi en sont content !

    • [^] # Re: Tout bon!

      Posté par  (site web personnel) . Évalué à 4.

      > Ca donne une meilleure visibilité à l'Ocaml, montre qu'il est utilisé "dans la vraie vie"

      Quand je vois les concurrents "Python, Ruby, Mono, ..." . Je me dis que les actions de visibilité ne suffiront pas. Python n'a pas besoin d'un "summer project" pour être aujourd'hui incontournable (notamment pour en language de script) .

      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...).

      L'Inria a tout simplement loupé l'opportunité du langage multi-plateforme et haut niveau. Il en faudras encore du temps pour en faire le deuil.

      • [^] # Re: Tout bon!

        Posté par  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  (site web personnel) . É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 ?

            • [^] # Re: Tout bon!

              Posté par  (site web personnel) . É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  (site web personnel) . É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  . É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à...

            • [^] # Re: Tout bon!

              Posté par  (site web personnel) . É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  . É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?

              • [^] # Re: Tout bon!

                Posté par  . É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  (site web personnel) . É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  (site web personnel) . Évalué à 7.

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

                  • [^] # Re: Tout bon!

                    Posté par  (site web personnel) . Évalué à 2.

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

                  • [^] # Re: Tout bon!

                    Posté par  . Évalué à 4.

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

                    ~~>[]

                    BeOS le faisait il y a 20 ans !

    • [^] # Re: Tout bon!

      Posté par  . Évalué à 3.

      Je participerais bien mais ça m'a l'air un peu dur, et il n'y a pas beaucoup de places :'(

      • [^] # Re: Tout bon!

        Posté par  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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.

                • [^] # Re: Tout bon!

                  Posté par  . É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  . É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  . É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 ;)

  • # Bémol !?

    Posté par  (site web personnel) . Évalué à 4.

    Je précise que je n'ai rien contre OCaml ni contre les logiciels 'non-industriels' (pour le libriste que je suis ça serait vraiment cracher dans la soupe). Pour en avoir fait un petit peu, c'était effectivement vraiment pas mal. A écouter certains, c'est le meilleur langage du monde et on peut jeter le reste (mais bon je ne suis pas le dernier à précher pour mes outils favoris, je sais ce que c'est), mais j'aimerais quand même la réponse de personnes qui s'y connaissent bien en OCaml à mes quelques questions :
    - Si j'en crois la doc, les threads sont lightweight et n'utilisent donc pas les multi-processeurs. Est-ce exact ?
    - Toujours en mattant la doc, le chargement dynamique de bibliothèques ne marche qu'en mode bytecode, et pas en mode natif. Là encore, est-ce que je me trompe ?

    Parce que si je ne me trompe pas, ça fait quand même 2 trucs assez indispensables qui manquent. Alors, je suis le 1er à m'extasier sur des conceptions super haut niveau ou des algos élégants et performants, mais pour un langage que certains voudraient voir remplacer le C, je trouve ça très handicapant.

    Voilà mon objectif n'est absolument pas de dégouter les gens de OCaml (il y a des tas de langage très nuls mais super utilisés, alors un bon langage sous utilisé je vais pas taper dessus en priorité), mais juste de signaler que faire un langage avec des abstractions super bien foutues c'est bien, mais pour pouvoir remplacer les autres langages, il va quand même falloir pouvoir faire au moins autant que ces derniers.

    • [^] # Re: Bémol !?

      Posté par  . Évalué à 2.

      Tu pointes (à mon avis) les deux plus gros défauts d'OCaml à l'heure actuelle.

      À l'image des implantations actuelles de Ruby ou Python, les threads d'OCaml ne tirent pas partie du multi-coeur : il me semble que c'est lié au glaneur de cellules (GC) et aux difficultés liées à la mise en oeuvre d'une version concurrente de ce dernier.

      Pour le chargement de code dynamique, en effet le module http://caml.inria.fr/pub/docs/manual-ocaml/libref/Dynlink.ht(...) ne gère que le chargement de bytecode, et ne peut donc pas ètre utilisé dans un programme compilé vers du code natif.

      • [^] # Re: Bémol !?

        Posté par  . Évalué à 2.

        Bonjour,

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

        • [^] # Re: Bémol !?

          Posté par  . É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 !?

      Posté par  (site web personnel) . Évalué à 2.

      - Si j'en crois la doc, les threads sont lightweight et n'utilisent donc pas les multi-processeurs. Est-ce exact ?

      Pas tout à fait. Il y a deux implémentations pour les threads: une pour le bytecode avec des threads usermode (lightweight comme tu dis) et une pour le code natif qui utilise les pthreads du système. Mais dans le cas des pthreads il y a un lock global qui assure qu'il n'y a qu'un seul thread caml qui s'exécute à la fois (comme en python).

      - Toujours en mattant la doc, le chargement dynamique de bibliothèques ne marche qu'en mode bytecode, et pas en mode natif. Là encore, est-ce que je me trompe ?

      En effet. Il y a un patch qui traîne sur le net pour permettre plus ou moins ça il me semble.

      Mais bon ces 2 limitations sont là "by design" et ce n'est pas près de changer AMHA. Par exemple le runtime n'est pas concurrent parce que cela permet des allocations mémoire trés rapides et qu'un GC concurrent est beaucoup plus complexe.

      Parce que si je ne me trompe pas, ça fait quand même 2 trucs assez indispensables qui manquent.

      rien n'est indispensable :) OCaml n'est pas le langage magique qui permet tout facilement et sûrement. Il est mieux adapté pour certaines tâches que pour d'autres. Le cas typique c'est un (assez gros) programme qui fait une tâche bien définie sans avoir besoin de dizaines de bibliothèques, par exemple un compilateur.


      Ensuite pour ce qui est de "l'industrie", ça ne change rien, c'est toujours la même question: savoir si le langage est adapté à ce qu'il faut faire. Dans certains domaines ça l'est tout à fait.

Suivre le flux des commentaires

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