Publicité
+ Répondre à la discussion
Page 2 sur 5 PremièrePremière 12345 DernièreDernière
Affichage des résultats 21 à 40 sur 86
  1. #21
    Invité de passage
    Inscrit en
    mars 2005
    Messages
    2
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 2
    Points : 2
    Points
    2

    Par défaut Choix du langage ...

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

  2. #22
    Membre Expert
    Avatar de InOCamlWeTrust
    Inscrit en
    septembre 2006
    Messages
    1 036
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 1 036
    Points : 1 265
    Points
    1 265

    Par défaut

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

  3. #23
    Invité de passage
    Inscrit en
    mars 2007
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : mars 2007
    Messages : 1
    Points : 4
    Points
    4

    Par défaut Et pourquoi pas un mix?

    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.

  4. #24
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 263
    Points
    1 263

    Par défaut

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

  5. #25
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro Nicolas Vallée
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 217
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Vallée
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 217
    Points : 17 566
    Points
    17 566

    Par défaut

    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
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  6. #26
    Membre Expert
    Avatar de InOCamlWeTrust
    Inscrit en
    septembre 2006
    Messages
    1 036
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 1 036
    Points : 1 265
    Points
    1 265

    Par défaut

    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 :

    Citation Envoyé par LLB
    - listes en compréhension (comme dans Haskell)
    On peut en faire une macro Camlp4...

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

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

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

    Citation Envoyé par LLB
    - le type Seq (comme une liste, mais paresseuse, donc potentiellement infinie)
    Cf.: -> 'a Stream.t... encore appelés les flots.

  7. #27
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 263
    Points
    1 263

    Par défaut

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

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

  8. #28
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro Nicolas Vallée
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 217
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Vallée
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 217
    Points : 17 566
    Points
    17 566

    Par défaut

    Citation 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

    Citation 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


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


    Citation 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

    Citation 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

    Citation 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"

    Citation 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

    Citation 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...
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  9. #29
    Membre Expert
    Avatar de InOCamlWeTrust
    Inscrit en
    septembre 2006
    Messages
    1 036
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 1 036
    Points : 1 265
    Points
    1 265

    Par défaut

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

  10. #30
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 263
    Points
    1 263

    Par défaut

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

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

  11. #31
    Membre Expert
    Avatar de InOCamlWeTrust
    Inscrit en
    septembre 2006
    Messages
    1 036
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 1 036
    Points : 1 265
    Points
    1 265

    Par défaut

    Citation Envoyé par LLB
    Code :
    1
    2
    3
    4
          INTEGER N
          DOUBLE PRECISION H
          H = 1 / N
    Clairement, c'est une erreur de typage.
    Non : c'est parfaitement autorisé en FORTRAN... tout comme en C !

  12. #32
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 263
    Points
    1 263

    Par défaut

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

  13. #33
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro Nicolas Vallée
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 217
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Vallée
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 217
    Points : 17 566
    Points
    17 566

    Par défaut

    Citation 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é
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  14. #34
    Membre Expert
    Avatar de InOCamlWeTrust
    Inscrit en
    septembre 2006
    Messages
    1 036
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 1 036
    Points : 1 265
    Points
    1 265

    Par défaut

    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.

  15. #35
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 263
    Points
    1 263

    Par défaut

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

  16. #36
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro Nicolas Vallée
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 217
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Vallée
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 217
    Points : 17 566
    Points
    17 566

    Par défaut

    Citation 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...
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  17. #37
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 263
    Points
    1 263

    Par défaut

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

  18. #38
    Membre Expert
    Avatar de InOCamlWeTrust
    Inscrit en
    septembre 2006
    Messages
    1 036
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 1 036
    Points : 1 265
    Points
    1 265

    Par défaut

    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

  19. #39
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro Nicolas Vallée
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 217
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Vallée
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 217
    Points : 17 566
    Points
    17 566

    Par défaut

    Citation 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


    Citation 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
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  20. #40
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 263
    Points
    1 263

    Par défaut

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

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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •