Discussion :

[funtix]

'soir.

Je voudrais apprendre un langage fonctionnel, mais je sais pas quoi choisir entre OCaml et Lisp ou Scheme...
Je voudrais m'orienter vers celui qui pourra réellement me servir pour mes développements persos et prototypages. Donc il est important que le langage soit répandu (libs, bindings), qu'il ait une communauté active (forum), qu'il y ait des livres et des outils (IDE en particulier) etc...

Sur tous ces points j'ai l'impression que l'on trouve davantage de choses pour Lisp/Scheme.

A plusieurs reprises, j'ai commencé à regarder OCaml mais, étant sous Windows, je me suis heurté à des difficultés qui font qu'à chaque fois j'ai abandonné. Cette fois-ci, j'espère bien aller jusqu'au bout.
L'environnement DrScheme m'a l'air plus simple.

J'ai tenté de peser le pour et le contre pour chaque langage, résultat : match nul.

• OCaml a un puissant compilo, qui permet de faire des exécutables rapides et de petite taille (meme au runtime). Je crois avoir lu qu'avec Lisp, les exe atteignent minimum 16Mo. Est-ce qu'il existe des compilos Lisp ou Scheme permettant de créer des applis qui tournent aussi vite que celles créées avec OCaml ? Si oui lesquels, si non à vu d'oeil combien de % plus lentes ?
• Le typage statique par inférence d'ocaml est intéressant pour coder bien du premier coup, mais contraignant également...
• La syntaxe de Scheme est vraiment simple et les constructions sont homogènes du peu que j'ai vu.
• Les macros intrinsèques à Lisp/Scheme ont l'air vraiment plus simples que celle en camlp4.

J'attends vos avis/témoignages argumentés...

[Eusebius]

à lire sur le forum :
[Résolu] Débuter en programmation fonctionnelle
[CAML] Dans quel(s) domaine(s) le langage caml est utile ?

[funtix]

Merci pour tes liens...
Le 2eme lien montre que l'on peut à priori tout faire avec CAML. Pour preuve MLDonkey. C'est en decouvrant MLDonkey que j'ai commencé a regarder CAML. Par contre quand est il de scheme/lisp ?

[millie]

La syntaxe de Scheme est vraiment simple et les constructions sont homogènes du peu que j'ai vu.

La syntaxe est peut être simple, mais personnellement, je trouve beaucoup plus simple à lire un code en OcamL (ce qui est également important pour la maintenance du programme).

J'ai appris les deux langages (un premier jet de camL en prépa, puis un jet de Lisp en école et je suis retourné vers camL/OcamL par moi même ensuite), et je prefère nettement plus OcamL que je trouve moins contraignant.

[funtix]

C'est clair qu'avec scheme il faut faire gaffe a bien indenter et faire de fonction de moins de 10 lignes, sinon apres avec l'imbrication de parenthese (et malgé des editeurs qui mettent en correspondance les parentheses) ca doit vite donner mal au crane.
Mais faut voir le bon coter! On est pousser a ecrire de petites fonctions, pleins de petites fonctions.

Sinon, vu que tu connais les 2, est ce que il y a autant de possibilité dans l'un comme dans l'autres ?

J'ai créé un programme de derivation de fonction (en me basant sur des exemples trouvés), une version caml et une version scheme. L'approche est differente en caml du fait du typage, mais dans les 2 cas, j'ai trouvé ca interessant.

[funtix]

Sur ce thread [CAML] Dans quel(s) domaine(s) le langage caml est utile ?, il est dit que caml est un language general que l'on peut tout faire avec. Qu'en est il pour Scheme ?

[millie]

Sinon, vu que tu connais les 2, est ce que il y a autant de possibilité dans l'un comme dans l'autres ?

Un langage fonctionnel (LISP, scheme et OcamL) est équivalent à une machine de Turing, donc on est capable de tout faire avec

Après, ça dépend du nombre de module existant dans chacun des langages. Il faudrait se renseigner sur ce point, mais je ne sais pas trop. Je pense que dans les deux langages, il doit y avoir des modules à peu près dans tous les domaines.

En camL, si tu fais du purement fonctionnel, tu te retrouves également à réaliser de petite fonction, mais la notation est souvent beaucoup plus clair (par exemple avec les notations de la forme : a::L pour les listes...). Parce que en LISP (je ne connais pas Scheme, mais apparement, ça doit être ressemblant), les listes sont certes plus puissantes (on peut directement créer des arbres binaires), mais je ne supporte pas la syntaxe Et je trouve mieux de bien séparer les fonctionnalités des objets comme en camL.


Par exemple, je trouve que la fonction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
let rec getVoisins g sommet = 
  match g with
  [] -> failwith "Accès à un sommet non existant"
 |(s, voisins)::reste -> if s = sommet then 
                             voisins
  			 else
			     getVoisins reste sommet;;

Devient imbuvable en LISP

[Gnux]

La syntaxe est peut être simple, mais personnellement, je trouve beaucoup plus simple à lire un code en OcamL (ce qui est également important pour la maintenance du programme).

J'ai appris les deux langages (un premier jet de camL en prépa, puis un jet de Lisp en école et je suis retourné vers camL/OcamL par moi même ensuite), et je prefère nettement plus OcamL que je trouve moins contraignant.

Je suis un fan de Scheme mais je suis vraiment d'accord. La lisibilité et le coté terse des ML est vraiment une force.
La syntaxe n'est pas bien compliqué non plus en Caml, il ne faut pas exagérer.

[millie]

La syntaxe n'est pas bien compliqué non plus en Caml, il ne faut pas exagérer.

Aaah, j'ai pas dit ça.

Je parlais de la syntaxe simple au sens : grammaire simple, analyse syntaxique simple.

Je disais que la syntaxe est Lisp (scheme) est simple mais que je trouve dur à lire.

[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]

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 :

- listes en compréhension (comme dans Haskell)

On peut en faire une macro Camlp4...

- 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 !

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

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

Cf.: -> Format...

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

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

[LLB]

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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]

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

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

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

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

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

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"

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

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]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.