Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
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 ...
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).
When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.
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.
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.J'avoue que la syntaxe m'est plus familère, mais est elle aussi puissante que ocaml?
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.Envoyé par loupvaillant
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.
Et que penses-tu de F# ?Tout le reste, c'est du ... mis à part peut-être SML, et encore...
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.
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
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 :
On peut en faire une macro Camlp4...
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 !
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.
Cf.: -> Format...
Cf.: -> 'a Stream.t... encore appelés les flots.
When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.
C'est quand même vachement avancé pour un jouet. Mais je suis d'accord que le langage manque encore de maturité.
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.
Quand on compare, la différence est flagrante :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 !
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.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
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.
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.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.
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.
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) ?Cf.: -> Format...
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).
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
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 :Cf.: -> 'a Stream.t... encore appelés les flots.
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.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
+1, mais les détracteurs peuvent se tourner vers menhir
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
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...
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
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
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"
Je suis d'accord qu'il manque cette fonctionnalité... qui au fond n'est utile qu'en phase de conception/debug
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...
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
2
3
4
5
6
7
8
9
10C 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.
When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.
Ces cas sont très rares. Mais si jamais ça pose problème, les opérateurs "+.", "*." et autres sont toujours disponibles.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...
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.
Parce qu'il y a beaucoup d'abus en C++.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
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).
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é.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
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) ?
Pour Obj.magic, je suis d'accord.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...
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.
Clairement, c'est une erreur de typage.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4INTEGER N DOUBLE PRECISION H H = 1 / N
Pour l'opérateur '/', les surcharges dans F# sont (c'est pas exhautif, mais tu vois l'idée) :
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.".
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
OK, je préfère donc l'approche de F#. C'est plus naturel.
Comment ça ?- des listes en compréhension (donc éventuellement très longues et dont on ne peut pas réellement en contrôler finement la construction)
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à.
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).
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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 deuxième exemple, c'est encore une fois bien plus joli qu'en Caml. Et ça reste clair et lisible.
Non : c'est parfaitement autorisé en FORTRAN... tout comme en C !
When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.
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 !).
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é
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.
When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.
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.
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).
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
When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.
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
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
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.
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é :
Le fait que l'on ne puisse pas écrire de fonction avec un nombre variable d'arguments est aussi une limitation.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
Comment écrire aussi une fonction qui renvoie le complément d'une autre fonction ? Exemple en Ruby :
En Caml, je peux l'écrire pour les fonctions prenant un argument ; mais comment faire dans le cas général ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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
Autre exemple :
Comment écrire cette fonction de façon plus générale ? Je ne veux pas me limiter aux fonctions à un seul argument.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
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...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager