Oui oui je connais, enfin Caml tout court, c'est avec ce langage que j'ai redécouvert les langages fonctionnels (j'avais fait du Scheme il y a quelque temps), j'ai eu droit à un semestre de cours, et j'avoue que ca m'a réfléchir de manière différente sur la programmation.
- il gère la généricité (bon aujourd'hui ça peut paraître classique, c'est vrai)
Hmm, je suis pas sûr que OCaml fasse ça, mais il y a sûrement d'autres moyens d'y arriver s'il ne le fait pas.
En tapant "ocaml generics" sur google, je suis tombé sur ca : http://lambda-the-ultimate.org/node/view/804(...)
Qui parle d'un article sur lequel j'étais déjà tombé. En bref, dans les commentaires j'ai lu que Ocaml gérait le parametric polymorphism (??) et que ca résoudrait le problème. Bon j'ai pas cherché beaucoup. Mais je pense que les generics sont la un peu pour palier le "statisme" des langages OO classiques, et que les langages fonctionnels n'en ont généralement pas besoin.
- les traits, sorte de classes sans état interne, qui permette d'"imiter" l'héritage multiple
Je n'ai pas compris le principe de ce que tu décrit ? tu peux préciser ?
Je viens de revoir leur page pour essayer d'éclaircir mes propos, mais en les relisant je ne comprend plus trop. Ils disent que l'exemple de trait peut etre utilisé dans les mixins, mais en fait ils ne le font pas (pages pas à jour?).
Ce que je sais sur un trait, c'est que c'est une classe qui ne contient pas de variable d'instance. Ainsi, on peut hériter d'une classe classique et d'un trait (donc c'est de l'héritage multiple) sans que ca pose de problème avec les conflits de variable d'instance, car si on hérite de deux classes qui ont une variable d'instance en commun, ca pose problème. (j'avais commencé une explication avec la problème de l'héritage en diamant en C++, mais je me suis un peu embrouyé et j'ai arrêté ...)
A part peut-être une syntaxe un peu plus proche des langages objet 'communs' (comme Ruby par exemple), je ne vois pas l'intérêt de ce langage, ce qui ne veut pas dire que je blâme les inventeur de Scala :-)
Justement, je pense ce qui repousse la plupart des développeurs élevés au C (comme moi ;-)), c'est la syntaxe. Le manque de librairies aussi, mais cela vient du manque de développeurs, et donc de la syntaxe (selon moi, hein). C'est vrai que faire une syntaxe à mi-chemin entre fonctionnel et OO, tout en évitant les problèmes que ca peut impliquer, c'est galère, mais je trouve que Scala se débrouille pas mal sur ce point.
[^] # Re: et Objective Caml ?
Posté par benoar . En réponse au journal Scala : un langage de prog sympa. Évalué à 1.
Oui oui je connais, enfin Caml tout court, c'est avec ce langage que j'ai redécouvert les langages fonctionnels (j'avais fait du Scheme il y a quelque temps), j'ai eu droit à un semestre de cours, et j'avoue que ca m'a réfléchir de manière différente sur la programmation.
- il gère la généricité (bon aujourd'hui ça peut paraître classique, c'est vrai)
Hmm, je suis pas sûr que OCaml fasse ça, mais il y a sûrement d'autres moyens d'y arriver s'il ne le fait pas.
En tapant "ocaml generics" sur google, je suis tombé sur ca :
http://lambda-the-ultimate.org/node/view/804(...)
Qui parle d'un article sur lequel j'étais déjà tombé. En bref, dans les commentaires j'ai lu que Ocaml gérait le parametric polymorphism (??) et que ca résoudrait le problème. Bon j'ai pas cherché beaucoup. Mais je pense que les generics sont la un peu pour palier le "statisme" des langages OO classiques, et que les langages fonctionnels n'en ont généralement pas besoin.
- les traits, sorte de classes sans état interne, qui permette d'"imiter" l'héritage multiple
Je n'ai pas compris le principe de ce que tu décrit ? tu peux préciser ?
Je viens de revoir leur page pour essayer d'éclaircir mes propos, mais en les relisant je ne comprend plus trop. Ils disent que l'exemple de trait peut etre utilisé dans les mixins, mais en fait ils ne le font pas (pages pas à jour?).
Ce que je sais sur un trait, c'est que c'est une classe qui ne contient pas de variable d'instance. Ainsi, on peut hériter d'une classe classique et d'un trait (donc c'est de l'héritage multiple) sans que ca pose de problème avec les conflits de variable d'instance, car si on hérite de deux classes qui ont une variable d'instance en commun, ca pose problème. (j'avais commencé une explication avec la problème de l'héritage en diamant en C++, mais je me suis un peu embrouyé et j'ai arrêté ...)
A part peut-être une syntaxe un peu plus proche des langages objet 'communs' (comme Ruby par exemple), je ne vois pas l'intérêt de ce langage, ce qui ne veut pas dire que je blâme les inventeur de Scala :-)
Justement, je pense ce qui repousse la plupart des développeurs élevés au C (comme moi ;-)), c'est la syntaxe. Le manque de librairies aussi, mais cela vient du manque de développeurs, et donc de la syntaxe (selon moi, hein). C'est vrai que faire une syntaxe à mi-chemin entre fonctionnel et OO, tout en évitant les problèmes que ca peut impliquer, c'est galère, mais je trouve que Scala se débrouille pas mal sur ce point.