友人と一緒に学校に行って、開発者になることだけを夢見ていたとき、私たちは一緒に何かを作る方法を考えました-ゲームまたは非常に有用なプログラム。
私はプロとC＃を学び始めました、それはJavaScriptです。 私たちは高校を卒業し、大学で勉強し、軍隊に勤め、仕事に就きました。 私たちはあちこちで産業の発展に悩まされていましたが、二人ともそれに飽きたら、どこから始めたのかを思い出しました。
すでにベテランの開発者を集めて、私たちはついに自分たちのプロジェクト、つまり二次元のビデオゲームを作ることに決めました。 友人は前線がきれいで、私はフルスタックだったので、ブラウザは私たちにとって明らかなプラットフォームになりました。 私はTypeScriptでのみフロントを開発していましたが、問題はないと考えました。TSはJavaScriptのスーパーセットにすぎません。 それを取り、すべてがスムーズに行きます。 どんなに。 私たちが仕事について議論し始めたとき、私たちはお互いを誤解する驚くべき深byに直面しました。
だから私はゲームを作成するタスクを見ました。 私はそのようなものです。ええ、「ゲーム」のタイプ、「在庫」のタイプ、「もの」のタイプ、「地図」のタイプ、「場所」のタイプがあります。 それらがどのように連携し、説明し、プロジェクトを組み立て、すべてが機能するかを大まかに想像できます。 コンパイラは私をチェックしました、私はすべてを正しくしました。 次に、これらの型を使用するコードの記述を開始します。 それらがあるという事実のために、それは私にとってはるかに簡単です。 IDEは私に通知し、エラーをチェックします。 プロジェクトが予定されている場合-おそらく動作しています。 型の説明に多くの時間を費やし、それは良かったです。 これが私のアプローチです。
私の友人は反対のことをしたかった-すぐにコードを書き、タイプを記述しないでください。 彼は問題をタイプファミリーとして定義する準備ができていませんでした。 私はその上に構築したくありませんでした;タスクをクラス、タイプ、レコード、またはそのような何かのセットとして見ませんでした。 それは私には考えられないように思えた。 私たち二人とも多くの点で正しかったのです。私たち一人一人の正しさだけが他者を排除しました。
真剣に、私たちは何時間も話しましたが、それぞれが異なる言語であるかのように、彼自身のことを話しました。 そして、あなたは私たちの脳が柔軟でないことを推測することはできません。 ほんの一年前、私は痛みを感じることなくオブジェクト指向から機能的な世界へ、そしてその逆に移行しました。 さらに、JSの学習に多くの時間を費やし、彼はいくつかの静的に型付けされた言語を学習していました。
しかし、開発者にとって最初の「戦闘」技術となったこの技術は、彼らを非常に強力に定義しているため、経験豊富な2人の成人が互いに耳を傾ける用意ができていません。 開発を研究してきた長年にわたって、私たちのビジョンはあまりにも異なって形成され、問題を解決するアプローチはまったく連動しませんでした。
その結果、私たちは互いに協力するという考えを捨てました。 問題は私たち2人だけにあるとすぐに思い浮かびます。 たぶん、しかし、私は業界の他の人々とこれを見ました。
静的タイピングと動的タイピングには、根本的に相容れない違いがあります
私のコードは、「これをどのように使用するか」という質問に答え、動的型付けに慣れている開発者向けのコードとして、「どのように機能するか」を示します。 両方のアプローチには生命権があり、両方のツールがありますが、最前線にいるのは1つだけです。
静的は、長年にわたって何百人もの開発者を行ってきた大規模なプロジェクトに適しています。また、書き込み専用のコードが頻繁に必要なタスクに適した小規模なチームには動的です。 ダイナミックを使用すると、開発の開始時に時間と労力を節約し、終了時に静的を節約できます。
型を最前線に置くというアイデアは、開発者に対する私の考えに深刻な影響を与えました。
旅の始めにC＃を選択して、今私が苦しんでいる私の世界観に静的な典型を打ち付けました。 問題を見つけたので、その解決策を一連のタイプと相互作用の原則として提示しようとします。 モジュールを開発するとき、最初に行うことは、そのモジュールが動作するタイプとその環境と相互作用するタイプを判別することです。 以前にどのように問題解決に取り組んだかさえ覚えていません。
すべてのJavaプログラミングトレーニングは、型の設計と使用のトレーニングです。 .NET CLR-C＃ランタイム-型上および型用に構築されています。 静的型付けは、オブジェクト指向プログラミングの設計の中心にあります（こんにちは、JSのクラス、私はあなたが必要ないと決めました）。 ほとんどのOOPパターンの標準的な実装には、動的に型付けされた言語では完全に無意味なInterfaceが豊富です。
パターン自体は言語を超えたものですが、動的に型付けされた言語で「状態」パターンが必要な理由を誰かに教えてもらえますか？ ビルダーはどうですか？ これらのパターンは開発に関するものではなく、タイプに関するものです。 タイプとOOPは密接にリンクされています。
タイプに基づいてビジネスロジックを構築することはできませんが、開発プロセスではそれらについて何も知りません。 これが、想像を絶する数の単体テストでコードをカバーするフロントエンドベンダーが存在する理由です。このテストでは、型エラーがないかどうかコードベースをチェックするだけです。
カバレッジによるセキュリティは幻想であることを、私たちは皆よく知っています。 テストは手書きで書かれており、定義上、言語に組み込まれている型チェックシステムよりも信頼性が低くなります。
これは、動的に型付けされた言語が不要であることを意味するものではありません（実際、これらの言語は不要であると本当に思っています）。 これは、それらを使用する場合、OOPを支配的なパラダイムとして放棄する必要があることを意味します。 これらのデータとそれらの操作のすべては、静的チェックを持つ人向けです。
私が扱った開発者は、静的型付けの存在が開発へのアプローチを変えるとは思わず、型チェックを追加して動的言語と同じコードを記述します。 これは根本的に間違っていると思います。 そして、これは最新のフロントエンドの場合に正確に最も顕著です。
前線を批判することはタブーの主題であることを知っています。 かつて、私の友人と私はツイッターでみんなを荒らしているAIを取得し始め、ブレンダン・アイクはそれをたるんだ。 真剣に、javascriptの作成者はコメントで私たちのニューラルネットワークと戦いました。
いくつかの未知の理由で、これらの人たちは彼らのビジョンが深刻なギャップを含む世界に生きる準備ができていません。 したがって、私は間違いなく型付けされたプロジェクトに突入し、自分の注文をそこに入れた人だけを批判します。
私たちは小さな世界に住んでいましたが、TypeScriptは私たちを押してくれました
そのため、型が原因で誤って使用できないコードを書いています。 プロジェクトでは、他の人も型を使用することを期待しています。 その後、私のコードは意図したとおりに動作します。 そして、私は故意にこのコードの誤用のすべてのケースをカバーしているわけではありません（タイピングはこれを除外するからです）。 しかし、JSのニックネームがプロジェクトに入り、このタイプの私のニックネームを取り込んで、それをラップし、それを誤って使用し始めると、微妙なバグにつながります。
JavaScript開発者は、Typescriptは依然として同じJSであると確信していますが、必要に応じて静的型チェックを追加できる場合もあります。 そうではありません。 このスクリプトは100倍強力であり、その機能の3％にのみ関心があります。
最も有害な議論は、TypeScriptはJSのスーパーセットにすぎないということです。 しかし実際には、たとえあなたがフロントレンダーのひどい王様であったとしても、Typescriptを独立した言語と見なさざるを得ません。 ここでは、動的ではなく静的な異なるアプローチが必要だからです。
静的型付けの主な利点は保証です。 あるモジュールで使用し、別のモジュールでは使用しない場合、型の記述と開発に時間と労力を費やしただけで、保証はありません。
TypeScriptは、JSとJavaの間の型システム間の妥協であるように思われます。 彼は妥協ではなく、彼の型システムは特別なものです。
今日、最前線での2番目の仕事にはTSの知識が必要であるという事実によって、すべてが複雑になっています。 これは、JS開発者がTypescriptの機能を表面的に研究し、それに基づいてコードを書き始め、膨大な数の有害な慣行を作成するという事実につながります。 静的な型チェックを本当に必要としない状況が発生しますが、それを課して台無しにしました。 最後に、動的型付けと静的型付けを使用した開発アプローチは互いに矛盾することを認識しておく必要があります。これらは混合できるものではありません。
JavaScriptは、私が見ているように、不必要な抽象化を強調せずに問題を解決するコードを記述するための非常に優れたツールです。 その中で最も悪質なケースは、Ice factoryパターンです。 このインスタンスにインスタンスをフィードすることができ、ランタイムイミュニティでそれらをカバーします。 このファクトリを使用してオブジェクトを処理すると、同じ結果が得られますが、いずれかのプロパティの値を変更しようとすると、例外が発生します。 ただWAT？！？
前線がどこかでクールな免疫について読んでいて、それを彼ら自身の言語にドラッグすることに決めたので、パターンは起こりました、それは免疫を決して意図しませんでした。 Typescriptでは、同じファクトリーを作成できますが、コンパイル時間に例外があり、例外はありません。
一方、純粋な関数型プログラミングがあるため、これは必要ありません。 F＃、Haskell、OCaml、ReasonMLを使用します-箱から出して突然変異は禁止されています。 しかし、フロントエンドを関数型言語に提供すると、すぐにそれが近代化され、動作がJSのように見えるようになることを恐れています。
入力の選択はリターンのないパスだからです。 すべての妥協ソリューションは、妥協の錯覚のみを与えます。 タイプを最前線に置くかどうか。 すべてがどうなるかはわかりませんが、C＃とJavaScriptを同時に並行して学習し始めます。 しかし今では、動的型付けの利点を見ない、また見たくないという考えに釘付けになっています。 彼らはそうですが、私の目からは見えません。私に残されているのは、私と一緒に生きなければならない私にとって異質な世界の兆候について、彼らに目をつぶることです。 私は間違っていることを理解していますが、今ここで働く必要があり、極間を急ぐ予算はありません。
したがって、私は妥協を求めたくありませんが、私はそれを率直に言っています。 開発を学び始めたばかりの場合は、静的型付けから始めてください。