lasher a écrit 2738 commentaires

C'est pas vraiment une coïncidence. Le 386 avait deux variantes : SX et DX. Dans les deux cas le processeur avait des registres 32 bits, mais le bus du 386/SX était 16 bits (ce qui était une « bonne » chose pour ceux qui voulaient pouvoir réutiliser leur matos connecté à un 286, et qui ne comprenait que le 16 bits, ce qui permettait d'éviter de devoir récrire trop de pilotes). Le 386/DX était complètement 32 bits, y compris le bus d'adresses.

On m'a toujours dit que dire qu'un processeur était « X » bits se référait à la taille du mot pour un registre généraliste (les registres vectoriels/spécialisés ne comptent pas, vu que ben, ils sont spécialisés). Sinon, pourquoi ne pas considérer qu'un x64 récent est en fait un processeur 128 bits ou 256 bits ? Après tout, le bus qui va au cache fait bien 128 ou 256, voire 512 bits de large… :-)

C'est un peu bizarre je trouve. Si l'auteure est unique, je ne vois pas l'intérêt d'utiliser un genre grammatical. Soit elle dit « Je » (et tout est donc au féminin par la suite), soit elle dit « nous » (qui est la façons classique de rendre « neutre » un article académique), et par transition il faut que le sujet soit neutre, ce qui implique l'accord au masculin.

C'est quoi la mémoire immatérielle ? Une mémoire ineffable ? :-)

Je suppose que tu voulais franciser « mémoire RAM », et dans ce cas je dirais plutôt « mémoire centrale » (par opposition à « mémoire/stockage de masse » ).

La pratique en 2016 c'est que presque toutes les instructions consomment un cycle, voire une partie de cycle, on a assez de transistors pour cela. Donc on fait quoi ? On rajoute à nouveau des instructions : MMX, SSE (SIMD), AES… Alors CISC vs RISC, moi je rigole : ça n'existe plus.

Ça c'est faux. Les instructions vectorielles (AltiVec pour PowerPC, MMX/SSE/AVX pour x86) durent effectivement moins d'un cycle lorsque le pipeline est plein (donc en termes de « débit »). Mais la latence d'une instruction, fut-elle vectorielle, dure bien plus qu'un cycle.

De même, les instructions x86 scalaires de type « arithmétique avec opérandes à la fois en registre et en mémoire » nécessitent par définition plus d'un cycle pour s'exécuter, en particulier si on parle de divisions, modulo, ou opération flottantes.

Un jeu d'instruction RISC sépare explicitement les accès mémoire du reste : toutes les opérations arithmétiques se font registre à registre, là où les autres jeux d'instructions proposaient des systèmes plus ou moins complexes (calcul par accumulation, par pile, registre-mémoire, mémoire-mémoire, etc.; le x86 mélange tout ça).

La raison derrière le succès de RISC (et la raison pour laquelle Intel utilise un système de micro-opérations—AMD ne faisait [fait?] pas ça avec ses instructions x86 pour les premiers Athlon & Opteron), c'est justement qu'en réduisant le jeu d'instruction, et en le simplifiant,

1. On permet au pipeline d'être plus efficace : le débit en termes de cycles du pipeline est grosso-modo aussi rapide que le plus lent de ses étages. Donc si tous les étages de ton pipeline durent 1 cycle, sauf un étage qui en dure 5, ben t'es coincé avec un débit moyen par instruction de 5 cycles¹
2. On permet au compilateur d'être plus efficace : lorsque le modèle machine est simple, la génération de séquences d'instruction est simplifiée. Lorsque le back-end du compilateur est mis à contribution, la plupart des algorithmes utilisés sont basés sur des heuristiques car les problèmes d'ordonnancement impliqués sont NP-complets.

• Les algorithmes de sélection d'instruction doivent réussir à repérer des expressions dans la représentation intermédiaire du programme de manière à utiliser la meilleure instruction si possible. Par exemple, si j'ai une expression de type a = b + c * d, sur des machines x86 d'il y a 6 ans, il aurait fallu générer une multiplication et une addition séparément; sur les processeurs x86 récents, on peut utiliser une opération de Fused Multiply-Add (FMA) qui va se charger de tout. On y gagne en nombre d'instructions (une de moins) et en performance.
• Le list scheduling (ordonnancement par liste) est un algorithme glouton qui se base sur la pondération de certaines contraintes pour choisir dans quel ordre émettre les instructions.
• L'allocation de registres en utilisant un graphe d'interférence se base aussi sur des heuristiques, pour réduire le nombre de débordements (spills) qui forcent le programme à sauvegarder une valeur contenue dans un registre vers la mémoire et inversement.

Le principe de CISC, c'était de faire des instructions complexes qui utilisaient des registres cachés pour aller plus vite (et aussi gagner en espace mémoire). RISC, c'était un concept qui simplifiait le jeu d'instruction, demandait d'avoir beaucoup de registres adressables, et se reposait sur les progrès en théorie de la compilation pour correctement exploiter le pipeline (qui n'existait pas sur x86 avant le 486, et n'a commencé à être efficace qu'à partir du Pentium).

Je l'ai déjà dit ailleurs, un x86 (au moins chez Intel) aujourd'hui se comporte comme un RISC dès qu'on a passé le front-end (partie récupération d'instruction et décodage), vu que (1) toutes les instructions sont décomposées en micro-instructions, et (2) on est passé de ~8 registres adressables du Pentium 1 (32 bits) à 32 (16 « généraux » et 16 « vectoriels » mais qui peuvent être utilisés comme des vecteurs scalaires), comme les processeurs RISC classiques, sur les architectures 64 bits actuelles.

En attendant, le front-end du pipeline d'Intel reste limité, et la raison pour laquelle les instructions prennent en moyenne 1-2 cycles en termes de débit (hors accès mémoire), c'est qu'il y a en interne un cache de micro-instructions (à noter que le PowerPC/POWER d'IBM a un truc similaire, et pourtant le jeu d'instruction est bien plus proche de RISC que le x86).

Dans un univers de sources ouvertes ou il suffit de recompiler avec un compilateur adapté, tu peux avoir un set d'instruction qui reflète mieux l'organisation interne de ton CPU, et avoir au final une meilleure efficacité de ton CPU (et utilisation énergétique). D'où la percée des ARMs sur téléphones.

Oui et non : si ça reflète trop le comportement interne de ton processeur, alors il y a un vrai risque que le programmeur qui aurait besoin d'écrire de l'assembleur ait vraiment plus de mal à écrire son programme. La conception d'ISA doit être relativement fidèle à ce que fait le processeur, mais aussi doit permettre au concepteur de compilateur et au programmeur bas-niveau de pouvoir raisonner sur un modèle machine suffisamment complet mais aussi suffisamment simple. Exemple à la con : j'ai bossé (en tant que « programmeur ») sur une archi expérimentale qui faisait explicitement la différence entre nombres flottants et entiers (jusque là, pourquoi pas, ce ne serait pas la première fois), mais aussi entre les pointeurs « lointains » et « proches » (mémoire scratchpad locale ou de niveau supérieur, ce qui en soit n'est pas non plus complètement nouveau, ça se faisait avant aussi), et où il n'y avait aucun caches, donc tous les mouvements mémoire devaient être explicites. Franchement, écrire un compilateur optimisant pour ce truc, c'est dur.

Plus tard, lorsque l'architecture a été simplifiée du point de vue du logiciel, nous avions toujours besoin d'effectuer les mouvements mémoire manuellement, mais au moins le matériel avait intégré un système permettant de détecter la « distance » pour une opération mémoire (c'est important, vu que la raison première pour cette distinction était l'économie d'énergie: un accès « proche » pouvait ne demander que 16 bits, un accès moyen 32 bits, et un accès lointain ou absolu, 64 bits d'adresse).

EDIT: Oups. J'étais bien fatigué, mais ce message est aussi inutile…

Je connais (« de loin ») l'un des chercheurs du MIT derrière Bluespec. La courbe d'apprentissage est peut-être un peu raide, mais les principes sur lesquels elle se base permettent de créer des conceptions correctes pour du matériel (et techniquement, du logiciel aussi, mais il y a des environnements plus simples à utiliser dans ce cas).

Comme tu le dis dans le journal, avoir des notions de preuves formelles n'est pas un luxe. En retour, Bluespec promet (mais je ne sais franchement pas à quel point c'est vrai) qu'avec un langage relativement haut-niveau, on peut générer un bitstream ou autre description matérielle/bas-niveau optimisés, corrects, et qu'on peut repérer les erreurs bien plus tôt qu'avec des outils standard (genre : ta simulation VHDL te dit que tout va bien, mais tu n'as pas remarqué que tu as affecté deux signaux à un unique pin parce que c'est définit dans deux modules).

Je n'ai jamais utilisé le truc, et la seule raison qui fait que je connais un peu, c'est parce que Bluespec se base sur des concepts que j'utilise au boulot.

Souvent un algo en log(N) prendra plus de mémoire

Alors ça j'aimerais avoir une source. :) Oui, il faut prendre en compte à la fois la complexité en espace et en temps, mais au contraire, mon expérience est qu'un algo en O(N log N) peut gagner en temps parce qu'il stocke plus d'état que son équivalent O(N).

Les histoires de robuste/plus long à implémenter, je ne vois pas trop ce que ça a à faire ici : je connais des algorithmes qui en théorie sont pires que d'autres en temps ET en espace, mais parce que les jeux de données pour lesquels ils sont utilisés dépassent rarement (voire jamais) une taille déterminée, la complexité n'entre pas en compte, et justement tout l'intérêt de cet algo est qu'il est plus simple à implémenter malgré son temps d'exécution asymptotique plus grand.

Le typage statique ne suffit pas. Dans le cas d'OCaml (ou même C++, si tu respectes les règles et que tu ne fais pas des transtypages barbares style C) tu as non seulement un typage statique, mais surtout un typage fort. Je ne pense pas que ton expérience avec OCaml serait la même si l'un de ces deux aspects n'était pas présent.

Un exemple pour illustrer : le langage C a un typage statique. Techniquement on peut dire que le typage est fort (tous les transtypages ne sont pas autorisés implicitement), mais il est malgré tout extrêmement permissif pour stocker une valeur d'un type T1 dans une variable de type T2. N'importe quel développeur un peu expérimenté te dira qu'il faut utiliser ton compilateur de façon à ce qu'il ait les warnings au maximum, si possible qu'il considère les warnings comme des erreurs, etc., car le langage lui-même n'impose pas cela, et donc il faut se reposer sur le compilateur pour ajouter ces fonctionnalités.

Ce n'est pas tout à fait vrai. La CIA n'a pas le droit d'opérer sur le sol US : c'est une agence de renseignement dont le mandat est de détecter les menaces externes. La NSA a parfaitement le droit d'opérer sur le sol US, pour détecter les menaces internes.

Je suis d'accord avec toi sur le principe, mais même avec une grosse structure de données, si on suppose un accès régulier (du genre le traitement examine toujours les mêmes champs de la structure), alors O(N) ou O(N log N) ne devraient différer qu'en termes de complexité non?

Ensuite, c'est sûr qu'après quelques itérations de ton algo en O(N log N) tu risques de te retrouver avec un jeu de données suffisamment petit pour tenir en cache, et là il peut être plus avantageux de passer à un algorithme en théorie moins performant du point de vue complexité, mais qui en pratique tire parti de l'architecture cible. Un bon exemple est le tri fusion, où on fait du diviser et régner jusqu'à atteindre un certain niveau de récursion, pour ensuite utiliser un tri rapide ou par insertion car l'algo a un meilleur comportement avec les caches (ne serait-ce que parce qu'ils trient sur place).

Mais lorsqu'on parle de comportement hors caches (communications inter-nœuds de calcul par ex), je ne vois pas vraiment de raison pour ne pas utiliser l'algo avec la complexité la plus basse, vu que les données devront être copiées sur le réseau de toute manière (je ne sais pas si je suis clair).

[à propos des ordonnanceurs de tâche et des perfs de celui de Linux] Si ils ne le font pas, peut-être que c'est juste de beaux théoriciens à la critique facile sans risquer de montrer qu'on peut mieux faire.

C'est surtout que même si tu as un chouette patch à proposer pour le noyau, s'il n'est pas adopté et que tu es « tout seul » (pas de soutien de la part de structures plus ou moins grosses), alors ça ne vaut pas le coup de le maintenir, vu qu'il faudra courir après toutes les modifs effectuées sur les versions suivantes du noyau et que tu n'auras sans doute pas beaucoup d'aide pour maintenir ton code.

Je n'ai plus tous les détails en tête, mais lorsqu'il s'était s'agit de refondre le code pour les threads Linux, il y avait une certaine compétition entre l'implémentation actuellement utilisée par le noyau, et la bibliothèque proposée par IBM. Il y a sans doute une certaine rancœur et une certaine jalousie, mais j'en connais qui disent que la bibliothèque d'IBM était supérieure mais avait le défaut de ne pas avoir été codée par un pote de Linus (notons que tout ça n'est que commérage—mon premier paragraphe est celui qui a du « contenu » :-) ).

Mais la plupart des calculs scientifiques font des opérations mathématiques en parallèle sur des grilles en N dimensions, ce qui est parfaitement adapté à du calcul sur GPU.

Les GPU sont très utiles dans beaucoup de cas, mais tout dépend du type de données que tu manipules. S'il y a beaucoup d'indirections par exemple, le GPU n'aura sans doute pas l'opportunité de tirer avantage de motifs d'accès à la mémoire qui lui seront favorables (en gros : si l'accès à la mémoire GPU est « unitaire » alors le GPU a du matériel qui permet l'accélération des accès; sinon, l'accès se fera mais beaucoup plus lentement).

Il y a aussi le problème des tests. Certes, dans un code scientifique on a tendance à limiter les branchements autant que possible, mais certains types de calculs requièrent l'utilisation fréquente de branchements difficile à prédire en général (par exemple : les codes de compression, qui sont souvent utilisés avant de transmettre les données via le réseau ou pour les stocker sur disque).

Enfin, il y a tout un tas d'applications qui manipulent un volume de données important (sans pour autant être du type « big data »), mais les objets qui sont manipulés et transformés sont parfois très petits individuellement, c'est-à-dire qu'il y a de gros tableaux n-dimensionnels, mais aussi de petites matrices (genre 20×20, 30×30, etc.), qu'il est difficile à agréger. Du coup, s'il est possible de changer le code pour accommoder le GPU, ça requiert un effort significatif, qui peut être jugé comme trop important (car après il faut passer tous les tests de régression, etc.).

Rocard a arreté de s'intéresser à la politique franco-française après les présidentielles de 1995. Il s'est prequ'entièrement consacré à l'UE par la suite, et le sujet des brevets logiciels était un sujet houleux en 2002, avec énormément de lobbying pour pousser à l'adoption d'un bureau européen des brevets qui puisse imposer l'application de brevets (notamment logiciels) à l'UE entière.

Au niveau national, mis à part les libristes à l'époque, quasiment personne n'en parlait. Le fait est que Rocard était l'un des rares politiciens francophones à être vocal sur le sujet (Cohn-Bendit en étant un autre, mais moins visible en France que Rocard).

Quant à l'ego de Rocard, lui-même ne s'en est jamais caché, et franchement, n'importe qui ayant des ambitions électorales comme les siennes (présidentielles, donc) a nécessairement un énorme ego. Tous ne le montrent pas de la même manière, c'est tout.

EDIT tardif: je n'avais pas vu les commentaires qui te répondaient, et j'ai tenté de modifier mon commentaire trop tard. Bon ben, tant pis. :)

Le problème de l'exemple 1 est que la force physique « brute » n'est pas ce qui est le plus nécessaire pour aller bosser dans une mine, surtout si on considère les équipements modernes.

J'ai vu une variante de cet exemple pour ce qui est d’enrôler des femmes dans les unités d'élite des différents corps d'armée US (en particulier Navy Seals, ou certains groupes de pompiers « d'élite »). Voici ce qui en ressort en lisant les différents commentaires de gens qui ont été à l'armée (Navy, Marines, Army, etc.): mis à part lesdits corps d'élite, qui ont des prérequis drastiques en termes d'endurance, de capacités physiques, etc.¹, les femmes sont tout à fait capables d'opérer au sein de l'armée, avec les mêmes fusils d'assaut et les mêmes responsabilités, y compris le besoin d'aider un camarade blessé en plein milieu d'un conflit armé.

Passons à l'exemple 2 : cet exemple est relativement pourri pour être honnête. Comme pour tous les sports, tu vas avoir tout un tas de jeunes qui vont aller dans des clubs de sports, dont ceux de natation, et parmi ceux-là, quelle que soit la couleur de peau, tu vas te retrouver avec peut-être 1% de jeunes compétiteurs avec des capacités qui pourraient les mener à des niveaux de compétition internationaux. Du coup, si un jeune Noir se débrouille bien, t'auras pas eu à dépenser des millions : tu regardes ses stats, tu vois qu'il a (ou pas) la capacité à concourir dans des compétitions nationales ou internationales au vu des résultats des autres, et c'est tout. Les millions, tu les dépenseras uniquement si tu as déjà une preuve tangible que le potentiel est là.

Dans tout ce qui est sport de compétition, on touche non seulement à l'obsession des joueurs/sportifs qui s'entraînent comme des fous (donc à la régularité et à la fréquence des entraînements au niveau individuel), mais aussi aux exceptions (à ce niveau il est fort probable que la génétique soit impliquée à un certain niveau).

Notons aussi que dans ton exemple 2, tu parles des « Noirs », mais j'aimerais savoir desquels on parle : Noirs originaires d'Afrique sub-saharienne (a.k.a., l'impropre « afro-américains ») ? Je suppose que c'est ce dont tu parles dans ce cas. Si oui, presqu'aucun n'est un « pur » Noir en ce sens : beaucoup ont 30 à 50% de leur patrimoine génétique qui vient de populations « blanches » (irlandais, allemands, britanniques). Qu'en est-il de ceux qui viennent de la Réunion ? De ceux qui viennent de la Jamaïque ? Etc.

Enfin, concernant l'exemple 3 :

La « vitesse de calcul » est aussi un exemple un peu bidon. Oui, c'est du jeunisme. Le mec de 50 ans qui a bossé pendant 30 ans dans un domaine lié à l'ingénierie de pointe (« de pointe », parce que sinon, quelle est la raison d'avoir besoin d'une « vitesse de calcul » élevée ?) est sans doute bien meilleur que moi pour reconnaître un problème, savoir quels outils de calcul il faudrait utiliser, etc. Sa « vitesse de calcul » brute sera peut-être moins bonne qu'un p'tit jeune diplômé, mais je suis presque certain que sa capacité à déterminer le type de solution pour le problème sera meilleure. Tout le monde ne se réfugie pas dans un rôle managérial où on oublie sa science.

Si tu t'arrêtes à l'âge du candidat pour déterminer qui embaucher, alors que sur son CV il y a marqué qu'il faisait partie des ingénieurs qui ont permis à Airbus de sortir l'A380, ou de lancer des satellites, ou, pour un truc d'ingénierie un peu moins pointu, qui a permis de mettre au point certains modèles de voiture, je me dis que tu es un piètre responsable pour ce qui est des embauches. Visiblement ce mec a les compétences; il faut juste que les deux parties s'entendent sur le salaire (et évidemment, c'est souvent là que se trouve le vrai problème).

16 couleurs ? Tu avais une carte EGA ? C'te privilégié. Bon, ceci dit, le 386 DX de mes parents avait 1MB de RAM, et pouvait afficher en 800×600, voire 1024×768 (en entrelacé). Mais comme seuls les jeux vidéo m'intéressaient à l'époque, je bavais plus sur les Amiga et Atari des potes…

Rah la la, ces petits frimeurs, avec leurs 486 flambant neufs.

Il regarde l'horizon, le regard perdu dans le lointain, pensant à son clone AMD 386 DX/33…

(et là je m'attend à ce quelqu'un parle du C64, des MO5 et TO7, du ZX80, etc, donc:)

…Puis repense à son TI99-A, où il avait appris à copier sans comprendre des lignes de code Basic.

Albert demandait (à propos du problème d'utilisation de code libre sujet à brevets):

Et c'est cette clause qui rend la CDDL incompatible avec la GPL v2?

PsychoFox répondait:

non pas spécialement je crois.

Je suis d'accord avec l'histoire que Sun ne voulait/pouvait pas utiliser GPL v2 à l'époque pour les raisons que tu décris. Mais ils auraient parfaitement pu utiliser une license Apache v2 ou BSD, avec une clause additionnelle concernant les brevets (un peu comme les runtime exceptions pour certains codes GPL pour mettre de les lier à d'autres softs). Pas besoin de créer une nouvelle licence directement incompatible avec la GPL mais pas avec BSD…

Pour la licence Apache: v1 et v1.1 sont incompatibles avec GPL v3, mais Apache v2 est compatible (au moins dans le sens Apache v2 → GPL v3).

J'ajouterai qu'il y'a pléthores de licences libres jugées incompatibles avec la GPLv2, de la apache licence à la licence zimbra en passant par la licence mozilla, les licences de xinetd, openssl, eclipse et que sais-je et que :
* on n'en fait pas tout un fromage.
* l'incompatibilité tiens souvent plus de la gplv2 qui fait sa nazie plutôt que de l'autre licence.

Je pense que la différence ici est que ZFS est clairement un outil qui bénéficie à tout le système, et à l'époque de sa publication, c'était une révolution en terme de résilience, tolérance aux pannes, etc., comparé à ext3 (ou parfois XFS) qui était le plus souvent utilisé sous Linux.

Je pense qu'il est naïf de croire que Sun n'a pas rédigé la CDDL comme une façon de dire à ses clients « oui bien sûr, nous faisons du logiciel libre. Mmmh ? Ah non, ça n'est pas compatible Linux, vous devrez utiliser [Open]Solaris. » Un peu comme IBM qui fait du Linux sur certains serveurs bas de gamme (voire milieu de gamme). Cependant, lorsqu'un client dit à IBM qu'il voudrait un truc qui a plus de puissance, etc., il se verra dire par le commercial IBM que « On a de plus gros serveurs, mais il faudra laisser votre OS jouet derrière et prendre un vrai OS pour homme, qui a des poils, viril, et tout ». :)

J'ai des gens de ma famille qui ont eu à subir les maths modernes. Ça les a franchement traumatisés. Je tends à penser comme toi : ceux qui ont une affinité naturelle avec certains raisonnements faits en maths ont été encouragés, mais ce n'était sans doute pas la majorité (même si je suis le premier à dire que mes exemples « perso » tiennent bien entendu de l'anecdote).

Après, je trouve qu'en général la France a une approche des maths parfois trop formelle, mais au moins (même au collège ou au lycée, et très clairement dans le supérieur), elle est relativement logique. Aux USA par exemple, l'apprentissage de l'algèbre relationnelle est rarement « constructiviste » : on apprend à se servir d'un déterminant ou d'une matrice avant de savoir ce qu'est un espace vectoriel. Ce n'est qu'un exemple parmi tant d'autres, mais c'est le côté trop pragmatique des choses : on veut que les étudiants soient capables d'utiliser matlab/octave très vite pour faire des trucs en génie électrique/mécanique/chimique, et on verra plus tard pour expliquer pourquoi ça marche.

Ça donne des trucs rigolos, du genre des bouquins qui s'intitulent « Linear Algebra Done Right » et qui … suivent en gros une façon logique et constructiviste pour enseigner l'A.L.

Nicolas Bourbaki s'inscrirait en faux contre de tels propos. Il a grandement contribué à la réforme de l'enseignement des mathématiques sous la forme des mathématiques modernes. Cette réforme fut sur le plan pédagogie, et cela de manière surprenante, un véritable échec ! :-P

Soit dit en passant, vu qu'en fac on « réapprend » les maths apprises depuis la primaire, je pense que l'approche de « Bourbaki » se défend parfaitement en premier cycle universitaire.

Bon sérieusement, on peut reprocher pas mal de choses à Zenitram, mais la misogynie n'en est pas une selon moi. Le contexte est très clair dans son texte : il entoure l'expression « femme hystériques » de guillemets justement car il fait de l'ironie (et donc au pire, si on considère qu'il s'agit d'une expression misogyne, ce qui peut se comprendre, il faut l'attribuer aux gens qui penseraient qu'une pièce initialement pensée pour être jouée par des hommes est désormais jouée par des femmes, et que des idiots demanderaient « qui sont ces femmes hystériques qui dénaturent la pièce ? », ce qui est justement l'argument contre lequel Zenitram se bat — chépasichuiclair).

Bref, beaucoup de bruit pour pas grand chose.

J'avais écrit une grosse réponse, mais je vais essayer de la réduire à un ou deux paragraphes.

1. Je me suis trompé dans mon message précédent, il existe bien une implémentation pour Python 3. Il y a donc un ensemble de gens qui ont un intérêt à pouvoir faire interagir l'écosystème .Net avec Python, et je ne vois pas pourquoi on devrait les ignorer. Tout comme les gens qui écrivent du Scala ou du Clojure se servent de la JVM et de bibliothèque standard de Java pour réutiliser des briques de base déjà bien testées. Que Microsoft ait commencé cette initiative pour attirer plus de développeurs n'est pas pertinent pour la discussion : il existe bel et bien une implémentation complète du langage autre que CPython. Que toi tu n'en aies pas l'utilité est un autre problème.
2. La grande majorité des langages réellement utilisés n'ont pas de norme associée à ma connaissance (évidemment je peux me tromper) : Java a un comité « informel » (± les gros acteurs industriels que Sun/Oracle doivent accepter car sinon ils se tourneraient vers d'autres technologies), OCaml, Scala, Python, Ruby, Perl, etc. Par contre, il existe des spécifications pour le langage et ce qui doit être considéré comme la bibliothèque standard associée (voir par exemple ici pour Python 3).
3. La plupart de ces langages n'ont qu'une implémentation de référence. Il y a peut-être des ports ailleurs, mais souvent seule l'implémentation de référence est compétitive en termes de performance, ou pas complète en termes de bibliothèque standard par exemple ¹. Même Java, qui n'est pas normé mais qui est clairement un standard, n'a que 2 vraies implémentations « compétitives » : OpenJDK et l'implémentation d'IBM (l'implémentation GNU est intéressante d'un point de vue académique mais je ne l'ai jamais vue déployée en industrie). Dans le cas de Python, comme l'implémentation de référence est libre et que c'est celle qui est utilisée en pratique, il existe un moyen « organique » de faire évoluer le langage ou la bibliothèque standard : s'inscrire sur la liste de diffusion, participer activement à l'évolution du langage ou de la bibliothèque en proposant des patches, etc. Parmi les langages qui ont une vraie norme, je ne connais que C++ qui permet à un individu (dans le sens qu'il ne s'exprime pas pour sa boite, ni n'est nécessairement soutenu par elle) de pouvoir réellement influer sur l'évolution du langage.

J'oubliais :

Python n'est un standard ni sur le papier, ni dans les faits. Il n'y a pas de standard multi-implémentation, […]

C'est faux. Par exemple, Python 2.x possède plusieurs implémentations. Il y a au moins celle de référence, et aussi IronPython (une implémentation en .Net).

Une norme est un document qui définit formellement comment implémenter une certaine technologie. Un standard est « simplement » quelque chose qui est en pratique utilisé par un grand nombre de gens. Comme c'est (le plus souvent) une technologie utilisée en grande majorité pour une implémentation spécifique (par exemple : Python, Ruby, Perl), cette implémentation de référence devient le standard.

[…] la référence du langage évolue en tandem avec l'évolution de l'implémentation principale

IronPython (qui semble arrêté depuis que Python 3 devient de plus en plus utilisé, c'est dommage) a implémenté Python jusqu'en version 2.7.

Autre exemple : Java n'est pas une norme (Sun/Oracle ont toujours refusé de passer par un institut de normalisation), mais ont produit un ensemble de benchmarks/outils de vérification pour garantir qu'une implémentation autre que celle de référence est conforme à la spécification du langage. Java est donc bien un standard, mais pas une norme.

Dans cette discussion nous utilisons la notion de langage standardisé dans deux sens, un faible (standard sur le papier) et un fort (standard dans les faits):
- sens faible (sur le papier): il existe une spécification du langage annoncée comme un standard multi-implémentations
- sens fort (dans les faits): la possibilité d'avoir plusieurs implémentations conformes et compatible est utilisée en pratique, et la communauté est sainement répartie entre plusieurs implémentations

Contrairement à l'Anglais, le Français a une façon de distinguer les deux : on parle de norme lorsqu'il s'agit d'avoir un groupe de gens qui décident de spécifier quelque chose de façon formelle (exemples : AFNOR, ISO, ANSI, etc.), et on parle de standard lorsqu'il s'agit d'une « norme de fait » (par exemple : Perl, Python, Ruby, etc.).

Donc je propose d'utiliser ces termes pour le reste de la discussion s'il y a besoin de faire une distinction. ;)

Oui, je pensais aux lambdas qui simplifient pas mal de choses.

Ensuite, de mon point de vue de chercheur en parallélisme (« argument » d'autorité, je sais), franchement, créer une fermeture ou un thread dans un langage « fait pour »¹, c'est très proche au final. :) Après tout, il faut capturer le contexte, puis appliquer un traitement dessus avec par-dessus le marché des paramètres qui, eux, peuvent varier. Bon ben, la différence entre une fermeture et un thread à ce niveau c'est que le thread peu en plus s'exécuter en parallèle.

Et surtout, je trouve que la syntaxe n'est ni plus ni moins compliquée que pour d'autres langages qui chercheraient à faire quelque chose d'équivalent. Par exemple en Perl, pour créer une fermeture on peut écrire ainsi :

# Exemple complètement artificiel.
my $fixed_arg = shift @ARGV;
my $cmp_fixed_arg_with = sub { 
    my $operand = shift;
    return $operand <=> $fixed_arg;
};
say "$fixed_arg " . ($cmp_fixed_arg_with($_) == 0 ? '==' : '=/=') . " $_" for (1 .. 100);

On peut trouver ça « naturel » ou « intuitif » ou au contraire « compliqué ». Je pense que c'est principalement un problème d'habitude et d'exposition à des langages divers.