Yusei a écrit 4649 commentaires

Je connais des gens qui sont très contemplatifs, lorsque confrontés à un gros 4x4 flambant neuf.

Il y a peu de points communs entre un 4x4 en ville, un téléphone portable et une guirlande de Noël. Au niveau de l'utilisation aussi bien qu'au niveau de la pollution.

Qu'est-ce que ça veut dire, avoir besoin d'un téléphone portable ? Dans l'absolu, personne n'a besoin de téléphone, pas plus que d'électricité ou d'eau courante. Par contre, l'utilité d'un téléphone portable est assez évidente, et je ne te ferai pas l'affront de rappeler qu'il s'agit surtout du fait de pouvoir l'emmener partout.

L'utilité d'un 4x4 en ville, c'est de se croire plus fort que les autres.

Quant aux guirlandes électriques, celles en LED ne consomment presque rien.

Avec une énumération comme la tienne, on peut voir entre les lignes un argument du genre "si toi tu as un téléphone portable ou des guirlandes de noel, alors pourquoi n'aurais-je pas un 4x4 ?". Peut-être que ce n'est pas ce que tu voulais dire, mais c'est généralement ce que disent les amateurs de 4x4.

Le relativisme systématique est une plaie. Non, toutes les choses ne sont pas égales. On peut polluer moins sans être Amish.

Il faudra un jour que je trouve quelqu'un qui a VRAIMENT besoin d'une bombe atomique en France aujourd'hui.

L'énumération d'exemples différents n'est pas une réfutation.

Bon, et bien, c'est un Schrödinbug, visiblement. Maintenant ça marche, alors que je n'ai strictement rien changé. Hier, je n'avais absolument aucun réseau en vue, sur les 36 qui m'entourent...

Merci de votre attention ;)

Oui oui, c'est pour ça que j'ai précisé "même après reboot". Ce qui m'intrigue un peu, c'est que ndiswrapper utilise un driver (windows) récupéré sur le site de dlink, si je me souviens bien, donc ça n'a pas l'air d'être un truc propriétaire d'apple.

J'ai aussi essayé de refaire les manips (modprobe ndiswrapper et ndiswrapper -i le_driver), mais en vain.

D'après slashdot, il le passe encore, c'est le serveur hébergeant le test qui est mal configuré et qui casse tout, pour tous les navigateurs.

Toujours d'après slashdot, IE8 passe le test aussi.

Le choix des mots est important. Est-ce qu'il "déclame", ou bien est-ce qu'il répond quand on lui pose la question ? Est-ce qu'il "déconseille", ou bien est-ce qu'il ne conseille pas ?

En particulier, en effet, RMS et la FSF en général ne conseillent pas l'utilisation de certaines distributions de GNU/Linux parce qu'elles contiennent des logiciels non libres ou permettent de les installer facilement. RMS estime que si la FSF doit recommander une distribution, cette distribution se doit de respecter tous ses principes à la lettre, et c'est une position cohérente, à défaut de plaire à tout le monde.

Ta citation est-elle vraiment un point pertinent ? C'est pertinent si c'est vrai. On peut toujours discuter des "vraies" raisons de RMS, ça restera sans fondement. Il est plus intéressant de savoir si ce qu'il dit est vrai, si c'est cohérent avec sa position habituelle et si, comme souvent, ses détracteurs ont détourné ses propos pour les faire sembler intégristes. Il n'y a qu'à voir les réactions de ce journal pour voir que certains sont prompts à lui reprocher tout et n'importe quoi, sans se renseigner sur les faits. En particulier, lui reprocher de donner son avis alors qu'on le lui a demandé, et lui reprocher de venir se justifier lorsqu'on l'attaque sur une ML, c'est assez drôle.

Le seul moyen de savoir s'il défend sa licence plutôt que des convictions serait de sortir une distrib sous licence BSD, respectant tous les critères qu'il annonce publiquement, et voir s'il essaye de la démonter.

Intéressant, comme raisonnement, il est fermé d'esprit parce qu'il a une opinion que tu trouves abrutie (ie. "il ne faut pas conseiller l'usage de logiciels propriétaires"). Je suppose que tu es ouvert d'esprit, toi qui l'insultes à cause de cette opinion.

Ils n'offrent plus les 5% qu'aux abonnés parce qu'ils ont eu des problèmes à cause du prix unique des livres. Avant, ils offraient les 5% à tout le monde, plus des avantages aux abonnés, et ça a été considéré comme une double réduction. Comme il leur fallait bien justifier l'intérêt de l'abonnement, ils ont donc restreint la réduction. Pour info, Virgin a fait pareil, probablement pour les mêmes raisons.

Il est relativement logique qu'ils en veuillent à Amazon de livrer gratuitement, puisqu'il n'y a guère d'intérêt à aller à la Fnac faire ses achats. À cause de la loi Lang, ils n'ont aucun moyen de se rendre plus attractifs, puisqu'objectivement Amazon est "moins cher" (même prix mais sans le déplacement), a moins de difficultés à gérer ses stocks, et propose des recommandations qui valent bien celles des vendeurs Fnac.

explicit is better than implicit

Si tu en es vraiment convaincu, tu pourrais éviter de garder ton argumentation implicite.

Pourquoi join ne convertit pas automatiquement en string, sachant que join n'accepte que les strings ? Ca veut dire que le langage t'oblige à expliciter quelque chose que tu dois toujours faire. Pourquoi ? Si j'ai besoin d'un string, pourquoi ne pas convertir l'objet en string ?

Il y a des cas où ce n'est pas évident, et dans ce cas la conversion ne doit pas être automatique. Par exemple, si j'écris "a + b" alors que a est un string et b un int, il n'est pas évident de conclure que je veux convertir "b" en string. Peut-être qu'en fait je voulais convertir "a" en int. Mais quand il n'y a pas d'ambiguité, forcer la convertion explicite n'a pas l'air justifié.

1) Je suis au regret de t'annoncer que tout ce qu'on peut faire en Python peut se faire en C. Ou en Java, ou en Perl, ou en Brainfuck.

2) De la même façon que "for" n'apporte rien face à "while", ou bien que Python n'apporte rien face au C, je suppose. On peut toujours tout faire en C, peu importe que ce soit inélégant et que ça prenne 30 lignes au lieu de 3. Sur l'utilité des itérateurs, je pense qu'actuellement le consensus est clair. De même sur l'utilité de la programmation fonctionnelle.

(Je commence à croire que tu considères que si c'est possible en Python, alors ça ne mérite pas d'être mentionné pour les autres langages. Ca expliquerait tous ces messages, en fait, et peut-être que j'ai eu tort de réagir.)

Je suis vraiment très bête, je n'arrive plus à comprendre ce que tu veux dire. Est-ce que j'ai donné un exemple idiot et académique, ou bien est-ce que j'ai donné un exemple trop spécifique et que j'aurais dû généraliser à tous les itérateurs ?

Formulé autrement, est-ce que tu changes de thèse à chaque message parce que tu essayes seulement de prouver que ton interlocuteur a tort ?


Au cas où tu serais de bonne foi, ce qui me semble improbable, je voudrais te faire remarquer qu'il s'agit d'un exemple sorti en 5 minutes dans une discution sur les itérateurs, pas d'une thèse de doctorat sur les langages, ou d'un cours de génie logiciel. Il s'agit d'une illustration de comment on peut écrire un certain type de choses, plus précisément de comment on peut "passer" plus d'un bloc à un itérateur.

Il est assez facile d'écrire la même chose en permettant de choisir l'itérateur, mais le code est moins accessible à quelqu'un qui ne connaît pas Ruby, et donc illustre beaucoup moins le sujet de la discution. Ca donne quelque chose comme ça:

class Object
 def takewhile(iterateur, predicat)
  self.send(iterateur) do |element|
   break unless predicat.call(element)
   yield(element)
  end
 end
end

(0..10).takewhile(:each, lambda { ... }) do |element|
...
end

Ca ne marche pas bien avec les itérateurs qui renvoient plus d'un élément à la fois, mais j'ai la flemme de faire un exemple parfait, surtout aussi stupide et académique. Tu remarqueras que le code est presque identique au précédent, puisque la seule différence est qu'on passe l'itérateur en paramètre, en plus du bloc et du prédicat.

En Ruby, join s'applique à tout ce qui est énumérable, simplement parce que n'importe quel objet peut être converti en String à l'aide de la méthode to_s.

Au fait, ton exemple ne fait pas un foreach_while. Il prend tous les éléments qui vérifient la condition. Dans foreach_while, il faut s'arrêter au premier qui ne la vérifie pas. (Dans le cas précis de l'exemple, ça fonctionne uniquement parce que le tableau est trié)

Alors pour info, d'une part avoir des itérateurs conditionnels est utile dans le monde réel, parce qu'il arrive qu'on n'ait pas envie de parcourir toute une liste, d'autre part cet exemple soi-disant académique sert essentiellement à illustrer comment on peut passer plus d'un bloc à une fonction, ce qui est également utile tous les jours dans le monde réel.

Si tu penses que pour aborder un aspect d'un langage (itérateurs et blocs) il faut étudier des cas concrets, je peux t'en sortir à la pelle, mais ça risque de prendre un peu plus de place. Par exemple je peux t'écrire un exemple où on veut parcourir un graphe en profondeur, et s'arrêter au premier sommet non marqué. C'est typiquement une variante de foreach_while.

Concernant la remarque sur join, je suis bien d'accord que ça ne s'applique pas qu'aux tableaux ou aux listes, ça s'applique à tout ce qui est énumérable. C'est pour cette raison que c'est une méthode appartenant au module Enumerable en Ruby. Ce module est implémenté par Array, mais aussi par d'autres objets. Je ne vois toujours pas en quoi on peut penser que c'est une méthode de String, mais admettons, c'est peut-être une autre manière de voir qui est valide.

Enfin, concernant l'opérateur ".", je pense que mon raisonnement est devinable dans la manière dont j'ai écrit mon post. D'abord j'ai supposé que c'était un appel de méthode, parce que c'est ce à quoi je suis habitué, mais je ne trouvais pas ça logique. Ensuite, je me suis rappelé qu'en Perl ou PHP, le point était l'opérateur de concaténation, d'où ma question.

Je te trouve un peu méprisant, ce qui est ironique sachant que même quand on t'explique que tu n'as pas compris nos exemples, tu as l'air trop "stupide" pour essayer de le faire.

Pour la dernière fois (parce que t'es lourd et que j'arrête là), nos exemples n'affichent pas les nombres de 1 à 10, nos exemples montrent différentes manière d'écrire un itérateur "foreach_while".

Et tu n'as pas de mal à comprendre pourquoi "times" est une méthode des entiers en Ruby ? Marrant ça, je croyais que la notation objet était naturelle pour les rubyistes ?

J'ai du mal à comprendre pourquoi join est une méthode de la chaîne, et pas du tableau. Maintenant que quelqu'un de plus serviable que toi m'a expliqué ce que ça faisait au lieu de me demander d'apprendre le Python avant de vouloir discuter, je ne comprends toujours pas la raison de ce choix. Ce n'est pas la chaîne que l'on joint avec quelque chose, c'est le tableau que dont on joint les éléments en les collant avec la chaîne. Intuitivement, je penserais que join est une méthode du tableau, comme c'est le cas dans beaucoup de langages.

Quant au fait d'apprendre le Python avant d'avoir le droit de te répondre, j'oserais souligner que c'est toi qui a pris l'initiative de participer à cette discution où l'on parle essentiellement de Ruby. Je ne vois pas pourquoi on devrait apprendre ton langage favori avant de te répondre.

Je rêve ou leur animation Flash (sapu) prétend qu'ils ont découvert le concept de gènes ? "The scientists who discovered the genes... now bringing... to the whole world"

Ils ne doivent pas être tout jeunes, dans cette boîte.

Sachant que la Fnac et Virgin n'offrent plus les 5% de réduction autorisés à tout le monde, il est probable qu'amazon va maintenir les 5%, rajouter le prix de l'expédition, et rester moins cher pour les grosses commandes.

Quelqu'un a des indices concernant le prix de l'expédition ? Je suppose qu'ils ont des accords avantageux avec la Poste.

Ca ne fait pas la même chose que nos "exemples stupides", et en plus c'est assez moche, selon moi. Je suppose que "str(i) for i in t" construit un tableau ou une liste, mais j'ai du mal à comprendre pourquoi join est une méthode de la chaîne. Est-ce que ça ajoute avant la chaîne, et donc avant le retour à la ligne ?

Ou alors "toto".join n'est pas un appel de méthode comme ça en a l'air, mais "." est l'opérateur de concaténation, auquel cas il n'y a plus aucun doute, tu mets le retour à la ligne avant le texte, c'est normal ?

Sauf erreur, ça construit un nouveau tableau, donc ce n'est pas toujours souhaitable. De même, il est souvent préférable d'utiliser un reverse_each plutôt que de construire un tableau inversé avec reverse, et ensuite appeler each dessus. Il n'y a pas de mal à créer de nouveaux itérateurs, et Ruby est déjà bien assez lent sans qu'on l'aide en créant plein d'objets inutiles :)

Par contre dans mon exemple, je n'aurais pas dû dériver la classe Array mais lui ajouter une méthode, ça aurait été plus simple.

Pour le foreach_while, c'est possible aussi en Ruby, mais de manière moyennement élégante, en écrivant quelque chose du genre:

class Toto < Array
 def each_while(cond)
  self.each { |item|
    break unless cond.call(item)
    yield(item)
  }
 end
end

t = Toto.new
0.upto(9) { |i| t << i }

t.each_while( lambda { |i| i < 5 } ) do |i|
 puts i
end

Ruby est plus lent que PHP.
Rails de base est plus rapide que PHP de base, parce qu'il fournit plein de caches à différents niveaux sans effort de programmation.
Par contre, il faudrait comparer Rails à un framework PHP proposant les mêmes outils.

Pour info, il existe un module apache Ruby, mais il n'est pas utilisé par Rails, probablement parce qu'il n'est pas assez puissant. Il ne permet que d'intégrer du Ruby dans des pages web, à la PHP.

Je ne dis pas qu'il faut le faire, rien ne t'empêche de coder ta méthode de transtypage où tu veux et comme tu veux. Pour les conversions basiques, il est souvent plus logique que ce soit l'objet qui sache se convertir lui même dans un autre type.

C'est aussi une question de syntaxe. Si tu préfères faire "i = Fixnum.from_string(str)" au lieu de "i = str.to_i", pourquoi pas. Après, ça va produire des cas étranges. Par exemple si ton string contient un nombre très grand, au lieu d'obtenir un Fixnum tu vas obtenir un Bignum, ce qui est un peu surprenant quand tu écris Fixnum.from_string.

Je ne sais pas si c'est un débat très intéressant, mais je voudrais encore apporter un exemple dans lequel je pense que la solution de Ruby est plus élégante:

a = Catalogue.find(:all).to_a.reverse

Catalogue est un modèle de Rails (ActiveRecord). "find" renvoit un truc qui ressemble superficiellement à un Array, mais parfois on a besoin d'un vrai Array, d'où la conversion avec to_a.

Maintenant, suivant l'autre approche:

a = Array.from_active_record_model_query_result(Catalogue.find).reverse

Ok, le nom de méthode que j'ai choisi est peut-être artificiellement long, mais c'est pour souligner que tu as dû créer un constructeur dans Array qui est très spécifique. Ça ne fonctionne que sur le genre de trucs renvoyé par "ActiveRecord::Base#find".

Est-ce que ce constructeur de tableau a sa place dans Array, ou dans ActiveRecord ? Je pense que tu seras d'accord: c'est propre à ActiveRecord, ça ne doit pas être une méthode de Array.

On peut imaginer une solution intermédiaire, en faisant: ActiveRecord::Base.array_from_query_result( Catalogue.find(:all) ), mais bon, c'est encore plus laid.

j'imagine qu'il doit y avoir une methode spécifique la classe entier pour recuperer la valeur entiere contenu dans un string

C'est le contraire: un String sait se convertir en entier ou en flottant. Un nombre (et n'importe quel objet) sait se convertir en String, etc. Les méthodes standards s'appellent to_i (integer), to_f (float), to_s (string), etc.

Cette manière de faire est un peu plus propre, car ça signifie que quand tu programmes ta classe d'objet, il suffit de leur ajouter une méthode to_i, to_s, etc. selon tes besoins. Dans l'autre manière de faire, il faudrait créer un Integer.parseIntFromToto(Toto t) pour créer un entier à partir d'un Toto. Je préfère n'avoir à modifier que ma propre classe, et pouvoir appeler toto.to_i.

Foreach est une forme d'itérateur, mais c'est un peu moins générique malgré tout. Le problème, c'est qu'en utilisant un mot clé au lieu d'une méthode d'instance, on fixe une fois pour toutes le comportement de l'itérateur: il est censé énumérer les éléments d'un contenant, dans un ordre prédéfini (par l'objet contenant).

Il y a des tonnes d'autres manières d'imaginer une itération:

- on peut vouloir parcourir les éléments dans un autre ordre que celui "intuitif"
- sur une table de hachage, on peut vouloir parcourir les clés ou les valeurs
- on peut vouloir parcourir un arbre ou un graphe de plusieurs manières (profondeur, largeur...)
- on peut vouloir parcourir un graphe en spécifiant de quel sommet on part
- on peut vouloir faire autre chose qu'exécuter du code sur chaque élément, par exemple construire un tableau contenant les résultats de chaque visite d'un élément. Ça oblige, soit à faire du code pas très beau, soit à ajouter un mot clé "map" au langage, qui souffrira des mêmes limitations que foreach sur l'ordre du parcours.