Als mein Freund und ich zur Schule gingen und nur davon träumten, Entwickler zu werden, überlegten wir, wie wir etwas zusammenstellen könnten - ein Spiel oder ein sehr nützliches Programm.
Ich fing an, die Profis und C # zu lernen, es ist JavaScript. Wir haben die High School abgeschlossen, an der Universität studiert, in der Armee gedient und einen Job bekommen. Wir waren hier und da von industrieller Entwicklung geplagt, und als wir beide es satt hatten, erinnerten wir uns daran, wo wir angefangen hatten.
Nachdem wir bereits erfahrene Entwickler versammelt hatten, beschlossen wir schließlich, unser eigenes Projekt zu erstellen - ein zweidimensionales Videospiel. Da der Freund eine saubere Front war und ich Full Stack war, wurde der Browser zur offensichtlichen Plattform für uns. Früher habe ich die Front nur mit TypeScript entwickelt, und wir dachten, kein Problem, TS ist nur eine Obermenge von JavaScript. Nehmen Sie es und alles läuft reibungslos. Egal wie. Als wir anfingen, über Arbeit zu diskutieren, waren wir mit einem unglaublichen Abgrund von Missverständnissen konfrontiert.
Also sah ich die Aufgabe, ein Spiel zu machen. Ich bin so - ja, wir haben eine Art "Spiel", eine Art "Inventar", eine Art "Ding", eine Art "Karte", eine Art "Ort". Ich kann mir ungefähr vorstellen, wie sie zusammenarbeiten, sie beschreiben, ein Projekt zusammenstellen und alles funktioniert. Der Compiler hat mich überprüft, ich habe alles richtig gemacht. Als nächstes beginne ich mit dem Schreiben von Code, der diese Typen verwendet. Aufgrund der Tatsache, dass sie es sind, ist es für mich viel einfacher. Die IDE sagt es mir und sucht nach Fehlern. Wenn das Projekt läuft, funktioniert es höchstwahrscheinlich. Ich habe viel Zeit mit Typbeschreibungen verbracht und es war gut. Hier ist mein Ansatz.
Mein Freund wollte das Gegenteil tun - sofort Code schreiben und keine Typen beschreiben. Er war nicht bereit, das Problem als Typenfamilie zu definieren. Ich wollte nicht darauf aufbauen, ich sah die Aufgabe nicht als eine Reihe von Klassen, Typen, Datensätzen oder Ähnlichem. Es schien mir einfach undenkbar. Wir hatten beide in vielerlei Hinsicht Recht, nur die Richtigkeit eines jeden von uns schloss den anderen aus.
Im Ernst, wir unterhielten uns stundenlang, aber jeder sprach für sich, als ob er in verschiedenen Sprachen sprach. Und Sie können nicht schreiben, dass unser Gehirn nicht flexibel ist. Noch vor einem Jahr bin ich schmerzlos von der objektorientierten in die funktionale Welt gewechselt und umgekehrt. Außerdem habe ich viel Zeit damit verbracht, JS zu lernen, und er lernte mehrere statisch typisierte Sprachen.
Die Technologie, die für Entwickler zur ersten „Kampftechnologie“ wurde, definiert sie jedoch so stark, dass zwei erwachsene erfahrene Menschen einfach nicht bereit sind, einander zuzuhören. Im Laufe der Jahre, in denen wir uns mit Entwicklung befasst haben, hat sich unsere Vision zu unterschiedlich entwickelt, und Ansätze zur Lösung von Problemen haben überhaupt nicht zusammengearbeitet.
Infolgedessen haben wir die Idee der Zusammenarbeit aufgegeben. Der Gedanke kommt sofort in den Sinn, dass das Problem nur bei uns beiden liegt. Vielleicht, aber ich habe das bei anderen Leuten in der Branche gesehen.
Statische und dynamische Typisierung weisen einen grundlegenden unvereinbaren Unterschied auf
Mein Code beantwortet die Frage "Wie man damit arbeitet" und als Code für Entwickler, die an dynamisches Tippen gewöhnt sind - "Wie es funktioniert". Beide Ansätze haben ein Recht auf Leben, und es gibt Werkzeuge für beide, aber nur einer kann an vorderster Front stehen.
Static ist gut für große Projekte, die sich über Hunderte von Jahren entwickelt haben, und dynamisch für kleine Teams für Aufgaben, bei denen häufig nur Schreibcode benötigt wird. Mit Dynamic sparen Sie Zeit und Mühe zu Beginn der Entwicklung und mit Static am Ende.
Die Idee, Typen in den Vordergrund zu stellen, hat mein Denken über den Entwickler ernsthaft beeinflusst.
Als ich zu Beginn der Reise C # gewählt habe, habe ich die statische Typisierung auf mein Weltbild übertragen, unter dem ich jetzt leide. Nachdem ich ein Problem gesehen habe, versuche ich, seine Lösung als eine Reihe von Typen und Prinzipien ihrer Interaktion darzustellen. Wenn ich ein Modul entwickle, bestimme ich zuerst, auf welchen Typen es arbeitet und welche mit seiner Umgebung interagieren. Ich kann mich nicht einmal daran erinnern, wie ich zuvor mit dem Lösen von Problemen umgegangen bin.
Alle Java-Programmiertrainings sind Schulungen zum Entwerfen und Verwenden von Typen. .NET CLR - C # -Runtime - basiert auf Typen und für Typen. Die statische Typisierung steht im Mittelpunkt des Entwurfs der objektorientierten Programmierung (Hallo, Klassen von JS, ich habe entschieden, dass Sie nicht benötigt werden). Die kanonischen Implementierungen der meisten OOP-Muster sind mit Interface gefüllt, das in einer dynamisch typisierten Sprache völlig bedeutungslos ist.
Muster selbst sind eine sprachübergreifende Sache, aber kann mir jemand sagen, warum das "Zustands" -Muster in einer dynamisch typisierten Sprache benötigt wird? Was ist mit dem Erbauer? Bei diesen Mustern geht es nicht um Entwicklung, sondern um Typen. Typen und OOP sind untrennbar miteinander verbunden.
Sie können Ihre Geschäftslogik nicht basierend auf Typen erstellen, wissen aber im Entwicklungsprozess nichts darüber. Aus diesem Grund gibt es Front-End-Anbieter, die ihren Code mit einer unvorstellbaren Anzahl von Komponententests abdecken, bei denen lediglich die Codebasis auf das Fehlen von Typfehlern überprüft wird.
Wir alle wissen sehr gut, dass Sicherheit durch Berichterstattung eine Illusion ist. Tests werden von Hand geschrieben und sind per Definition weniger zuverlässig als das in die Sprache integrierte Typprüfungssystem.
Dies bedeutet nicht, dass dynamisch typisierte Sprachen nicht benötigt werden (tatsächlich denke ich wirklich, dass sie nicht benötigt werden). Dies bedeutet, dass Sie bei der Verwendung von OOP das vorherrschende Paradigma aufgeben müssen. All diese Einheit von Daten und Operationen auf ihnen ist für Leute, die eine statische Prüfung haben.
Die Entwickler, mit denen ich mich befasst habe, glauben nicht, dass das Vorhandensein statischer Typisierung den Entwicklungsansatz ändert, und sie schreiben denselben Code wie in dynamischen Sprachen und fügen eine Typprüfung hinzu. Ich denke, das ist grundsätzlich falsch. Und das macht sich gerade bei einem modernen Frontend bemerkbar.
Ich weiß, Fronten zu kritisieren ist ein Tabuthema. Eines Tages starteten mein Freund und ich eine KI, die alle auf Twitter trollt, und Brendan Ike schnappte danach. Im Ernst, der Schöpfer des Javascript kämpfte in den Kommentaren mit unserem neuronalen Netzwerk.
Aus irgendeinem unbekannten Grund sind diese Jungs einfach nicht bereit, in einer Welt zu leben, in der ihre Vision ernsthafte Lücken enthält. Deshalb kritisiere ich nur diejenigen von ihnen, die in mein definitiv typisiertes Projekt stürzen und dort ihre eigenen Bestellungen aufgeben.
Wir hätten in unseren kleinen Welten gelebt, aber TypeScript hat uns gepusht
Ich schreibe also Code, der aufgrund von Typen nicht falsch verwendet werden kann. Im Projekt erwarte ich, dass auch andere Typen verwenden. Dann funktioniert mein Code wie beabsichtigt. Und ich decke nicht wissentlich alle Fälle des Missbrauchs dieses Codes ab (weil die Eingabe dies ausschließt). Aber ein JS-Spitzname kommt in das Projekt, nimmt diese Art von mir, verpackt sie in eine beliebige und verwendet sie falsch, was zu subtilen Fehlern führt.
JavaScript-Entwickler sind davon überzeugt, dass Typescript immer noch dasselbe JS ist, jedoch manchmal die Möglichkeit bietet, statische Typprüfungen hinzuzufügen, wenn sie diese benötigen. Es ist nicht so. Das Skript ist hundertmal leistungsfähiger und sie interessieren sich nur für drei Prozent seiner Funktionen.
Das schädlichste Argument ist, dass TypeScript nur eine Obermenge von JS ist. In der Praxis können Sie jedoch nicht anders, als Typescript als eigenständige Sprache zu betrachten, selbst wenn Sie der gottverdammte König der Frontrender sind. Denn hier brauchen wir einen anderen Ansatz - statisch, nicht dynamisch.
Der Hauptvorteil der statischen Typisierung ist die Garantie. Wenn Sie es in einem Modul verwenden, aber nicht in einem anderen, haben Sie nur Zeit und Mühe mit der Beschreibung und Entwicklung von Typen verbracht, aber keine Garantien erhalten.
Vielen scheint TypeScript ein Kompromiss zwischen Typsystemen zwischen JS und Java zu sein. Er ist kein Kompromiss, sein Typensystem ist einfach etwas Besonderes.
Hinzu kommt, dass heute jeder zweite Job an der Front Kenntnisse über TS erfordert. Dies führt dazu, dass JS-Entwickler die Funktionen von Typescript oberflächlich untersuchen und damit beginnen, Code darauf zu schreiben, wodurch eine Vielzahl schädlicher Praktiken entstehen. Eine Situation entsteht, wenn sie wirklich keine statische Tippprüfung benötigen, sie ihnen aber auferlegt und sie ruiniert haben. Es muss endlich erkannt werden, dass sich Entwicklungsansätze mit dynamischer und statischer Typisierung widersprechen, dies sind keine Dinge, die gemischt werden können.
Aus meiner Sicht ist JavaScript ein sehr gutes Werkzeug, um Code zu schreiben, der das Problem löst, ohne unnötige Abstraktionen hervorzuheben. Der ungeheuerlichste Fall ist das Muster der Eisfabrik. Sie können dieser Instanz Ihre Instanzen zuführen und sie werden mit Laufzeitimmunität abgedeckt. Wenn ich mein Objekt mit dieser Factory verarbeite, erhalte ich dasselbe, aber wenn ich versuche, den Wert einer der Eigenschaften zu ändern, wird eine Ausnahme angezeigt. Nur WAT?!?
Das Muster entstand, weil die Fronten irgendwo über coole Unveränderlichkeit lasen und beschlossen, es in ihre eigene Sprache zu ziehen, die in keiner Weise für Immunität gedacht war. In Typescript kann ich dieselbe Factory erstellen, jedoch mit einem Verbot von Mutationen zur Kompilierungszeit und ohne Ausnahmen.
Dies ist jedoch nicht erforderlich, da es sich um eine reine funktionale Programmierung handelt. Nehmen Sie F #, Haskell, OCaml, ich sage es, ReasonML - dort sind Mutationen sofort verboten. Ich befürchte jedoch, dass wenn Sie einer funktionalen Sprache das Front-End geben, diese sofort modernisiert wird und das Verhalten wie JS aussieht.
Weil die Wahl der Eingabe ein Pfad ohne Rückkehr ist. Alle Kompromisslösungen geben nur die Illusion eines Kompromisses. Sie stellen entweder Typen in den Vordergrund oder nicht. Ich weiß nicht, wie sich alles entwickeln würde. Lernen Sie C # und JavaScript gleichzeitig und parallel zueinander. Aber jetzt bin ich so an mein Denken gebunden, dass ich die Vorteile des dynamischen Tippens nicht sehe und nicht sehen möchte. Sie sind es, aber außer Sichtweite, und alles, was mir bleibt, ist, ihnen die Augen zu verschließen, was alle mir fremden Manifestationen der Welt betrifft, mit denen ich leben muss. Ich verstehe, dass ich falsch liege, aber ich muss hier und jetzt arbeiten, und es gibt kein Budget zwischen den Polen.
Deshalb möchte ich keine Kompromisse suchen, aber ich spreche direkt. Wenn Sie gerade erst anfangen, die Entwicklung zu lernen, beginnen Sie mit der statischen Eingabe.