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 Ontologia (site web personnel) . Évalué à 1.
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 GTof . Évalué à 4.
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 scand1sk (site web personnel) . Évalué à 4.
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 GTof . Évalué à 2.
[^] # Re: Réédition du livre "Le langage Caml"
Posté par Bertrand Mathieu . Évalué à 0.
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 LeMarsu . Évalué à 3.
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 kra . Évalué à 1.
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 Mickaël Rémond (site web personnel) . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Réédition du livre "Le langage Caml"
Posté par Mickaël Rémond (site web personnel) . Évalué à 1.
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 Nicolas Bernard (site web personnel) . Évalué à 6.
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 scand1sk (site web personnel) . Évalué à 2.
[^] # Re: Réédition du livre "Le langage Caml"
Posté par Erwan . Évalué à 2.
# COCAN ?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
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 dromadaire35 . Évalué à 3.
Ça existe déjà, ça s'appelle The Caml Hump et c'est là : http://caml.inria.fr/cgi-bin/hump.en.cgi(...)
Il y est déjà :-)
[^] # Re: COCAN ?
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
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 Vivi (site web personnel) . Évalué à 2.
Actuellement il y a GODI http://godi.ocaml-programming.de/(...) qui se rapproche assez de ce que tu cherches.
[^] # Re: COCAN ?
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
[^] # Re: COCAN ?
Posté par Vivi (site web personnel) . Évalué à 3.
[^] # Re: COCAN ?
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
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.