1 pièce(s) jointe(s)
Un développeur parvient à exécuter DOOM dans le système de types de TypeScript
Un développeur parvient à exécuter DOOM dans le système de types de TypeScript :
La plus grande réalisation technique de TypeScript a nécessité 3,5 trillions de lignes de code, 90 Go de mémoire vive et une année entière de travail
Depuis sa création en 2012, TypeScript s’est imposé comme un langage incontournable du développement web moderne, offrant une couche de typage statique robuste à JavaScript. Il a permis aux développeurs d’écrire du code plus sûr, plus maintenable et mieux structuré. Pourtant, malgré toutes ses avancées, personne n’aurait pu prédire qu’un jour, les types TypeScript eux-mêmes pourraient exécuter… DOOM. Oui, DOOM, le célèbre jeu de tir à la première personne sorti en 1993 et devenu un symbole du hacking créatif dans le monde du développement. Cette prouesse technique, à la fois absurde et géniale, marque un tournant dans l’histoire de TypeScript. Non seulement elle démontre l’expressivité extrême du système de types, mais elle repousse aussi les limites de ce que l’on croyait possible dans un langage conçu pour la vérification statique.
À la base, TypeScript est un surensemble de JavaScript qui introduit un typage statique optionnel. Ce typage permet de détecter les erreurs à la compilation et d’améliorer « l’intelligence » des éditeurs de code.
L'exploit a été conçu par l'ingénieur logiciel Dmitri Mitropoulos, fondateur de Michigan Typescript et cofondateur de Squiggleconf. Il a publié une vidéo présentant les résultats d'une année d'efforts pour faire fonctionner le jeu dans le système Typescript.
Cette vidéo YouTube (avec d'excellentes valeurs de production - « environ 200 heures ont été consacrées à cette vidéo de 7 minutes ») décrit un projet incroyablement absurde : Dimitri Mitropoulos a passé une année entière à faire tourner DOOM entièrement via le compilateur TypeScript (TSC).
En cours de route, il a implémenté une machine virtuelle WASM complète dans le système de type, y compris l'implémentation des 116 instructions WebAssembly nécessaires à DOOM, en commençant par l'arithmétique des entiers et en incorporant la gestion de la mémoire, la répartition dynamique et plus encore, le tout fonctionnant au-dessus de nombres binaires en complément à deux stockés sous forme de chaînes de caractères littérales.
Le résultat final était de 177 To de données représentant 3,5 trillions de lignes de définitions de types (un trillion étant 1 000 milliards). Le rendu de la première image de DOOM a pris 12 jours à raison de 20 millions d'instanciations de types par seconde.
Pour donner du grain à moudre, Dmitri Mitropoulos a noté quelques types dont il s'est servi :
Citation:
Envoyé par Dmitri Mitropoulos
Tour des types ridicules
Au cas où vous ne seriez là que pour chahuter, voici de quoi alimenter vos cauchemars :
- ShiftRight : ce fichier entier contient des choses ridicules, mais parfois il faut faire ce qu'il faut.
- Add : c'est la pierre angulaire de l'arithmétique dans l'application. En le voyant pour la première fois, certaines personnes ont dit « Je vois des types TypeScript à l'écran, mais je ne vois pas bien où se fait l'addition ». C'est juste. Mais elle est là.
- La division a été de loin l'instruction la plus difficile à implémenter pour passer à 64 bits. C'est à @teamchong que revient tout le mérite. Pour y arriver, nous avons dû construire un bit à la fois pour voir où il y avait des limites de performance avec le terrain de jeu de la division.
- certains des assistants binaires sont un peu difficiles à regarder en plein écran.
- final-doom-pun-intended contient les fichiers où la ligne d'arrivée a été franchie. Pendant que le projet avançait, nous avons réalisé des maquettes qui montraient à quoi il ressemblerait une fois terminé. Comme c'est souvent le cas, les maquettes ont fini par être la vraie chose à la fin, haha.
- david-blass-incredibleness, ainsi nommé en raison d'une information très importante fournie par @ssalbdivad qui a provoqué une explosion de progrès, est le tableau de bord principal pour le développement des tests individuels.
- Les tests de conformité pour la boucle complète (c'est-à-dire de C à WASM à types) ainsi que de WASM à types peuvent être trouvés ici. Ils sont appelés tests de conformité parce que les mêmes entrées sont testées à nouveau contre le moteur d'exécution WebAssembly intégré à JavaScript, ce qui est la façon dont je me suis assuré que le comportement de ce moteur est correct.
- La plupart des instructions sont étonnamment simples, mais certaines instructions relatives au flux de contrôle ont un peu de chair sur l'os.
- bootstrap montre comment démarrer le moteur d'exécution WebAssembly dans les types TypeScript.
- Il y en a probablement d'autres plus amusantes, mais la dernière que je mentionnerai est que vous pouvez trouver certains des types primitifs de base ici et le « comment la machine d'état fonctionne-t-elle réellement » ici.
Les implications et conséquences de cette prouesse
Bien sûr, jouer réellement à DOOM avec TypeScript n’a pas de valeur pratique. Mais ce genre d’expérimentation ouvre la porte à des discussions plus profondes sur les limites et les possibilités des langages de programmation.
Cet exploit ne se limite pas à un simple tour de force amusant. Il illustre plusieurs aspects fascinants du langage et de la programmation en général :
TypeScript est-il turing-complet ?
Turing complet est un concept fondamental en informatique, car il définit les capacités d’un système ou d’un langage de programmation. Être Turing complet signifie qu’un système a la capacité de gérer n’importe quel calcul, ce qui le rend polyvalent et puissant. Cette propriété permet aux programmeurs d’exprimer des idées complexes, de résoudre des problèmes complexes et de concevoir des applications logicielles sophistiquées.
Pour simplifier, nous pourrions dire qu'un système est dit complet au sens de Turing lorsque, avec suffisamment de temps et de mémoire, ainsi que les instructions nécessaires, il a la capacité de résoudre n'importe quel problème informatique, quelle que soit sa complexité. Ce terme est couramment appliqué aux langages de programmation modernes, car la plupart d’entre eux (notamment C++, Python, JavaScript et autres) sont Turing-complet (par calque de l’anglais Turing-complete). Cela signifie que ces langages peuvent théoriquement exécuter n’importe quel algorithme, à condition de disposer des ressources et des instructions nécessaires.
Dans le cas d'espèce, est-il possible d’écrire n’importe quel programme arbitraire uniquement à travers des types ? Cette idée, bien que théorique, a maintenant un élément qui s'ajoute à la discussion avec DOOM.
L’abus du compilateur TypeScript
Le compilateur TypeScript n’est pas censé être un moteur d’exécution, mais cette démonstration laisse entrevoir qu’il peut être détourné pour exécuter des tâches bien au-delà de ce pour quoi il a été conçu. Cela pourrait potentiellement soulever des questions sur la sécurité et la scalabilité du langage.
Le fait que TypeScript permette ce genre d’abus pourrait être vu comme un signal d’alarme pour l’équipe de Microsoft. Si le système de types est si expressif qu’il peut exécuter du code arbitraire, cela peut aussi signifier des temps de compilation anormalement longs et des comportements imprévus dans les gros projets.
Une performance et une absurdité sans précédent
Faire tourner DOOM de cette manière est inefficace et incroyablement lent comparé à une exécution normale. Pourtant, c’est une déclaration puissante : si un système de typage peut faire cela, alors il est plus qu’un simple outil de vérification. Peut-on le considérer comme une plateforme d’expérimentation à part entière ?
Conclusion
Faire tourner DOOM en pur TypeScript est probablement le plus grand exploit technique jamais réalisé avec ce langage. C’est une démonstration de force, un pied de nez aux conventions, et une preuve que l’ingéniosité des développeurs n’a pas de limites. Au-delà de son côté absurde et inutile en pratique, cet exploit montre à quel point TypeScript est un langage puissant et flexible, dépassant largement son rôle initial. C’est une véritable lettre d’amour aux langages de programmation, à la bidouille informatique et à la créativité sans bornes des développeurs.
:fleche: code source du moteur d'exécution WASM
Source : vidéo dans le texte
Et vous ?
:fleche: Que révèle cette expérience sur la puissance du système de types de TypeScript ? Si TypeScript peut exécuter DOOM, quelles autres applications insoupçonnées pourraient émerger ?
:fleche: Cet exploit prouve-t-il que les systèmes de typage modernes deviennent trop complexes ? À partir de quel moment un langage de typage cesse-t-il d’être un outil de validation pour devenir un langage de programmation à part entière ?
:fleche: Peut-on imaginer des usages concrets de cette expressivité extrême dans un contexte industriel ? Est-ce une démonstration utile ou simplement un exploit absurde sans impact réel sur le développement ?
:fleche: Cette expérimentation change-t-elle votre perception de TypeScript en tant qu’outil de développement ?
Voir aussi :
:fleche: Cinq vérités inconfortables à propos de TypeScript selon Stefan Baumgartner, auteur de livres sur le langage de programmation
:fleche: Le jeu Doom original est désormais jouable dans un fichier PDF personnalisé contribuant ainsi à son héritage de portage sur à peu près toutes les plates-formes
