Ce sujet est la suite du topic http://www.developpez.net/forums/d78...t-quen-pensez/, afin d'éviter le HS au sein de celui-ci.
Oulà, celà fait beaucoup de réponses d'un seul coup !
Bluestorm, le souci c'est qu'en fait à la base je viens du milieu Python, qui est un langage merveilleux mais qui pour le moment est VRAIMENT lent pour certaines applications.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.
Seulement, le C c'est bien mais je préfère les langages haut-niveau (et je n'ai de toutes façons pas les compétences pour produire du code C optimisé) et le paradigme fonctionnel m'intéressait. C'est pourquoi je m'y suis lancé, mais en cherchant cette fois un langage qui était quand même plus rapide, pour pouvoir faire des choses différentes, tout en découvrant ce que la prog fonctionnelle pouvait m'apporter.
Ne crois pas que je sois obnubilé par les performances, je ne demande pas la vitesse du C, je cherche justement maintenant à apprendre un langage un tant soit peu rapide, et Haskell m'a maintenant l'air tout à fait convenable.
Je préfère un langage clair et réfléchi et un peu moins performant plutôt qu'un langage pour lequel le développement est lourd mais où l'on peut - but at what cost? - avoir des perfs exceptionnelles, ne te méprends pas.
Concernant le quicksort, je ne l'ai pas testé moi même, je ne fais que citer des trucs que j'ai vu sur le net.
Sinon, oui, je parle bien de cette version :
Oui, j'aurais utilisé 'partition' plutôt qu'une double list-comprehension.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 qsort [] = [] qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x where elts_lt_x = [y | y <- xs, y < x] elts_greq_x = [y | y <- xs, y >= x]
Oui effectivement, c'est un exemple de ce type qui est utilisé par Real World Haskell pour introduire les 'seq', mais il n'était pas mentionné que ghc sait se rendre compte tout seul que l'évaluation stricte est mieux appropriée ici.
J'ai en effet compris l'importance d'utiliser un maximum les foncions standard au lieu de faire sa "récursion maison", par exemple.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.
Partager