Les architectes sont plus que jamais devant la nécessité d'améliorer les performances de leurs applications Web, de plus en plus complexes et diversifiées. Parmi les possibilités qu'il leur faut regarder de près, figurent WebAssembly d'origine W3C et LLVM, les deux ayant en commun une compilation intermédiaire qui produit un code plus performant, différent dans les deux cas, voire plus proche des machines sous-jacentes. Alors qu'il existe déjà un ASM.js que certains qualifient d'assembleur JavaScript, bien qu'il s'agisse d'une restructuration de l'arbre syntaxique AST, WebAssembly est une sorte de formatage de bas niveau du code issu d'une compilation C ou C++ (entre autres), le code s'exécutant dans un "run time" dédié. A vrai dire WebAssembly est structurellement très proche de JavaScript, avec lequel il interagit. LLVM, à l’inverse, produit un bitcode, le projet ayant pour finalité de fabriquer des compilateurs qui vont le produire. Sur une sorte d'échelle de Richter des performances, WebAssembly et LLVM se situent à 80 % environ de celles d'une application native. Dans ce webinaire, nous allons nous attacher à définir ce que sont exactement ces technologies et à en définir les contextes, pour lesquels elles seront les mieux adaptées. Une longue pratique du codage ne sera pas nécessaire pour en apprécier le contenu.

Notre webinaire n'a pas pour ambition d'apporter un éclairage nouveau sur l'autisme, simplement de rappeler à quel point notre cerveau est une machine complexe et qu'il ne faut pas classer les autistes par rapport aux personnes "normales", selon la canadienne Michelle Dawson, mais en fonction de critères différents, susceptibles de mettre en valeur leurs "hypercompétences", dont le moins que l'on puisse dire est qu'elles sont fascinantes. Dans notre domaine, les autistes ont parfois des capacités à traiter des gros volumes de données, sans méthodes particulières, car elles sont innées, avec un sens de la "vérité" qu’IBM, par exemple, exploite pour les insérer dans des groupes de surveillance ou de tests d'applications. De la même manière qu'un "bipède" normal voit tout de suite la différence entre un rouge et un bleu, parce qu'il est programmé pour cela, grâce à des bâtonnets au fond de l’œil, les autistes sont parfois capables d'aborder de longues séquences de chiffres et d'en faire ressortir instantanément ceux qui sont supérieurs à la moyenne, comme le ferait en moins bien, un tableur Excel. Et les autistes d'ajouter qu'ils ne calculent rien, mais qu'ils "voient" les résultats… Notre webinaire a été programmé une première fois en début d’année, mais la réticence de certains des abonnées LeMarson, nous a amené à prendre un peu de recul… Il est vrai que le sujet est très délicat, qui nous fait toucher du bois à quel point nous ne comprenons rien à la "neuromorphologie" de l'être humain…

La question reste posée. Que faire des énormes silos de codes Cobol, qui se sont accumulés dans les entreprises depuis 1970. On peut en "basculer" une partie dans un environnement plus favorable, Unix ou Linux, avec les utilitaires transactionnels adéquats. On peut aussi réécrire les applications avec un langage plus récent : Java, C#, Ceylon…et les API adaptées. Tout dépendra de la volonté du management de prendre, ou non, des risques. Il est cependant indispensable et c'est le but de notre webinaire, d'essayer de comprendre la "substantifique moelle" de l'écosystème Cobol, ce qu'est un langage impératif, histoire d'être mieux armé quand le moment de passer à l'acte sera venu Quant à qualifier Cobol de "vieux" langage, c'est aussi idiot que de dire que les langages objet sont plus modernes. La preuve. Cobol est né chez Grace Hopper en 1959, mais n'a été vraiment utilisé qu'à partir de 1964, avec l'arrivée de la série 360 d'IBM, alors que Smalltalk, considéré comme le premier langage objet de l'histoire, remonte à 1966, chez Xerox. En fait, ils sont contemporains. Ce qui n'enlève rien au problème posé et au choix qui reste à faire.