Antoine a écrit 5722 commentaires

Bref, c'est parce ces langages gèrent automatiquement les threads, en n'affectant pas un thread par tâche, mais un thread pour plusieurs tâches (les espaces d'exécutions) qu'ils obtiennent de meilleur perfs.

Oui, parce que le benchmark est idéal pour favoriser ce genre d'implémentation (créer des tas de petits threads dont chacun ne fait pas grand'chose). C'est loin d'être le cas de toutes les utilisations du multi-threading.

Les langages qui s'en sortent bien dans le shootout sont les langages qui automatisent la gestion des threads

C'est une affirmation totalement infondée et probablement foireuse. Aucun des langages présentés n'est capable de paralléliser automatiquement un algo.
On voit aussi qu'Erlang n'a pas des performances extraordinaires comparé à, par exemple, OCaml. Pourtant l'implémentation testée (HiPE) est censée produire du code natif, non du bytecode.

C'est clair, il vaut beaucoup mieux avoir une opération synchrone qui bloque le processeur d'un coté en attendant (par exemple) un retour I/O

Heu... c'est quoi ton OS ?
Parce que n'importe quel OS digne de ce nom va ordonnancer un autre processus si le processus actuel se trouve bloqué à attendre un retour I/O.

Sur un desktop, on a tendance à faire beaucoup de chose en même temps : musique, navigateur web + autres applis. Sur un serveur on multiplie en général moins les usage

C'est vraiment n'importe quoi là (bis).
Au contraire, un serveur par construction va souvent devoir servir plusieurs utilisateurs à la fois et de façon indépendante, ce qui est tout de même un vecteur idéal de parallélisation.
Après, si l'appli utilisée ne le permet pas, c'est qu'elle a été écrite par des guignols (bis repetita, cf. plus haut).

Quand tu te retrouves avec une vieille application monothread

Heu... c'est un peu n'importe quoi là.
Les serveurs multiprocesseurs, ça existe depuis des décennies, donc si ton appli est une appli serveur et que l'éditeur n'est pas totalement minable, elle devrait déjà être capable de tirer parti de plusieurs processeurs ou coeurs.

Si je ne me trompe pas, les opérations virgule flottante en x86-64 utilisent par défaut le jeu d'instructions SSE(2) plutôt que la vieille ISA x87.

Tu n'en sais absolument rien si les performances sont bonnes : Il n'y a plus aucuns points de comparaison.

Bien sûr que si, il y a encore des points de comparaison.
Sun continue à développer des processeurs Sparc, et IBM des processeurs POWER. Par ailleurs Intel lui-même développe une architecture concurrente depuis 15 ans, l'Itanium.

C'est à peine mieux en x86_64, puisque pour utiliser les 8 registres supplémentaires (total de 16 donc), il faut utiliser un préfixe...

Et, au final, on s'en contrefout, puisque c'est le compilateur qui fait le boulot.

Par ailleurs le journal est juste un troll de première classe, l'architecture x86 n'est pas pire que les autres pour faire du multicoeur (Linus Torvalds semble même penser que son modèle de cohérence mémoire -- memory ordering model -- est plus sain que celui d'autres architectures).

Le problème est moins de perdre la mémoire (cf. l'excellente conférence de Michel Serres postée plus haut) que de perdre les savoir-faire. En déléguant sans cesse un nombre croissant d'actes techniques à des dispositifs externes, on prend le risque de perdre nos savoir-faire (il y a des vidéos à ce sujet de Bernard Stiegler, où il lie d'ailleurs la perte des savoir-faire à la perte des savoir-vivre, qui sont deux moments orchestrés par le capitalisme pour récupérer à son profit l'énergie libidinale des individus (ce sont les mots de Stiegler)).

Or pour moi (et, je pense, pas mal d'informaticiens), le logiciel libre, c'est avant tout la résurgence du (ou des) métier(s) (*), bien plus qu'une histoire de libertés. Quelle que soient la licence et les conditions juridiques, ce qui est important c'est de se retrouver entre pairs et de travailler ensemble sur une matière qui nous tient à coeur, en étant maître de nos propres pratiques et de notre organisation. Ce n'est pas le cas dans l'organisation (industrielle) du travail informatique tel que la plupart des entreprises cherchent à l'imposer, et, s'il n'y avait à disposition que le modèle de production que l'on trouve par exemple dans les SSII, programmer serait insupportable.

(*) (il faut bien voir que les métiers ont disparu presque partout, des agriculteurs prisonniers de Monsanto & co jusqu'aux boulangers qui en achetant telle ou telle farine se voient aussi imposer des règles d'utilisation draconiennes)

Je vois surtout mal comment je pourrais sauvegarder une base de données sur un serveur distant si la notion de fichiers n'existe pas.

Accéder à une base de données, c'est souvent du SQL, le medium de stockage physique n'apparaît pas à ce niveau d'abstraction.

Comment je pourrais récupérer les photos de mon appareil numérique pour les visionner sur mon ordinateur.

C'est sûr que si tu veux intéropérer avec des systèmes basés sur la notion de fichier, il faut être capable de leur parler. Ca n'implique pas que la notion de fichier se retrouve au coeur du système.

Comment un serveur d'emails stocke les centaines de gigaoctets de données.

Mémoire virtuelle swappée sur disque ?

Ce qui m'amuse c'est la note du rédacteur qui s'applique à distribuer les bons et les mauvais points :
« Le discours tenu par Nicholas Negroponte est malheureusement assez courant chez ceux qui n'ont pas compris la partie éthique du logiciel libre et pensent que les défenseurs des logiciels libres devraient faire des concessions "techniques" alors qu'il s'agit de défendre les libertés des utilisateurs. »

Non que je sois en désaccord avec le fond de la pensée (j'ai toujours pensé que l'OLPC était conçu comme un projet à la fois missionnaire et opportuniste, et je suis somme toute assez content de le voir capoter), mais le ton utilisé ainsi que le besoin affiché de rappeler la ligne officielle du parti sont assez cocasses -- façon Pravda, si on veut.

On dirait qu'il y a une véritable hantise à l'idée que les utilisateurs ou contributeurs du libre pourraient se mettre à penser différemment et à développer des idées qui ne vont pas dans le sens de la parole officielle. D'où cette obsession de faire de la « pédagogie » et de s'assurer que les brebis ne quittent pas le troupeau.

Plus rapide à sortir, tu veux dire ?

Les itérateurs c'est bien pour l'accès séquentiel, mais pour l'accès aléatoire, tu fais comment sans indices dis-moi ?
(ne me réponds pas qu'il suffit d'itérer l'itérateur N fois...)

Et en Ruby, les tableaux commencent à 1 plutôt qu'à 0 ? Parce que sinon l'argument est plutôt foireux...

C'est un truc batard , pratique, mais qui ne correspond en rien à la POO et à la notion de classification.

Si je comprends bien, les langages à prototype comme Javascript ne sont pas non plus estampillés "POO" parce qu'ils ne correspondent pas à ta notion de classification ?

On peut voir le duck-typing au contraire comme définissant une classification de fait. C'est vrai qu'en Java il faut tout déclarer...

Je ne m'aventurerai pas non plus sur le terrain du multi-héritage en comparant son modèle à celui du C++ qui adresse presque tous les pbs lié à ce modèle

En français, on n'adresse pas des problèmes, on les résoud.

Sinon, l'héritage multiple de Python correspond à l'héritage "virtuel" de C++, je ne vois pas trop où se situe la différence. Si tu as besoin d'un héritage multiple non-virtuel, c'est AMHA que tu devrais faire de la délégation plutôt que de l'héritage.

Tu sais cet acronyme en 3 lettres qui G.I.L ne sera jamais remis en question car ca casserai tout ce bel édifice.

Effectivement, ça tient 1) du hors-sujet 2) du troll mal informé, puisqu'il y a des implémentations de Python sans GIL et qui pourtant respectent la sémantique du langage.

Java, C++ ont fait le choix du compromis entre performance et purété

Là ça me fait marrer, la raison pour laquelle Java a des performances acceptables aujourd'hui, c'est qu'un tas d'ingénieurs est payé à temps plein depuis plus de dix ans pour ça. Mettre C++ dans le même sac de ce point de vue est grotesque.

C'est pas vraiment clair sur le site Web (la page documentation est minimaliste), mais si Mercurial est correctement supporté, ce serait pas mal d'annoncer InDefero sur les MLs Mercurial.
(http://selenic.com/mailman/listinfo/mercurial, mais tu peux aussi poster via gmane : http://news.gmane.org/gmane.comp.version-control.mercurial.g(...)

D'ailleurs, je me demande si les compréhensions de listes de Python permettent de faire ce que permet LINQ

Ca dépend du sens exact de la question. En tout cas ça ne permet pas de s'interfacer avec une base SQL, ça ne travaille que sur le type liste natif.

et ton "objet" définissant ta fonction, il définit quoi ? une fonction (par définition :P)

??? Je ne comprends pas ta phrase.

C'est beau l'objet, mais bon un moment il faut quand même revenir à des paradigmes précis si on veut discuter.

Eh bien, "objet", c'est précis : il y a des méthodes, des attributs, un passage par référence (en Python), etc. Une fonction, c'est simplement un object qui implémente la méthode __call__.

Ce que je voulais dire en répondant au zozo du dessus, c'est que ce n'est pas parce qu'un langage est "objet" (et Ruby et Python sont beaucoup plus "objet" que Java) que tout s'écrit sous forme de déclarations de classes et de méthodes.

Au PS, il y a encore de la démocratie interne et ce sont les militants qui font le programme d'une certaine manière.

Je me fiche personnellement de savoir si un parti est "démocratique" en interne, ce qui m'importe plus est s'il respecte et promeut la démocratie au niveau national.

Le bilan du PS n'est pas rose, du feu vert donné à l'inversion du calendrier électoral par Jospin à l'approbation récente du traité de Lisbonne en passant par l'enterrement de toute tentative de limiter le cumul des mandats ou de mettre un frein à la concentration des médias en quelques mains (et on pourrait remonter à la façon dont Mitterrand a favorisé la poussée du FN, bref...).

Mais que des militants puissent faire mumuse au sein de leur organisation en votant pour des bouts de programme, je m'en bats les c*. C'est leur tambouille interne, et la démocratie, la vraie, doit s'exprimer au niveau de la nation.

Prenons les exemples que j'ai donnés pour les boucles: pour peu qu'on parle anglais, les trois sont parfaitement explicites et ne demandent pas d'explication.

Pas d'accord. Si tu lis upto(4) ou downto(0), il n'y aucun moyen de savoir (autre que d'apprendre le langage) si cela s'arrête à 3 ou à 4, à 0 ou à 1 (voire à -1).
Bref, c'est un joli raccourci, mais ça ne simplifie rien.

C'est implicite et lisible

C'est implicite et lisible parce que c'est le cas d'école d'utilisation de Perl dans n'importe quel tutorial pour débutants.
Dès qu'on s'éloigne de ce genre de démonstrations de cinq lignes et qu'on cherche à faire autre chose que du parsing à base de regexp, il n'y a plus rien de très attirant dans Perl...

Dans un langage objet par contre, par essence, tu vas passer par des classes pour ce genre d'operations (ie, tu ne vas pas utiliser une "fonction" mais une methode d'une classe).

Mon dieu mon dieu...
Dans un langage objet, tout est objet y compris les fonctions, les classes et les méthodes (cf. Python), que ce ne soit pas le cas en Java est un autre sujet.

La dynamo n'utilise pas l'énergie dépensée quand tu marches, elle utilise un schouia d'énergie que tu utilises en plus de l'énergie dépensée à marcher...

L'avantage d'avoir un language trés haut niveau comme le javascript c'est qu'il est trés simplemet preemtable et que le code de toutes les pages peut être exécuté par un seul ensemble de thread.

Oui, et comme ça si une application plante, toutes les autres plantent avec. Bien vu.

d'autre part ça demande souvent la disponibilité d'un réseau 3G ou WiFi qui sont loin d'être présent partout.

Heu, on peut imaginer des applis offline programmées en Javascript et utilisant HTML & co pour l'affichage.