TypeScript entre dans le top 20 des langages les plus populaires
D'après le classement Redmonk de juin 2017

Le , par yahiko, Rédacteur/Modérateur

Selon le nouveau classement de Redmonk du mois de juin 2017, il apparaît que TypeScript, le langage open source, surensemble typé de JavaScript, développé initialement par Microsoft, semble avoir gagné sa légitimité dans le paysage concurrentiel des langages Web.

Il est désormais et durablement installé dans le top 20 du classement de Redmonk, à la 17e place pour être précis.

Cette progression, on ne peut plus remarquable, est très certainement à mettre sur le compte de son association avec le framework Angular 2 développé par Google.

En complément à cette vue d'ensemble, on trouvera ci-dessous un focus sur la progression sur l'année des principaux langages liés au Web. Le départ d'une flèche indique la position du langage un an auparavant, et l'arrivée d'une flèche, la position actuelle du langage concerné.

Évolution sur un an des principaux langages Web


Quelques précautions avant d'interpréter les progressions. Il faut noter que la méthodologie de Redmonk a changé durant l'année écoulée. Ces changements n'impactent que la composante horizontale des progressions puisque Redmonk ne prend plus en compte le nombre de dépôts sur GitHub, mais le nombre de pull requests (il se pourrait que votre humble serviteur a peut-être pu contribuer à ce changement, qui sait...). Ceci limite l'influence des dépôts « morts », sans activité, et tend à mieux refléter la dynamique des langages.

La composante verticale, relative à Stackoverflow, n'a pas été impactée par le changement de méthodologie et les évolutions sur cet axe peuvent être interprétées sans précaution particulière.

On peut par exemple supposer que la progression, assez modérée, du langage Dart essentiellement sur l'axe horizontal, est en partie due au changement de méthodologie du classement Redmonk.

Par contre, on notera une légère baisse, principalement sur la composante verticale, celle qui peut être interprétée sans restriction, du langage JavaScript. Est-ce là les premiers signes d'un essoufflement de la popularité du langage phare des développeurs Web au profit des nouveaux arrivants ? Il y a tout de même un gouffre que peu de personnes oseront franchir. Il est plus sage de voir si cette tendance se confirme ou pas à l'avenir.

On constatera à titre d'anecdote le fort décrochage sur un an du langage ActionScript d'Adobe. Il est probablement promis à la marginalité dans les années à venir, sauf révolution chez l'éditeur de Photoshop.

Comment interprétez-vous ce classement ?
Les positions et les évolutions vous surprennent-elles ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de koyosama koyosama - Membre éprouvé https://www.developpez.com
le 21/06/2017 à 8:45
Quand j'ai commencé typescript avec les premières versions et l'ai mis sur CV. Les recruteurs, les tech leaders se sont bien foutus de ma gueule. Après avec ce classement, ça fait extrêmement bizarre d'entendre cette soudaine popularité.
Maintenant, je suis revenu à la mode Vanilla JS car je suis déjà en train d'estimer que tout ce qui va apparaître dans typescript va apparaître avec ES6, 7 ou même 8 dans le futur. Je m'attendais pas du tout à ce que les initiatives d’évolution de Javascript aient eu lieu.
Avatar de codec_abc codec_abc - Membre averti https://www.developpez.com
le 21/06/2017 à 13:07
Le principal avantage de Typescript c'est le typage statique (ie, détecté les erreurs - au moins une partie - avant l’exécution) et à moins d'avoir raté un épisode je crois pas que les prochaines versions de Js s'orientent dans cette voie. Donc il y a aura toujours quelque chose que Ts fera que Js ne fera pas. Après, libre à chacun d'estimer le gain ou la perte d'un système de type statique vs dynamique. Pour moi le choix est vite fait, à partir de plus de 20 lignes de code je vois déjà l’intérêt.
Avatar de kilroyFR kilroyFR - Membre éclairé https://www.developpez.com
le 21/06/2017 à 17:15
Je trouve ca vraiment merité pour TypeScript car c'est un reel progres pour faire du javascript. Jamais compris comment un langage aussi degueulasse que js puisse avoir autant de succes et etre aussi laborieux a utiliser.
Une telle permissitivité dans un langage est pour moi un anti pattern absolu (le mot clé var etant le summum) car ca autorise a faire tout et n'importe quoi sans aucun controle.
Depuis que je fais du typescript je prends vraiment plaisir a coder en javascript. Merci a M$ pour ça, enfin quelque chose d'utile et vraiment productif.
Avatar de yahiko yahiko - Rédacteur/Modérateur https://www.developpez.com
le 21/06/2017 à 18:30
Citation Envoyé par sitexw Voir le message
Et ce, via le "strong mode", un sous ensemble de JavaScript dans le même genre que le "strict mode" mais en plus hard. L'objectif est de retirer tous les éléments de javascript qui le ralentissent ou qui le rendent trop permissif. Et dans la même continuité, un autre sur ensemble optionnel au "strong mode" permettant le typage static que l'on connaît aujourd'hui avec typescript est aussi dans les cartons.
En tout cas, JavaScript est très loin d'être sur ça fin, je dirais même qu'il en est qu'au début de son aventure et ce, même après 20 ans d'existence.
Tout d'abord le "strong mode" est une notion assez indépendante de la question du typage.
Types: We also intend to propose a (sound) gradual type system for JavaScript. This addresses similar goals, and can benefit significantly from some of the restrictions we propose here. However, it is a much more complex feature, and potentially interesting independent of strong mode. We hence defer such a type system to a separate proposal. Strong mode can be viewed as a transition path to such a typed JavaScript.
La réflexion de Google au sujet d'un "strong mode" est assez ancienne, de 2015 pour être précis. Un petit billet à ce sujet avait été publié sur developpez.com d'ailleurs où Google mentionnait explicitement vouloir s'inspirer de TypeScript : https://javascript.developpez.com/ac...le-JavaScript/

Depuis 2015, absolument aucune avancée ou réflexion supplémentaire sur le sujet n'a été publiée par Google, autant que je sache. A tel point que la page sur le sujet a disparu du site dédié au moteur V8...

Il est possible que le typage statique arrive officiellement dans JavaScript, mais autant se l'avouer tout de suite, ce n'est pas demain la veille, pour diverses raisons dont certaines relativement polémiques sur lesquelles j'ai déjà pu échanger avec des membres de ce forum et sur lesquelles je ne reviendrai pas. Donc en attendant ce jour tout à fait hypothétique, TypeScript peut tout à fait convenir à des personnes préférant travailler avec un langage proposant un typage statique, tout en étant très proche de JavaScript.
Avatar de koyosama koyosama - Membre éprouvé https://www.developpez.com
le 22/06/2017 à 19:37
Citation Envoyé par codec_abc Voir le message
Le principal avantage de Typescript c'est le typage statique (ie, détecté les erreurs - au moins une partie - avant l’exécution) et à moins d'avoir raté un épisode je crois pas que les prochaines versions de Js s'orientent dans cette voie. Donc il y a aura toujours quelque chose que Ts fera que Js ne fera pas. Après, libre à chacun d'estimer le gain ou la perte d'un système de type statique vs dynamique. Pour moi le choix est vite fait, à partir de plus de 20 lignes de code je vois déjà l’intérêt.
Je ne pense pas que c'est que statique vs dynamique. Je travaille avec JS / C# et Typescript. Je peux te dire que le typescript ressemble plus a C# que Javascript.
La facont dont tu ecris le code est completement different.

Apres les erreurs avant et apres, tu les auras forcement dans tous les language, c'est pour sa qu'on se fait chier a faire des logs, des try-cactch, des proxy pattern, etc ...
Javascript est plus proche du fonctionnal programming, alors que typescript est plus proche de l'imperative.

Pour avoir essayer de creer une framework sous Javascript et sous Typescript, il y a une *** grosse difference. Dans Typescript tu as cette motion d'encapsulation alors que Javascript c'est derisoire. La syntax est aussi un peu different quand on regarde bien. Et la compilation joue un mega role super important qui permet a un developpeur de pouvoir regler les erreurs basique de programmation tel que la syntax ou le type. Mais le type tu peux tricher. C'est justte que c'est plus simple que le compilateur me crache a la geule que je fasse des erreurs d'utilisation de mes fonctions. Et puis le compilateur joue un autre role que le developpeur ne voit pas souvent, il optimise ton code a mort. Par exemple, imaginons que ce projet (prepack) marche, il peut tres bien etre integrer au compilateur typescript. Le compilateur c'est pas que verifie les erreurs. Google par exemple ompile different versions de Chrome pour differentes platforme car tu as besoin d'optmiser la memoire pour cetaine machine, mais d'autre la performance. Voir cette video lighthouse. Et le compilateur tyepscript fera sa dans le futur pour cibler quel type d'optimisation tu as besoin.

Apres ES6 a apport e le sugar syntax de la creation de classe, c'est avoir PHP 4 avec le systeme de classe qui est apparu mais n'est pas encore totalement bien foutu. Par example mettre en private les variables dans une classe c'est chiant.
Tu vas me dire qu'on a pas besoin de l'encapsulation dans un code Javascript puisque de toute facon a acces au code et on doit toujours proteger les transaction clients / serveur par de meilleurs controle cote serveur.
Sauf que cette reflexion ne s'applique pas que je fais un jeu mobile ou un RPG avec RPG maker MV par exemple, j'ai besoin de cacher des information pour eviter que le joueur cheat par exemple ou encore avec Electron, les applications offline en gros.

Je me rappelle encore des gens qui me disaient il y a 5 ans que c'etait une heresie de voir le terme class dans Javascript ou encore PHP 6 avait ete anule parce que le comite ne voulait pas de typage fort, ben il est dans PHP 7 pas grave.
ES8 n'est pas encore sur papier et ES7 n'est pas encore termine ou meme pas commence. Et quand tu regardes les propositions de ES7, surtout celui la, tu vois qu'il devient, sur certains aspects, le meme que les autres langages.

Javascript evolue plus dans le sens de NodeJS pour servir NodeJs que pour servir Javascript Client. Parce que demain on va faire des software avec electron, des jeux en Javascript pour les plateformes. Le single thread principle de NodeJS va peut etre disparaitre. D'ailleurs Google a choisi Typescript parce que la syntax actuel de Javascript est super complique pour faire ce qu'il veut faire avec angular JS 2 et 4.

En fait, on te l'a pas dit mais Javascript c'est le nouveau Java ^^.
Avatar de codec_abc codec_abc - Membre averti https://www.developpez.com
le 22/06/2017 à 20:03
J'ai pas l'impression que tu sais que vraiment de quoi tu parles.

Citation Envoyé par koyosama Voir le message
Je ne pense pas que c'est que statique vs dynamique. Je travaille avec JS / C# et Typescript. Je peux te dire que le typescript ressemble plus a C# que Javascript.
La facont dont tu ecris le code est completement different.
Oui justement, C# a (majortairement) un système de type statique alors que Js est dynamique.

Citation Envoyé par koyosama Voir le message

Apres les erreurs avant et apres, tu les auras forcement dans tous les language, c'est pour sa qu'on se fait chier a faire des logs, des try-cactch, des proxy pattern, etc ...
Javascript est plus proche du fonctionnal programming, alors que typescript est plus proche de l'imperative.
Les 2 langages sont multi-paradigme et tu peux très bien faire de la programmation fonctionnelle en Ts. Quant aux erreurs, plus le langages est strict moins tu aura d'erreurs au runtime. De plus, certains languages n'ont pas de système de try-catch et les logs n'ont pas pour but de gérer les erreurs mais de d'avoir une idée de l'état du système a posteriori.

Citation Envoyé par koyosama Voir le message

Pour avoir essayer de creer une framework sous Javascript et sous Typescript, il y a une putain grosse difference. Dans Typescript tu as cette motion d'encapsulation alors que Javascript c'est derisoire. La syntax est aussi un peu different quand on regarde bien. Et la compilation joue un mega role super important qui permet a un developpeur de pouvoir regler les erreurs basique de programmation tel que la syntax ou le type. Mais le type tu peux tricher.
Tu te contredis par rapport au début. Un compilateur/transpileur a 2 rôles : Garantir une certaine cohérence des sources et/ou générer du "code" de plus bas niveau (et peut-être l'optimiser au passage). En Ts, on a que le premier cas qui est uniquement utile grâce au fait que Ts est a typage statique.

Citation Envoyé par koyosama Voir le message

Apres ES6 a apport e le sugar syntax de la creation de classe, c'est avoir PHP 4 avec le systeme de classe qui est apparu mais n'est pas encore totalement bien foutu. Par example mettre en private les variables dans une classe c'est chiant.
Tu vas me dire qu'on a pas besoin de l'encapsulation dans un code Javascript puisque de toute facon a acces au code et on doit toujours proteger les transaction clients / serveur par de meilleurs controle cote serveur.
Sauf que cette reflexion ne s'applique pas que je fais un jeu mobile ou un RPG avec RPG maker MV par exemple, j'ai besoin de cacher des information pour eviter que le joueur cheat par exemple ou encore avec Electron, les applications offline en gros.
Comme Ts te génère du code Js je vois pas comment tu va protéger quoi que soit au runtime si l'utilisateur décide d'ouvrir la console (de chrome, FF ou autre) et de faire ce qu'il veut.

Citation Envoyé par koyosama Voir le message

Je me rappelle encore des gens qui me disaient il y a 5 ans que c'etait une heresie de voir le terme class dans Javascript ou encore PHP 6 avait ete anule parce que le comite ne voulait pas de typage fort, ben il est dans PHP 7 pas grave.
ES8 n'est pas encore sur papier et ES7 n'est pas encore termine ou meme pas commence. Et quand tu regardes les propositions de ES7, surtout celui la, tu vois qu'il devient, sur certains aspects, le meme que les autres langages.

Javascript evolue plus dans le sens de NodeJS pour servir NodeJs que pour servir Javascript Client. Parce que demain on va faire des software avec electron, des jeux en Javascript pour les plateformes. Le single thread principle de NodeJS va peut etre disparaitre. D'ailleurs Google a choisi Typescript parce que la syntax actuel de Javascript est super complique pour faire ce qu'il veut faire avec angular JS 2 et 4.
Js ne dispose pas de features dans le langage qui permet de faire du multi-thread. La seule chose qui s'en rapproche ce sont les web-workers qui sont des solutions du pauvre par rapport aux autres langages. De plus, j'ai pas l'impression que Js évolue plus pour une plateforme (le browser) que l'autre (NodeJs). En plus, pour le browser wasm arrive tranquillement donc ca m’étonnerai que Js et les VMs Js (V8, Chakra,...) évoluent pour faire de Js un langage qui supportent la programmation concurrente alors que son système de type est moisi. Le multi-thread ça sert avant tout à gagner en perf (et aussi bloquer le thread UI lors des longs calculs, mais pour le reste Js est asynchrone donc la programmation concurrente n'est pas utile). Sauf qu'en Js tous les nombres sont représentés par des doubles (ie nombre flottant sur 64 bits) ce qui est stupide quand on sait qu'ils sont beaucoup plus lent que les nombre entier ou flottant sur 32 bits. Bref, Js n'aura probablement jamais de programmatation concurrente car ce n'est utile que pour les langages qui peuvent offrir des performances correctes ce qui n'est pas son cas.

Citation Envoyé par koyosama Voir le message

En fait, on te l'a pas dit mais Javascript c'est le nouveau Java ^^.
Java est assez lourd à utiliser mais le comparer à Js c'est le dénigrer. Pour un langage sorti après Java, Js est assez mauvais et fait pas mieux voire souvent pire que Java dans tous les domaines.
Avatar de yahiko yahiko - Rédacteur/Modérateur https://www.developpez.com
le 22/06/2017 à 21:40
1. Concernant la programmation concurrente en JavaScript, à noter qu'une fonctionnalité permettant de dépasser les limitations des WebWorkers est à l'étude au sein du comité ECMAScript. Il s'agit du SharedArrayBuffer.

2. TypeScript propose le paradigme OO classique, mais ne l'impose pas comme en Java. Rien n'empêche d'écrire un programme TypeScript comme on écrit un programme JavaScript (c'est d'ailleurs la recommandation officieuse de l'équipe Microsoft qui n'encourage pas l'utilisation des classes) en mentionnant juste le typage lorsque cela est nécessaire. Il convient de rappeler que l'inférence automatique des types évite de tout typer explicitement. Si le code TypeScript côtoyé ressemble à du C#, c'est sans doute que les personnes qui ont codé viennent de cette culture, mais ce n'est pas un impératif du langage en lui-même. C'est un avantage à mon sens. Cela permet à la fois aux programmeurs venant du fonctionnel et à ceux venant de la POO d'appréhender facilement ce langage.

3. Les programmes codés dans des langages à typage statiques sont statistiquement moins sujets à bugs que ceux codés dans des langages à typages dynamiques. Voir l'étude à ce sujet menée sur la plateforme GitHub :
For those with positive coefficients we can expect that the language is associated with, ceteris paribus, a greater number of defect fixes. These languages include C, C++, JavaScript, Objective-C, Php, and Python. The languages Clojure, Haskell, Ruby, Scala, and TypeScript, all have negative coefficients implying that these languages are less likely than the average to result in defect fixing commits.
Néanmoins, ceux qui souhaitent continuer à programmer en JS sont toujours libres de le faire, mais il n'est pas exact d'affirmer que le typage statique n'apporte rien en terme de fiabilité.
Avatar de codec_abc codec_abc - Membre averti https://www.developpez.com
le 22/06/2017 à 23:54
1. La fonctionnalité est assez pauvre. C'est juste un partage d'un tableau de bytes avec des opérations atomiques dessus. On est loin des primitives de la programmation concurrente d'un langage haut niveau (mutex/sémaphore, queue thread-safe, etc..). En l’occurrence c'est plutôt ce que l'on retrouve quand on fait de la programmation sur GPU.

2. C# est pas mal orienté coté fonctionnel. Les classes Func<T> et Action<T> permettent de retourner ou passer en paramètres des fonctions. Linq a bien poussé C# du coté fonctionnel aussi. Certes on pas du niveau de F#/Haskell/Idris/.... mais c'est pas si mal. Après les gens qui le pratique depuis longtemps ont surement un état d'esprit très "OO" s'ils ont pas fait l'effort de se tenir à jour des évolutions du langage.

3. Même si je préfère de loin les langages typés statiquement le passage cité de l'étude est étrange. Ruby et Clojure sont typés dynamiquement et Scala est bourré de "gotcha". En plus python est très similaire à Ruby et j'ai du mal a concevoir comment l'un peut-être dans une catégorie et l'autre dans celle opposé. Pour avoir regarder le papier en diagonale la méthodologie me parait approximative. D'ailleurs la phrase qui suit ta citation est la suivante : "One should take care not to overestimate the impact of language on defects". Bref on est d'accord sur le fond mais c'est clairement pas le meilleur argument pour les langages à typage statique.
Avatar de koyosama koyosama - Membre éprouvé https://www.developpez.com
le 23/06/2017 à 3:21
Citation Envoyé par codec_abc Voir le message
J'ai pas l'impression que tu sais que vraiment de quoi tu parles.
Marrant, beaucoup de personne me dit sa et au final la plupart des choses que j'ai predit sont arrives ^^.

Citation Envoyé par codec_abc Voir le message
Oui justement, C# a (majortairement) un système de type statique alors que Js est dynamique.
Il y a utilisattion et technicite, d'ou ce qu'on appelle les bonnes pratique et le permissif.

Citation Envoyé par codec_abc Voir le message

Les 2 langages sont multi-paradigme et tu peux très bien faire de la programmation fonctionnelle en Ts.
Sa contredit le message d'au dessus.

Citation Envoyé par codec_abc Voir le message

Tu te contredis par rapport au début. Un compilateur/transpileur a 2 rôles : Garantir une certaine cohérence des sources et/ou générer du "code" de plus bas niveau (et peut-être l'optimiser au passage). En Ts, on a que le premier cas qui est uniquement utile grâce au fait que Ts est a typage statique.

Comme Ts te génère du code Js je vois pas comment tu va protéger quoi que soit au runtime si l'utilisateur décide d'ouvrir la console (de chrome, FF ou autre) et de faire ce qu'il veut.
En fait je partais dans l'hypothese d'un interet futur. Typescript est tres tres jeune encore. Je regarde aussi par rapport sur quoi il est succeptible de copier et le plus proche est peut etre GCC a mon sens. Sans compte que j'ai vu le code qui generait derriere, et me demande si c'est pas plus simple de voir un intermediaire genere du code a ta place. Tu as raison sur Transpileur et Compilateur.

Citation Envoyé par codec_abc Voir le message

Js ne dispose pas de features dans le langage qui permet de faire du multi-thread. La seule chose qui s'en rapproche ce sont les web-workers qui sont des solutions du pauvre par rapport aux autres langages. De plus, j'ai pas l'impression que Js évolue plus pour une plateforme (le browser) que l'autre (NodeJs). En plus, pour le browser wasm arrive tranquillement donc ca m’étonnerai que Js et les VMs Js (V8, Chakra,...) évoluent pour faire de Js un langage qui supportent la programmation concurrente alors que son système de type est moisi. Le multi-thread ça sert avant tout à gagner en perf (et aussi bloquer le thread UI lors des longs calculs, mais pour le reste Js est asynchrone donc la programmation concurrente n'est pas utile). Sauf qu'en Js tous les nombres sont représentés par des doubles (ie nombre flottant sur 64 bits) ce qui est stupide quand on sait qu'ils sont beaucoup plus lent que les nombre entier ou flottant sur 32 bits. Bref, Js n'aura probablement jamais de programmatation concurrente car ce n'est utile que pour les langages qui peuvent offrir des performances correctes ce qui n'est pas son cas.
Mouais et alors. Apres j'ai appris que google etait un bon magicien quand ile le voulait. Et en plus j'ai entedu les meme arguments sur Ruby et bizrrement cette annee, il y a le hype de la programmation concurrente sur Ruby en ce moment.

Citation Envoyé par codec_abc Voir le message

Java est assez lourd à utiliser mais le comparer à Js c'est le dénigrer. Pour un langage sorti après Java, Js est assez mauvais et fait pas mieux voire souvent pire que Java dans tous les domaines.
Non je voulais jsute blaguer un peu. Je voulais dire que le nouveau truc hype avec un system de module sur module comme Java et aussi qu'il evolue a la vitesse que Java prenait a l'epoque. En fait Java est le language le plus demande dans les entreprise selon le parametre de TIOBE.
Qui aurait pu penser que firefox aurait ete battu par chrome, ou encore que IE6 par firefox.

^^ Tu as peu etre raison. Je ne sais pas de quoi je parle. Comme indique en haut, on s'est bien foutu de ma geule avec typescript, je m'attendais a ce qu'un gars sur developpez me fasse la meme reflexion.
Apres je peux comprendre avec le flop de dart et durant ce flop, je me souviens de la conference microsoft qui disait qu'il faut pas creer un nouveau language mais ameliorer et supporter Javascript.

Assembly c'est pas pour maintenant et c'est pas encore stable, c'est aussi affirmatif de dire que dart allait remplacer Javascript ^^ ou d'attendre que les entreprises arrent d'utiliser Objective-C pour la programmation IOS. C'est une migration c'est pas 5 minutes ><.
Avatar de yahiko yahiko - Rédacteur/Modérateur https://www.developpez.com
le 23/06/2017 à 11:01
Citation Envoyé par codec_abc Voir le message
1. La fonctionnalité est assez pauvre. C'est juste un partage d'un tableau de bytes avec des opérations atomiques dessus. On est loin des primitives de la programmation concurrente d'un langage haut niveau (mutex/sémaphore, queue thread-safe, etc..). En l’occurrence c'est plutôt ce que l'on retrouve quand on fait de la programmation sur GPU.

3. Même si je préfère de loin les langages typés statiquement le passage cité de l'étude est étrange. Ruby et Clojure sont typés dynamiquement et Scala est bourré de "gotcha". En plus python est très similaire à Ruby et j'ai du mal a concevoir comment l'un peut-être dans une catégorie et l'autre dans celle opposé. Pour avoir regarder le papier en diagonale la méthodologie me parait approximative. D'ailleurs la phrase qui suit ta citation est la suivante : "One should take care not to overestimate the impact of language on defects". Bref on est d'accord sur le fond mais c'est clairement pas le meilleur argument pour les langages à typage statique.
1. Avec les WebWorkers qui permettent le parallélisme, l'introduction du SharedArrayBuffer est une étape supplémentaire vers la concurrence. Ton affirmation
Js n'aura probablement jamais de programmatation concurrente car ce n'est utile que pour les langages qui peuvent offrir des performances correctes ce qui n'est pas son cas.
est à mon sens excessive puisqu'à partir du moment où JavaScript dispose d'un mécanisme de mémoire partagée entre threads, il est possible de développer des bibliothèques avec les primitives que tu cites. L'obstacle ne me paraît pas du tout insurmontable. D'ailleurs, dès que les SharedArrayBuffer seront supportés par les navigateurs, il sera tout à fait possible de faire de la programmation concurrente en compilant du code concurrent C++ en WebAssembly (ou asm.js).

3. La citation choisie avait surtout pour intérêt de faire apparaître TypeScript. Pour le reste, il suffit de lire l'abstract et la conclusion pour voir que les langages à typage statique sont dans cette étude plus fiables que ceux à typage dynamique. Après, il est toujours possible de critiquer une étude, mais il me semble que c'est celle qui est la plus aboutie à ce jour sur le sujet. Après, il est un peu curieux de qualifier la méthodologie d'approximative quand on a soit même fait une lecture "approximative" (en "diagonale" si je reprends tes mots). N'hésite pas à exposer plus en détail tes reproches néanmoins. Il n'en reste pas moins qu'il s'agit d'une étude sérieuse, scientifique, même si probablement perfectible, comme tout, et que je ne connais pas de meilleur argument sur un tel sujet que la démarche scientifique.
Contacter le responsable de la rubrique Accueil