Version imprimable
Bonjour,
je découvre ce forum (honte à moi...). J'ai fait de l'Haskell à la fac dans les années 90', et je viens de découvrir...... qu'il existerait un version Visual" ??
Je m'interroge sur les temps de calcul: j'ai un bon gros algo mathématiques (stochastique) gourmand en calcul en .net, et je me demande ce que cela donnerait sous Visual Haskell. Question peut-être débile, je ne suis pas MOE....
Quelqu'un pratique-t-il cette version?
Visual Haskell est basé sur GHC (the Glorious Glasgow Haskell Compiler), qui est actuellement le nec plus ultra en matière de compilateur Haskell. Dans certains cas on peut obtenir des performances proches du C.
Ce n'est cependant pas garanti et il y a de toute façon un surcout inévitable dû à l'évaluation paresseuse, bien que cette même évaluation paresseuse permette de gros gains sur la simplicité des programmes et de la modularisation.
Je n'ai personnellement jamais utilisé Visual Haskell, mais j'utilise principalement GHC et ses performances sont très honnêtes. :king:
Tout dépend de la nature de ton algorithme. N'hésite pas à reposer des questions sur des points plus précis si tu décides d'essayer. Si tu as déjà fait du Haskell, tu dois le savoir, mais je te préviens tout de même, Haskell est un monde un peu à part, c'est sans doute l'un des seul langage où la mailing-liste voit régulièrement des discussions sur la théorie des catégories... :aie:
--
Jedaï
Merci Jedai pour ce retour. Haskell remonte à très-très loin, mais du coté théorique j'ai mangé énormément de théorie des catégories (c'était mon "core" de recherches quand j'bossais à la fac).
Je vais te présenter en survol un exemple d'algo. Tu as une fonction avec ~ 50000 valeurs, et tu en veux une "approximation" par une fonction en escalier en 8 morceaux selon certaines fonction de coûts via des distances "quadratiques" par morceaux.
Nombres d'utilisateurs (allez, disons une cinquantaine) peuvent lancer en même temps ces calculs d'évaluation, non pas sur une seule fonction mais sur une collection de fonctions -- pouvant aller jusqu'à 500 --. 500 fois 50000, ça fait du bruit...
L'algo actuel en .net fonctionne "bien", il a été tuné à mort, mais on est toujours preneur d'une amélioration des perfs.
Je me demandais ce qu'Haskell pourrait donner.
Je pense qu'il est toujours possible de faire mieux que .NET (surtout depuis que ByteString a réglé le problème d'IO récurrent en Haskell) sur GHC, mais est-ce que ça vaudra vraiment le coup et est-ce que ce sera facile... probablement pas (surtout en face de .NET "tuné à mort") :?
--
Jedaï
tu me déconseilles donc la tentative?
Je te déconseille de te lancer dans une telle réécriture en t'attendant à obtenir des performances supérieures à ton implémentation en .NET facilement (si tu veux juste voir ce que ça donnerait en Haskell et les performances d'une implémentation naïve, c'est plutôt une bonne idée au contraire, ou si tu as du temps devant toi et que tu es prêt à faire des efforts (mais pourquoi ne pas le réécrire en C dans ce cas ? Ou au moins les parties critiques ?)).Citation:
Envoyé par Nemerle
Je te conseillerais par contre de te familiariser avec le Haskell d'aujourd'hui, c'est un excellent langage, plutôt performant par rapport à la plupart des langages de haut niveau plus ou moins comparable, et qui comporte un certain nombre de concepts qui sont de plus en plus reconnus et sont en train d'être introduit progressivement dans les langages "mainstream" (C#3.0 s'inspire pas mal d'Haskell). Je ne répèterais pas ici les arguments pour l'emploi d'Haskell, mais cet article en répertorie un certain nombre, il est un peu long et tu en as déjà entendu une bonne partie mais il reste intéressant. Pour un développeur familier avec les deux, je suis à peu près sûr qu'il est plus rapide et facile de développer en Haskell qu'en C#.
C'est gros et confidentiel au fait, ou je peux jeter un coup d'oeil à un bout du code pour te dire ce que j'en pense ?
--
Jedaï
Merci pour cet article, que je vais lire en détails!
Bein oui, désolé, c'est top confidentiel... mais je vais essayer de t'envoyer un truc par MP.Citation:
Envoyé par Jedai
Par ailleurs, repose moi la question à la fin de l'année et la réponse aura peut-être changé ! En effet Haskell connait un fort regain d'intérêt actuellement, et les performances de GHC s'améliorent rapidement, il reste encore un grand nombre de pistes qui devraient amener des améliorations importantes en terme de vitesse. On peut espérer se rapprocher du C pour un certain nombre de programmes. :D
--
Jedaï
Par exemple, si tu veux coder wc, Haskell est très bon !
(bouh, ils sont moches les smileys)
Ouaip, depuis qu'il y a ByteString du moins, parce qu'avant... *frémissement d'horreur* ;)Citation:
Envoyé par bluestorm
Evidemment l'exemple de wc est anecdotique, mais ByteString ne l'est pas : c'est une excellente bibliothèque de String et d'IO, et en passant le concepteur a mis au point une technique qui sera appliquée dans les prochaines versions de GHC et permettra d'avoir plus de fusions automatiques (des choses comme "map f . map g" qui devient "map (f . g)", en plus compliqué maintenant (ce cas trivial était déjà fusionné par GHC)), ce qui est toujours bon à prendre (en fait vu le style de programmation dominant en Haskell, c'est une très bonne nouvelle).
--
Jedaï
Tu parles des "stream fusions" ?
(faudrait que je regarde ça un jour)
Au fait, et que dites-vous de Linq???????
[Edit] Arghhhhhhhhhhhhhh!! c'est mon 666 messages!!!!!!!!!!!!!! [/Edit]
Ca a l'air très sympa, du sucre syntaxique bien agréable, reste à voir à l'usage si l'interface avec le reste du langage est si bien foutue que ça. :DCitation:
Envoyé par Nemerle
--
Jedaï
Effectivement, il est maudit :lol:Citation:
Envoyé par Nemerle
Jedaï >> Que signifie exactement cette expression de "sucre syntaxique" qu'on retrouve à tout bout de champ dans le monde fonctionnel
cf « Syntactic sugar causes cancer of the semi-colon. »
Le "sucre syntaxique" n'est pas du tout spécifique du "monde fonctionnel", on peut en trouver dans n'importe quel langage. Il s'agit d'une syntaxe qui n'est là que pour la convenance du programmeur, mais qui est en réalité traduite pour le compilateur en une forme plus régulière mais moins agréable à l'oeil/pratique.Citation:
Envoyé par Trap D
Linq est un tel sucre syntaxique parce qu'il s'agit d'une syntaxe entièrement nouvelle (et qui ne correspond pas au reste du langage) qui est en fait traduite en sous main par des appels de méthodes. L'exemple canonique du sucre syntaxique, c'est les "list comprehension", autrement dit les générateurs de listes, qui se présentent sous différentes formes dans un nombre croissant de langage. Haskell a été l'un des premier à les introduire, et ils s'y présentent sous cette forme :
génère la liste des triplets pythagoricien dont la somme des membres est 1000 (il n'y en a qu'un seul à vrai dire). (ce code est très naïf, ce n'est qu'un exemple)Code:[ (a,b,c) | a<-[1..998], b<-[a..999], c<-[b..1000], a^2 + b^2 == c^2, a+b+c == 1000]
Ce code peut-être "désucré", et c'est sous cette forme plus régulière qu'il sera en réalité compilé.
est ainsi traduit en :Code:[ x^2 | x<-[1..1000], even x]
à peu près (pas tout à fait mais presque).Code:map (^2) $ filter even $ enumFromTo 1 1000
--
Jedaï
Bein je te dirais ça dans quelques temps on va migrer une appli en .net 3.5 + Linq....Citation:
Envoyé par Jedai