Je comprends pas le pas dans les ranges Haskell 
En toute logique,
[2,4..10] devrait renvoyer [4,6,8,10] non ? Pourquoi ça renvoie [2,4,6,8,10] en d'autre termes pourquoi il ajoute le pas à la liste?
Et pourquoi si on fait [20,19..1] on a 1..20 en renversé? 
Sur une ligne ne veut pas dire plus court.
Théoriquement, tu as plus de charactère au total dans ta ligne de ruby que dans mon expression python de 6 lignes.
Richard > parce que j'ai fait bien plus que ça, j'ai aussi demandé explicitement les valeurs que je voulais récupérer dans le tas infini et les ai affichées, tout en illustrant comment les blocks en Ruby développent à la fois le principe des closures et des fonctions de première classe 
Le strict équivalent de ton snippet devrait grosso modo ressembler à ça :
(1..Float::INFINITY).lazy
Okay j'ai compris.
Il fait la différence entre les deux élements, crée une liste initiale avec les deux premiers élements puis rajoute la différence + le dernier élement jusqu'a ce qu'on arrive à la borne supérieure.
Bordel
Jamy > j'ai oublié de préciser, mais en apprenant le Haskell il est plus judicieux d'oublier tout ce que tu sais actuellement sur la programmation et l'algorithmique
Sauf la récursion. Ça tu vas en manger 
Oui enfin c'est bien connu le code Ruby est plus court que le code Python, j'aimerais bien comparer le temps d'execution des deux par contre 
J'ai acheté le bouquin sur le C++ de la noix ( ) Je pars un peu en vacance et je m'y remet au retour
Jamy > http://www.wikivs.com/wiki/Python_vs_Ruby#Speed
Source parfaitement fiable et totalement prouvée, n'insistez pas.
Tu peux te replonger dans ton Haskell
Franchement on s'est tapé les 25 premiers problèmes de project euler avec un pote. Moi avec Ruby (>2.0) et lui Python 3.
Bah résultat en temps d'execution il me niquait à chaque fois
Après comme tu as dis il y a peut être la méthode à utiliser en Ruby pour avoir un résultat optimisé, je pense principalement à inject dont je suis très friand et qui est très puissante mais très très lente 
Y'a déjà les refinements de Ruby 2.0 qui m'attirent si y'a aussi une **vraie** évaluation paresseuse ça va me faire venir encore plus vite.
Ruby faut pas s'y mettre si t'as envie de comprendre l'informatique. C'est très efficace mais y a beaucoup trop de wrappers.
Je fais en une ligne en Ruby ce que je fais en 20 lignes en C
Langages fonctionnels 
Merci Calet sans toi j'aurais attendu quelques mois avant de me lancer dans l'Objective CamL
Jamy > C'est le même principe que pour n'importe quel langage de haut niveau.
Et on peut toujours descendre : c'est pas avec du C que tu vas comprendre l'informatique, je fais en une ligne de C ce que je fais en 320 lignes d'assembleur
Et niveau wrappers, je trouve que c'est plus l'inverse : les débutants ont tendance à trop utiliser les boucles manuellement, alors qu'on a des collections d'itérateurs super complètes (ce que tu appelles wrappers) pour écrire du Ruby idiomatique.
Franchement, j'aime pas passer pour un gourou d'un langage particulier, mais arrêtez de blâmer le Ruby pour tous les maux en informatique, merde 
vava > non, pas que je sache. C'est un simulacre d'évaluation paresseuse, c'est pas vraiment complet (et c'est encore récent ; ruby s'oriente un peu vers le fonctionnel, ça s'améliorera peut-être).
Concrètement .lazy s'applique sur un énumérateur et retourne une sorte d'énumérateur (un objet Enumerator::Lazy) qui redéfinie les méthodes d'inspiration fonctionnelles classiques : map, each_<foo>, ...
Je suis désolé mais c'est la vérité, quand t'as des fonctions built-in qui fout tout le boulot à ta place tu comprends beaucoup moins. J'adore Ruby mais il faut lui attribuer que ce côté est un peu abusé, Python sur ce côté est déjà beaucoup plus viable.
Je t'invite à faire les problèmes du projet euler et de remarquer la certaines complexités de certaines enigmes pourtant résolues en 10 sec avec ce cheat qu'est Ruby.
D'ailleurs je connaissais pas l'évalution paresseuse non plus et c'est en effet assez efficace
"beaucoup plus"
Oklm svp 
Oui peut-être, mais juste avoir .lazy() comme ça ne sert pas à grand chose, donc ça veut rien dire.
Tu veux du vrai fonctionnel? Matte ça: http://pastebin.com/2fv9ZKuQ
Les listes de compréhension, vous connaissez ça en natif chez Ruby 
Calet en 100
Bordel le routage freebox ne fonctionne pas en IPv6 
Si c'est pas inciter les gens à revenir à l'ipv4 ça 
Mais on peut pas raisonnablement se plaindre du fait qu'un langage automatise certaines tâches répétitives à partir du moment où cette automatisation n'apporte aucun inconvénient technique ! Pour certaines, c'est même plus performant que leur équivalent à la main (je pense notamment aux :attr_<foo> qui sont en fait directement écrits en C alors que les setters/getters manuels sont interprétés comme du Ruby classique).
Pour l'anecdote, je pense pas non plus que Ruby soit le meilleur langage pour débuter, parce qu'il est tellement souple qu'on finit toujours par trouver la pire méthode pour résoudre un problème si on fait pas attention. Mais pour des développeurs ayant déjà un minimum d'expérience, je vois pas en quoi empaqueter les boucles dans des itérateurs dérivés ou des énumérateurs devrait poser problème
Et puis c'est pas comme si les structures originales étaient cachées, on peut toujours les utiliser si on aime réinventer la roue à chaque fois quand une solution éprouvée est déjà disponible.
C'est quand même incroyable de considérer un langage comme 'cheat' parce qu'il vise à simplifier le développement. Qu'on l'attaque sur le point des sacrifices qu'il fait pour ça, okay, mais là, l'histoire des wrappers, ça n'a que des avantages. C'est pas ça en soit qui ralentit l'exécution.
À ce moment-là on la mets où la barrière entre ce qui est okay et ce qui ne l'est pas ? Le C ou le C++ ont bien des fonctions utilitaires qui au final ne sont que des fonctions qui empaquettent d'autres fonctions plus primaires. C'est okay de les utiliser ou c'est du 'cheat' ?
D'ailleurs c'est marrant que tu parles du projet euler, parce que j'en ai fait aussi pas mal (une cinquantaine, mais discontinus), en Ruby, Haskell et C++. Et tu seras étonné de voir à quel point le Haskell simplifie la résolution de certains types de problèmes, notamment géométriques. Tu peux littéralement résoudre une bonne partie des 20 premiers problèmes en seulement quelques lignes de Haskell.
Richard > je suis pas un expert en Python, mais ce snippet c'est pas l'équivalent du premier pastebin que je t'ai montré ? 
Je sais pas vraiment ce qu'est une liste de compréhension donc pour le coup je peux pas te répondre. Tu peux détailler ? Je suis sûr qu'on a ça
Ce n'est pas cheat en soi mais ça gène l'apprentissage. Certains chercheurs de mon université trouvent même que le C est de trop haut niveau pour l'enseignement donc
Il ne s'agit pas de débuter, je pense qu'une fois que tu es sorti d'un cursus de 5 ans d'enseignement en Informatique alors tu peux utiliser Ruby. Dans le cas contraire c'est néfaste et non adapté. Je parle pour des personnes qui souhaitent apprendre l'informatique en tant que science.
La programmation ne se résume pas qu'a apprendre un langage puis traduire les concepts basiques qu'on a dans la tête dans ce langage particulier, une telle manière de faire est équivalente à de la traduction. Il faut assimiler les concepts si tu veux comprendre et être beaucoup plus effiace et percer dans le game.
La première pratique que j'ai cité est aussi connue sous le nom de "pissage de code"
Je t'invite à voir cette conférence quand tu auras le temps qui est extrêmement enrichissante: http://www.framablog.org/index.php/post/2013/06/11/francois-elie-education-conference
