🏇🏽 🗡️ 👲🏼 La frappe dynamique n'est pas un outil de développement. C'est absurde (moche) ⛩️ 👩🏿‍💻 🕸️

Il y a beaucoup de choses dans la programmation que je comprends très mal. Tellement que parfois ils me demandent - à quoi êtes-vous même doué?

Je comprends les types et la conception d'une API pratique et fiable. Mais pour une bonne moitié des développeurs, ces choses ne signifient rien. Parce qu'ils utilisent la frappe dynamique, et ils n'ont aucune idée de quels problèmes et pourquoi je les résous.

Pendant la majeure partie de ma vie, je leur ai simplement fait signe de la main et suis passé. Ces imbéciles ne comprennent pas les choses évidentes, et je n'ai pas entrepris d'expliquer à chaque pseudonyme pourquoi son code n'est pas du développement, mais du prototypage de jouets. Mais le temps passe, et le nombre d'idiots autour ne pense même pas à diminuer, au lieu de déplacer enfin toute leur industrie front-end vers un script de temps statique, ces ânes commencent à utiliser toutes sortes de choses, à écrire des tonnes de tests et à passer à toutes les astuces imaginables - juste pour ne pas comprendre les types.

Il y a beaucoup de choses controversées dans le monde lorsque, selon ce que vous voulez obtenir, la vérité est transférée d'une échelle à l'autre, ne laissant aucune place à une vérité ultime en dernier ressort. Il y a quelques années, j'ai déjà écrit sur la dactylographie, mais j'étais jeune, stupide et lâche - j'avais une position, mais afin de ne pas ressembler à un idiot, je l'ai soigneusement caché derrière des discussions philosophiques sur la complexité de tout et sur la difficulté pour les adhérents de travailler différents modèles de dactylographie ensemble.

Mais aujourd'hui, je suis venu ici pour dire:

Le typage dynamique est une merde infernale, et les ingénieurs qui croient en une telle approche se trompent sérieusement.

Regarde. La frappe statique est une chose qui me permet d'exprimer certaines des conditions dans lesquelles le code ne peut pas fonctionner comme des instructions supplémentaires pour le compilateur. Autrement dit, je sais que cette fonction ne fonctionne qu'avec de tels objets, je les décris dans sa signature et j'obtiens une garantie - un objet d'un type différent ne sera pas transféré vers la fonction. De plus, les types me permettent de dire au compilateur comment fonctionne mon code. Le compilateur pourra utiliser ces informations pour effectuer des optimisations et, par exemple, me donner des conseils. Différents outils de développement peuvent utiliser les informations de type pour refactoriser automatiquement, le faire en toute sécurité et avec la garantie que la baise ne se casse pas. Le code de type lui-même rend la base de code compréhensible et rapproche vos jeux d'instructions des processus que vous décrivez avec ce code.

Les opposants au typage statique disent que toutes ces choses sont inutiles. Ils me disent que

Les bogues qui interceptent les types ne valent pas la peine d'écrire du code pour ces types.

Sérieusement? Sérieusement? Sommes-nous trop paresseux pour écrire des personnages? Bro. Vous réfléchissez pendant cinq heures et vous imprimez dix minutes. Vous êtes ingénieur, alors essayez de comprendre de quel type de confort vous parlez. Et n'oubliez pas qu'avec ou sans typage statique, vous décrirez plus d'une fois dans votre base de code les structures d'objets avec lesquelles vous travaillerez. Mais si vous utilisez la statique, le compilateur et l'IDE peuvent faire le travail pour vous. Et vérifiez votre code pour les erreurs décrivant ces objets. Si vous êtes trop paresseux pour écrire des annotations de type dans des fonctions - utilisez le langage d'inférence de type ou générez-les à l'aide d'extensions de l'EDI.

Si vous piétinez que les annotations gonflent la base de code - rappelez-vous, bon sang, tous nos principes sur le fait que l'explicite est meilleur que l'implicite, que l'une des tâches importantes de la base de code est d'être compréhensible et lisible, à la fois par une personne et par une machine. Si vous êtes trop paresseux pour travailler dans votre tête stupide pour comprendre sur quels types d'applications votre application fonctionnera, alors j'ai de mauvaises nouvelles pour vous. Pour écrire quelque chose qui fonctionne, vous devez toujours faire ce travail. Faites-le, vous ne serez pas déterminé, mais à la demande. En conséquence, vous décrirez le processus, mais vous ne le mettrez pas dans votre tête, et la qualité de votre code répondra. Bugs, incohérence et béquilles.

Les opposants au typage statique disent que les premières erreurs de capture ne sont pas si importantes.

Alo. Votre tableau des tâches est rempli de bogues autorisés par les développeurs. La réparation des bogues est une grande partie de tout le travail dans l'industrie. Nous passons des milliards d'heures humaines pour corriger des erreurs ridiculement ridicules. Écrivez-vous du code sans bugs? ou avez-vous seulement des bogues intelligents? Oui, l'enfer a nagé là-bas. Si le compilateur ne vérifiait pas que vous avez fermé l'accolade, croyez-moi, nous aurions des centaines de bogues avec une accolade ouverte.

Lorsque vous pensez à l'endroit où un bogue peut potentiellement se produire et où il ne l'est pas, une illusion dangereuse apparaît que vous maîtrisez la situation et avez prévu tous les cas. Je travaille depuis sept ans, il n'y a jamais eu une telle chose que j'ai prévu tous les cas. Parce que c'est un cas particulier du problème du voyageur de commerce - vous ne pouvez JAMAIS prévoir tous les cas. Vous ne pouvez même pas considérer le plus commun et le plus probable. Quand, qui et dans quelle situation écrira le code avec un bogue critique, dans quel module et comment il le fera - vous, bon sang, vous n'en avez aucune idée. Tout ce que vous pouvez faire est de réduire les risques de bug. Alors réduisez-le, vous êtes payé de l'argent fou pour cela.

Les opposants aux types de contraste de typage statique avec des tests.

Je ne dirai pas qu'ils sont idiots, je dirai qu'ils n'y ont tout simplement pas bien pensé. Voici la vérité évidente pour vous - les tests indiquent que le code existant fonctionne dans certaines conditions. Et les types garantissent que le code qui n'a pas encore été écrit sera écrit sous certaines conditions. Des tests sont nécessaires. Les types sont nécessaires. Vous réduisez toujours les chances que tout tombe. Dans un monde où nous avons un budget pour discuter avec l'équipe pendant cinq heures de ce qui ne va pas avec notre Edge, nous aurons le temps d'ajouter des annotations et quelques tests.

Les nerds du monde dynamique disent que la saisie statique prive le code de flexibilité.

Je ne comprends pas de quel type de flexibilité ils parlent. Même dans le C # appauvri, le système de type me permet de ne pas avoir le contrôle sur les types de données dont le type n'a pas d'importance pour moi. Je peux toujours prouver à la langue qu'ici, disent-ils, écoutez ici, je ne peux pas décrire ce qu'est cette chose, mais je sais avec certitude qu'elle a un tel champ, de ce type ou de ce type. Et je ne travaillerai qu'avec lui. Toute langue typée statiquement le permet. Et la flexibilité et la liberté d'écrire du code qui ne peut tout simplement pas fonctionner - je n'ai pas besoin d'une telle flexibilité.

Les adolescents JS disent que la saisie statique déplace le focus de la tâche vers la description du type.

Et je dis que la description des types est la description du processus que vous automatisez. En programmation orientée objet, en programmation fonctionnelle, dans toute autre programmation, nous décrivons des choses du monde réel, et notre code contient les connaissances à leur sujet, sans lesquelles il ne peut pas fonctionner. Vous ferez toujours ce travail.

Si le système de typage d'une langue spécifique ne vous permet pas de décrire votre domaine correctement et en toute sécurité - il s'agit d'un problème d'une langue particulière, et non de la frappe statique en général. C'est normal, et en particulier dans ce langage, vous utilisez toutes sortes d'objets et dynamiques dans des endroits, mais partout où vous pouvez obtenir des garanties, vous les obtenez.

J'ai écrit du code avec une frappe dynamique et statique. Avec strict et non strict, structurel et nominatif.

Seul le dynamique m'a fait sentir fortement que j'écrivais un pseudo-code enfant qui ne fonctionnerait que si les étoiles convergeaient.

La frappe dynamique est un jouet, une chose qui fonctionne lorsque vous décidez de coder quelque chose en un et de l'oublier. Lorsque vous envisagez de développer, lorsque d'autres personnes travailleront avec votre code, lorsque le code sort sur le prod et commence à résoudre les problèmes des utilisateurs, la mise à jour une fois par semaine - la frappe dynamique est absolument inacceptable. N'oubliez pas cela et changez les extensions de vos fichiers de .js en .ts.

Et regardez mon podcast - il y a un nouveau numéro

La frappe dynamique n'est pas un outil de développement. C'est absurde (moche)