🐞 🕝 🌦️ Dynamisches Tippen ist kein Entwicklungswerkzeug. Das ist Unsinn (mies) 🧘 👩🏻‍🤝‍👨🏿 🏳️

Es gibt viele Dinge in der Programmierung, die ich sehr schlecht verstehe. So viele, dass sie mich manchmal fragen - was kannst du überhaupt?

Ich verstehe die Typen und das Design einer praktischen und zuverlässigen API. Aber für eine gute Hälfte der Entwickler bedeuten diese Dinge nichts. Weil sie dynamisches Tippen verwenden und keine Ahnung haben, welche Probleme und warum ich sie löse.

Die meiste Zeit meines Lebens winkte ich ihnen nur zu und ging vorbei. Diese Dummköpfe verstehen die offensichtlichen Dinge nicht, und ich habe mich nicht verpflichtet, jedem js-Spitznamen zu erklären, warum sein Code nicht Entwicklung, sondern Spielzeug-Prototyping ist. Aber die Zeit vergeht, und die Anzahl der Idioten in der Umgebung denkt nicht einmal daran, abzunehmen. Anstatt ihre gesamte Front-End-Branche endlich auf ein statisches Zeitskript umzustellen, beginnen diese Esel, alle möglichen Dinge zu verwenden, Tonnen von Tests zu schreiben und sich vorstellbare Tricks zu stellen - nur um sie nicht zu verstehen Typen.

Es gibt viele kontroverse Dinge auf der Welt, bei denen die Wahrheit, je nachdem, was Sie erhalten möchten, von einer Waage auf eine andere übertragen wird und im letzten Ausweg keinen Platz für eine endgültige Wahrheit lässt. Vor ein paar Jahren schrieb ich bereits über das Tippen, aber dann war ich jung, dumm und feige - ich hatte eine Position, aber um nicht wie ein Idiot zu wirken, versteckte ich sie sorgfältig hinter philosophischen Diskussionen darüber, wie kompliziert alles ist und wie schwierig es für Anhänger ist, zu arbeiten verschiedene Schreibmodelle zusammen.

Aber heute bin ich hergekommen, um zu sagen:

Dynamisches Tippen ist höllische Scheiße, und Ingenieure, die an einen solchen Ansatz glauben, irren sich ernsthaft.

Schau mal. Durch statische Typisierung kann ich einen Teil der Bedingungen ausdrücken, unter denen der Code nicht als zusätzliche Anweisungen für den Compiler fungieren kann. Das heißt, ich weiß, dass diese Funktion nur mit solchen Objekten funktioniert, ich beschreibe sie in ihrer Signatur und erhalte eine Garantie - ein Objekt eines anderen Typs wird nicht an die Funktion übertragen. Außerdem kann ich dem Compiler anhand von Typen mitteilen, wie mein Code funktioniert. Der Compiler kann diese Informationen verwenden, um Optimierungen durchzuführen und mir beispielsweise Hinweise zu geben. Verschiedene Entwicklungstools können Typinformationen verwenden, um automatisch umzugestalten, dies sicher zu tun und mit der Garantie, dass der Fick nicht bricht. Der Typcode selbst macht die Codebasis verständlich und bringt Ihre Befehlssätze näher an die Prozesse, die Sie mit diesem Code beschreiben.

Gegner der statischen Typisierung sagen, dass all diese Dinge unnötig sind. Das sagen sie mir

Fehler, die Typen abfangen, sind die Mühe nicht wert, Code für diese Typen zu schreiben.

Ernsthaft? Ernsthaft? Sind wir zu faul, um Charaktere zu schreiben? Bruder. Sie denken fünf Stunden und drucken zehn Minuten. Sie sind Ingenieur, versuchen Sie also herauszufinden, von welcher Art von Unbehagen Sie sprechen. Und vergessen Sie nicht, dass Sie mit oder ohne statische Eingabe mehr als einmal in Ihrer Codebasis die Strukturen von Objekten beschreiben, mit denen Sie arbeiten werden. Wenn Sie jedoch Statik verwenden, können der Compiler und die IDE die Arbeit für Sie erledigen. Überprüfen Sie Ihren Code auf Fehler, die diese Objekte beschreiben. Wenn Sie zu faul sind, um Typanmerkungen in Funktionen zu schreiben, verwenden Sie die Sprache der Typinferenz oder generieren Sie sie mithilfe von Erweiterungen der IDE.

Wenn Sie darauf stampfen, dass Anmerkungen die Codebasis aufblasen - denken Sie verdammt noch mal an all unsere Prinzipien, dass das Explizite besser ist als das Implizite, dass eine der wichtigen Aufgaben der Codebasis darin besteht, sowohl für eine Person als auch für eine Maschine verständlich und lesbar zu sein. Wenn Sie zu faul sind, um in Ihrem blöden Kopf zu arbeiten, um zu verstehen, auf welchen Arten von Anwendungen Ihre Anwendung funktioniert, habe ich schlechte Nachrichten für Sie. Um etwas zu schreiben, das funktioniert, müssen Sie diese Arbeit noch erledigen. Tun Sie es einfach, Sie werden nicht bestimmt, sondern auf Anfrage. Infolgedessen werden Sie den Prozess beschreiben, aber Sie werden ihn nicht in Ihren Kopf setzen, und die Qualität Ihres Codes wird reagieren. Bugs, Inkohärenz und Krücken.

Gegner der statischen Typisierung sagen, dass das frühzeitige Erkennen von Fehlern nicht so wichtig ist.

Alo. Ihr Task Board ist voller Fehler, die Entwickler zugelassen haben. Das Reparieren von Fehlern ist ein großer Teil der gesamten Arbeit in der Branche. Wir verbringen Milliarden menschlicher Stunden damit, lächerlich lächerliche Fehler zu beheben. Schreiben Sie Code ohne Fehler? oder hast du nur smarte bugs Ja, die Hölle ist dort geschwommen. Wenn der Compiler nicht für Sie überprüft hätte, dass Sie die geschweifte Klammer geschlossen haben, glauben Sie mir, wir hätten Hunderte von Fehlern mit einer offenen Klammer.

Wenn Sie darüber nachdenken, wo ein Fehler möglicherweise auftreten kann und wo nicht, erscheint eine gefährliche Illusion, dass Sie die Situation unter Kontrolle haben und alle Fälle vorausgesehen haben. Ich arbeite seit sieben Jahren, es gab noch nie einen solchen Fall, dass ich alle Fälle zur Verfügung gestellt habe. Da dies ein Sonderfall des Problems des Handlungsreisenden ist, können Sie NIEMALS alle Fälle vorhersehen. Sie können nicht einmal das häufigste und wahrscheinlichste betrachten. Wann, wer und in welcher Situation wird den Code mit einem kritischen Fehler schreiben, in welchem Modul und wie er es tun wird - Sie haben verdammt noch mal keine Ahnung. Alles, was Sie tun können, ist die Wahrscheinlichkeit eines Fehlers zu verringern. Reduzieren Sie es also, Sie bekommen dafür verrücktes Geld bezahlt.

Gegner der statischen Typisierung Kontrasttypen mit Tests.

Ich werde nicht sagen, dass sie Idioten sind, ich werde sagen, dass sie einfach nicht gut darüber nachgedacht haben. Hier ist die offensichtliche Wahrheit für Sie - Tests zeigen, dass der vorhandene Code unter bestimmten Bedingungen funktioniert. Und Typen garantieren, dass Code, der noch nicht geschrieben wurde, unter bestimmten Bedingungen geschrieben wird. Tests sind erforderlich. Typen werden benötigt. Sie verringern immer noch die Wahrscheinlichkeit, dass alles fällt. In einer Welt, in der wir ein Budget haben, um fünf Stunden lang mit dem Team zu besprechen, was mit unserem Edge nicht stimmt, bleibt Zeit, Anmerkungen und einige Tests hinzuzufügen.

Nerds aus der dynamischen Welt sagen, dass statische Typisierung dem Code die Flexibilität nimmt.

Ich verstehe nicht, um welche Flexibilität es sich handelt. Selbst im verarmten C # erlaubt mir das Typsystem, keine Kontrolle über Datentypen zu haben, deren Typ für mich keine Rolle spielt. Ich kann der Sprache immer beweisen, dass hier, sagen sie, hier zuhören, ich kann nicht beschreiben, was dieses Ding ist, aber ich weiß sicher, dass es ein solches Feld hat, von diesem Typ oder von diesem Typ. Und ich werde nur mit ihm arbeiten. Jede statisch typisierte Sprache erlaubt dies. Und Flexibilität und die Freiheit, Code zu schreiben, der einfach nicht funktioniert - ich brauche keine solche Flexibilität.

JS-Teenager sagen, dass statische Typisierung den Fokus von Aufgabe zu Typbeschreibung verschiebt.

Und ich sage, dass die Beschreibung von Typen die Beschreibung des Prozesses ist, den Sie automatisieren. In der objektorientierten Programmierung, in der funktionalen Programmierung, in jeder anderen Programmierung beschreiben wir Dinge aus der realen Welt, und unser Code enthält das Wissen darüber, ohne das es nicht funktionieren kann. Sie werden diese Arbeit noch machen.

Wenn das Typensystem einer bestimmten Sprache es Ihnen nicht ermöglicht, Ihre Domain korrekt und sicher zu beschreiben, ist dies ein Problem einer bestimmten Sprache und nicht der statischen Typisierung im Allgemeinen. Dies ist normal und speziell in dieser Sprache werden manchmal alle Arten von Objekten und Dynamiken verwendet, aber wo immer Sie Garantien erhalten können, erhalten Sie diese.

Ich habe Code sowohl mit dynamischer als auch mit statischer Typisierung geschrieben. Mit streng und nicht streng, mit strukturell und nominativ.

Nur die dynamische gab mir das starke Gefühl, dass ich einen Kinderpseudocode schrieb, der nur funktionieren würde, wenn die Sterne konvergierten.

Dynamisches Tippen ist ein Spielzeug, eine Sache, die funktioniert, wenn Sie sich entscheiden, etwas in eins zu codieren und es zu vergessen. Wenn Sie planen zu entwickeln, wenn andere Leute mit Ihrem Code arbeiten, wenn der Code auf dem Produkt herauskommt und anfängt, Benutzerprobleme zu lösen, wird er einmal pro Woche aktualisiert - dynamisches Tippen ist absolut inakzeptabel. Denken Sie daran und ändern Sie die Erweiterungen Ihrer Dateien von .js in .ts.

Und schauen Sie sich meinen Podcast an - es gibt eine neue Ausgabe

Dynamisches Tippen ist kein Entwicklungswerkzeug. Das ist Unsinn (mies)