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
Oz/Mozart, qu'en pensez-vous ?
Salut ! Je voulais savoir si il y avait ici des gens qui connaissaient bien le Oz.
En fait, ce langage me semble intéressant, mais j'aimerais connaître les avis (positifs comme négatifs) de ceux qui l'ont déjà bien testé.
[GrosAPriori] A première vue, il m'a paru comme quelque chose qui mélange du Prolog et du Erlang. [/GrosAPriori]
Bien testé ça n'est pas vraiment mon cas.
Il est sans doute intéressant pour qui veut réunir tout ce qui est déclaratif en un seul langage.
À mon avis ce langage souffre de ce que le typage dynamique est un peu passé de mode en programmation fonctionnelle (alors que parallèlement il revient à la mode du côté langages impératifs).
Il y a aussi un risque lié à l'intégration fonctionnel-logique : non seulement l'apprentissage est difficile mais en plus l'expérience ne sera pas toujours adaptable dans un autre langage (même un de la même "famille", du genre lambda-prolog).
Du même auteur: mon projet, le dernier article publié, le blog dvp et le jeu vidéo.
Avant de poser une question je lis les règles du forum.
Mmm... Oui, mais comme on a là des variables à unification (i.e. qui n'ont initialement pas de valeur et qui, une fois qu'elles en ont une, ne peuvent pas en changer), le typage dynamique n'a pas le même sens qu'en impératif (ou une même variable peut allègrement passer de int à liste et caetera).Envoyé par SpiceGuid
Le mécanisme d'attachement (passage en paramètre, assignation, unification) n'entre pas en compte, ce qui compte c'est que l'attachement soit sécurisé ou non.
Une variable non typée peut s'unifier avec n'importe quelle expression, tu peux très bien l'unifier un fois avec un int et une autre fois avec une liste. C'est le principe même d'une variable qu'elle n'a pas la même valeur d'un attachement à un autre.le typage dynamique n'a pas le même sens qu'en impératif (ou une même variable peut allègrement passer de int à liste et caetera)
Du même auteur: mon projet, le dernier article publié, le blog dvp et le jeu vidéo.
Avant de poser une question je lis les règles du forum.
J'ai lu le CTM et j'ai vraiment été séduit. Je n'utiliserais pas Oz pour coder quelque chose (d'ailleurs je n'en ai pas écrit une ligne en lisant le livre), mais je pense que ça m'a apporté des choses.
L'unification est un concept très séduisant. Le traitement des objets est intéressant (même si j'ai préféré un traitement plus orienté vers le typage comme dans le TAPL), le traitement de la concurrence passionnant.
Ce qui est séduisant dans le CTM, Oz et les travaux de Peter Van Roy dans leur ensemble, c'est l'approche multi-paradigme au vrai sens du terme : un grand nombre de paradigmes (pas juste 2 ou 3) sont présentés dans un cadre unifié, leurs spécificités et différences comparées, avec des différences très fines (concurrence avec et sans nondéterminisme par exemple). Tout cela est permis par la grande flexibilité du langage, construit par couches successives.
Si vous voulez un aperçu du travail sur les paradigmes, vous pouvez regarder le paper Programming Paradigms for Dummies (pdf). Il reprend une partie des explications du CTM. À mon avis elles sont trop réduites et moins compréhensibles, mais c'est toujours plus court qu'un livre de 1000 pages.
Pour ce qui est du débat statique/dynamique, je pense que l'exploration de l'espace des fonctionnalités n'aurait pas été possible avec un langage statiquement typé : en plus de la théorie du langage des termes, il faut développer le langage des types, ce qui augmente quand même nettement l'effort nécessaire, et aurait sans doute transformé le tour de force d'Oz en mission impossible (à faire d'un seul coup).
En résumé, Oz pour moi c'est comme Haskell : excellent à apprendre, pas indispensable pour programmer. Oz a sans doute encore moins d'utilisations pratiques que Haskell (moins d'utilisateurs, moins de support, moins de libs), par contre il bénéficie de l'excellent CTM : je n'ai toujours pas rencontré d'ouvrage Haskell qui soit à la hauteur.
Parce qu'il y a des langages indispensables pour programmer ? Je comprends ce que tu veux dire mais généralement je présente plutôt ce type de langage comme ça : Un langage dont l'apprentissage vous rendra meilleur programmeur, même si vous ne l'utilisez jamais plus par la suite.
Nettement meilleur que "Real World Haskell" ? (juste pour l'information, je ne mets pas ta parole en doute, ce n'est pas si difficile d'être meilleur que RWH)
Par ailleurs je pense qu'il faut prendre des pincettes avec l'aspect "pratique" d'Haskell vu l'explosion actuelle du nombre de librairies et l'augmentation du nombre d'utilisateurs. Tu te rend compte que quand j'ai commencé Haskell, Hackage n'existait pas et qu'elle contient maintenant plus de 1250 librairies ?
Surtout que Oz intègre encore plus de paradigmes que cela ! Pour un pur mélange fonctionnel/logique, Curry est sans doute un meilleur exemple.
--
Jedaï
Pour moi RWH et le CTM n'ont pas du tout la même portée. Le CTM est un livre qui décortique différents paradigmes en discutant de leurs avantages et inconvénients respectifs, et des choix de design que peuvent/doivent faire d'un côté les concepteurs du langage et de l'autre les utilisateurs. Tu trouveras par exemple une discussion sur la manière dont représenter (~ implémenter) des Abstract Data Types de plusieurs manières différentes et leurs avantages/inconvénients respectifs, un encodage des objets, une présentation de la concurrence déclarative déterministe, des futures, etc. Il y a bien sûr des exemples de codes, mais ils sont là pour illustrer des concepts fondamentaux et tu les oublies rapidement.
Le RWH (que j'ai survolé à plusieurs moments de sa conception mais jamais lu en entier) est beaucoup plus pratique : il va t'apprendre comment parser du JSON ou utiliser la FFI, ce qui est bien si tu veux pratiquer du Haskell, mais n'est pas la manière la plus directe de découvrir les choix profonds du design du langage Haskell. S'il y avait un équivalent de CTM en Haskell, je pense qu'il présenterait des choses comme :
- une présentation en longueur de l'évaluation paresseuse, de ses spécificités, avantages et inconvénients, et un ensemble de principes abstraits permettant de déterminer quand il faut choisir plutôt strict ou plutôt paresseux dans une situation particulière (si cela existe)
- une présentation en longueur du choix de la pureté et de ce que cela apporte ou retire du langage; une présentation objective des monades, avec leurs avantages et aussi leurs inconvénients (qui sont très présents et rarement évoqués par les Haskelliens); encore une fois une discussion des avantages et inconvénients des monades par rapport aux autres manières de faire la même chose (ça se trouve en partie dans le paper sur l'histoire de Haskell de Peyton-Jones, et le très bon "Monads for functional programming" de Wadler)
- une présentation des type classes et une comparaison aux autres méthodes de permettre la programmation modulaire et la réutilisation (les modules ML en particulier)
- des excursions dans des domaines plus avancés comme les extensions de typage, en lien avec la question de la décidabilité de l'inférence de type, ou les méthods de concurrences facilitées par le design de Haskell
En gros, un truc beaucoup plus "principled". CTM et RWH n'ont pas du tout les même usages, mais pour quelqu'un qui veut étendre son point de vue sur la programmation en découvrant un langage je crois que CTM est beaucoup plus intéressant. Pour faire une comparaison, je vois un peu le CTM comme une version modernisée et étendue du SICP : ça t'apprends plein de choses sur la programmation en général, et aussi le Scheme/Oz. Je pense (sans avoir entièrement lu le SICP non plus) que le CTM présente plus de choses, et des choses plus intéressantes par rapport aux pratiques de programmation d'aujourd'hui (parce qu'un évaluateur méta-circulaire reste un accomplissement remarquable mais c'est pas le genre de choses que tu vas réutiliser dans ta pratique et/ou un autre langage).
C'est clair, RWH est carrément axé sur la pratique, il ne t'explique pas le pourquoi du comment du langage, et je n'ai jamais vu un autre cours Haskell qui t'explique comment parser du JSON ^^. Mais je pense que c'est une bonne chose, vu que le monde impératif a une sale tendance à voir les langages fonctionnel comme des "joujoux académiques de matheux" (croyance étoffée par tous les beaux algos de fibonacci, factiorelle et quicksort qu'on trouve à chaque présentation du langage)
Concernant Oz (enfin, Mozart), un truc qui m'intéresserait ce serait de connaître ses perfs (je sais qu'Haskell par exemple c'est pas sa qualité majeure...)
Oz est un langage qui tourne sur une machine virtuelle, ses performances sont donc moins bonnes que celles d'un langage compilé en natif, mais l'implémentation est très correcte donc les performances raisonnables. D'après ce message, ce serait comparable au bytecode OCaml.
En gros, Oz est pour les problèmes généraux plus performant qu'un langage de script, moins performant qu'un langage natif, et raisonnablement comparable aux autres langages à VM raisonnables (lua, erlang, Neko, etc.).
Si tu es intéressé par les performances brutes, tu devrais peut-être aussi t'intéresser à Alice ML, qui est un peu le penchant typé de Oz et qui a continué à travailler sur les performances, avec par exemple du travail sur du JIT ou ce genre de choses.
Le shootout n'est bien sûr pas une mesure parfaite, mais il te donne une idée, regarde les rangs de Haskell et d'Oz/Mozart (au fait pourquoi crois-tu qu'Haskell a des performances médiocres ? GHC est justement l'un des meilleurs compilateurs dans son domaine) ou cette comparaison, une comparaison avec OCaml compilé donnerait à peu près les mêmes résultats.
En résumé, c'est un interpréteur plutôt performant (pour un interpréteur) ou une VM peu performante, mais ça s'explique vu le nombre de fonctionnalités à supporter.
--
Jedaï
Oui, enfin, Oz étant conçu pour être distribué c'est sur que si ils le font tourner avec peu de threads, même sur un quad-core, c'est moins efficace.
EDIT: C'est bien ce que je pensais: sur les 13 benchmarks seul DEUX utilisent des threads ! (chameneos-redux et thread-ring, et COMME PAR HASARD c'est chameneos-redux qui est le plus rapide) Est-ce que les mecs qui font ces benchmarks savent vraiment utiliser tous les langages ?
Effectivement. Au vu des benchmarks (il rivalise avec OCaml, on dirait. J'ai toujours entendu dire qu'OCaml était plus rapide), on va dire que c'est moi qui sait pas m'y prendre comme il faut.
EDIT: Truc dont je viens de me rendre compte : la différence de vitesse entre une fonction Haskell compilée dans un exécutable et la même fonction utilisée en interpréteur interactif est gigantesque ! Par contre, je vois pas trop la différence de vitesse selon si l'on compile avec -O2 ou pas...
A vrai dire, je suis en train de découvrir les automates cellulaires, et je tente de faire marcher ça bien avec Haskell. Ne sachant pas trop comment m'y prendre, je regarde sur le net, mais à chaque fois c'est une solution soit peu performante soit peu adaptable : je cherche à ce que mon prog puisse gérer facilement et efficacement aussi bien des automates 1D que 2D ou 3D. Un algo rapide est le HashLife, qui marche pour le jeu de la vie, mais je ne sais pas si il marche pour tous les types d'automates discrets (i.e. pas les automates à espace continu, je vais pas pousser jusque là non plus). Ou bien je ferai peut-être mieux de finir Real World Haskell avant de m'attaquer à ça, qu'en penses-tu ?
-O2 est parfois nettement plus rapide que -O1, il est possible qu'il ne fasse pas grand chose sur ton programme, mais statistiquement il va plus vite.
Et il est certain que l'Haskell compilé va infiniment plus vite que l'interprété : le but de l'interprété est de pouvoir tester son programme, ses fonctions au plus vite, donc il ne fait absolument aucune optimisation, or pour un langage comme Haskell, si on ne fait pas au moins une analyse de mode d'appel (strict ou paresseux), tu as des performances déplorables.
J'en pense que si tu as un problème spécifique, tu devrais l'exposer sur notre forum Haskell pour qu'on te fasse des propositions, ou venir discuter avec nous sur #haskell.fr (ou #haskell si tu es à l'aise en anglais) ou haskell-cafe (la mailing list). L'un des avantages d'Haskell actuellement, c'est sa communauté très sympathique.
--
Jedaï
Oui, oui. Faut vraiment que j'apprenne le profiling en Haskell avant de me lancer dans des trucs compliqués. Mais attends, tu veux dire que, via les optims, c'est GHC qui fait l'analyse de mode d'appel pour déterminer si tel ou tel code doit être appelé de façon lazy ou stricte ? Ca ne reste pas à la charge du développeur ?
Concernant GHCi, je pensais que lorsque je lui demandais de charger un module que j'avais déjà compilé avant il ne réinterprétait pas tout.
C'est vrai que c'est un avantage que l'on cite souventL'un des avantages d'Haskell actuellement, c'est sa communauté très sympathique.
Non. Augmenter le nombre de coeurs ne peut pas rendre les opérations de base d'un langage plus rapides. Si Oz est lent comparativement à d'autres langages avec un seul flux d'exécution à la fois, ses opérations resteront plus lentes sur plus de coeurs. Au mieux (sans changer d'algorithme) la vitesse sera multipliée par le nombre de coeurs, mais la vitesse des opérations de base n'augmentera pas.Oui, enfin, Oz étant conçu pour être distribué c'est sur que si ils le font tourner avec peu de threads, même sur un quad-core, c'est moins efficace.
Alors effectivement, si tu augmentes beaucoup le nombre de coeurs il pourrait se trouver à battre d'autres langages qui n'ont pas, ou on mal implémenté le parallélisme, mais ça ne rend pas Oz "efficace" pour autant, c'est juste que les autres ne sont pas adaptés au parallélisme.
La différence c'est surtout que le code Haskell, pour un certain nombre de raisons liées au design du langage, a des performances très "sensibles", dans le sens où de petites modifications sur le code peuvent avoir de très grandes conséquences sur les performances, sans forcément que tu saches pourquoi si tu ne connais pas toutes les subtilités du langage d'une part, et du compilateur d'autre part, qui (GHC) est effectivement très malin, mais du coup est souvent assez imprévisible si tu ne connais pas bien son fonctionnement interne. Un programme Haskell bien écrit, d'une manière à la fois haskell-friendly et ghc-friendly, peut profiter des très bonnes capacités d'optimisation de GHC et être très rapide (basiquement, aussi rapide que du C pour faire la même chose, sachant que le programme en C est souvent considérablement plus chiant à écrire). Le problème c'est qu'en général quand une personne normale écrit un programme il n'est pas "bien écrit" dans ce sens là : soit c'est par hasard, soit c'est parce que le programme est particulièrement court (ce qui permet à une personne au cerveau normalement développé d'avoir une image mentale correcte de l'ordre d'évaluation dans ce cas), soit c'est parce que l'auteur est un spécialiste reconnu en optimisation Haskell/GHC depuis 5 ans. Tu peux par exemple aller voir sur la Planet Haskell, certaines personnes savent bien optimiser leurs codes et en parlent (le type qui bossait sur la supercompilation par exemple), d'autres tatonnent avec leurs outils de profiling, en essayant un peu au hasard jusqu'à qu'une des personnes de la première catégorie vienne leur sauver la vie en postant un commentaire éclairant.Effectivement. Au vu des benchmarks (il rivalise avec OCaml, on dirait. J'ai toujours entendu dire qu'OCaml était plus rapide), on va dire que c'est moi qui sait pas m'y prendre comme il faut.
Au contraire, la compilateur OCaml est très "bête" : il a une représentation efficace des données, un GC sophistiqué etc., mais ne fait pas beaucoup d'optimisation et tout le monde sait ce qu'il compile bien (entre autres les boucles, les appels directs de fonction, la tailrec, les tableaux de flottants, les filtrages de motifs et les appels de méthodes) ou mal (les applications de foncteur). Il est donc nettement plus facile d'écrire du code qui a de bonnes performances, et même quelqu'un qui ne connaît pas les détails de son compilateur (à part qu'il implémente la tailrec) peut le faire.
C'est pour ça que le ressenti général est que les performances des programmes OCaml sont plus fiables : on a rarement de mauvaises surprises, ou de surprise tout court. Après, il y a aussi la question de la tête du code résultat : si le compilateur OCaml n'optimise pas à travers les optimisations de foncteur, ça pousse les gens à ne pas trop utiliser de foncteurs, donc limite l'abstraction, ce qui n'est pas très bien pour le langage. Le compilateur GHC ne fonctionne pas aussi simplement et certains programmes très haut-niveau et abstraits peuvent être très bien optimisés et au final très performant (une grande partie des optimisations de GHC est là pour que le code abstrait ne soit pas pénalisé). Cependant, si tu regardes le code des benchmarks Haskell, tu vas voir que certain sont écrits dans un "bon style" (du beau Haskell qui en plus compile bien), mais que d'autres sont quand même massacrés.
Je trouve ça pas mal dommage, justement. Premièrement parce que d'après ce que tu me dis, on doit connaître les rouages de GHC (et ça d'un point de vue abstraction c'est pas la joie), et deuxièment parce que GHC, ce n'est pas la seule implémentation de Haskell existante, ok c'est celle qui est majoritaire mais quand même. Je ne comptais pas en utiliser une autre, mais quid des gens qui utilisent yhc ou jhc ? (je mets hugs à part, étant donné qu'il s'agit d'un interpréteur)
Mais c'est quand même engageant parce que - selon tes dires - un code abstrait et haut-niveau (et donc plus agréable à coder) pourrait être plus performant que son équivalent bas-niveau.
Cependant, un exemple récurrent de fonction en Haskell (cf page wikipédia) c'est son fameux quicksort de 5 ou 6 lignes. Il est classe, abstrait car exprimé d'une manière quasi-humaine et mathématique, mais à chaque fois qu'on nous le présente on nous dit : Attention, ce code sera lent, gnagna... non optimisé, gnagna... multiples copies de listes... C'est quand même rageant.
Plus performant, non, pas au sein d'un même langage. Au mieux en rajoutant de l'abstraction tu ne perds pas en performances, mais c'est déjà très bien.
Edit : après il y a des manières d'écrire quelque chose qui sont plus propices aux optimisations (par exemple si tu utilises les capacités de stream fusion de GHC tout ça), mais je ne vois pas ça comme des augmentations de l'abstraction.
Au sujet des spécificités GHC, il faut que tu comprennes quelque chose : GHC est la seule implémentation utilisée de Haskell. Les gens qui codent autre chose font beaucoup de bruit, et sont certainement très compétents, mais personne n'utilise leurs outils. Le mieux qu'ils puissent espérer c'est que leur travail soit au final intégré à GHC. GHC est codé par les gurus Haskell, payés par Microsoft, donc il est assuré de survivre pour encore un temps, et il étend énormément le langage de façon pas forcément compatible avec les autres implémentations (même s'ils sont très bien pensants et essaient d'uniformiser ça entre eux). Beaucoup de code produit aujourd'hui dépend (plus ou moins fortement) d'extensions de GHC et les autres implémentations ne sont qu'un mirage. À la rigueur je sais que Hugs est un peu utilisé dans l'implémentation, sans doute parce que le toplevel de GHC (ghci) est en pratique complètement inutilisable, alors que c'est un outil crucial pour certaines pratiques d'apprentissage.
Pour ce qui est du code de quicksort, je trouve que tu exagères un peu. Oui il fait deux parcours du tableau, mais ça ne change pas ses performances de manière dramatique. Effectivement on peut faire plus rapide (et même en restant haut niveau, avec une fonction de partition qui fait la même chose en un seul parcours), mais ça reste acceptable, et si le code est simple à écrire et à comprendre ça peut être le meilleur choix.
Il faut bien voir que la prog c'est pas qu'une histoire de performances brutes, l'important c'est d'arriver à ton but (résoudre un certain problèmes dans certaines contraintes de ressources) de manière simple et fiable. Si une partie de ton code qui n'est pas utilisée très souvent est un peu lente, mais codée si clairement qu'on y voit immédiatement tous les bugs, ça peut être un bien meilleur choix qu'un truc subtil codé dans un langage bas niveau et qui va très vite (dans l'exemple du quicksort, tu connais sans doute l'algo impératif avec remplissage du tableau dans les deux sens, la manipulation des pointeurs/indices est quand même nettement plus source d'erreur que l'impl. Haskell).
Après il faut se méfier des "fausses belles écritures", des choses qui ont l'air très jolies mais qui sont en fait asymptotiquement plus mauvaises que le vrai algorithme (ce sont donc des faux). Les Haskelliens ont historiquement produit ou popularisé une certaine quantité de ces arnaques, à commencer par le célèbre faux crible d'eratosthene.
Globalement je trouve que le profil de toi qui se révèle dans ce fil, c'est que tu es trop attaché aux performances. Je ne sais pas qui tu es et ce que tu veux faire (il y a des gens qui font de l'embarqué et qui ont vraiment besoin d'optimiser les perfs au maximum au détriment du confort), mais il y a de fortes chances que tu t'en soucies trop et que ça risque de nuire à ta pratique. Prendre en compte les performances d'un langage quand on le choisit pour faire quelque chose, c'est normal, mais si c'est ton seul/principal critère de choix et que la lecture d'un shootout peut te faire changer d'avis sur les choix à prendre (sur des choses qui finalement se valent plus ou moins), je pense que tu as un problème.
Le développeur peut forcer une évaluation stricte où il le souhaite, dans ce cas GHC ne la rendra pas paresseuse (même si ça améliorait les performances, cas relativement fréquent pour ceux qui rajoutent trop d'annotation stricte). Ce que GHC fait, c'est analyser ton code pour voir où une évaluation stricte ne pourrait qu'améliorer les choses sans changer la sémantique, il est donc conservateur et n'optimise que s'il est sûr que ça ne ralentira pas ton programme et ne changera pas son sens. Un exemple simple :
Ce code est par défaut relativement plus inefficace que s'y attendrait un habitué des langages stricts avec TCO : en fait l'accumulateur n'est pas évalué à chaque appel de go (puisque ce n'est pas nécessaire) et accumule un "thunk" (une expression pas encore évaluée, en mémoire) d'une taille proportionnelle à la taille de la liste... Cela peut même entraîner un dépassement de pile lorsque le thunk doit finalement être évalué (puisqu'à ce stade il faut empiler un tas de (+) d'un seul coup, vu que (+) est strict).
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5sum :: [Int] -> Int sum = go 0 where go acc [] = acc go acc (x:xs) = go (acc+x) xs
Si tu actives les optimisations, GHC s'apercevra que faire (acc+x) immédiatement est une bonne idée à tout point de vue, donc il rendra go strict en ce paramètre (éliminant du même coup le risque de dépassement de pile et améliorant les performances considérablement).
Tout à fait, si GHCi trouve une version compilée plus récente que le source du module, il utilise la version compilée, donc profite de ses performances.
Si tu as besoin de performances exceptionnelles, effectivement connaître bien GHC est un plus, mais en général une simple réflexion sur le modèle d'évaluation d'Haskell, les structures de données et l'algorithme suffisent largement à obtenir des performances plus que potables (incomparable avec tout ce qui se fait dans le domaine des langages de script par exemple, avec une concision équivalente et des vérifications statiques plus importantes).
Pas plus performant, soyons clair : on peut toujours faire plus performant avec du bas-niveau, mais à quel coût ? Un code Haskell sera souvent 10 à 20 fois plus petit que son équivalent en C, pour une différence de performance de seulement un facteur 2 à 5, et avec une fiabilité bien supérieure. Exceptionnellement, tu pourras avoir des codes aussi performant que du C, voir plus performant que du C utilisant naïvement les fonctions standards. De plus le temps dégagé signifie que tu as des chances de peaufiner les algorithmes, ce qui peut avoir des conséquences autrement importantes pour les performances.
Tu parles de :
??
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
Ce code présente plusieurs problèmes, à ce sujet tu peux lire cette article. Néanmoins, il est parfaitement clair, et pas si lent que ça : ne pas oublier qu'il est ici utilisé sur une liste chainée, pas sur un tableau, pas mal de gens semble oublier ça et s'attendent à obtenir des performances comparables au quicksort de tableau de leur librairie en C, lequel est généralement une version extrêmement raffinée, changeant par exemple d'algorithme de tri pour les petits tableaux, avec une sélection aléatoire du pivot, etc... occupant largement plus que 4 lignes, et bien plus difficile à vérifier. On peut écrire un quicksort tableau efficace en Haskell, si c'est ce que l'on souhaite.
Généralement cela coïncide néanmoins : le but des systèmes de fusion est de permettre d'utiliser de long pipeline de fonctions d'ordre supérieur sur une structure de donnée sans perdre en performance par rapport à une fonction tout-en-un implémenté avec de la récursion directe. Je considère que cela autorise un style plus abstrait (et à mon goût souvent plus lisible). Bien sûr le résultat n'est pas toujours parfait, mais l'initiative est intéressante.
Je ne dirais pas qu'elle ne sont qu'un mirage, je dirais qu'elles permettent des expériences que la lourdeur et l'ampleur de GHC prohibe, en tant que tel elles jouent un rôle important dans les progrès d'Haskell, même si GHC est le seul compilateur à utiliser en production.
GHCi est parfaitement utilisable, au moins autant que Hugs (il est même mieux maintenant), Hugs a principalement persisté parce qu'il était plus léger et simple à installer pour les enseignants/étudiants et qu'il fournissait pendant un temps de meilleurs messages d'erreur. Ce n'est plus le cas aujourd'hui et il n'y a vraiment pas trop de raison d'utiliser Hugs, même pas WinHugs, depuis que WinGHCi a vu le jour.
--
Jedaï
Désolé du lapsus, je voulais dire "utilisé dans l'éducation". Et, pour voir des gens qui utilisent encore Caml Light à grande échelle, je sais que dans l'éducation on reste souvent coincé avec des solutions logicielles du siècle précédent :p
GHCI est quand même inutilisable, dans le sens où on ne peut pas faire de Haskell sérieux dedans. Tu connais sûrement le toplevel OCaml, c'est le jour et la nuit à côté. GHCi est très bien pour demander le type d'une fonction ou la kind d'un type, en gros il joue le rôle de substitut de lambdabot en local, avec cependant beaucoup moins de features. Par contre dès que tu veux déclarer des fonctions et jouer un peu, c'est la fin des haricots. D'une part la syntaxe n'est pas la même que dans du code normal (introduction des let, super pour le débutant...), en plus il ne type pas pareil (genre tu te fais rejeter sur des type-classes, tu commences à flipper sur la monomorphism restriction, avant de te rencontre que dans un .hs normal ça type exactement comme tu veux), etc. Pour moi c'est pas utilisable.
Pour ce qui est de qsort, je pense qu'il faisait référence à la version sans "partition" qui utilise deux compréhensions, qui est la version la plus connue.
Comme d'autres l'ont déjà dit, la question de la performance ne se pose pas vraiment pour Oz/Mozart dans le sens où la performance ici c'est d'intégrer harmonieusement plusieurs paradigmes (dont certains à usage assez spécialisé) dans un langage noyau très cohérent.
Dans le cas où Oz te faciliterait la recherche opérationnelle en fournissant de meilleurs outils pour restreindre l'espace de recherche, tu réaliserais vite qu'un facteur 5, 10 ou 20 sur les performances n'est qu'une constante, ça compte toujours moins qu'une exponentielle.
Sinon, dans le cas où tes programmes sont plus calculatoires qu'exploratoires l'intérêt de Oz/Mozart devient plus éducatif que pratique.
Du même auteur: mon projet, le dernier article publié, le blog dvp et le jeu vidéo.
Avant de poser une question je lis les règles du forum.
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