Quel langage fonctionnel choisir ? Caml, Lisp ou Scheme ?

[sylvainp]

Il me semble que GIMP, EMACS et AUTOCAD sont développés en Lisp/Scheme
Je pense également, que les programmeurs affectionnent les langages qu'ils pratiquent. Bien souvent, le choix d'un nouveau langage se fait soit par obligation (pendant ses études ou au boulot), soit parceque le langage qu'on pratique présente des faiblesse par rapport à ce qu'on développe ...

[InOCamlWeTrust]

Ouh-la, attention : j'ai pas dit que Lisp et Scheme c'était de la merde !

C'est simplement la sensation que seuls Objective Caml et Haskell sont aujourd'hui à même de se positionner comme de vrais langages généralistes, prêts à tout faire avec de très bonnes performances en général, et d'offrir des outils avancés pour les programmeurs (bref, des outsider sérieux).

C'est tout.

Lisp et Scheme, c'est très bien, mais même si on peut tout faire avec, il y a des choses qui ne sont pas très bien adaptées à ces langages-là. On a le même phénomène, bien entendu avec Objective Caml et Haskell (et tous les langages, C compris), mais la différence est beaucoup moins prononcée, ne serait-ce que par la richesse des systèmes de types de ces deux langages (bien que très différents et radicalement opposés).

[loupvaillant]

Et pourquoi pas un mix?

J'aime Ocaml, mais pas trop sa syntaxe. Grâce à Camlp4, on peut la changer et ajouter des constructions Ad Hoc, mais ça reste assez lourd. Je verrais bien Ocaml avec une syntaxe Lisp. Avec Camlp4 on a une chance d'y parvenir.

On garde alors le typage statique, (avec ses avantages et inconvéniants),et on gagnerais les macros, source majeure de la puissance de Lisp.

Ensuite, je trouve la syntaxe Lisp plus lisible que celle d'Ocaml (révisée ou pas). Elle est en effet plus systématique (elle s'explique grossièrement en une ligne de BNF). Pour ceux qui se sentent noyés sous les parenthèses, n'oubliez pas que c'est surtout l'indentation qui nous aide à lire le code.

J'avoue que la syntaxe m'est plus familère, mais est elle aussi puissante que ocaml?

Je ne suis pas certain que tu voulais le dire, mais certaines syntaxes sont plus puissantes que d'autres: plus lisibles, plus faciles à analyser, plus facile à transformer (on le fait peu, en dehors de Lisp). et je parle bien de syntaxe, non de sémantique.

[LLB]

Envoyé par loupvaillant

Ensuite, je trouve la syntaxe Lisp plus lisible que celle d'Ocaml (révisée ou pas). Elle est en effet plus systématique (elle s'explique grossièrement en une ligne de BNF).

Je préfère largement plus la syntaxe d'OCaml. Bien sûr, celle de Lisp est plus simple, plus systématique, plus logique... mais elle est surtout adaptée pour une machine. Moi, je suis un être un humain, et je ne veux pas me plier à ses exigences. Je préfère écrire "3 + 4 * 2 - 5" que "(- (+ 3 (* 4 2)) 5)". Même chose pour les autres structures : la syntaxe d'un "if" ou d'un "for" me semble bien plus naturelle en Caml.
Je code de temps en temps en Lisp, c'est un langage très puissant, mais j'ai toujours du mal à m'habituer à cette syntaxe.

Tout le reste, c'est du ... mis à part peut-être SML, et encore...

Et que penses-tu de F# ?
Ca fait plusieurs mois que je n'utilise plus que ce langage et il me plaît beaucoup. Il manque encore de maturité, il n'est pas encore parfait, mais il me semble très prometteur.

En vrac, quelques fonctionnalités nouvelles, que j'apprécie beaucoup :
- syntaxe allégée, basée sur l'indentation (c'est en option)
- listes en compréhension (comme dans Haskell)
- augmentations de types (pour définir par exemple une fonction membre aux types sommes, ou autres types)
- surcharge d'opérateur, et ça, ça embellit la vie
- introspection, grâce à .Net
- affichage générique (print_any peut afficher n'importe quel type de variable)
- la bibliothèque StructuredFormat, pour redéfinir l'affichage du print_any (avec tout plein de fonctions, pour l'indentation, etc.)
- le type Seq (comme une liste, mais paresseuse, donc potentiellement infinie)
- et bien sûr, toute la bibliothèque .Net.

[gorgonite]

au passage, vous oubliez Scala...
http://www.scala-lang.org/index.html

mais perso, je dirais que comme mon ami InOCamlWeTrust : Ocaml ou Haskell

si tu veux te mordre les doigts avec les callcc, éventuellement tu peux essayer SML

[InOCamlWeTrust]

F# en est encore au stade de jouet, ou de projet titubant entre la curiosité de laboratoire et l'outil industriel.

Les mecs qui le développent, je pense, buteront encore longtemps sur ce qui fait la force d'Objective Caml : le pré-processeur, les foncteurs et surtout, surtout... la merveilleuse extension objet du langage, que l'on semble utiliser trop peu souvent.

Cependant, F# représente un très bon vecteur de divulgation du langage Objective Caml.

Pour ce qui est des "plus", désolé, mais ils n'en sont pas :

Envoyé par LLB

- listes en compréhension (comme dans Haskell)

On peut en faire une macro Camlp4...

Envoyé par LLB

- surcharge d'opérateur, et ça, ça embellit la vie

De loin la plus mauvaise idée : on ne sait plus de quel type sont les expressions construites par l'intermédiaire de fonctions ou opérateurs surchargés !

Envoyé par LLB

- introspection, grâce à .Net

Là encore, mauvaise idée : on ne peut plus rien garantir sur l'exactitude et la robustesse des résultats si on peut modifier les valeurs depuis l'extérieur.

Envoyé par LLB

- la bibliothèque StructuredFormat, pour redéfinir l'affichage du print_any (avec tout plein de fonctions, pour l'indentation, etc.)

Cf.: -> Format...

Envoyé par LLB

- le type Seq (comme une liste, mais paresseuse, donc potentiellement infinie)

Cf.: -> 'a Stream.t... encore appelés les flots.

[LLB]

Envoyé par InOCamlWeTrust

F# en est encore au stade de jouet, ou de projet titubant entre la curiosité de laboratoire et l'outil industriel.

C'est quand même vachement avancé pour un jouet. Mais je suis d'accord que le langage manque encore de maturité.

Envoyé par InOCamlWeTrust

On peut en faire une macro Camlp4...

En pratique, qui en fait ?
Je suis désolé, mais faire des macros Camlp4 est quand même très contraignant. En pratique, on ne le fait que pour des bibliothèques, quand il y a vraiment le besoin.
Les listes en compréhension, ça allège énormément la syntaxe et augmente la lisibilité. En Caml, on se débrouille avec ce que l'on a, et on le remplace par des List.map, List.filter, etc. Mais, c'est plus lourd.

De loin la plus mauvaise idée : on ne sait plus de quel type sont les expressions construites par l'intermédiaire de fonctions ou opérateurs surchargés !

Quand on compare, la différence est flagrante :

Code :

1
2
3
4
5
let f x = num_of_int 3 +/ num_of_int 42 */ x
let f x = 3N + 42N * x

let g x y = 42. *. x +. y
let g y = 42. * x + y

Lorsque l'on a des fonctions qui manipulent des entiers, et que l'on veut les remplacer par des Num, ça demande beaucoup de travail en Caml. On doit ouvrir le module Num dans chaque fichier, on doit ajouter num_of_int à chaque constante et on doit remplacer chaque opérateur. C'est lourd.
En F#, il y a juste un N à ajouter derrière les constantes. Tout le reste est inféré.

Pareil pour les flottants. C'est extrèmement désagréable de devoir ajouté un point partout. Quand j'écris du code avec des flottants, je me plante une fois sur deux. Les opérateurs "+.", "*.", etc. sont moches et non-intuitifs. C'est aussi une perte de temps.

La possibilité de pouvoir étendre l'opérateur + sur ses propres types est super intéressant. La surcharge d'opérateurs est quand même l'un des principaux apports du C++ par rapport au C (avec l'objet et les templates) : et regarde la différence entre ces deux langages !
C'est vraiment fatigant d'imaginer de nouveaux opérateurs, plus longs et moins intuitifs que les autres, à chaque fois que l'on définit un nouveau type numérique. Ca ne te semble pas indispensable d'avoir les opérateurs "+", "-"... quand tu manipules des matrices ?

Mais si jamais tu n'es pas convaincu, sache que tu peux ne pas utiliser la surcharge. F# est en grande partie compatible avec OCaml. Les opérateurs "+.", "+/", etc. existent. Mais à part enlaidir le code, je ne vois pas trop l'intérêt.

Là encore, mauvaise idée : on ne peut plus rien garantir sur l'exactitude et la robustesse des résultats si on peut modifier les valeurs depuis l'extérieur.

Euh... tout ce qui est valeur ne peut pas être modifié (heureusement !). Donc, si tu codes en fonctionnel pur, tu peux toujours garantir les mêmes choses qu'en Caml.
Je ne connais pas tout les détails de l'introspection, mais je sais que l'on peut : récupérer l'ensemble des fonctions d'un objet (avec leurs types), faire du pattern matching sur des types... La seule fois que je suis servi de l'introspection, c'était pour avoir des infos sur les méthodes .Net, générer du code assembleur CIL à la volée et l'exécuter dynamiquement. Dans tous les cas, ce ne peut pas être une régression : tu ne t'en sers que si tu en as besoin.

Cf.: -> Format...

D'accord pour l'indentation et le pretty-printing (même si je ne trouve pas ça agréable à utiliser en Caml). Par contre, comment affiches-tu une variable de n'importe quel type (sans utiliser d'outil extérieur) ?

Code :

1
2
3
4
> print_any [2; 5; 4]
[2; 5; 4]
> print_any [box 2; box "foo"; box (4, 2)]
[2; "foo"; (4, 2)]

D'ailleurs, tu remarqueras dans ce dernier exemple l'utilisation de box. Ca permet entre autres d'avoir du typage dynamique (et seulement quand on le souhaite, donc ne reproche pas la sûreté). Et ça remplace aussi Obj.magic (en vachement plus sûr quand même, vu qu'on a l'information de type).

Cf.: -> 'a Stream.t... encore appelés les flots.

Oui, en effet. On doit avoir à peu près la même chose, sauf peut-être au niveau de la syntaxe. J'ai été voir stream.mli, mais je trouve qu'il y a vraiment très peu de fonctions. En F#, il y a toutes les fonctions du module List, mais en paresseux :

Code :

1
2
3
4
5
> let s1 = Seq.init_infinite (fun x -> x * x)
> let s2 = Seq.map (fun x -> x, x * x) s1
> print_any (Seq.take 10 y)
[(0, 0); (1, 1); (4, 16); (9, 81); (16, 256); (25, 625); (36, 1296); (49, 2401);
 (64, 4096); (81, 6561)]

En pratique, est-ce que l'utilisation du module Stream est facile ? J'ai bien sûr vu quelques exemples pour les parser ou pour générer une suite de nombres, mais est-ce que l'on utiliser des Stream partout où l'on avait des List ? Par exemple, comment faire utiliser map dessus ? L'utilisation de ce module me semble relativement lourde.

[gorgonite]

Envoyé par LLB

En pratique, qui en fait ?
Je suis désolé, mais faire des macros Camlp4 est quand même très contraignant.

+1, mais les détracteurs peuvent se tourner vers menhir

Envoyé par LLB

Les listes en compréhension, ça allège énormément la syntaxe et augmente la lisibilité. En Caml, on se débrouille avec ce que l'on a, et on le remplace par des List.map, List.filter, etc. Mais, c'est plus lourd.

perso, j'aime bien les listes en compréhension... mais ce n'est pas pour autant que je les utiliserais à tour de bras
si l'on modélise correctement son problème, ce n'est pas plus lourd d'utiliser le système Caml

Envoyé par LLB

Lorsque l'on a des fonctions qui manipulent des entiers, et que l'on veut les remplacer par des Num, ça demande beaucoup de travail en Caml. On doit ouvrir le module Num dans chaque fichier, on doit ajouter num_of_int à chaque constante et on doit remplacer chaque opérateur. C'est lourd.
En F#, il y a juste un N à ajouter derrière les constantes. Tout le reste est inféré.

perso, je dirais que ce genre de pratique insère une amiguité qui souvent amène les résultats de l'inférence à etre moins précis...

Envoyé par LLB

La possibilité de pouvoir étendre l'opérateur + sur ses propres types est super intéressant. La surcharge d'opérateurs est quand même l'un des principaux apports du C++ par rapport au C (avec l'objet et les templates) : et regarde la différence entre ces deux langages !

ben le c reste la référence des langages devant etre certifies... car le C++ est difficilement compréhensible par une nouvelle équipe sans qu'une doc très garnie soit fournie

Envoyé par LLB

Mais à part enlaidir le code, je ne vois pas trop l'intérêt.

l'intéret est de garder un certain determinisme dans le comportement d'un programmeur qui va relire ton travail... éviter les sauts longs vers le fichier où sont redéfinis ces @#?^$ d'opérateurs

Envoyé par LLB

Je ne connais pas tout les détails de l'introspection, mais je sais que l'on peut : récupérer l'ensemble des fonctions d'un objet (avec leurs types), faire du pattern matching sur des types... La seule fois que je suis servi de l'introspection, c'était pour avoir des infos sur les méthodes .Net, générer du code assembleur CIL à la volée et l'exécuter dynamiquement. Dans tous les cas, ce ne peut pas être une régression : tu ne t'en sers que si tu en as besoin.

le problème de l'introspection est que tu peux t'amuser à lancer des méthodes non statiquement controlées comme existantes et compatibles avec les arguments que tu vas lui passer... et à ce rythme on perd le mythe du "quand ça compile, on a 90% de chance que ça s'exécute sans bug"

Envoyé par LLB

Par contre, comment affiches-tu une variable de n'importe quel type (sans utiliser d'outil extérieur) ?

Je suis d'accord qu'il manque cette fonctionnalité... qui au fond n'est utile qu'en phase de conception/debug

Envoyé par LLB

D'ailleurs, tu remarqueras dans ce dernier exemple l'utilisation de box. Ca permet entre autres d'avoir du typage dynamique (et seulement quand on le souhaite, donc ne reproche pas la sûreté). Et ça remplace aussi Obj.magic (en vachement plus sûr quand même, vu qu'on a l'information de type).

on peut se passer de Obj.magic en OCaml... (si si on peut )
perso, quand on a recours à ce genre "d'outils", c'est que :
1) on est un dieu du langage qui veut implémenter rapidement un truc vachement bizarre... et on sait ce qu'on fait
2) on est un clown qui ferait mieux de revoir la modélisation de son problème...

[InOCamlWeTrust]

Envoyé par LLB

En pratique, est-ce que l'utilisation du module Stream est facile ? J'ai bien sûr vu quelques exemples pour les parser ou pour générer une suite de nombres, mais est-ce que l'on utiliser des Stream partout où l'on avait des List ? Par exemple, comment faire utiliser map dessus ? L'utilisation de ce module me semble relativement lourde.

L'utilisation des flots est relativement facile si on connaît deux principes : 1) un flot n'est pas une liste et 2) on ne mélange pas les flots construits à l'aide de "[<" et ">]" avec ceux obtenus lors d'appels aux fonctions du module Stream. Leur filtrage est destructif et un peu particulier : il faut simplement y faire un peu gaffe pour ne pas se planter.

Concernant la surcharge, moi aussi je trouve ça très chiant de devoir écrire les opérateurs différemment selon qu'il s'agisse d'un type ou d'un autre, mais lorsque je code en C ou en FORTRAN, par exemple, j'ai toujours la frousse : "Est-ce que le compilateur comprendra ceci :

Code :

1
2
3
4
5
6
7
8
9
10
C     UN ENTIER
      INTEGER N
C
C     UN FLOTTANT
      DOUBLE PRECISION H

...

      H = 1 / N

?"

Lorsque l'on traite des E.D.P. ou autres, on a souvent ce genre de chose à faire... malheureusement, si on ne fait pas attention, on aura trop souvent un pas H nul avec ce code.

Cependant, si ce que l'on veut c'est :

- de la surcharge
- des listes en compréhension (donc éventuellement très longues et dont on ne peut pas réellement en contrôler finement la construction)
- faire de jolies impressions
- utiliser abusivement l'introspection et les interfaçages avec d'autres langages

il existe une seule réponse : Haskell... et là, on n'est plus du tout dans le même cadre.

[LLB]

perso, je dirais que ce genre de pratique insère une amiguité qui souvent amène les résultats de l'inférence à etre moins précis...

Ces cas sont très rares. Mais si jamais ça pose problème, les opérateurs "+.", "*." et autres sont toujours disponibles.
Très souvent, ça rend service. Et si jamais à un moment donné ça nous gène, on peut utiliser la syntaxe Caml. Au risque de me répéter, F# est en très grande partie compatible avec Caml. Le compilateur F# est écrit en Caml, mais il compile aussi sous F#. Donc, si jamais les fonctionnalités que j'ai citées ne vous plaisent pas, vous pouvez ne pas les utiliser. Personnellement, elles me plaisent beaucoup.

ben le c reste la référence des langages devant etre certifies... car le C++ est difficilement compréhensible par une nouvelle équipe sans qu'une doc très garnie soit fournie

Parce qu'il y a beaucoup d'abus en C++.
Ce n'est pas parce qu'une fonctionnalité est disponible qu'on doit forcément l'utiliser. En F#, la surcharge reste très discrète et elle n'existe que lorsqu'elle est vraiment utile (par exemple, les opérateurs mathématiques).

l'intéret est de garder un certain determinisme dans le comportement d'un programmeur qui va relire ton travail... éviter les sauts longs vers le fichier où sont redéfinis ces @#?^$ d'opérateurs

De la même façon qu'il faut parfois faire de longs sauts pour retrouver où a été (re-)définie une fonction. Bien sûr, l'abus de surcharge d'opérateurs est très néfaste. Mais quand on code proprement, on utilise des noms de fonctions explicites et des opérateurs explicites. Personnellement, utiliser l'opérateur '+' pour l'addition entre deux nombres (éventuellement en float) ne m'a jamais choqué.

J'ai du mal à saisir ton argument. Tu veux dire que "parce que des développeurs peuvent mal utiliser cette fonctionnalité, il faut la supprimer" ?
Et quid de la possibilité de redéfinir l'opérateur (+), (!), (mod) ou (=) en Caml (et F# aussi) ?

quand on a recours à ce genre "d'outils", c'est que :
1) on est un dieu du langage qui veut implémenter rapidement un truc vachement bizarre... et on sait ce qu'on fait
2) on est un clown qui ferait mieux de revoir la modélisation de son problème...

Pour Obj.magic, je suis d'accord.
Mais mettre des valeurs de types différents dans une même liste peut avoir son intérêt. Derrière, il y a toujours un vrai typage (contrairement à Obj.magic) qui empêche de faire des bêtises. Mais par exemple, si cette liste sert surtout à être affichée (print_any), ce n'est pas choquant d'utiliser la fonction box. Parfois (assez rarement, je suis d'accord), ça peut être utile. Mais le jour où ça arrive, on est bien content de l'avoir.

Code :

1
2
3
4
      INTEGER N
      DOUBLE PRECISION H
      H = 1 / N

Clairement, c'est une erreur de typage.

Pour l'opérateur '/', les surcharges dans F# sont (c'est pas exhautif, mais tu vois l'idée) :

Code :

1
2
3
4
int-> int -> int
float-> float -> float
Num -> Num -> Num
BigInt -> BigInt -> BigInt

Mais il n'y a pas de conversion implicite ! De cette façon, le code reste sûr. Si on veut 1 en flottant, on écrit donc "1.".

Envoyé par InOCamlWeTrust

1) un flot n'est pas une liste et 2) on ne mélange pas les flots construits à l'aide de "[<" et ">]" avec ceux obtenus lors d'appels aux fonctions du module Stream. Leur filtrage est destructif et un peu particulier : il faut simplement y faire un peu gaffe pour ne pas se planter.

OK, je préfère donc l'approche de F#. C'est plus naturel.

- des listes en compréhension (donc éventuellement très longues et dont on ne peut pas réellement en contrôler finement la construction)

Comment ça ?

On contrôle le résultat tout aussi finement qu'avec les appels classiques à List.map et autres. Et l'ajout de cette fonctionnalité ne fait pas disparaître ce qui existait déjà.

Code :

1
2
3
4
5
6
7
8
9
10
11
> let data = [ Some("James"); None; Some("John") ]
> [|for Some nm in data -> nm.Length|];;
val it : int array = [|5; 4|]

> [ for row in 0 .. 4
    for col in 0 .. row
      -> (row,col) ];;
val it : (int * int) List
       = [(0, 0); (1, 0); (1, 1); (2, 0); (2, 1); (2, 2); (3, 0); (3, 1);
          (3, 2); (3, 3); (4, 0); (4, 1); (4, 2); (4, 3); (4, 4)]

Pour le premier exemple, il faut utiliser du List.map, du List.filter et du Array.of_list pour obtenir le même résultat. Ce n'est bien sûr que du sucre, mais c'est agréable de temps en temps. Et bien sûr, pour gorgonite, rien n'empêche d'utiliser l'écriture Caml quand on le souhaite (c'est d'ailleurs la majorité des cas).

Pour le deuxième exemple, c'est encore une fois bien plus joli qu'en Caml. Et ça reste clair et lisible.

[InOCamlWeTrust]

Envoyé par LLB

Code :

Clairement, c'est une erreur de typage.

Non : c'est parfaitement autorisé en FORTRAN... tout comme en C !

[LLB]

Oui mais ici, dans ce forum, on parle de langages bien.
La surcharge dans F# ne génère pas ce problème (c'est un typage fort quand même !).

[gorgonite]

Envoyé par LLB

Et si jamais à un moment donné ça nous gène, on peut utiliser la syntaxe Caml. Au risque de me répéter, F# est en très grande partie compatible avec Caml. Le compilateur F# est écrit en Caml, mais il compile aussi sous F#. Donc, si jamais les fonctionnalités que j'ai citées ne vous plaisent pas, vous pouvez ne pas les utiliser. Personnellement, elles me plaisent beaucoup.

mais si on se met à utiliser des fonctionnalités que personne ne souhaitent voir dans la communauté (et elle est assez restreinte avec ce type de langage), on risque fort de faire quelque chose que personne ne voudra commenter (utile parfois d'avoir un avis extérieur), ou compléter (en cas de difficulté insurmontable)


Je peux donner l'exemple d'un contributeur OCaml qui utilise systématiquement les objets... pas très courant dans les codes sources de ce langage
Et la plupart du temps, d'autres redéveloppent les memes fonctionnalités de manière traditionnelle, au lieu d'utiliser ses ressources... qui sont souvent de qualité

[InOCamlWeTrust]

Il faut adapter sa façon de programmer à la mentalité du langage.

Le TOUT objet, ce n'est pas dans la mentalité Objective Caml, étant donné que celà se révèle lourd dès que lon veut parcourir les structures... tout comme la surcharge.

Pareil pour Haskell : la programmation à la ML ne lui sied pas très bien, même si on peut parfaitement le faire.

Concernant F#, je me demande si ces petits "plus" ne sont pas là pour tenter de compenser un manque énorme au niveau de l'extension objet et du langage de modules, ce qui fait toute la richesse d'Objective Caml. Je suis assez perplexe sur l'avenir de ce langage.

[LLB]

Envoyé par InOCamlWeTrust

Concernant F#, je me demande si ces petits "plus" ne sont pas là pour tenter de compenser un manque énorme au niveau de l'extension objet et du langage de modules, ce qui fait toute la richesse d'Objective Caml. Je suis assez perplexe sur l'avenir de ce langage.

Moi, je suis plutôt confiant sur son avenir.
Le langage me semble suffisamment abouti pour que l'on puisse l'envisager sérieusement pour un vrai projet. Il a quand même deux très gros avantages sur OCaml :
- il bénéficie d'un véritable IDE : le support F# de Visual Studio est très bon : tout le code, le typage et l'indentation sont vérifiés au fur et à mesure que je tape le code. Il y a aussi la complétion, l'affichage du type des valeurs au survol de la souris
- il possède une véritable bibliothèque (celle de .Net). Il n'y a pas à attendre des mois que quelqu'un fasse un binding Caml pour profiter d'une bibliothèque.

Donc, même si on peut trouver que le langage est "moins bien" qu'OCaml (ce dont je ne suis pas tout à fait d'accord), il reste quand même ces deux avantages. Et ça me semble être suffisant pour préférer F# à Caml, du moins quand on est sous Windows.

[gorgonite]

Envoyé par LLB

Donc, même si on peut trouver que le langage est "moins bien" qu'OCaml (ce dont je ne suis pas tout à fait d'accord), il reste quand même ces deux avantages. Et ça me semble être suffisant pour préférer F# à Caml, du moins quand on est sous Windows.

ce qui supprime le cas de 80% des universitaires...

[LLB]

Oui, c'est sûr. OCaml est bien plus adapté pour l'enseignement, mais F# représente une alternative sérieuse pour le monde du travail (et personnellement, ça m'intéresse beaucoup vu que les autres langages fonctionnels ont du mal à se faire une place en entreprise).

[InOCamlWeTrust]

Le manque de couche objet et l'absence de foncteurs ampute sérieusement F# pour le monde de l'entreprise, car la programmation objet n'est pas aussi répandue dans le milieu universitaire.

Il y a aussi le fait que Objective Caml est bien plus riche et bien plus raffiné dans son système de typage. J'étais justement avant-hier soir en train de me documenter sur les dernières évolutions du typage du langage... et bien il n'y a rien à faire, Objective Caml possède bel et bien le meilleur système de types au monde.

Ce qui fait la richesse de Objective Caml, c'est l'intégration de son sytème de types à la ML dans un langage objet et impératif, et le fait que tout celà puisse exister en harmonie. D'ailleurs lorsque l'on regarde les sources des compilateurs, on s'aperçoit de suite qu'un soin tout particulier a été apporté au système de typage.

Pour moi, ce qui constitue une vraie avancée dans Objective Caml, c'est le type polymorphe, l'analyse statique au niveau objet et le fait de pouvoir utiliser des objets fonctionnels de A à Z, chose que l'on ne retrouve nulle part ailleurs.

Ensuite, chacun à ses préférences... mais certaines sont meilleures que d'autres

[gorgonite]

Envoyé par InOCamlWeTrust

Objective Caml possède bel et bien le meilleur système de types au monde.

tout dépend ce que l'on attend d'un système de types... parce que dans le meme style, je peux préférer celui de Coq

Envoyé par InOCamlWeTrust

l'analyse statique au niveau objet et le fait de pouvoir utiliser des objets fonctionnels de A à Z, chose que l'on ne retrouve nulle part ailleurs.

cette analyse statique pose aussi de sérieuses limitations au modèle objet de Caml... normalement, l'héritage assure d'une certaine "force" du type, alors qu'en OCaml une classe n'est définie "que par ses méthodes"

par ailleurs, cela interdit l'introspection et le lancement dynamique de méthode

[LLB]

Envoyé par InOCamlWeTrust

Le manque de couche objet et l'absence de foncteurs ampute sérieusement F# pour le monde de l'entreprise, car la programmation objet n'est pas aussi répandue dans le milieu universitaire.

D'une part, il y a l'objet en F#. Il est d'ailleurs complètement compatible avec le système objet de .Net (et donc, du typage nominal plutôt que structurel). D'autre part, l'utilisation de l'orienté objet n'est pas fréquent en Caml, de ce que j'ai pu voir. Tu as peut-être des contre-exemples, mais personnellement je ne rencontre jamais de bibliothèque ou de projet qui utilise l'objet. Et même, j'ai vu très souvent des gens déconseiller l'utilisation de l'objet. Pour moi, l'objet n'est pas le principal intérêt d'OCaml.

Si j'ai à faire un projet sous Windows, par exemple un jeu, j'utiliserais F# sans hésiter. J'aurais bien trop peur de ne pas trouver de bibliothèque adéquate en utilisant OCaml. Ou de manquer de support lors de l'utilisation de la bibliothèque.

Envoyé par InOCamlWeTrust

J'étais justement avant-hier soir en train de me documenter sur les dernières évolutions du typage du langage... et bien il n'y a rien à faire, Objective Caml possède bel et bien le meilleur système de types au monde.

Il a pourtant un certain nombre de limitations...

Le fait que l'on ne puisse pas écrire par exemple une fonction qui prenne un nombre en argument (soit entier, soit flottant...) me semble être une limitation du système de typage.

Le fait que chaque structure doive avoir des noms de champs différents (et quand on en a beaucoup, c'est pénible), me semble en être une autre.

Il y a aussi le fait que l'on ne puisse pas écrire une liste de fonctions. Par exemple, ce code devrait pouvoir être exécuté :

Code :

1
2
3
let f () = Printf.printf "foo"
let g () = Printf.printf "bar"; 1
let list = [f; g] in List.iter (fun f -> ignore (f ())) list

Le fait que l'on ne puisse pas écrire de fonction avec un nombre variable d'arguments est aussi une limitation.

Comment écrire aussi une fonction qui renvoie le complément d'une autre fonction ? Exemple en Ruby :

Code :

1
2
3
4
5
# Builds a function that returns true
# when 'f' returns false, and vice versa.
def complement f
  lambda {|*args| not f.call(*args) }
end

En Caml, je peux l'écrire pour les fonctions prenant un argument ; mais comment faire dans le cas général ?

Autre exemple :

Code :

1
2
3
let trydef def f x =
  try       f x
  with _ -> def;;

Comment écrire cette fonction de façon plus générale ? Je ne veux pas me limiter aux fonctions à un seul argument.

Comment écrire une fonction prenant un tuple en argument et renvoyant son premier élément ?

Comment écrire une fonction prenant en argument un entier positif ? Ou un entier compris entre 10 et 20 ? Même Pascal permet de faire ça !

Le fait que le système de typage interdise la surcharge est aussi une limitation : OCaml doit être l'un des rares langages qui "oblige" à mettre l'information de type dans le nom même de la fonction : print_int, print_float, print_string... abs, abs_float...