Journal Vitalité d'Objective Caml ?

Posté par  (site web personnel) .
Étiquettes : aucune
0
6
juil.
2005
Cher journal,

Depuis quelques temps, je suis assez intéressé par Objective Caml, et je commence doucement à m'y mettre à l'aide notamment du livre en ligne Développer des applications avec Objective Caml, disponible là :

http://www.pps.jussieu.fr/Livres/ora/DA-OCAML(...)

Ce langage a l'air d'avoir de nombreux atouts :
- portabilité
- puissance et rapidité
- diversité des styles de programmation possibles
- etc.

Malgré ce portrait idyllique, il y a quand même une petite question que je me pose : est-ce que le langage est toujours bien "vivant" ? En effet, d'après ce que j'ai pu voir, le seul vrai bouquin sur le sujet date de 2000, l'IDE Cameleon ne bouge plus depuis 2003, et la cadence de sortie des versions du langage n'a pas l'air infernale.

Vous me direz : peut-être, mais tout cela ne présume en rien de la qualité du langage en lui-même, et je vous répondrais que vous avez bien raison, et que ça ne m'empêchera pas, quoi qu'il arrive, de continuer à me pencher dessus à mon rythme.

Disons que c'est juste de la curiosité.

Merci d'avance si vous avez un avis ou une info sur le sujet !
  • # Réédition du livre "Le langage Caml"

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

    Ayant commandé celui-ci en librairie et ne le voyant pas arriver, j'ai interrogé la librairie qui m'a appris qu'il était en réédition. Pierre Weiss, son auteur m'a appris qu'il serait effectivement réédité à la rentrée :-)

    Mon humble avis est que Caml est toujours utilisé par une petite communauté qui ne se dément pas, mais je dis ça de loin.

    Le problème est que ce langage n'est accessible qu'à une élite.

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Réédition du livre "Le langage Caml"

      Posté par  . Évalué à 4.

      Objective Caml est un langage fonctionnel donc très loin des religions dominantes que sont C, C++, Java, ... . C'est un style de programmation totalement différent et forcément quand on débarque alors qu'on a connu que les langages impératifs, ca fait un choc, mais avec "Développer des applications avec Objective Caml" la prise en main est facile et rapide.

      De plus il y a quelques avantages comme ne pas avoir a ce soucier de la mémoire (a chaque fois que je vois une appli faire seg fault je me dis que ce ne serait pas arrivé en O'Caml), et avec le typage fort on élimine beaucoup de bug de mauvais type d'argument très difficiles a repérer dans d'autres langages (souvent à l'origine des seg fault d'ailleurs). Et cerise sur le gateau le compilateur est très performant. Il dispose de plus de beaucoup de bibliothèques. Alors c'est vrai qu'il nécéssite un petit temps d'adaptation mais le jeu en vaut largement la chandelle.

      Maintenant en ce qui concerne la vivacité du projet, il est bien vivant et un grand nombre d'étudiant depuis quelques temps ont été formé a O'Caml donc petit a petit ce langage va se propager même si vraissemblablement cela va prendre beaucoup de temps (les habitudes sont tenaces).

      Si tu cherche un langage avec une vraie petite communauté et vraiment d'accès ardu, jette un coup d'oeil du coté de Maude ( http://maude.cs.uiuc.edu/(...) ).
      • [^] # Re: Réédition du livre "Le langage Caml"

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

        [quote]a chaque fois que je vois une appli faire seg fault je me dis que ce ne serait pas arrivé en O'Caml[/quote]

        En même temps, y a plein de langages bien faits et relativement répandus qui permettent d'éviter ce genre de problèmes. En fait, la plupart des langages développés après le C (sauf le C++) : Java, Ada, C#... et même le Prolog (mais là par contre, y a pas de typage).
        • [^] # Re: Réédition du livre "Le langage Caml"

          Posté par  . Évalué à 2.

          Je n'excluais pas les autres langages ! Quant a Java, c'est partiellement vrai, je suis souvent tombé sur des Null Pointer Execption quand j'en ai fait alors qu'en O'Caml ce n'est arrivé qu'en utilisant le binding de la SDL qui est en C. O'Caml n'a pas seulement un garbage collector pour éviter ca mais aussi un typage statique fort ce qui n'est pas le cas de Java. En ce qui concerne Ada ou C#, je ne peux rien dire, jamais essayé.
          • [^] # Re: Réédition du livre "Le langage Caml"

            Posté par  . Évalué à 0.

            mais aussi un typage statique fort ce qui n'est pas le cas de Java


            D'après les souvenirs que j'en ai, ça ne serait pas plutôt un type dynamique fort chez ocaml?
            • [^] # Re: Réédition du livre "Le langage Caml"

              Posté par  . Évalué à 3.

              Nonon, il s'agit bien d'un typage statique avec Objective Caml! C'est uniquement à la compilation que le programme connait les types de donnée qu'il aura. C'est entre autre pourquoi il va vite, il fait fi de toutes les vérification de type durant le runtime.

              Lorsqu'un programme en OCaml se compile, il tournera. Il ne fera pas forcément ce que tu veux (si tu sais pas coder) mais, il risque pas de segfault!

              Et pour montrer un exemple a quel point le typage statique est fort, si on veut additionner un entier avec un flotant, il faut passer par la fonction float_of_int pour convertir l'entier en flotant, pour ensuite l'additionner avec l'opérateur flotant (et oui, il est différent de l'opérateur d'addition d'entier : "+" pour les entiers et "+." pour les flotants).

              Ex : (float_of_int 2) +. 3.2 ;;

              Mes 2 centimes...

              LeMarsu
          • [^] # Re: Réédition du livre "Le langage Caml"

            Posté par  . Évalué à 1.

            ben en fait, tous les garbages collectors du monde reunis ne pourront empecher un NullPointerException..
            c'est juste que le codeur a essaye d'acceder un pointeur initialise a null.

            apres, je sais pas trop comment caml gere ca (jamais fait d'objet en caml)?
            c'est possible d'avoir une variable non initialisee en caml? (j'ai pas de souvenirs du mot cle null, mais plutot d'un type void, qui ne peut etre retourne depuis une fonction me semble t il).
        • [^] # Re: Réédition du livre "Le langage Caml"

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

          Erlang est également un langage robuste, capable de bien résister à ce type d'erreur.
          Voir: http://www.erlang.org/(...)

          --
          Mickaël Rémond
          http://www.erlang-projects.org/(...)
          http://www.3pblog.net/(...)

          Mickaël

          • [^] # Re: Réédition du livre "Le langage Caml"

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

            mais qui est looooooooooin des perf de Ocaml :)

            "La première sécurité est la liberté"

            • [^] # Re: Réédition du livre "Le langage Caml"

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

              Ca dépend sur quoi tu te bases pour juger. De nombreuses d'applications Erlang comme le serveur Web Yaws ou le serveur XMPP ejabberd ont des performances impressionnantes par rapport à leur concurrent en terme de montée en charge.

              Si tu t'appuies sur le benchmark shout out, l'ensemble n'est pas vraiment optimisé, en particulier sur les temps de démarrage de l'environnement qui pénalise Erlang dans la plupart des benchmarks (qui sont en général très court). Avec l'outil stand alone Erlang, je fais gagner pas mal de position à Erlang sur de 60% des benchmarks.

              Et il ne faut pas oublier qu'Erlang dispose aussi de compilation native avec HiPe, le compilateur Erlang (Mais qui est utilisé pour les benchmarks shout out cependant).

              --
              Mickaël Rémond
              http://www.erlang-projects.org/(...)
              http://www.3pblog.net/(...)

              Mickaël

    • [^] # Re: Réédition du livre "Le langage Caml"

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

      Attention, si mes souvenirs sont bons, le livre "Le langage Caml" traite de Caml Light, pas d'Objective Caml.

      Pour ce qui est d'Objective Caml, c'est à mon avis un très bon langage, mais dont le principal problème est qu'il n'a pas encore atteint une masse critique de développeurs, en raison sans doute
      -du fait qu'il est au départ fonctionnel (ce que peu de dev comprennent, la plupart ne connaissant que la programmation impérative);
      -du fait qu'il n'y a pas de grosse entreprise derrière pour dire "c'est bon, mangez-en".
      -le fait que c'est au départ un langage de recherche fait que pendant un certain temps il y a eu des modifs assez fréquentes sur la syntaxe, ce qui est génant s'il faut modifier les programmes à chaque nouvelle version. (Mais on peut dire la même chose pour Perl par exemple).

      La conséquence de ce peu d'utilisateurs est que le nombre de modules et de bindings pour Ocaml est faible comparé à ce que l'on peut trouver pour Java ou Perl.
      • [^] # Re: Réédition du livre "Le langage Caml"

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

        En même temps, quand je vois comment l'Ada, qui a tous les avantages indiqués au dessus, qu'il est impératif, qu'il y a quelques grosses entreprises derrière (Agence Spatiale Européenne, armée US...), qu'il est remarquablement stable (c'est un des rares langages qui ait été normalisé avant que le premier compilateur ait été fonctionnel)... et qu'il est malgré tout totalement ignoré par 90% des informaticiens, je me dis qu'il faut bien plus que des avantages techniques pour qu'un langage de prog se répande...
        • [^] # Re: Réédition du livre "Le langage Caml"

          Posté par  . Évalué à 2.

          Il faut des bibliotheques ! C'est comme un OS, il faut des applications... Et des fois le fait que la mayonnaise prenne ou pas au debut est assez ineplicable.
  • # COCAN ?

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

    Personnellement, je ne comprends pas qu'avec ses moyens, l'INRIA ne mette pas en place un "Comprehensive Objective Caml Archive Network", à la manière de Perl et de TeX.

    C'est personnellement un de mes principals frein à son utilisation. Allez chercher ici ou là des paquets est franchement ennuyeux et peu fiable dans le temps.

    Une archive centralisé permet d'avoir une dynamique communautaire forte. Je ne dis pas que ça marchera mais que serait Perl et TeX sans le CPAN et le CTAN aujourd'hui. A mon avis, peu de chose.

    Je ne suis pas sur qu'aujourd'hui, OCaml ai envie de jouer dans la cour des grands...
    • [^] # Re: COCAN ?

      Posté par  . Évalué à 3.

      Personnellement, je ne comprends pas qu'avec ses moyens, l'INRIA ne mette pas en place un "Comprehensive Objective Caml Archive Network", à la manière de Perl et de TeX.

      Ça existe déjà, ça s'appelle The Caml Hump et c'est là : http://caml.inria.fr/cgi-bin/hump.en.cgi(...)

      Je ne suis pas sur qu'aujourd'hui, OCaml ai envie de jouer dans la cour des grands...

      Il y est déjà :-)
      • [^] # Re: COCAN ?

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

        > Ça existe déjà, ça s'appelle The Caml Hump

        Désolé mais ca n'a rien à voir. Sur le CTAN et le CPAN, il y a TOUS les sources. Ce ne sont pas simplement des bases de données de liens.

        Avec un système centralisé, tu donnes tes sources à la communauté. Dans le cas "The Caml Hump", tu acceptes que la communauté vienne chez toi. Il t'es facile ensuite de supprimer cet accès. Ce n'est pas un système pérenne.
    • [^] # Re: COCAN ?

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

      Ça a été évoqué plusieurs fois sur la ML. C'est pas aussi simple que ça apparemment.

      Actuellement il y a GODI http://godi.ocaml-programming.de/(...) qui se rapproche assez de ce que tu cherches.
      • [^] # Re: COCAN ?

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

        Je ne dis pas que c'est trivial. Mais j'évoque l'INRIA, pas une simple association de quartier. Je pense qu'un EPST ayant un forte consonnance informatique est capable de mener ce genre de projet, sinon je trouve cela inquiétant.
        • [^] # Re: COCAN ?

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

          L'équipe développant OCaml à l'INRIA a pour thème la recherche sur les langages de programmation, leur sémantique, implémentation, typage, tout ça ... Réaliser un environnement de programmation de qualité industrielle n'est apparemment pas leur objectif.
          • [^] # Re: COCAN ?

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

            Nous sommes d'accord. L'INRIA ne semble pas réellement motivé par l'utilisation de son langage...

            Que l'équipe de recherche ne veuille pas se charger de ça, je le comprends fort bien. C'est pour cela que j'invoque l'étage au dessus.

            Si l'on veut faire du transfert, il faut mettre quelques moyens humains et matériels. Ce n'est pas forcément une tache à rajouter encore aux chercheurs (on les encombre déjà bien assez avec de la paperasse sans intérêt).

Suivre le flux des commentaires

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