Yusei a écrit 4649 commentaires

C'est rigolo de parler d'une "vraie" machine virtuelle... Une machine virtuelle est... virtuelle, elle n'existe pas. Une machine c'est quelque chose de physique.

Tout le monde est d'accord pour dire qu'une machine virtuelle (MV) n'est pas une machine physique, mais il y a plusieurs manières de concrétiser les machines virtuelles. Le language C décrit une MV (une couche d'abstraction par rapport aux vraies machines), mais quand on compile un programme C vers du code natif, on obtient un programme pour une MV de niveau plus bas que quand on compile un programme en Java. Simplement pare qu'avec gcc la MV est une abstraction utilisée pendant la traduction, alors qu'avec java, la MV est une abstraction utilisée pendant l'exécution.

Le jour où t'auras une vraie machine qui existe pour .NET ou Java, ca sera un proc dédié pour exécuter les instructions du langage intermédiaire. Ce dont tu parles c'est l'environnement d'exécution

Tu fais la leçon en expliquant (tout à fait justement) que même GCC possède une machine virtuelle, mais tu oublies que même les machines physiques sont construites en couches logiques (électronique -> logique -> microinstructions -> système d'exploitation, quelque chose comme ça). À partir de quand est-ce qu'on a une machine réelle ? Est-ce qu'une machine avec un processeur x86 dédié qui ne fait qu'exécuter une JVM, c'est une machine (java) réelle ? Pourtant, vu de l'extérieur (vu de l'OS), impossible de faire la différence avec un processeur spécialisé qui comprend le bytecode java directement.

Au final, je n'ai pas l'impression que la distinction entre langage natif et langage à MV soit fixe, ou qu'on puisse en tirer quelque chose d'intéressant. Plus on a de couches à traverser, plus ça prendra de temps de les traverser, mais le nombre de couches à traverser dépend grandement du contexte (et de toutes façons, la traduction d'un langage à l'autre n'est pas nécessairement la partie la plus coûteuse en temps).

Quand je pense que du temps de ma prime jeunesse, enlightenment était synonyme de gros truc lourd bourré de trucs jolis, mais inutilisable sur une machine "bon marché"... =)

À part au niveau des concepts, je doute que l'implémentation d'un interpréteur ruby ressemble beaucoup à une JVM, et un brevet qui s'attaque aux deux serait probablement trop générique pour être dangereux.

Dans le cas de Mono, ce qui fait peur à beaucoup de gens c'est que MS a breveté des morceaux de .NET, donc il y a des chances pour que ces brevets là s'appliquent aussi à Mono.

$toto = ($i == 2) ? 3 : ($i == 5) ? 6 : 42
Comme quoi, on peut faire ca aussi.

Oui, bien sûr, en Ruby aussi l'opérateur "?" existe, mais ce n'était qu'un exemple du fait que chaque expression a une valeur de retour, puisque c'est fonctionnel. Faut bien avouer que l'opérateur ternaire, c'est sale :)

Perl a de la bouteille, est moins hype que python ou ruby. Mais il reste un excellent langage, il me permet d'etre efficace.

Note que je n'ai rien contre Perl, à part certains détails de syntaxe qui m'énervent, j'aime beaucoup. Personnellement, je n'ai jamais rien compris aux objets en Perl, alors je me suis d'abord servi de Ruby comme d'un Perl avec un modèle objet bien fait.

C'est vrai, le switch case en perl n'existe pas en tant que tel.

"use Switch", non ? :)

Je faisais plutot référence à la possibilité de récupérer la valeur de n'importe quelle expression, par exemple (salement):
toto = if (a == 2) then 3
      elsif (a== 5) then 6
      else 42
      end

Moi, j'ai jamais aime les iterateurs, ca m'embrouille l'esprit, je n'arrive pas a "visualiser" ce qui se passe derriere. J'ai l'impression qu'on veut me masquer l'aspect "boucle" de la chose. Alors qu'un bon vieux foreach, ca te prend 2 lignes de plus que ton iterateur, je ne vois pas le probleme.

Sauf qu'un itérateur peut faire autre chose qu'itérer sur les éléments d'une collection dans l'ordre. Tu as each, bien sûr, mais tu peux avoir reverse_each qui itère à l'envers. Pour faire ça avec un foreach, tu dois d'abord inverser ta collection. Tu as aussi str.each(délimiteurs) qui fait quelque chose comme foreach my $s (split(délimiteurs, $str)).

Et si tu fais une matrice, tu peux faire des itérateurs each_row, each_cell, etc.

ton Net::HTTP peut se retrouver dissemine dans tout ton code

Oui, mais on peut coder salement dans n'importe quel langage :) Ceci dit, il suffit de faire un grep pour retrouver toutes les définitions d'une classe.

@articles = sort {$b cmp $a} @files;

Et en ruby, articles = files.sort { |a,b| b <=> a }, comme quoi ça se ressemble. Mais la magie de la redéfinition des opérateurs, c'est que tu peux définir une bonne fois pour toutes comment "<=>" compare tes objets. C'est pratique quand tu as des données structurées, et une fois que tu as redéfini <=>, tu peux faire if a < b ... et ça marche.

justifier de la pertinence d'un langage par une application en particulier

Je ne sais pas si tu as essayé Rails, mais justement, ça roxor des ours grace à Ruby. C'est une bonne démonstration de la flexibilité que permet Ruby, et certaines choses seraient vraiment très difficiles à faire avec un langage plus "rigide". Rails n'est pas vraiment "une application", c'est plutôt un ensemble de code Ruby qui t'aide à construire une application Ruby.

Pour prendre un exemple qui parlera peut-être aux sysadmins habitués aux scripts d'analyse de logs, il ne doit pas être très difficile en Perl d'obtenir la date de dans dix jours, mais j'ai cherché deux minutes sans trouver de méthode standard qui gère les mois de 28, 29, 30 et 31 jours. En Ruby, on fait Date.today+10, et en Rails on peut aussi écrire 10.days_from_now (je pense). Ce sont des détails, mais des détails qui rendent le développement rapide et agréable.

Qu'est-ce qui te surprend dans le fait de coder ce qui a besoin d'être rapide en C, et le reste dans un langage de haut niveau ? C'est pourtant une pratique courante. Par exemple, il y a des bindings GTK pour plein de langages, mais la lib n'est pas recodée à chaque fois: elle est codée en C et réutilisée. C'est pour ça que java-gnome est rapide, et que java-swing est lent.

Un troll ? Je n'ai pas dit que sa complexité était O(n), simplement qu'on pouvait le calculer (trivialement) en O(n), et que donc ce n'était pas "dur" (j'avoue avoir eu la flemme de réfléchir/chercher quel était l'algo le plus rapide).

Je n'étais pas au courant que la complexité de fibo était un sujet de troll... tu ne confondrais pas trolls et erreurs ?

En algorithmique, fibo n'est pas complexe... ça se calcule en O(n).

Après, je suppose que dans le bench c'est codé récursivement, donc que c'est un peu plus lourd. En même temps, la récursivité est pas mal utilisée, donc c'est bien de savoir si une plateforme la gère bien.

Il y a deux problèmes différents: juger des performances ou de la stabilité des applis Mono à partir de softs pas finis, et juger de la rapidité/facilité de développement. Je faisais référence au premier point.

Après, pour le deuxième point, j'ai brièvement regardé C# et les libs fournies par Mono, et ça n'a pas l'air moins bien que Java, mais ça n'a rien de transcendant non plus. Je ne suis pas allé très loin dans mon expérience, mais je pense que si Beagle traine c'est plutôt:
1- parce que c'est difficile à faire
2- parce que ça manque de devs, ou bien que ça en a manqué pendant longtemps
3- à cause de problèmes d'organisation

Pendant longtemps, pour tester Beagle il fallait patcher le noyau, activer des options au niveau du système de fichiers, bref, ça n'aidait pas à s'impliquer. Je pense qu'il y a eu trop de buzz autour de ce truc avant qu'il soit suffisamment avancé.

Oui et j'ai viré Beagle vite fait.

Ça fait plusieurs fois que je vois des gens juger Mono à partir de Beagle ou F-Spot... vous avez vu le numéro de version de ces logiciels ? Beagle est une 0.2.x, et fspot une 0.1.x.

Il existe un binding Python pour GTK alors pourquoi rajouter toute une machine virtuelle complète en plus ?

Python est interprété. Il n'y a aucune différence entre un interpréteur et une machine virtuelle. Généralement, on dit "interpréteur" quand le langage est interprété tel quel, et "machine virtuelle" quand il est d'abord traduit en "bytecode" qui est ensuite interprété, mais la séparation entre les deux est très floue. Quand tu fais du Python, du Ruby, du PHP... tu utilises une machine virtuelle (ce n'est pas sale).

Par contre, c'est sûr qu'un desktop qui utilise des applis Python, Ruby et Mono doit charger trois machines virtuelles, et c'est d'autant plus lourd. Moralité: il faut que tout le monde utilise Python.NET et Ruby.NET, pour n'avoir que Mono :)

(je rigole, utilisez Parott)

(Je vous prie de m'excuser pour cet "Inconvénients" qui se promène au milieu des avantages. Le fait que RoR roxor des castors est définitivement un avantage, mais vous aurez corrigé de vous même.)

J'ajouterais, quand même, que j'ai fait pas mal de Perl avant de faire du Ruby, et que Ruby en est fortement inspiré, ce qui est agréable. Ruby rend simple tout ce que Perl rendait simple, et ne rend rien plus difficile. Généralement, les modes de pensée perliens se traduisent assez bien en Ruby. Boucler sur un fichier, appliquer des regexps sur chaque ligne, utiliser des backticks pour exécuter une commande, balancer le résultat dans un hash et sortir des statistiques à la fin, bref l'utilisation standard de Perl, se traduit presque directement.

Quand à Ruby, à part le tout objet (qui a aussi ses inconvénients amha), je ne vois pas trop l'intéret par rapport à perl pour l'utilisation que j'en ai.

Avantages:
- c'est un langage fonctionnel, en plus d'être objet, et ça permet certaines constructions élégantes, par exemple récupérer la valeur de retour d'un "case" (équivalent du switch de C, en mieux).
- les itérateurs, c'est vachement mieux que toutes les variantes de foreach. Je suppose qu'on doit pouvoir en ajouter à Perl, mais c'est bien quand tous les objets énumérables les ont d'office.
- tu peux rajouter ou redéfinir des méthodes d'objets existants quand tu veux, là où en Perl tu devrais définir une fonction d'enrobage. Je prend un exemple à la con: si tu décides que tu veux logger toutes les connexions effectuées via http, il te suffit de redéfinir la méthode de connexion de la classe Net::HTTP (ou quelque chose du style) au début de ton script, et tu n'as rien à faire d'autre.
- tu n'as pas besoin de mémoriser si ta variable est un array, un hash, un ensemble, un graphe, un arbre... pour savoir comment prendre un élément dedans, tu fais juste variable[identifiant].
- tu peux redéfinir les opérateurs, c'est pratique, surtout pour l'opérateur de comparaison qui sert à faire des tris.
- le controle d'accès des méthodes, ça a du bon pour les gros projets. (La philosophie de perl c'est: on n'exécute pas une fonction privée, pas parce que c'est impossible mais parce que ce n'est pas poli. En ruby c'est pas possible.)
Inconvénients.
- Ruby on Rails, ça déchire des ours, et ça aurait été vraiment difficile à coder en Perl.

Inconvénients:
- C'est plus lent que perl, donc si ton usage principal est d'analyser des logs, par exemple, ça risque de ne pas être rentable.
- Il y a un peu moins de libs, même si j'ai presque toujours trouvé ce dont j'avais besoin tout prêt dans debian. Par contre, c'est vraiment simple de faire des extensions Ruby à partir d'une lib en C.
- Pas de "use strict" pour t'obliger à être rigoureux, même si on doit pouvoir bidouiller un truc similaire.

En fait, je compare surtout à mes besoins: il est extrêmement rare que je cherche quelque chose et que ça ne soit ni dans le ruby book ni dans les docs des API. Le fait qu'il existe un outil ruby similaire à javadoc/doxygen est pour beaucoup dans le fait que c'est bien documenté. Perldoc, c'est bien mais c'est limité. Les seuls petits problèmes que j'ai rencontré avec Ruby, c'était pour des bindings GTK dont certaines fonctions n'étaient pas documentées, et pour lesquelles il fallait "deviner" à coups d'introspection ou en cherchant dans la doc pour la version en C de la lib.

Une comparaison injuste: je suis en train de "jouer" avec les modules Perl pour manipuler Cyrus, et c'est extrêmement peu documenté. Ok, c'est pas la faute de Perl, c'est la faute de Cyrus, mais bon... :) Après, je ne sais pas si c'est parce que j'ai perdu l'habitude de Perl, mais je trouve beaucoup plus difficile de "trouver comment ça marche" en Perl qu'en Ruby, où tu peux faire un obj.methods pour avoir la liste des méthodes de obj (par exemple).

Je suis au crédit lyonnais et j'arrive à me connecter sans problèmes (d'un autre côté, je ne suis pas abonné à un truc particulier). Je ne sais pas si ça peut t'aider, mais mon URL de connexion est différente, et commence par "particuliers." (je ne suis pas chez moi pour vérifier l'URL en entier).

Ruby brille par sa documentation, si si.

Il y a la première version du rubybook, qui est libre et intégrée dans debian, qui est très bien pour apprendre. Pour le reste, il y a la deuxième version du rubybook en livre (traduit en français il me semble), des API sur le net, des tutoriaux un peu partout...

La barrière du japonais, c'était vrai il y a 4-5 ans, plus maintenant.

Javascript est un langage relativement agréable à utiliser et moderne, malgré sa styntaxe un peu lourde héritée de C/Java. Sa réputation est surtout due aux implémentations approximatives qu'on a pu voir un peu partout, mais ça ne change rien aux qualités du langage. Pour ma part, quand j'ai été "obligé" de m'y mettre pour rajouter un peu d'ajax dans une appli web trop lourde, j'ai été agréablement surpris par ce que j'ai trouvé.

A mon avis, dans la vrai vie, tous le monde sait que l'ONU n'a pas le droit d'intervenir

C'est un peu ce qu'on essayait de dire... puisqu'ils n'ont pas le droit d'intervenir, ils ne peuvent pas faire d'intimidation

je pense que dans une guerre y a pas d'intimidation, c'est le premier qui tire qui gagne

Pour le coup, c'est toi qui confonds guerre et duel dans un western. Même si tu tires le premier, dans une guerre, sauf exception, tu ne peux pas éliminer l'ennemi avant qu'il puisse riposter.

Et puis pour éliminer tous les pays membres de l'ONU, il faut un paquet de munitions. Et de soldats.

Et si Proudhon avait vécu de nos jours, aurait-il dit « la propriété intellectuelle, c'est le v(i)ol (de licence) » ? :-)

il vole les ayants droits des rémunérations qu'il aurait percu si le keygen n'était jamais sorti.

Il prive les ayants droits des rémunérations qu'ils auraient perçu, il ne les vole pas. (C'est à dire: il ne les perçoit pas à leur place.)

Cette vision des choses pourrait aussi faire penser que le viol de licences n'est réprimandable que dans le cas où les ventes de licences auraient pu apporter de l'argent à leur créateur, ce qui n'est pas le cas.

je préfère de loin être un crétin pour qui violer une licence c'est voler

Je ne t'ai pas traité de crétin pour ça, mais parce que dans ta vision limitée du monde, si on n'est pas d'accord avec ta définition on est un Voleur. En quoi penser que le vol est différent du viol de licences implique que mon passe-temps favori est de violer des licences ?

Jouez avec les mots, violez les licences

Mais quel incommensurable crétin !

(Ouais, ouais, j'insulte, c'est mal, moinssez. Mon score ne descendra pas en dessous du niveau de raisonnement de ce navet décérébré, de toutes façons.)

La violer, c'est aller à l'encontre de la volonté de l'auteur, c'est lui voler le fruit de son travail.

Tu pourrais argumenter le saut entre « aller à l'encontre de la volonté » et « voler » ? C'est justement le coeur du débat. Je prend la définition de "vol" du vieux Littré du domaine public: « action de celui qui prend la chose d'autrui pour se l'approprier. »

Ça ne correspond pas à un viol de licence, à plusieurs niveaux:
- Le viol de licence ne change rien à la propriété de la "chose". L'ancien propriétaire reste propriétaire, et on ne devient pas propriétaire.
- Le viol de licence ne prive pas le propriétaire de la "chose".
- Le viol de licence n'est pas limité au téléchargement illégal, il peut porter sur des points de détail, qui n'ont rien à voir avec la propriété.

Il y a certainement plein de gens qui vont en déduire que je cautionne le viol de licence, et me moinsser en conséquence. À ces gens là, je demande juste: pourquoi ne pas appeler le vol "vol", et le viol de licence "viol de licence" ?

Pour le coup, c'est toi qui veut absolument y lire autre chose que ce qu'il dit. Tu demandes une prise de position bien manichéenne, "c'est Bien" ou "c'est Mal", alors que tout ce qu'il dit c'est "ce n'est pas du vol".

Si je dis "donner un coup de tête à un joueur de football n'est pas un crime contre l'humanité", tu en déduis quoi sur ma position ? Pour ou contre les coups de tête ?

Si ça peut te rassurer sur les positions du monsieur, il me semble qu'il dit quelque part que violer la loi parce qu'on n'est pas d'accord avec la loi n'est pas une bonne solution en démocratie. Et qu'il souligne la différence entre désobéissance civile et violer la loi.

Il ne dit pas que c'est bien, il dit que ce n'est pas du vol. Le vol suppose que l'on retire quelque chose à quelqu'un, au moins dans le sens commun (je ne connais pas la définition juridique).

1) Reclaim ne veut pas dire "assumer" mais "revendiquer" et "réobtenir". Ça veut dire qu'à chaque fois que quelqu'un emploi "hacker" pour dire pirate, il faut le corriger et redonner son sens premier à "hacker".

5) Soyez sûr qu'ils connaissent votre position

29) Je crois qu'on dit "fouille de données", mais le terme "data mining" est largement utilisé en français. Si le [?] implique que tu ne sais pas de quoi il parle, il fait référence au fait que le gouvernement américain espère trouver des terroristes en inspectant méthodiquement les communications de ses citoyens, thèse idiote démontée par Schneier, entre autres (cf. point 84, il se répète, le bougre).

32) Ça existe, "gospel", en français ? Si non, "la parole de dieu" ne serait pas mal, à la place.

55) en anglais, "must" est en italique.

59) plein de gens (mais pas moi) te diront qu'il ne faut pas dire crypter mais chiffrer.

60) "connaissez-les", plutôt, car là on a l'impression qu'il faut être conscient du fait qu'ils ont des droits, pas être conscient des droits.

62) Ça serait bien de mettre une url sur "Spimes", comme dans le texte d'origine. Je n'ai jamais lu/entendu ce mot avant :)

71) "offensive" == "choquant", "offensant", pas "dangereux"

C'est [pas] pour autant que c'est intelligent, judicieux, justifiable, souhaitable, cautionnable, et autres termes en -able.

Pour les fans de vi et les employés de Microsoft, c'est inévit-able.