ロバート・S・マーティンのオリジナル記事の翻訳に注目してください。
過去数か月にわたって、2つの新しい言語を試しました。 スウィフトとコトリン 。 これら2つの言語には、多くの共通機能があります。 実際、類似性が非常に強いため、これが言語ミキサーの新しいトレンドであるかどうか疑問に思いました。 これが当てはまる場合、 これは暗い道です。
両方の言語には、いくつかの機能的な機能が含まれています。 たとえば、両方にラムダがあります。 全体として、これは良いことです。 関数型プログラミングについて学ぶほど、より良い結果が得られます。 これらの言語は、真に機能的なプログラミング言語とはほど遠いものです。 しかし、この方向のすべてのステップは良いステップです。
問題は、両方の言語が強力な静的型付けに依存していることです。 両方とも、それぞれの言語のすべての穴を塞ぐつもりです。 Swift
の場合、これはObjective-Cと呼ばれるC
とSmalltalk
奇妙なハイブリッドです。 したがって、おそらくタイピングの強調は理解できるでしょう。 Kotlinに関しては、その祖先はすでにかなり強く型付けされたJavaです。
私は静的に型付けされた言語に反対していると思わせたくありません。 私は気にしません。 動的言語と静的言語の両方に特定の利点があります。 そして、私は両方のタイプの使用を楽しんでいます。 私は動的型付けを好むので、時々 Clojure
使用します。 一方、私はおそらくClojure
よりも多くのJava
書いていJava
。 したがって、私はバイタイプと見なすことができます。 私は通りの両側を歩く-私がそう言うかもしれない場合。
Swift
とKotlin
静的型付けについて心配しているわけではありません。 むしろ、静的型付けの深さは気になります。
静的型付けに関してはJava
非常に頑固な言語とは呼びません。 型規則に従うJava
構造を作成できます。 ただし、必要に応じて、必要に応じて、多くの型規則を破ることもできます。 あなたがこれを行うと、言語は少し不満を言い、これに対して適切な障壁を作りますが、閉塞主義者ほどではありません。
一方、 Swift
とKotlin
、タイプルールに関しては完全に頑固になります。 たとえば、 Swift
では、例外をスローする関数を宣言する場合、この関数のすべての呼び出しは、呼び出しツリーの開始まで 、 do-try
またはtry!
でラップする必要がありますtry!
、またはtry?
。 この言語では、コールツリー全体をスローせずに、トップレベルまで例外を静かにスローする方法はありません。 （ジャスティンと私がこれをどのように扱っているかは、 モバイルアプリケーションのケーススタディビデオで確認できます）
おそらくあなたはこれが良いと思います。 おそらく、誤った例外が原因でシステムに多くのエラーが発生したと思われます。 伴わない例外は、ステップごとに、呼び出しスタックを上って、危険でエラーが発生しやすいと考えるかもしれません。 そして、もちろん、あなたは正しいでしょう。 宣言されていない管理されていない例外は非常に危険です。
そして今、質問。 誰がこれらのリスクをすべて解決すべきですか？ 言語？ それともプログラマーの仕事ですか？
Kotlin
、このクラスまたは関数をopen
キーワードでマークするまで、クラスから継承したり、関数をオーバーライドしたりすることはできません。 関数がoverride
マークされていない場合、関数をオーバーライドすることもできません。 クラスを継承用にオープンとして宣言しない場合、言語はそのようなクラスから継承することを許可しません。
おそらくあなたはこれが良いと思います。 制限なく成長できる継承階層は、エラーとリスクの原因であると考えるかもしれません。 おそらく、プログラマーにクラスを継承用に明示的に宣言することを強制することで、エラーのクラス全体を排除できると思うかもしれません。 そして、あなたは正しいかもしれません。 継承は危険なものです。 派生クラスの関数をオーバーライドすると、何らかの問題が発生する場合があります。
そして今、質問。 誰がこれらのリスクをすべて解決すべきですか 言語？ それともプログラマーの仕事ですか？
Swift
とKotlin
両方の言語には、 null許容型の概念が含まれています 。 変数にnull
が含まれる可能性があるという事実は、この変数の型の一部になります。 String
型の変数にnull
含めることはできません;特定の文字列のみを含めることができます。 一方、 String
型の変数は？ null許容型であり、 null
含む場合がありnull
。
言語の規則では、 null
変数を使用する場合、最初にこの変数のnull
チェックする必要があると主張していnull
。 s
がString?
場合はどうString?
var l = s.length
はコンパイルされません。 代わりに、 var l = s?.length ?: 0
またはvar l = if (s != null) s.length else 0
。
おそらくあなたはこれが良いと思います。 あなたの人生でかなりの数のNPEを見たことがあるかもしれません。 おそらく、テストされていないnull`
がソフトウェアクラッシュで数十億ドルを引き起こしていることを、疑う余地なく知っています。 （実際、 Kotlin
ドキュメントではNPEを「Billion Dollar Bug」と呼んでいます）。 そしてもちろんあなたは正しい。 制御不能なnull`
至る所にあることは非常に危険です。
そして今、質問。 誰がこれらすべてのnull`
を解決すべきですか？ 言語？ それともプログラマーの仕事ですか？
これらの言語は、オランダの小さな男の子が指でダムの穴を塞ぐのに似ています。 新しいエラーが発生するたびに、そのようなエラーを防ぐために新しい関数が言語に追加されます。 したがって、これらの言語は、ダムの穴にますます多くの指を蓄積します。 問題は、指とつま先が最後に終わるということです。
しかし、指と足の指が終わるまで、数十のキーワード、数百の制限、しなやかな構文、法の本のように読めるリファレンスガイドを含む言語を作成します。 実際、これらの言語の専門家になるには、言語弁護士 （ C++
時代に発明された用語）にならなければなりません。
これは間違った方法です！
言語機能で欠陥を修正しようとしている理由を自問してください。 答えは明白なはずです。 これらの欠陥は頻繁に発生するため、これらの欠陥を修正しようとしています。
これらの欠陥が頻繁に発生する理由を考えてみてください。 もし私たちの言語が彼らの邪魔をしないと答えたら、私はあなたの仕事をやめて、二度とプログラマーになることを考えないことを強く勧めます。 欠陥は私たちの言語では決して間違いではないからです。 欠陥はプログラマの間違いです。 言語ではなく、欠陥を作成するのはプログラマーです。
そして、プログラマーは欠陥を防ぐために何をすべきでしょうか？ 私はあなたをなぞなぞにします。 ここにいくつかのヒントがあります。 これは動詞です。 文字「T」で始まります。 はい わかった。 テスト！
システムが予期しないnull
値を返さないようにテストを記述します。 システムがすべての入力でnull
を処理するようにテストを記述します。 スローできるすべての例外がどこかで処理されるようにテストを作成します 。
これらの言語がこれらの機能をすべて使用するのはなぜですか？ プログラマーはコードをテストしないためです。 また、プログラマーはコードをテストしないため、継承するすべてのクラスの前に単語をopen
する言語が用意されています。 これで、コールツリー全体のすべての関数をtry!
ブロックにラップする言語ができましたtry!
。 現在、言語は非常に制限されており、コーディングが開始される前にシステム全体を事前に設計する必要があるように事前条件付けされています。
例を考えてみましょう。 クラスが継承のために開いているかどうかを知るにはどうすればよいですか？ コールツリーのどこかで誰かが例外をスローする可能性があることをどのようにして知ることができますか？ コールツリーで誰かが本当にnull
を返す必要があることが最終的にわかったときに、どのくらいのコードを変更する必要がありnull
か？
これらの言語によって課されたこれらの制限はすべて、プログラマがシステムを書く前に完全な知識を持っていることを示唆しています。 どのクラスが継承のために開かれるべきで、どのクラスが開かれないべきかを知っていると仮定します。 彼らは、どの呼び出しが例外をスローし、どの呼び出しが例外をスローしないかを知っていると仮定します。 どの関数がnull
を返し、どの関数がnull
を返さないかを知っていると仮定します。
そして、これらすべてのために、あなたが間違っているときに彼らがあなたを罰すると信じる理由があります。 try!
追加することで、戻って大量のコードを変更できますtry!
または?:
またはコールツリー全体でopen
ます。
そして、この罰をどのように回避しますか？ 2つの方法があります。 動作するものと動作しないもの。 うまくいかないのは、コードを書く前にすべてを設計することです。 そして罰を逃れる者はすべての予防措置を再定義しなければならない。
そして、すべてのクラスとすべての関数が継承のために開いていると宣言します。 例外を使用することはありません。 そして、あなたは多くのキャラクターを使うことに慣れます!
null
チェックを無効にし、NPEがシステムで成功できるようにします。
チェルノブイリ原子力発電所はなぜ火災を起こし、溶け、小さな都市を破壊し、大きな領土を生活に適さないままにしたのですか？ 彼らはすべての注意を再定義しました 。 そのため、大災害を防ぐために安全性に頼る必要はありません。 代わりに、使用する言語に関係なく、多くのテストの作成に慣れる方が良いでしょう！